[PATCH 00/12] imx9: switch to bootstd for i.MX93/1 EVK/QSB and i.MX8M EVK

[Frieder Schrempf]

On 07.01.25 12:45 AM, Tony Dinh wrote:
> Hi Peng & Simon,
> 
> On Mon, Jan 6, 2025 at 4:15 AM Simon Glass <sjg at chromium.org> wrote:
>>
>> Hi Peng,
>>
>> On Sun, 5 Jan 2025 at 18:14, Peng Fan <peng.fan at nxp.com> wrote:
>>>
>>>> Subject: Re: [PATCH 00/12] imx9: switch to bootstd for i.MX93/1
>>>> EVK/QSB and i.MX8M EVK
>>>>
>>>> Hi Peng,
>>>>
>>>> On Sun, 5 Jan 2025 at 17:27, Peng Fan <peng.fan at oss.nxp.com> wrote:
>>>>>
>>>>> Hi Simon,
>>>>>
>>>>> On Sun, Jan 05, 2025 at 08:30:55AM +1300, Simon Glass wrote:
>>>>>> Hi Peng,
>>>>>>
>>>>>> On Sat, 4 Jan 2025 at 16:19, Peng Fan (OSS)
>>>> <peng.fan at oss.nxp.com> wrote:
>>>>>>>
>>>>>>> Switch to bootstd for NXP i.MX9/8M boards with a bsp_bootcmd
>>>> as fallback.
>>>>>>>
>>>>> [...]
>>>>>>>
>>>>>>
>>>>>> This also switches to a text environment, great!
>>>>>>
>>>>>> For bsp_bootcmd is it possible to create a bootmeth for your use
>>>> case?
>>>>>> If you would like to take a look (separate from this series), I could
>>>>>> help with any issues that come up.
>>>>>
>>>>> I just give a quick look of bootmeth, seems needs extlinux or
>>>>> bootscript (boot.scr). But both are used on NXP i.MX release as of
>>>>> now. In NXP releases, we put all script in the U-Boot ENV.
>>>>>
>>>>> Do you have suggestions how to move to support bootmeth.
>>>>
>>>> I'm not entirely sure what you are trying to do with the bootcmd,
>>>
>>> With a single u-boot, we want to support Fedora/SUSE/etc and NXP
>>> Yocto releases.
>>>
>>> So add a bsp_bootcmd as fallback to run NXP Yocto releases.
>>> NXP Yocto releases not have extlinux.cfg, nor boot.scr, we just
>>> have simple uboot hush command in bootcmd, simplied saying:
>>> run loadimage; run loadfdt; run mmcargs; booti ${loadaddr} - ${fdtaddr}
>>>
>>>> you could write your own bootmeth, e.g. using common code from the
>>>> others. For example, bootmeth_script.c shows how to run a script and
>>>> bootmeth_extlinux.c shows how to run an extlinux file. You could then
>>>> create C code to perform your 'bsp' function, e.g. a new
>>>> bootmeth_bsp.c.
>>>
>>> I will give a look, but this seems we need put the "run loadimage and etc"
>>> in dtb and needs bootmeth_imx.c to support it.
>>
>> Note that my suggestion here is as a follow-on to you current series,
>> which I believe can be applied as is.
>>
>> Anyway, as a starting point, yes you can use run_command() lots of
>> times in the bootmeth to run the things you need. From there you can
>> potentially change some commands to direct calls into the U-Boot
>> functionality. The idea is to be able to locate the bootflow as a
>> separate thing from booting it. I am quite happy to help as well.
>>
> 
> Can we call this bootmeth_internal, and have it read the internal
> board/xxx/yyy/bootflow? And then this "default' bootflow can contain
> the envs scripting to boot the board when all other boot methods have
> failed. Of course, it can also be executed manually at command prompt
> like other bootflows.
> 
> I think if we go this far to add another bootmeth, it would be nice to
> make it generic so it can be used in other boards.

I agree that a generic bootmeth would be really helpful. We would like
to have some simple A/B boot mechanism (using RAUC) and I think
implementing it as bootmeth and sharing it across different platforms
and boards is better than implementing it in the env for each board/vendor.