On Sun, Apr 16, 2023 at 11:55 PM Rasmus Villemoes
<rasmus.villem...@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.
>
> 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:
Best Regards,
Tim
