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 common i.MX6 CPU identification code reads the Cortex-A9
> > SCU configuration register at PERIPHBASE + 0x4 even on i.MX6UL.
> > The value is only used to distinguish Cortex-A9 i.MX6 variants.
> >
> > Cortex-A7 reserves this address and reading it causes data abort.
> >
> > The same U-Boot abort was discussed on qemu-arm in September 2024:
> > https://lists.gnu.org/archive/html/qemu-arm/2024-09/msg00072.html
> >
> > Map only the four-byte configuration-register address as an
> > unimplemented device. Its zero read result gives U-Boot the
> > single-CPU encoding after the low two bits are masked, while
> > the remainder of the reserved Cortex-A7 page stays unmapped.
> >
> > Signed-off-by: Bin Meng <[email protected]>
> > ---
> >
> > (no changes since v1)
> >
> >  hw/arm/fsl-imx6ul.c | 9 +++++++++
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/hw/arm/fsl-imx6ul.c b/hw/arm/fsl-imx6ul.c
> > index 1863558a0d..d6f662efe4 100644
> > --- a/hw/arm/fsl-imx6ul.c
> > +++ b/hw/arm/fsl-imx6ul.c
> > @@ -187,6 +187,15 @@ static void fsl_imx6ul_realize(DeviceState *dev, Error 
> > **errp)
> >      sysbus_realize(SYS_BUS_DEVICE(mpcore), &error_abort);
> >      sysbus_mmio_map(SYS_BUS_DEVICE(mpcore), 0, FSL_IMX6UL_A7MPCORE_ADDR);
> >
> > +    /*
> > +     * 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.

Regards,
Bin

Reply via email to