"Core" thread doesn't become active in kernel initialization

[Bob Stewart]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20150703/540d19ef/attachment.html>