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