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

[Martin Stein]

Hi Bob,

Am 09.10.2017 um 23:44 schrieb Bob Stewart:
>    Regarding IAR/EOIR register definitions, I too was using version 2.0 of the Architecture document, document number ARM IHI 0048B.b  ID072613.
> What I see on pages 4-135 and 4-138 are tables defining the bit fields as:
> 
> [12:10] CPUID On a multiprocessor implementation, if the write refers to an SGI, this field contai> [9:0] EOIINTID The Interrupt ID value from the corresponding GICC_IAR access.

That's right, as I already said: [9:0] EUOINTID is 10 bits in width - thus Bitfield<0,10>
and [12:10] CPUID is 3 bits in width - thus Bitfield<10, 3>.

> In bootstrap, a board object is created whose initializers declare ram and mmio regions. The constructor is:
> 
> Bootstrap::Platform::Board::Board()
> : early_ram_regions(Memory_region { RAM_0_BASE,
>                                     RAM_0_SIZE}),                 
>   core_mmio(Memory_region { CORTEX_A7_PRIVATE_MEM_BASE,
>   CORTEX_A7_PRIVATE_MEM_SIZE },
>   Memory_region { UART_1_MMIO_BASE, UART_1_MMIO_SIZE },
>   Memory_region { GPT1_BASE, GPT1_SIZE }
>            ) {}
> 
> CORTEX_A7_PRIVATE_MEM_BASE is set at 0x00A00000, three pages in size and in that region the GIC-400 registers start on the, second page; 0x00A01000 for the distributor and 0x00A02000 for the cpu interface
> 
> As a first step in diagnosing the problem I looked in the Allocator outputs from the run script. I expected to see entries in the io_mmio_alloc dump related to the three regions in the above initializer list and none were there. So my question was/is what am I missing in my understanding?

Regarding the allocators Output:

:io_mem_alloc: Allocator 0x910cd334 dump:
Block: [00000000,80106000) size=2098200K avail=2098200K max_avail=2098200K
Block: [80110000,8025b000) size=1324K avail=1324K max_avail=2098200K
Block: [81000000,811a0000) size=1664K avail=1664K max_avail=1610612735
Block: [a0000000,ffffffff) size=1610612735 avail=1610612735 max_avail=161061273

Block [00000000,80106000) contains Block [0x00A00000, 0x00A02fff), doesn't it?
So the GIC-400 is in the io_mem_alloc. However, this has nothing to do with
the core translation table. These allocators are initialized long after the kernel
initialization where your troubles with the PIC occur.

Here is a short illustration of how Genode starts up:

1. [bootstrap] _start in bootstrap/spec/<ARCH>/crt0.s
   - init bss and kernel stack

2. [bootstrap] init bootstrap/init.cc
   - init core regions (e.g. core_mmio and core elf)
   - fill core translation table (e.g. with core_mmio and core elf)
   - enable mmu with core translation table
   - jump to entry of core elf (kernel)

3. [core (kernel)] _start in core/kernel/init.cc
   - init kernel objects of the cpus
   - init kernel object of the first userland thread of core

4. [core (kernel)] kernel in core/kernel/kernel.cc
   - update kernel state
   - schedule userland thread (only first core thread available)

5. [core (userland)] _core_start in core/spec/<ARCH>/crt0.s
   - init core object of the first userland thread of core
   - init stack pointer

6. [core (userland)] _main in startup/_main.cc
   - init C++ runtime and other stuff

7. [core (userland)] main in core/main.cc
   - init core resources (e.g. Platform which creates the
     allocators like _io_mem_alloc and dumps them)
   - init core services
   - start init

The point where the core page table is filled with the core_mmio is in
step 2 (see base-hw/src/bootstrap/platform.cc:172 for debugging) whereas
the allocator dump is in step 7.

Cheers,
Martin