commit 787f04bb6a - imx: add USB2_BOOT type

[Peng Fan]

On 4/24/2023 10:14 AM, Tom Rini wrote:
> 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.

Please see https://www.nxp.com/webapp/Download?colCode=IMX93RM
9.11 ROM API. It should be backwards with i.MX8MN/P.

Hope this helps.

Regards,
Peng.

> 
>>> 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.
>