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

Thu Oct 12 01:33:37 CEST 2017

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.

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.

I will not be able to get back to this until early next week.

Bob

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Martin Stein <martin.stein at ...1...>
Sent: Tuesday, October 10, 2017 8:56:06 AM
To: genode-main at lists.sourceforge.net
Subject: Re: Base-hw kernel GIC issue with a Cortex--A7 processor.

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 at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20171011/5d2c96d0/attachment.html>