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

[Martin Stein]

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?

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())
{ }

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.

Cheers,
Martin

[1] base/include/util/mmio.h