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? -- PMM
