[PATCH 1/2] board: ti: am62x: am62x.env: Fix boot_targets
Simon Glass
sjg at chromium.org
Sun Dec 31 13:48:33 CET 2023
Hi,
On Wed, Nov 29, 2023 at 7:48 PM Simon Glass <sjg at chromium.org> wrote:
>
> 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 :)
>
I'm just checking whether there is any feedback on the above? I sent
the FIT part as a separate proposal.
Regards,
Simon
More information about the U-Boot
mailing list