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? > * fetching and applying FIT overlay/config strings Re overlays, is this the 'extension' command? What are config strings? > * remote proc loading What command can do this? > * uEnv.txt processing What command can do this? > > 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. Regards, SImon