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 >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/genode-main >>> >> > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > genode-main mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/genode-main
------------------------------------------------------------------------------
_______________________________________________ genode-main mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/genode-main
