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@chromium.org wrote:
Hi Peng,
On Sun, 5 Jan 2025 at 18:14, Peng Fan peng.fan@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@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@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.