MMU issues with AM335X and 14.05

Martin Stein martin.stein at ...1...
Sun Aug 17 21:16:51 CEST 2014

Hi Bob,
Looks like there's a problem with the name spaces. Instead of being
comprised by 'Arm', 'Genode' should be a top-level name space as well as
'Kernel'. I think it would be a good idea to investigate why the 'Arm'
prefix is active at all at 'double_list.h:95'.


On 17.08.2014 18:57, Bob Stewart wrote:
> Hi Martin,
>     Been out-of-town for the past few days.
> I understand the changes due to issue 1199 and I did create the core
> library make file (in base-hw/lib/mk/platform_bbb) for the platform
> I'm working with before I left. Everything built ok until it got to
> /cpu_session_component.c/ in the core library build section where
> multiple errors occurred. The following error would indicate I'm
> missing something fundamental:
> In file included from
> /Work/Genode/genode-14.05/repos/base-hw/src/core/kernel/scheduler.h:19:0,
>                  from
> /Work/Genode/genode-14.05/repos/base-hw/src/core/kernel/processor.h:21,
>                  from
> /Work/Genode/genode-14.05/repos/base-hw/src/core/kernel/thread.h:21,
>                  from
> /Work/Genode/genode-14.05/repos/base-hw/src/core/include/platform_thread.h:29,
>                  from
> /Work/Genode/genode-14.05/repos/base/src/core/include/cpu_session_component.h:27,
>                  from
> /Work/Genode/genode-14.05/repos/base/src/core/
> /Work/Genode/genode-14.05/repos/base-hw/src/core/kernel/double_list.h:
> In member function ???void
> Arm::Kernel::Double_list<T>::insert_tail(Arm::Kernel::Double_list<T>::Item*)???:
> /Work/Genode/genode-14.05/repos/base-hw/src/core/kernel/double_list.h:95:4:
> error: ???printf??? is not a member of ???Arm::Genode???
> Regarding the page fault in the ROM fs  initialization, I did not
> isolate the route cause -- it appeared to be getting a low address of
> 0x1000 and try to create a translation table entry with that. I
> thought I saw some changes in the ROM area in the pull, so I was going
> to get a clean build and then try again.
>     Bob
> On 08/13/2014 05:12 AM, Martin Stein wrote:
>> Hey Bob,
>> The changes you're talking about originate from this issue:
>> Core now consists
>> of a generic 'base-hw/src/core/' 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 '' and
>> '' 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 file now appear in a
>>> repos//base-hw/lib/mk/ directory as 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 (
>>>>> recently that the shared-bit should be set only when using SMP. The
>>>>> related changes are in the current state of our master branch
>>>>> ( 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/' 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/' right before '_fault.submit()'.
>>>>> Cheers
>>>>> Martin
>>>>> ------------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> genode-main mailing list
>>>>> genode-main at
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> genode-main mailing list
>>> genode-main at
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> genode-main mailing list
>> genode-main at
> ------------------------------------------------------------------------------
> _______________________________________________
> genode-main mailing list
> genode-main at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list