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

[Bob Stewart]

Hi Martin,
   Thanks for the reply.

   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:

[31:13] - Reserved.
[12:10] CPUID For SGIs in a multiprocessor implementation, this field identifies the processor that
requested the interrupt. It returns the number of the CPU interface that made the
request, for example a value of 3 means the request was generated by a write to the
GICD_SGIR on CPU interface 3.
For all other interrupts this field is RAZ.
[9:0] Interrupt ID The interrupt ID.

and,

[31:13] - Reserved.
[12:10] CPUID On a multiprocessor implementation, if the write refers to an SGI, this field contains
the CPUID value from the corresponding GICC_IAR access.
In all other cases this field SBZ.
[9:0] EOIINTID The Interrupt ID value from the corresponding GICC_IAR access.

But regarding my problem, the A7 is different than the A9 in several regards -- No control over the SCU; an L2 cache that is tightly integrated with the L1 cache (meaning you can't control it); and no private timer but two generic timers are the main diferences as far as bringing it up are concerned.

I've modeled the code similar to the Cortex A9 implementation I did for an AM436x TI processor, accounting for the diferences in the A7 I mentioned above. The bootstrap code works fine as you can see from the output logging, and the translation table entries all look correct.

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?

Bob

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

From: Martin Stein <martin.stein at ...1...>
Sent: Monday, October 9, 2017 8:12:50 PM
To: Genode OS Framework Mailing List
Subject: Re: Base-hw kernel GIC issue with a Cortex--A7 processor.

Hi Bob,

Am 08.10.2017 um 22:06 schrieb Bob Stewart:
> Hi,
> I'm bringing up the 17.08 base-hw kernel/core on an NXP IMX6ULL SoC, which uses a Cortex A7 single core processor, and am having issues creating the singleton instance of the GIC after kernel initialization. In short the attempt to create the singleton causing the processor to die!
>
> The PIC code is all existing ARM code, I supply the addresses of the GIC-400 interrupt distributor and its cpu interface from the NXP documentation. Using the u-boot command line I see that the GIC register addresses in memory agree with the documentation. The physical addresses are 0x00A01000 and 0x00A02000 which are translated to virtual addresses 0xF0001000 and 0xF002000.
>
> The core initialization code in ../base-hw/src/core/kernel/init.cc first creates a cpu pool object then creates a cpu object in the pool passing to it the address of the unmanaged singleton object for the PIC.The cpu initialization code would use this object to unmask an interrupt for a timer, if it ever got that far! It appears to die in the execution of the placement new operator in ../base/src/include/base/internal/unmanaged_singleton.h:
>
> template <typename T, typename... ARGS>
> static void call(char * const dst, ARGS &&... args) { new (dst) T(args...); }
>
> (Where T would be Kernel::Pic)
>
> The Pic constructor is never called when the new executes.
>
> I was testing using the log run script which does not need a timer to execute the test, so I removed the creation of the Pic object and its use in the cpu object initialization. The test ran successfully to completion and provided the memory allocator outputs and the print test output:
>
> I guess I don't understand the allocator outputs as I would have expected the two pages at address 0xA01000 for the GIC-400 to show up in the io_mem_alloc allocator output with zero availability. I hope that has something to do with this problem as don't see a good way of debugging the placement new operation>
> As an aside, I noticed a lurking bug in the Pic cpu interface register definitions in ...base-hw/src/lib/hw/arm/pic.h:
> The struct Irq_id inside both struct Iar and struct Eoir are sized as struct Irq_id : Bitfield<0:10> { }; . They both should be
> {
>    struct Irq_id : Bitfield<0:9> { };
>    struct Cpu_id : Bitfield<10:12> { };
> };

I cannot confirm this. I think you misunderstood the parameters of Bitfield.
It's Bitfield<FIRST_BIT, BIT_WIDTH> and _not_ Bitfield<FIRST_BIT, LAST_BIT>.
The document "ARM Generic Interrupt Controller Architecture version 2.0"
states that IRQ_ID reaches from bit 0 and is 10 bits wide while CPU_ID
starts with bit 10 and is 3 bits wide.

By the way, if you're reusing our imx6 code, please be aware that it is
currently used only with the USB Armory and the Wandboard Quad. Both have
i.MX 6Dual/6Quad SOCs that are Cortex-A9 based and _not_ Cortex A7.
I cannot say how much, for instance, the GIC-400 of your platform differs
from the PL390 GIC our driver is made for.

To see how the GIC memory region is initialized on the currently supported
imx6 platforms you can do:

grep -r "CORTEX_A9_PRIVATE_MEM_BASE" base-hw | grep wand_quad

The Cortex A9 private memory region contains the GIC on Cortex-A9 platforms.

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/20171009/46aaf359/attachment.html>