Thank you for the suggestions, Stefan. I applied your patches. The __cxa_guard_release appears to be working fine as I get the three debug lines output. The lock() method you included in the second patch is never called so an exception is not being thrown. I'll move on to Martin's suggestions and read more of the TRM for the 437x.
Thanks, Bob
On 07/02/2015 04:47 AM, Stefan Kalkowski wrote:
Hi Bob,
On 07/01/2015 09:42 PM, Bob Stewart wrote:
Hi,
I'm bringing up Genode (15.05) on an TI AM437x SoC and it isfailing kernel initialization. The initialization appears go ok until the call to init_kernel_mp_primary(). Once the Core_thread singleton is created the last printf output that appears is one I inserted after the call to to _become_active() in the constructor. A printf inserted into the singleton method after the Core_thread creation never shows up on the console. The initialization never completes.
The AM437x is a Cortex-A9MP platform with a single core. It is very similar to the Panda board as far as memory mapping goes.
Any hints on how to debug this situation further would be very helpful.
Hmm, that sounds really strange. The only thing that is done between leaving the "Core_thread" constructor, and landing within the "Core_thread::singleton" function again, is the call of "__cxa_guard_release", which marks the static object as being constructed successfully. Of course, you can add printings there too. You can apply patch [1] to your branch, then compile core, and search for the guard variable of the Core_thread object like this:
genode-arm-nm bin/core | sort | c++filt | grep Core_thread::singleton
Take the address of the guard variable displayed, and replace the address "0xdeadbeef" within the patch with the address of the guard variable you've found. Thereby you can verify whether __cxa_guard_release is still executed successfully.
Maybe the kernel provokes a page-fault (due to some caching issues or whatever)? To detect a kernel page-fault you can use the kernel lock, that has no real use on a single-core system. It is used to synchronize different cores only. Therefore, if you detect that the kernel lock is still locked you know that the kernel was entered although you were in kernel mode just before. The patch [2] uses this knowledge. It extends the kernel lock by printing some exception information, when the kernel enters its lock twice.
Regards Stefan
[1] http://pastebin.com/C7gSVG6e [2] http://pastebin.com/qLkuZr0f
Thanks, Bob Stewart
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