On 10/5/23 12:16 PM, Nishanth Menon 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.
Right, FIT (and remote proc loading) are handled in ti_mmc, and this
is the patch removing that (so I do believe I am complaining on the right
patch here). I know that needs removed before we switch to stdboot, but
we cant remove it until someone has the the alternative in place.
Simply dropping it and hoping someone else comes along later and re-adds
the features isn't a good idea. Even if, as said above, the plumbing we
need should already exist, it needs done first.
Andrew
Maybe Simon or someone know how the stdboot flow handles authenticated
kernel image and dtb boot flow with FIT image?
