Hi, On Wed, Nov 29, 2023 at 7:48 PM Simon Glass <s...@chromium.org> wrote: > > Hi Andrew, > > On Mon, 6 Nov 2023 at 11:05, Andrew Davis <a...@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 <a...@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 <n...@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-rog...@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
