[PATCH 10/15] configs: j721e_evm_a72_defconfig: Switch to bootstd

Tom Rini trini at konsulko.com
Mon Nov 6 16:22:05 CET 2023


On Mon, Nov 06, 2023 at 06:21:16AM -0600, Nishanth Menon wrote:
> On 10:58-20231106, Manorit Chawdhry wrote:
> > Hi Nishanth,
> > 
> > On 19:38-20231102, Nishanth Menon wrote:
> > > Switch to using bootstd. Note with this change, we will stop using
> > > distro_bootcmd and instead depend entirely on bootflow method of
> > > starting the system up.
> > > 
> > > Signed-off-by: Nishanth Menon <nm at ti.com>
> > > ---
> > >  configs/j721e_evm_a72_defconfig | 5 +++--
> > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig
> > > index 99e0e168ebf7..98ac7ca59789 100644
> > > --- a/configs/j721e_evm_a72_defconfig
> > > +++ b/configs/j721e_evm_a72_defconfig
> > > @@ -29,10 +29,11 @@ CONFIG_SPL_SPI=y
> > >  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> > >  CONFIG_SPL_LOAD_FIT=y
> > >  CONFIG_SPL_LOAD_FIT_ADDRESS=0x81000000
> > > -CONFIG_DISTRO_DEFAULTS=y
> > >  CONFIG_OF_BOARD_SETUP=y
> > >  CONFIG_OF_SYSTEM_SETUP=y
> > > -CONFIG_BOOTCOMMAND="run envboot; run distro_bootcmd;"
> > > +CONFIG_BOOTSTD_FULL=y
> > > +CONFIG_BOOTSTD_DEFAULTS=y
> > > +CONFIG_BOOTCOMMAND="run envboot; bootflow scan -lb"
> > 
> > Coming back to [0], AM62x didn't have early remote procs but j721e does,
> > do you have any alternatives in place before migrating J7 platforms to
> > stdboot?
> 
> As I have stated before. distro boot support for remote proc has been
> hacked up atm. what needs to happen is standardize it. Which is
> independent of this series.
> 
> Please discuss with stdboot folks how to get it in. WORST case, envboot
> is still supported, so in effect, what is achieved today can still
> continue to occur with envboot.

There's not "stdboot folks" to talk with about this. The first step
would be someone from TI posting some RFC patches about how exactly the
remote proc support should be handled in that case, explaining where the
what being run comes from and so forth. Maybe the answer is that
"envboot" just keeps being defined and run before hand because that's
the standard way to handle what needs doing on those processors? At
least personally I feel like there's a gap in knowledge of what the use
cases here are. Thanks.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20231106/354ed712/attachment.sig>


More information about the U-Boot mailing list