Hi Frieder,
On Mon, 13 Jan 2025 at 02:48, Frieder Schrempf
<frieder.schre...@kontron.de> wrote:
>
> On 07.01.25 12:45 AM, Tony Dinh wrote:
> > Hi Peng & Simon,
> >
> > On Mon, Jan 6, 2025 at 4:15 AM Simon Glass <s...@chromium.org> wrote:
> >>
> >> Hi Peng,
> >>
> >> On Sun, 5 Jan 2025 at 18:14, Peng Fan <peng....@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....@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....@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.
I am hoping that VBE's abrec will land before too long. That is
programmatic. Fwupd only supports VBE-simple at present but I plan to
add support for that in the middle of the year.
Regards,
Simon
