other Auxiliary Control settings are desirable for
it.
Bob
Sent from my android device.
-Original Message-
From: Martin Stein
To: Genode OS Framework Mailing List
Sent: Tue, 07 Jul 2015 10:06 AM
Subject: Re: "Core" thread doesn't become active in kernel initialization
Hi
Thanks for the help, Martin. I'm digging through the L2 cache controller
section in the TRM now.
Bob
Sent from my android device.
-Original Message-
From: Martin Stein
To: Genode OS Framework Mailing List
Sent: Tue, 07 Jul 2015 10:06 AM
Subject: Re: "Core" thread
Hi Bob,
On 07.07.2015 15:32, Bob Stewart wrote:
> Hi Martin,
> By pure luck I got the kernel to initialize and the printf test to
> run to completion.
Cool that you managed to find the problem :)
> The issue appears to be with the member function
> "trustzone_hypervisor_call" in the PL31
Hi Martin,
By pure luck I got the kernel to initialize and the printf test to
run to completion.
The issue appears to be with the member function
"trustzone_hypervisor_call" in the PL310 struct which is in the board.h
file for the platform. My board.h file is just a direct copy of the
Thanks Christian. I'll use that.
Bob
Sent from my android device.
-Original Message-
From: Christian Helmuth
To: genode-main@lists.sourceforge.net
Sent: Mon, 06 Jul 2015 8:44 AM
Subject: Re: "Core" thread doesn't become active in kernel initialization
Hi Bob,
j
Hi Bob,
just a tiny side note from me: When debugging issues, which seem to
interfere with the binary layout, I add log messages like follows
/* global vars to prevent optimization */
int dbg_on = true;
int dbg_off = false;
if (dbg_off) PDBG("message 1");
if (dbg_on) PDBG("message 2"
Hi Martin,
I've made no changes to cpu_support.h, it's from main in 15.05. You'll
see below that the C and M bits are correctly set in the SCTRL register.
I'm currently seeing inconsistent behaviour depending on where I have
print statements in the kernel initialization code:
1. kernel.cc code
Martin,
I believe this issue is really related to translation table entry
attributes. After I cleaned up some of my printf's I got the exception
Stefan suggested I include in the lock(0 method. The DFSR and IFSR both
indicate an MMU fault:
/Starting kernel ... //
//void init_kernel_m
Hi Bob,
On 03.07.2015 13:52, Bob Stewart wrote:
> Regarding possible issues with CXA guards, I did change the constructor
> of Core_thread to be public and applied your [4] modification. That did
> allow allow the kernel initialization to complete and I got the "kernel
> initialized" message on
Thanks for the quick reply Martin.
Regarding possible issues with CXA guards, I did change the constructor
of Core_thread to be public and applied your [4] modification. That did
allow allow the kernel initialization to complete and I got the "kernel
initialized" message on the console. Now I n
Hi Bob,
On 02.07.2015 21:36, Bob Stewart wrote:
> (a)Your PINF in [1] yields a run-time error -- "SP format string argument>p". (Not sure why that would be.)
That is indeed strange. I can't reproduce this output with the current
master branch and the supported platforms. Instead of the warning c
Thank you for the suggestions, Martin.
Stack corruption does not appear to be the issue:
(a)Your PINF in [1] yields a run-time error -- "SP format string argument>p". (Not sure why that would be.)
(b) Replacing %p with 0x%x and applying the appropriate cast, results in
PINF showing "SP 0x810893f
Thank you for the suggestions, Stefan. I applied your patches. The
__cxa_guard_release appears to be working fine as I get the three debug
lines output. The lock() method you included in the second patch is
never called so an exception is not being thrown. I'll move on to
Martin's suggestions a
Hi Bob,
On 01.07.2015 21:42, Bob Stewart wrote:
> Once the Core_thread singleton is
> created the last printf output that appears is one I inserted after the
> call to to _become_active() in the constructor. A printf inserted into
> the singleton method after the Core_thread creation never show
Hi Bob,
On 07/01/2015 09:42 PM, Bob Stewart wrote:
> Hi,
>
> I'm bringing up Genode (15.05) on an TI AM437x SoC and it is
> failing kernel initialization. The initialization appears go ok until
> the call to init_kernel_mp_primary(). Once the Core_thread singleton is
> created the last pr
15 matches
Mail list logo
