Hi Bob, I wonder whether your problem has to do with a different memory map of the GIC. When looking at the documentation for Cortex A9 and A7, I could see they differ with respect to the offset of distributor and core-specific interface of the GIC within the cpu local private memory.
Please, introduce a new Hw::Cortex_a7_mmio structure analogue to the already existent Hw::Cortex_a9_mmio and Hw::Cortex_a15_mmio variants. You can find the right values for the A7 specific IRQ_CONTROLLER_DISTR_BASE and IRQ_CONTROLLER_CPU_BASE here (page 180): http://infocenter.arm.com/help/topic/com.arm.doc.ddi0464d/DDI0464D_cortex_a7_mpcore_r0p3_trm.pdf Of course, you'll need to replace the occurrences of Cortex_a9_mmio in your board.h file(s). I hope it will help you. Regards Stefan On 10/16/2017 03:18 PM, Bob Stewart wrote: > Thanks for the reply, Martin. Comments in-line: > > > On 10/12/2017 07:12 AM, Martin Stein wrote: >> Hi Bob, >> >> Am 12.10.2017 um 01:33 schrieb Bob Stewart: >>> A big oops by me Martin on the register declarations. I had forgotten >>> the bitfield format was a position a followed by length type as >>> opposed to start and end bit positions. >> This is why I wrote you an explanation of the Bitfield interface two >> emails ago :-) >> >>> Thanks for defining the steps in start up which I was a bit familiar >>> with through reading code. I only had time today to debug the >>> core_mmio translation table which had the expected physical addresses >>> based on the initialization list for the platform board object. The >>> virtual addresses started at 0xxF0000000. >>> I'll next figure out why a Pic object can be successfully constructed >>> during the bootstrap where the physical addresses for the distributor >>> and the cpu interface are used in the initialization list but the >>> construction appears to fail in kernel init when a singleton version >>> of it is created using virtual addresses in the initialization list. >> You said that you do not even enter the constructor but are you sure >> you don't >> enter the first initializer in the initializer list or have you only >> checked >> whether you enter the constructor body? > It is dying in the Initializers. It never gets to the body of the > constructor. >> >> I assume that there are several initializers like the distributer and >> CPU interface >> MMIO like in our ARM-GIC implementation: >> >> Hw::Pic::Pic() >> : >> >> _distr(Platform::mmio_to_virt(Board::Cpu_mmio::IRQ_CONTROLLER_DISTR_BASE)), >> >> _cpui >> (Platform::mmio_to_virt(Board::Cpu_mmio::IRQ_CONTROLLER_CPU_BASE)), >> _last_iar(Cpu_interface::Iar::Irq_id::bits(spurious_id)), >> _max_irq(_distr.max_irq()) >> { } > I'm using core/spec/arm_gic (and therefore the Hw::Pic in > lib/hw/spec/arm as the base class). So the only difference between this > implementation and the Cortex A9 implementation is what the values are > for IRQ_CONTROLLER_DISTR_BASE and IRQ_CONTROLLER_CPU_BASE. In kernel's > init.cc I created a local object for Pic and used that to pass to the > cpu init method instead of the reference to the unmanaged singleton > object. When I did that the kernel init completed successfully and the > log code was executed and completed with the expected results. This > would indicate that the Pic object is correctly constructed, would it not. >> Then, you could print '_base' in the 'Mmio_plain_access' constructor >> [1] for >> debugging. If you truely do not enter the first initializer your >> problem is most >> likely not related to any PIC IO mappings. I would suggest you to aim >> for the >> exact point where your system gets stuck. > For the first initializer, for the distributor object, base() returns > 0x0. This would indicate that a Pic object was not being constructed > correctly in the placement new operator, which is hard to imagine why. I > will go over my core make files again to see if I've got an incorrect > include path specified or specified an incorrect location for a source > file. Beyond that? > > Bob >> >> Cheers, >> Martin >> >> [1] base/include/util/mmio.h >> >> ------------------------------------------------------------------------------ >> >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> genode-main mailing list >> genode-main@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/genode-main > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > genode-main mailing list > genode-main@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/genode-main -- Stefan Kalkowski Genode Labs https://github.com/skalk · http://genode.org/ ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
