<div dir="ltr">All those options (bootcmd, bootargs) can be configured through the environment, which is left blank in current image.<div><br></div><div>As a separate step in image-overlay:do_generate_flash one can generate and populate that environment (using mkenvimage from u-boot-mkimage package) using simple text file as a source.</div><div><br></div><div>U-Boot source code just needs to provide sensible defaults.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 25, 2017 at 7:42 PM, Rick Altherr <span dir="ltr"><<a href="mailto:raltherr@google.com" target="_blank">raltherr@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">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.</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Jul 25, 2017 3:42 PM, "Patrick Williams" <<a href="mailto:patrick@stwcx.xyz" target="_blank">patrick@stwcx.xyz</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Jul 24, 2017 at 11:19:52AM -0700, Rick Altherr wrote:<br>
> The current bootcmd script is there to provide backward compatibility for<br>
> pre-FIT ramdisks.  That can probably be removed but we now want fallback<br>
> behavior for images that still use a ramdisk.<br>
<br>
Thanks for giving me the history on that BOOTCOMMAND snippet.  It wasn't<br>
obvious what it was doing to me.<br>
<br>
Agreed.  It seems a little odd to me that this is all controlled in the<br>
u-boot repository directly, hence my questions.  I would have expected<br>
that an IMAGE_FEATURE or MACHINE_FEATURE of Yocto would have triggered<br>
FIT vs non-FIT.  Same now with the transition to UBI with kernel and<br>
squashfs instead of distinct MTD devices.<br>
<br>
><br>
> On Fri, Jul 21, 2017 at 3:33 PM, Patrick Williams <<a href="mailto:patrick@stwcx.xyz" target="_blank">patrick@stwcx.xyz</a>> wrote:<br>
><br>
> > As part of the change-over from an initramfs-based boot sequence to a<br>
> > direct rootfs boot, we need to change some of the boot options for<br>
> > u-boot.  I expect these to change a few times in the near future as we<br>
> > also transition to UBI-managed volumes and we figure out how to set<br>
> > u-boot environment options to switch between different UBI kernels and<br>
> > rootfses.<br>
> ><br>
> > This is really independent from the current ast-*-defconfigs, in that<br>
> > those currently select between different network options.  I suspect<br>
> > we do not N*M combinations of defconfigs for network*image-structure.<br>
> > I plan to make a MACHINE_FEATURE (or DISTRO_FEATURE) in bitbake to<br>
> > control this, but looking for feedback on how we should change u-boot.<br>
> ><br>
> > Ideally, to me, this would have been passed in via the config file and<br>
> > we could have used config-snippets in Yocto like we do for the kernel.<br>
> > Due to the way u-boot builds, I could not find a simple way to even<br>
> > change this option from a include/config/ast-common.h #define into a<br>
> > machine_config driven option.<br>
> ><br>
> > Anyone have ideas?<br>
> ><br>
> > Patrick Williams (1):<br>
> >   config/ast-common: hack bootopts<br>
> ><br>
> >  include/configs/ast-common.h | 6 ++++++<br>
> >  1 file changed, 6 insertions(+)<br>
> ><br>
> > --<br>
> > 2.13.0<br>
> ><br>
> ><br>
> ><br>
<br>
--<br>
Patrick Williams<br>
</blockquote></div></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div><b>M</b>axim <b>S</b>loyko</div></div>
</div>