[PATCH 1/2] board: ti: am62x: am62x.env: Fix boot_targets
Simon Glass
sjg at chromium.org
Thu Nov 30 03:45:30 CET 2023
Hi Andrew,
On Mon, 6 Nov 2023 at 11:05, Andrew Davis <afd at ti.com> wrote:
>
> On 11/6/23 11:47 AM, Simon Glass wrote:
> > Hi Andrew,
> >
> > On Mon, 6 Nov 2023 at 10:27, Andrew Davis <afd at ti.com> wrote:
> >>
> >> On 11/6/23 9:31 AM, Tom Rini wrote:
> >>> On Mon, Nov 06, 2023 at 11:23:51AM +0530, Manorit Chawdhry wrote:
> >>>> Hi Simon,
> >>>>
> >>>> On 11:22-20231005, Simon Glass wrote:
> >>>>> Hi Nishanth,
> >>>>>
> >>>>> On Thu, 5 Oct 2023 at 11:16, Nishanth Menon <nm at ti.com> wrote:
> >>>>>>
> >>>>>> On 12:10-20231005, Nishanth Menon wrote:
> >>>>>>> On 12:36-20231005, Tom Rini wrote:
> >>>>>>>> On Thu, Oct 05, 2023 at 09:19:48AM -0500, Andrew Davis wrote:
> >>>>>>>>> On 10/4/23 8:54 AM, Nishanth Menon wrote:
> >>>>>>>>>> On 08:48-20231004, Andrew Davis wrote:
> >>>>>>>>>>> On 10/4/23 8:23 AM, Roger Quadros wrote:
> >>>>>>>>>>>> ti_mmc is not a valid boot_target for standard boot flow so
> >>>>>>>>>>>
> >>>>>>>>>>> Is there some way to make it into a valid boot_target? Otherwise
> >>>>>>>>>>> how do we use uEnv.txt files, or boot from FIT images with overlays?
> >>>>>>>>>>
> >>>>>>>>>> envboot takes care of uEnv.txt file (see
> >>>>>>>>>> https://lore.kernel.org/all/20231004132324.44198-3-rogerq@kernel.org/)
> >>>>>>>>>>
> >>>>>>>>>> Early remote proc loading and FIT image is a question for stdboot itself.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> If stdboot is missing these features then we shouldn't switch until it
> >>>>>>>>> has them. I'm all for switching to this, but only if it is complete.
> >>>>>>>>
> >>>>>>>> Depends on what you mean? Did you mean an option to run scripts
> >>>>>>>> (exists) or an option to do what TI needs done, via
> >>>>>>>> boot/bootmeth_something.c ? If the latter, someone from TI needs to
> >>>>>>>> figure out what that should be and do (but plumbing-wise everything it
> >>>>>>>> needs should exist).
> >>>>>>>
> >>>>>>> Andrew is generalizing here (on the wrong patch though).
> >>>>>>>
> >>>>>>> On am62x platforms, there is nothing regressing with this series. The
> >>>>>>> challenge is early remote_proc loading which is done for J7* platforms.
> >>>>>>>
> >>>>>>> How that is initiated as part of bootmethods is something of a gap.
> >>>>>>>
> >>>>>>> The other gap has been support for uEnv.txt -> which we can workaround
> >>>>>>> at the moment by using CONFIG_BOOTCOMMAND="run envboot; bootflow scan
> >>>>>>> -lb" in defconfig (This series from Roger already does that - hence I am
> >>>>>>> saying that Andrew is complaining on the wrong series).
> >>>>>>>
> >>>>>>> Ideally, we should just have CONFIG_BOOTCOMMAND="bootflow scan -lb" and
> >>>>>>> uEnv.txt remoteproc loads and the various standard bootmethods should
> >>>>>>> "just work".
> >>>>>>
> >>>>>>
> >>>>>> I forgot to add: FIT image authenticated boot flow. That is really what
> >>>>>> ti_mmc distroboot method was trying to solve.
> >>>>>>
> >>>>>> Maybe Simon or someone know how the stdboot flow handles authenticated
> >>>>>> kernel image and dtb boot flow with FIT image?
> >>>>>
> >>>>> Yes you can use FIT configuration verification and things should work as normal.
> >>>>>
> >>>>
> >>>> Could you give any reference documentation for this?
> >>>
> >>> I suspect you should start with doc/usage/fit/beaglebone_vboot.rst
> >>>
> >>
> >> From that doc:
> >>
> >> ```
> >> Boot the board using the commands below::
> >>
> >> setenv bootargs console=ttyO0,115200n8 quiet root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait
> >> ext2load mmc 0:2 82000000 /boot/image.fit
> >> bootm 82000000
> >> ```
> >>
> >> This is very much not stdboot :( This doc has some good and current info on building
> >> a secure FIT image, but much of it is showing its age. Stdboot is still missing
> >>
> >> * ability to limit boot mode search to only one image (FIT)
> >
> > What does this mean? Can you please be more specific or give an example?
> >
>
> Sure, for instance with secure boot we only want to search for FIT images
> and if for each media this fails we do not want to fall back to other
> image types or boot modes (like UART boot or net boot which would bypass
> the signature checks).
We could have something like:
bootstd {
image-types = "fit", "uimage";
}
to limit the supported types.
>
> Something similar is needed for searching for EFI compatible boot across
> each enabled boot media first, before trying other methods on each media.
> Basically breadth-first search on each media type not depth-first.
How about:
bootstd {
scan-order = "bootmeth,bootdev"; // instead of default "bootdev,bootmeth";
};
>
> >> * fetching and applying FIT overlay/config strings
> >
> > Re overlays, is this the 'extension' command? What are config strings?
> >
>
> When we have DT overlays in our FIT image, we build a string to pass to
> bootm to apply all the selected overlays[0]. If there is now another
> mechanism for this please let me know (building this string today is messy).
>
> https://source.denx.de/u-boot/u-boot/-/blob/master/include/env/ti/ti_common.env?ref_type=heads#L18
My proposal for this is to implement extensions in FIT. This would
have a new extensions nodes, so you can specify what extensions are
available for each FIT configuration.
configurations {
conf-1 {
compatible = ...
extensions = "ext1", "ext-2";
};
extensions {
ext-1 {
fdto = "fdt-1"; // fdt overlay for this 'cape'
compatible = "vendor,combined-device1";
extensions = "ext3";
};
ext-2 {
fdto = "fdto-2"; // fdt overlay for this 'cape'
compatible = "vendor,device2";
};
ext-3 {
fdto = "fdto-3";
compatible = "vendor,device3";
};
So FIT configurations now have a list of supported extensions. The
extensions are hierarchical so that you can have ext1 which can
optionally have ext-2 as well. This allows boards which share a lot of
'capes' to be specified only ones.
Extensions actually present are declared by a sysinfo driver for the
board, with new methods:
get_compat() - determine the compatible strings for the current platform
get_ext() - get a list of compatible strings for extensions which are
actually present
The extension compatible strings are used to select the correct things
from the FIT, apply the overlays and produce the final DT.
>
> >> * remote proc loading
> >
> > What command can do this?
> >
>
> https://source.denx.de/u-boot/u-boot/-/blob/master/include/env/ti/ti_common.env?ref_type=heads#L28
This could be a new property in bootstd:
bootstd: {
probe-before = <&phandle of remoteproc>, ...
};
>
> >> * uEnv.txt processing
> >
> > What command can do this?
> >
>
> run envboot;
>
> https://source.denx.de/u-boot/u-boot/-/blob/master/include/env/ti/mmc.env?ref_type=heads#L20
This could be a new bootmeth which looks for uenv.txt on available
devices. It might be better to put the env in a FIT or something with
a checksum.
>
> >>
> >> Last two can be solved by adding to CONFIG_BOOTCOMMAND before calling `bootflow scan`
> >> as suggested above. Until we figure out the first two I don't see us ready to switch.
> >
> > I'm happy to help figure this out.
> >
>
> Thanks, we are eager to standardize our boot flows and stdboot seems like the
> right way forward, very happy to have your guidance on these last few items :)
Regards,
Simon
More information about the U-Boot
mailing list