[PATCH u-boot 0/1] RFC: How to configure boot options?

[Rick Altherr]

I could see those as IMAGE_FEATURES. FIT vs non-FIT is controlled by
KERNAL_IMAGETYPE but that could be triggered by IMAGE_FEATURES. Regardless
of the options chosen, the built U-Boot should support booting the current
FIT+initramfs+cpio and a future FIT+UBI at least for the transition period.

On Jul 25, 2017 3:42 PM, "Patrick Williams" <patrick at stwcx.xyz> wrote:

> On Mon, Jul 24, 2017 at 11:19:52AM -0700, Rick Altherr wrote:
> > The current bootcmd script is there to provide backward compatibility for
> > pre-FIT ramdisks.  That can probably be removed but we now want fallback
> > behavior for images that still use a ramdisk.
>
> Thanks for giving me the history on that BOOTCOMMAND snippet.  It wasn't
> obvious what it was doing to me.
>
> Agreed.  It seems a little odd to me that this is all controlled in the
> u-boot repository directly, hence my questions.  I would have expected
> that an IMAGE_FEATURE or MACHINE_FEATURE of Yocto would have triggered
> FIT vs non-FIT.  Same now with the transition to UBI with kernel and
> squashfs instead of distinct MTD devices.
>
> >
> > On Fri, Jul 21, 2017 at 3:33 PM, Patrick Williams <patrick at stwcx.xyz>
> wrote:
> >
> > > As part of the change-over from an initramfs-based boot sequence to a
> > > direct rootfs boot, we need to change some of the boot options for
> > > u-boot.  I expect these to change a few times in the near future as we
> > > also transition to UBI-managed volumes and we figure out how to set
> > > u-boot environment options to switch between different UBI kernels and
> > > rootfses.
> > >
> > > This is really independent from the current ast-*-defconfigs, in that
> > > those currently select between different network options.  I suspect
> > > we do not N*M combinations of defconfigs for network*image-structure.
> > > I plan to make a MACHINE_FEATURE (or DISTRO_FEATURE) in bitbake to
> > > control this, but looking for feedback on how we should change u-boot.
> > >
> > > Ideally, to me, this would have been passed in via the config file and
> > > we could have used config-snippets in Yocto like we do for the kernel.
> > > Due to the way u-boot builds, I could not find a simple way to even
> > > change this option from a include/config/ast-common.h #define into a
> > > machine_config driven option.
> > >
> > > Anyone have ideas?
> > >
> > > Patrick Williams (1):
> > >   config/ast-common: hack bootopts
> > >
> > >  include/configs/ast-common.h | 6 ++++++
> > >  1 file changed, 6 insertions(+)
> > >
> > > --
> > > 2.13.0
> > >
> > >
> > >
>
> --
> Patrick Williams
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20170725/382189ed/attachment.html>