MMU issues with AM335X and 14.05

[Bob Stewart]

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
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20140812/8eca35f0/attachment.html>