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:
- 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");
Output produced: Starting kernel ...
void init_kernel_mp(): Starting kernel-6 Sctlr c5387d kernel initialized void init_kernel_mp(): Starting kernel-7
Commenting out the "PDBG("Starting kernel-7");" line results in the
ouput: Starting kernel ...
void init_kernel_mp(): Starting kernel-6
- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main