Hi Peter, On Sun, Oct 4, 2026 at 9:19 AM Bin Meng <[email protected]> wrote: > > Hi Peter, > > On Wed, Sep 16, 2026 at 12:13 AM Peter Maydell <[email protected]> > wrote: > > > > On Tue, 15 Sept 2026 at 16:52, Bin Meng <[email protected]> wrote: > > > > > > Hi Peter, > > > > > > On Mon, Sep 14, 2026 at 5:20 PM Peter Maydell <[email protected]> > > > wrote: > > > > > > > > On Fri, 4 Sept 2026 at 17:15, Bin Meng <[email protected]> > > > > wrote: > > > > > > > > > > + /* > > > > > + * U-Boot's shared i.MX6 CPU identification code reads the > > > > > + * Cortex-A9 SCU configuration register on i.MX6UL. Cortex-A7 > > > > > + * reserves this address, so provide only the compatibility word > > > > > + * needed before the console is initialized. > > > > > + */ > > > > > + create_unimplemented_device("a7mpcore-scu-compat", > > > > > + FSL_IMX6UL_A7MPCORE_ADDR + 0x4, 4); > > > > > > > > What is actually going on here, though? Why is u-boot reading > > > > an address that's only here for the A9? Has this been reported > > > > to u-boot as a bug? What does the real hardware do? > > > > > > I suspect the reason is that the imx6 family contains both A9 and A7 > > > based SoCs and it's a leftover when imx6ul support was introduced in > > > U-Boot. I do not see a bug report against U-Boot yet. > > > > > > > > > > > Whatever the answers are, I expect the correct fix is not going > > > > to be "fake up this specific 4 bytes to ignore accesses in the > > > > imx6 SoC model". > > > > > > > > > > Apparently the real hardware ignores the scu access on A7. So IMO it > > > could be accepted as a workaround for buggy software although guests > > > should not do so. > > > > Mmm, but I don't think the fix is going to be just this 4 bytes, > > and possibly it shouldn't be in this SoC specifically. > > > > What does the TRM for the SoC say is at this address? > > > > The TRM for the SoC only says 00A0_0000 - 00A0_7FFF windows is for > "ARM Peripherals: GIC400 Only visible to ARM core(s)", then in the TRM > for Cortex-A7 the address 0x0000 - 0x0FFF is marked as reserved. > > I plan to submit a patch to the U-Boot upstream to see how the > maintainer thinks. >
After further reading the GIC-400 TRM (DDI0471B), I found chapter 3.1 says: The following information applies to the GIC-400 registers: • The base address of the GIC-400 is not fixed, and can be different for a particular system implementation. The offset of each register from the base address is fixed. • Access to reserved or unused address locations is RAZ/WI (Read-as-Zero, Writes Ignored). • Unless otherwise stated in the accompanying text: — Do not modify reserved register bits. — Ignore reserved register bits on reads. — All register bits are reset to 0 by a system or power-on reset. It seems we should create a 4KiB unimplemented window within GiC-400. Regards, Bin
