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. Regards, Bin
