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

Bob Stewart robjsstewart at ...9...
Thu Oct 19 13:50:55 CEST 2017

Hi Stefan,
Thanks for looking at this.

I've been using that TRM in my efforts and using the 0x1000 and 0x2000 for the distributor and the cpu interface registers. I know they are correct and my base is correct as I can md in u-boot and see the non-zero initialized register values at the locations indicated in the ARM documentation.

I'm now back looking at the placement new operator functioning as my debugging leads me to the Pic constructor call in that operator as the location of the failure. Strangely, creating an instance of the Pic class locally works the goodness of time I will figure it out!


Get Outlook for Android<>

From: Stefan Kalkowski <stefan.kalkowski at ...1...>
Sent: Thursday, October 19, 2017 11:30:23 AM
To: genode-main at
Subject: Re: Base-hw kernel GIC issue with a Cortex--A7 processor.

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

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.


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
> 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,!
>> _______________________________________________
>> genode-main mailing list
>> genode-main at
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites,!
> _______________________________________________
> genode-main mailing list
> genode-main at

Stefan Kalkowski
Genode Labs ยท

Check out the vibrant tech community on one of the world's most
engaging tech sites,!
genode-main mailing list
genode-main at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list