"Core" thread doesn't become active in kernel initialization

[Bob Stewart]

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
>