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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main