"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