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
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main
