Martin, I believe this issue is really related to translation table entry attributes. After I cleaned up some of my printf's I got the exception Stefan suggested I include in the lock(0 method. The DFSR and IFSR both indicate an MMU fault:
/Starting kernel ... // //// //void init_kernel_mp(): Starting kernel-6 // //SP 0x810893f8 // //kernel initialized // //void init_kernel_mp(): Starting kernel-7 // //An exception was raised during kernel execution! // //DFSR=0x5 IFSR=0x5 DFAR=0x1
/Previously, when bringing up the AM335x on Genode I found that there were issues with that platform and the settings in arm/short_short_translation_table.h. So, I'll first I'll go back through the Tex, B, and C attribute values and set them to exactly what the the Arm_v7 spec says they should and see what happens.
This is a holiday weekend here, so I'll be slow getting back.
Bob
p.s. Just saw your reply to the previous message... I'll go through your 5 steps also.
On 07/03/2015 07:52 AM, Bob Stewart wrote:
Thanks for the quick reply Martin.
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. Now I need to study the guard code to see what is going on.
I'll take a look at Console::vprintf to see if I can find the reason I get that run-time error on the %p format variable.
My additions to thread.cc simply write a passed value to a register pointer which is also a passed argument. But I'll take them out if I can't solve the current issue.
My only method of debugging is via printf. After I'm through with this issue I think I'll take a look at CoreSight and see what's involved in creating a debugger using its trace facilities.
Thanks, Bob
On 07/03/2015 06:06 AM, Martin Stein wrote:
Hi Bob,
On 02.07.2015 21:36, Bob Stewart wrote:
(a)Your PINF in [1] yields a run-time error -- "SP <warning: unsupported format string argument>p". (Not sure why that would be.)
That is indeed strange. I can't reproduce this output with the current master branch and the supported platforms. Instead of the warning case, the switch(cmd.type) statement in [1] should end up in 'case Format_command::PTR'. If you want to dig deeper into that, I would use the _out_string method inside the switch statement to find out what's going on.
(b) Replacing %p with 0x%x and applying the appropriate cast, results in PINF showing "SP 0x810893f0". (c) The kernel_stack$ symbol is set at "81079440 B kernel_stack". (d )KERNEL_STACK_SIZE = 64 * 1024. So the stack pointer is appropriately near the top of the stack, assuming it's growing from top to bottom.
That's right. However, the stack data may still be corrupted by some code that uses a broken pointer. That would be hard to debug. A debugger that supports watchpoints would be helpful but as you likely would have used single stepping in this case, I assume that you don't have such an interface. However, before investigating more into that, I would check whether the return pointers are correct at the very end of Core_thread::Core_thread() respectively __cxa_guard_release by using __builtin_return_address(0).
Your suggestion, [4] failed to compile with the following error output: "//Work/Genode/genode-15.05/repos/base/src/base/include/unmanaged_singleton.h:
In instantiation of ‘T* unmanaged_singleton(ARGS ...) [with T = Kernel::Core_thread; int ALIGNMENT = 4; ARGS = {}]’:// ///Work/Genode/genode-15.05/repos/base-hw/src/core/kernel/thread.cc:805:45:
required from here// ///Work/Genode/genode-15.05/repos/base-hw/src/core/kernel/thread.cc:771:1:
error: ‘Kernel::Core_thread::Core_thread()’ is private//
Oh sorry, I didn't consider that the constructor is private. But after making it public in [2] the problem is solved and the patch works also at runtime.
I'll look into your thought about the cpu_id, once I understand its purpose and use.
This was a misconception of mine. I thought that the almost complete SMP support for Cortex A9 has already made its way to master. But as this is not the case, Cpu::executing_id() always returns 0 independently from any hardware. Additionally, if the CPU ID wouldn't be correct, the stack pointer would be broken as well as the initialization would have chosen the wrong item of the kernel_stack array.
I should also note that the thread.cc I'm using contains two additional methods and associated call case statements I ported from my modified kernel from an AM335x implementation. Those core-based kernel calls are necessary in both the 4371 and 335x to allow writing to control subsystem registers in these platforms. I don't believe these changes have anything to do with the issue, but it is a difference.
As long as they do not introduce additional data members to Kernel::Thread, this should indeed make no difference, especially at that early stage where such methods are not called yet. However, just to be sure, you may also remove these modifications for now.
Cheers, Martin
[1] base/src/base/console/console.cc - void Console::vprintf [2] base-hw/src/core/include/kernel/thread.h - class Kernel::Core_thread
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