"Core" thread doesn't become active in kernel initialization
Bob Stewart
robjsstewart at ...196...
Tue Jul 7 15:32:30 CEST 2015
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 one
from the panda directory.
I arrived at this conclusion when I took Christian's suggestion to
turn off compiler optimization. After a make clean, I ran "make
CC_OLEVEL=-O0 run/printf" which surprisingly failed in
platform_support.cc as the following build output shows
/ASSEMBLE spec/arm_v7/mode_transition.o//
// COMPILE spec/rico/platform_support.o//
//In file included from
/Work/Genode/genode-15.05/repos/base-hw/src/core/spec/rico/platform_support.cc:16:0://
///Work/Genode/genode-15.05/repos/base-hw/src/core/include/spec/rico/board.h:
In static member function ‘static void
Genode::Board::Pl310::trustzone_hypervisor_call(Genode::addr_t,
Genode::addr_t)’://
///Work/Genode/genode-15.05/repos/base-hw/src/core/include/spec/rico/board.h:44:4:
error: fp cannot be used in asm here//
// }//
// ^//
//make[3]: *** [spec/rico/platform_support.o] Error 1/
Just to see if I could get through a build I commented out the code in
"trustzone_hypervisor_call". The link for core failed with:
/Program core/core//
// COMPILE kernel/test.o//
// LINK core//
///Work/Genode/Builds/15.05/rico/var/libcache/core/core.lib.a(thread.o):
In function `Kernel::Core_thread::Core_thread()'://
///Work/Genode/genode-15.05/repos/base-hw/src/core/kernel/thread.cc:799:
undefined reference to `Kernel::Cpu_priority::max'//
///Work/Genode/Builds/15.05/rico/var/libcache/core/core.lib.a(platform_thread.o):
In function `Genode::Platform_thread::Platform_thread(char const*,
Genode::Native_utcb*)'://
///Work/Genode/genode-15.05/repos/base-hw/src/core/platform_thread.cc:103:
undefined reference to `Kernel::Cpu_priority::max'//
//collect2: error: ld returned 1 exit status//
//make[3]: *** [core] Error 1//
//make[2]: *** [core.prg] Error 2//
//make[1]: *** [gen_deps_and_build_targets] Error 2//
//make[1]: Leaving directory `/Work/Genode/Builds/15.05/rico'/
At which point I abandoned trying to build with that O flag setting.
I kept the code commented out in "trustzone_hypervisor_call" did a clean
and built the printf test without the the O flag setting. The uImage ran
correctly on the target hardware:
Starting kernel ...
void init_kernel_mp(): Starting kernel-6
SP = 8108942c
Sctlr c5387d
kernel initialized
Genode 15.05-77-g01f22d4 <local changes>
int main(): --- create local services ---
int main(): --- start init ---
int main(): transferred 506 MB to init
int main(): --- init created, waiting for exit condition ---
[init] Could not open ROM session for module "ld.lib.so"
[init -> test-printf] -1 = -1 = -1
[init] virtual void Genode::Child_policy::exit(int): child "test-printf"
exited with exit value 0
I'm not planning to use trustzone support currently but I'll take a look
at the assembly code and read the trustzone support in the Cortex-A9
TRM. The AM437x is at revision R2P10 of the Cortex-A9.
Does the Panda board come up in Secure mode?
Thanks,
Bob
On 07/06/2015 08:22 AM, Bob Stewart wrote:
> 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 snippet (around line 142 in
> base-hw/src/core/kernel/kernel.cc):
> /* enable timer interrupt */
> unsigned const cpu = Cpu::executing_id();
> pic()->unmask(Timer::interrupt_id(cpu), cpu);
> PDBG("Starting kernel-6");
> /* do further initialization only as primary CPU */
> if (Cpu::primary_id() != cpu) { return; }
> init_kernel_mp_primary();
> PDBG("Starting kernel-7");
>
> 2. Output produced:
> Starting kernel ...
>
> void init_kernel_mp(): Starting kernel-6
> Sctlr c5387d
> kernel initialized
> void init_kernel_mp(): Starting kernel-7
>
> 3. Commenting out the "PDBG("Starting kernel-7");" line results in the
> ouput:
> Starting kernel ...
>
> void init_kernel_mp(): Starting kernel-6
>
> 4. Additionally commenting out the "PDBG("Starting kernel-6");" line
> results in
> Starting kernel ...
>
> My theory is that that this behaviour is TLB entry attribute related,
> wherein an incorrect entry is encountered on an MMU table walk.
>
> I'm going through the Cortex-A9 and Arm_v7 architecture documentation
> to try to understand what's going on. According to section 1.5 in the
> Cortex-A9 MPCore TRM, related to Private Memory for an A9 core, the
> global and peripheral control registers must be accessed through
> memory mapped transfers to the Cortex-A9 MPCore private memory region.
> The memory regions used for these registers must be marked as Device
> or Strongly-ordered.The translation table code in
> short_translation_table.h has no code to allow a page table entry to
> be setup with either of these attributes. What is it I am missing?
>
> Thanks,
> Bob
>
> On 07/03/2015 09:29 AM, Martin Stein wrote:
>> 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 the console.
>> Nice! :)
>>
>>> Now I need to study the guard code
>>> to see what is going on.
>> Regarding the CXA guards: The reason why we have introduced the
>> unmanaged_singleton was that we already had troubles with the atomic
>> operations in the cmpxchg that is used by the guards. It was on the
>> Raspberry PI where atomic ops do not work until the caches are enabled.
>> Thus we replaced every static variable in an early called function by an
>> unmanaged_singleton. What made me rule out this explanation in your case
>> is that the problem definitely occurs after the MMU and thereby the
>> caches have been enabled (Cpu::init_virt_kernel in init_kernel_mp).
>>
>> Did you change something regarding this, e.g. switched off caches in
>> [1]? Can you please post the output of [2]. It may also help if you
>> enable the hw_info test by doing [3] and post the output. If the hw_info
>> test gets stuck at any point before it prints "--- End ---" you can
>> uncomment the respective register read in [4] (some registers are not
>> accessible on all platforms).
>>
>> Another idea: The atomic ops in ARM are realized through a so-called
>> "exclusive" state that a CPU can set. This state can be cleared via
>> assembly op "clrex". Maybe your exclusive state is erroneously set when
>> entering the kernel and clearing it right before [5] solves the problem.
>>
>> Cheers,
>> Martin
>>
>> [1]
>> Arm::Sctlr::init_common in
>> base-hw/src/core/include/spec/arm/cpu_support.h
>>
>> [2]
>> PINF("Sctlr %x", Genode::Arm::Sctlr::read());
>> during init_kernel_mp_primary
>>
>> [3]
>> cp base-hw/lib/mk/platform_panda/test-hw_info.mk
>> base-hw/lib/mk/platform_am437x/
>>
>> [4] base-hw/src/test/hw_info/spec/arm_v7/info.cc
>>
>> [5]
>> "ldr r0, =_bss_start" in
>> base-hw/src/core/spec/arm/kernel/crt0.s
>>
>> ------------------------------------------------------------------------------
>>
>> Don't Limit Your Business. Reach for the Cloud.
>> GigeNET's Cloud Solutions provide you with the tools and support that
>> you need to offload your IT needs and focus on growing your business.
>> Configured For All Businesses. Start Your Cloud Today.
>> https://www.gigenetcloud.com/
>> _______________________________________________
>> genode-main mailing list
>> genode-main at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/genode-main
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20150707/dee8dc61/attachment.html>
More information about the users
mailing list