MMU issues with AM335X and 14.05

[Martin Stein]

Hey Bob,

The changes you're talking about originate from this issue:
https://github.com/genodelabs/genode/issues/1199. Core now consists of a
generic 'base-hw/src/core/target.mk' that solely defines the target name
and a dependency to the library 'core'. All the other content that core
is composed of resides in the variant 'core.mk' and 'core.inc'
library-description files within 'base-hw/lib/mk' and its
sub-directories (respectively 'core-*.mk' and 'core-*.inc' for libraries
that are additions to the core library).
At the one hand these changes reduce redundancy and LOC count as
hardware-specifics were split up more fine-grained when transfered into
libraries, at the other hand we unified the scheme of handling
orthogonal specifiers (see for example the core-trustzone* files that
provide optional trustzone support for different platform specifiers).
Apart from that, the commits didn't change that much regarding the
substance of core.
I hope this short insight helps you applying your changes to the current
state. If you have further questions on this don't hesitate to ask.

Regarding the page fault: Does that mean that you were able to fix the
fault?

Cheers
Martin

On 12.08.2014 23:41, Bob Stewart wrote:
> Martin,
>     Have not been able to build with the pull from the master branch.
> Looks like there are changes to base-hw build that I've not seen
> before.   The platform target.mk file now appear in a
> repos//base-hw/lib/mk/ directory as core.mk. Is there documentation on
> the changes? I searched the git repository but couldn't find any.
>
>
> The mmu faulting address was coming from the creation of Rom_modules
> in the ROM fs.
>
> Thanks,
>         Bob
>
> On 08/11/2014 09:03 AM, Bob Stewart wrote:
>>
>> Thanks for the quick reply, Martin.
>>
>> I'll pull the current master branch tomorrow and let you know if it
>> fixes my issue.
>>
>> Thanks for the debugging tip on core faults.
>> My core-only mmio regions are the same as they were in 14.02 and
>> unless the handling of the region has changed I should have the
>> correct translation table entries. My PDBG output from the
>> _mmu_exception method was:
>>
>> /void Kernel::Thread::_mmu_exception(): f_addr 0x1008 f_writes 0x1
>> f_pd 0x813d6004 f_signal 0x0 label core//
>> /
>> Looks like I've a problem with the fault address, so I'll keep
>> digging to see where that is coming from.
>>
>> Thanks,
>>         Bob
>> On 08/11/2014 07:54 AM, Martin Stein wrote:
>>> Hi Bob,
>>>
>>> On 09.08.2014 22:21, Bob Stewart wrote:
>>>> I went back to the 14.05 issues today and found I could get the kernel 
>>>> initialization to complete successfully if I reverted the S bit to 
>>>> "unshared" in the memory attributes in a Section entry create. Prior to 
>>>> 14.05 this bit was set to "unshared" and was presumably changed in 14.05 
>>>> to allow for multiple processors accessing the same memory regions.
>>> We had an issue (https://github.com/genodelabs/genode/issues/1181)
>>> recently that the shared-bit should be set only when using SMP. The
>>> related changes are in the current state of our master branch
>>> (https://github.com/genodelabs/genode/tree/master) but not in version
>>> 14.05. Could you please give it a try?
>>>
>>>> In addition, after completing kernel initialization, core's "main" 
>>>> function is entered, the info message for creating local services shows 
>>>> up, a translation for the top of RAM (0x80000000) is created, then the 
>>>> message "failed to communicate thread event" occurs and init is never 
>>>> called. Any thoughts on why that message is appearing would be 
>>>> appreciated. It appears to be coming from initialization of the root 
>>>> interfaces.
>>> This seems to be a page fault in core. Normally core should never
>>> trigger a page fault because there's no one to handle it. So the kernel
>>> doesn't know who to inform about it and thus prints this message. To
>>> prevent this situation, memory regions statically needed by core
>>> (program image, MMIO regions) get mapped 1:1 in the 'Core_pd'
>>> constructor in 'base-hw/src/core/kernel/kernel.cc' using, among others,
>>> the platform specific method 'Platform::_core_only_mmio_regions'. I
>>> assume that your port misses a region in this function. You can get
>>> further information about the page fault by printing things like
>>> '_fault_addr', '_fault_writes', 'char const * Thread::label()', and
>>> 'unsigned long Thread::ip' in the method 'Thread::_mmu_exception()' in
>>> 'base-hw/src/core/arm/cpu_support.cc' right before '_fault.submit()'.
>>>
>>> Cheers
>>> Martin
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> genode-main mailing list
>>> genode-main at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/genode-main
>>>
>>
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> 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/20140813/d46e3efa/attachment.html>