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

Bob Stewart robjsstewart at ...9...
Mon Oct 16 15:18:58 CEST 2017

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 
> 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 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?

> 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

More information about the users mailing list