MMU issues with AM335X and 14.05

Bob Stewart robjsstewart at ...196...
Sun Aug 17 18:57:54 CEST 2014

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 
In member function ???void 
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.


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

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

More information about the users mailing list