On Wed, 7 Oct 2026 at 11:09, Bin Meng <[email protected]> wrote: > > Hi Peter, > > On Wed, Oct 7, 2026 at 4:41 PM Peter Maydell <[email protected]> wrote: > > > > On Sun, 4 Oct 2026 at 10:05, Bin Meng <[email protected]> wrote: > > > > > > U-Boot's shared i.MX6 identification code reads PERIPHBASE + 0x4 on > > > MCIMX6UL-EVK. The first private peripheral page is currently unmapped, > > > so that access causes a data abort before the console is ready. > > > > > > The GIC-400 register map reserves offsets 0x0000 through 0x0fff and > > > specifies read-as-zero, write-ignored accesses to reserved locations. > > > Model that page in the private peripheral device. > > > > > > Reference: GIC-400 TRM (ARM DDI 0471B), sections 3.1 and 3.2 > > > https://documentation-service.arm.com/static/5e8f15e27100066a414f7424 > > > > The Cortex-A15's internal GIC isn't a GIC-400, as far as I know. > > The Linux kernel says it is a GIC-400 on i.MX6UL > https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/nxp/imx/imx6ul.dtsi#L158 > > intc: interrupt-controller@a01000 { > compatible = "arm,gic-400", "arm,cortex-a7-gic";
Ah, is this a Cortex-A7? The TRM for the A7 says https://support.arm.com/documentation/ddi0464/f/Generic-Interrupt-Controller/GIC-functional-description/GIC-memory-map?lang=en#CHDEBJAJ "Access to reserved regions can result in a data abort exception to the requesting processor." I'm not sure why that vaguely says "can" rather than "will", or whether it's significant that the language is softer than the A15 TRM uses. In any case, I think the DTB compat strings the kernel DTB uses aren't necessarily indications of what the real hardware is. See the commit message in kernel commit 61efb56e30: The arm,gic-400 compatible is probably the best matching string for the GIC in most modern SoCs, but was only introduced later into the kernel. For historic reasons and to keep compatibility, some SoC DTs were thus using a combination of this name and one of the older strings [i.e. "arm,gic-400", "arm,cortex-a7-gic"] Kernel code correctly using the DTB binding will never touch the reserved area, so it's not important that the DTB binding be able to distinguish whether it faults or not. > > > Signed-off-by: Bin Meng <[email protected]> > > > > RAZ/WI doesn't match the documented behaviour of the Cortex-A15 > > for this region in its TRM: > > > > https://support.arm.com/documentation/ddi0438/i/generic-interrupt-controller/gic-functional-description/gic-memory-map?lang=en > > > > "Read access to reserved regions results in a Data Abort exception to > > the requesting processor. Write access to reserved regions results in > > the assertion of nINTERRIRQ." > > > > It seems the A15 manual and GIC-400 manual are contradictory. I am not > sure how to proceed. Do we have real hardware where we can check what the actual behaviour is? It's not unknown for TRMs to have errors, especially in areas where the documentation is really saying "don't do this" and the question is what exactly happens when software does something it shouldn't. If we're confident the TRM documentation is wrong we can follow the actual behaviour, as long as we have some clear commentary about it. Also, has anybody filed a bug against u-boot? This is clearly a software bug to be trying to read this address at all. We should record that bug issue number in the commit message here. thanks -- PMM
