Base-hw kernel GIC issue with a Cortex--A7 processor.

[Stefan Kalkowski]

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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main

-- 
Stefan Kalkowski
Genode Labs

https://github.com/skalk · http://genode.org/