MMU issues with AM335X and 14.05
Bob Stewart
robjsstewart at ...196...
Mon Aug 18 00:56:58 CEST 2014
Oops, looked like I stomped on the closing brace in the Namespace Arm
declaration in .../core/processor_driver/arm.h during a merge. Not sure
why the compiler didn't catch that, but the core library now builds.
I've one issue with an application module which I'll fix tomorrow then
get to test the kernel start up again.
Thanks,
Bob
On 08/17/2014 04:51 PM, Bob Stewart wrote:
> Yes, Martin, I did a make clean after the pull. Still looking as to
> why the Arm namespace shows up above Genode. Let you when I find it.
>
> Bob
>
> On 08/17/2014 03:27 PM, Martin Stein wrote:
>> Btw. hope you have done 'make clean' after your Makefile changes.
>> Otherwise this could cause the build system to act strange.
>>
>> On 17.08.2014 21:16, Martin Stein wrote:
>>> 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'.
>>>
>>> Martin
>>>
>>> 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/cpu_session_component.cc:21:
>>>> /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:
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>>
>>> _______________________________________________
>>> 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/20140817/56c500e9/attachment.html>
More information about the users
mailing list