On Fri, Dec 22, 2023 at 12:07 PM Tom Rini <tr...@konsulko.com> wrote: > > On Fri, Dec 22, 2023 at 12:05:39PM +0000, Shantur Rathore wrote: > > Hi all, > > > > On Mon, Dec 11, 2023 at 6:27 PM Tom Rini <tr...@konsulko.com> wrote: > > > > > > On Mon, Dec 11, 2023 at 11:22:45AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > [snip] > > > > > I think in hind-sight too much stuff is omitted without BOOTSTD_FULL. > > > > > The option itself then enables other stuff too by default, but some > > > > > parts of the bootflow command itself should be visible even without > > > > > FULL > > > > > to make things easier on the user. > > > > > > > > At the time the goal was to avoid growth compared to the distro > > > > scripts. We could perhaps add some more things in with BOOTSTD_FULL > > > > but still have it as an option? > > > > > > Right. But now that we've tried this, some of the feedback has been that > > > it's just too minimal right now. Like looking at the help message for > > > bootflow, list and info should probably always be available. And maybe > > > the flags for "scan" should be re-thought? Too late to change things now > > > but "bootflow scan -b" should maybe how it's always been for "scan and > > > boot". > > > > What would be the preferred approach for this patch? > > Is it to update the default capabilities of bootflow or we can have this > > patch? > > Well, I don't see a problem with just adding this to the platforms which > enable BOOTSTD_FULL until we can rework what's included/excluded by that > flag, and there's an issue filed for it now. > > -- > Tom
Great, can we have this merged in please then [0] [0] - https://patchwork.ozlabs.org/project/uboot/patch/20231119172310.1307942-...@shantur.com/ Regards, Shantur
