On Wed, Oct 7, 2026 at 8:49 PM Peter Maydell <[email protected]> wrote: > > 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. >
I don't have real hardware at hand right now, but I bet hardware doesn't data abort otherwise it won't sit in the U-Boot codes for years. > 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. > I've just sent a patch to U-Boot upstream (Cc Tom) https://lore.kernel.org/u-boot/[email protected]/T/#u Regards, Bin
