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