commit 787f04bb6a - imx: add USB2_BOOT type

[Tom Rini]

On Thu, Apr 20, 2023 at 03:13:42PM -0700, Tim Harvey wrote:
> On Sun, Apr 16, 2023 at 11:55 PM Rasmus Villemoes
> <rasmus.villemoes at prevas.dk> wrote:
> >
> > On 26/10/2022 01.42, Rasmus Villemoes wrote:
> > > On 18/10/2022 02.43, Peng Fan wrote:
> > >> + Stefano & Fabio
> > >>
> > >
> > >>>>>
> > >>>>> Is there any chance you could make some information on that ROM API
> > >>>>> public so it's possible for outsiders to understand what's going on?
> > >>
> > >> What could only help is to ask the ROM team to see whether they have
> > >> plan to public the ROM API details and when. Otherwise you could only
> > >> read the code to understand how it works.
> > >>
> > >>>>
> > >>>> Could you please try below changes to check whether it fixes your issue?
> > >>>
> > >>> Well, it seems very likely it would, but could you _please_ answer the
> > >>> real question so we as a community has a chance of evaluating whether
> > >>> that's the proper fix or something else entirely is needed. And so that
> > >>> in the future we as a community would have a chance of objecting to
> > >>> including 787f04bb6a in the first place.
> > >>
> > >> You could help reviewing if you have time.
> > >
> > > Don't you see the absurdity of on the one hand saying that the only way
> > > to understand the ROM API is to study the U-Boot side of the code, and
> > > on the other hand asking others to review changes to said code?
> > >
> > > If the API could be understood from merely reading existing U-Boot code,
> > > than that code is by definition perfect and won't need to be changed.
> > >
> > > Now that I know there is a dedicated ROM team, let me rephrase:
> > >
> > > Is there any chance you could reach out to said ROM team and ask if they
> > > could make some information on the API public?
> > >
> > > [The "you" in the previous questions have always meant NXP, not you
> > > personally.]
> >
> > And here we are, half a year later, and mainline U-Boot is still broken.
> >
> > I'm not gonna offer a tested-by or reviewed-by on that patch you
> > suggested upthread until and unless the ROM API gets documented.

To the NXP folks, is the API truly not documented in any part of the
normal public manuals for these chips? That seems like the kind of
oversight that indeed should be corrected, and internal bugs filed to
get resolved.

> > Rasmus
> >
> 
> I just stumbled across this as well after an hour or so of debugging.
> 
> It seems to me if we are not going to revert commit 787f04bb6a0af
> ("imx: add USB2_BOOT type") which breaks IMX8M bootrom booting over
> SDP due to boot_instance being non-zero then we should at least accept
> Peng's fix which I can verify works.
> 
> diff --git a/arch/arm/mach-imx/romapi.c b/arch/arm/mach-imx/romapi.c
> index b49e7f80a286..ff0522c2d117 100644
> --- a/arch/arm/mach-imx/romapi.c
> +++ b/arch/arm/mach-imx/romapi.c
> @@ -70,6 +70,8 @@ enum boot_device get_boot_device(void)
>                 boot_dev = SPI_NOR_BOOT;
>                 break;
>         case BT_DEV_TYPE_USB:
> +               if (!is_imx8ulp() && !is_imx9())
> +                       boot_instance = 0;
>                 boot_dev = boot_instance + USB_BOOT;
>                 break;
>         default:

And since it's not good to leave code broken either, the above should be
submitted as a proper patch I gather.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230423/9abd4918/attachment.sig>