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