Does anyone tftpboot the userspace image?

[Rick Altherr]

On Mon, Jan 23, 2017 at 11:23 AM, Xo Wang <xow at google.com> wrote:

> Hi folks,
>
> Thanks for chipping in on this.
>
> On Sun, Jan 22, 2017 at 5:10 PM, Brad Bishop
> <bradleyb at fuzziesquirrel.com> wrote:
> > Hi Xo
> >
> > Honestly this is my _only_ use case… I don’t ever flash machines unless
> > whatever I am testing specifically requires that, which for me anyway,
> > is very infrequent.
> >
> > There doesn’t necessarily have to be an all or nothing approach taken
> here.
> >
> > cpio.lzma.u-boot can be removed from IMAGE_FSTYPES in several places:
> >
> > -in your local.conf
> > -in zaius.conf in the zaius layer
> > -in a yet to be created ingrasys.conf in the ingrasys layer
> > -probably other ways too
> >
> > Alternatively, we can turn it off by default and add it where it is
> desired - possibly
> > -in my local.conf
> > -in in ibm.conf
> >
>
> I don't think we have to do anything about this. I didn't realize what
> the images are useful for until after I had mailed the change.
>
> Now that I know netbooting from the rootfs is possible I'll try it on
> my setup. It should save a fair bit of time flashing the userspace
> portion---another development annoyance for me. :)
>
> You should add this to the cheatsheet in the project docs.
>
> > I guess what I am not sure of is which makes more sense to be the
> default?
> > When these kinds of questions come up I tend to think in terms of what
> would
> > benefit new users of the project the most?  I honestly don’t know - what
> does
> > everyone else think?
> >
>
> I would say that it's a fair default to generate all the useful
> products on a simple "bitbake obmc-phosphor-image" invocation. Like
> you said, it's not difficult to remove products in local.conf.
>
> A third solution is to fix up the build dependency chain:
> do_generate_flash currently depends on do_image_complete (thus all the
> fs image products). If the netboot image were a separate recipe from
> obmc-phosphor-image, then you could run "bitbake -c generate_flash
> obmc-phosphor-image" for only the assembled flash image.
>
> However, I'm pretty sure this would require two image roots be
> installed with the same packages, so a normal build would be a lot
> slower. Probably not a good solution, but maybe you folks know of a
> way to make that work.
>
>
Ideally, do_generate_flash would be a separate image type, not a recipe.  I
don't know how to request specific IMAGE_FSTYPES from the command-line
other than editing local.conf.  I've not tried having an environment
variable overriding IMAGE_FSTYPES (i.e IMAGE_FSTYPE="cpio" bitbake
obmc-phosphor-image).  I've started the discussion in upstream OE-Core to
add raw-flash image generation to the wic tool (
http://lists.openembedded.org/pipermail/openembedded-core/2017-January/131533.html
).


> > -brad
> >
> >
> >> On Jan 20, 2017, at 8:59 PM, Xo Wang <xow at google.com> wrote:
> >>
> >> Hi folks,
> >>
> >> I noticed from this discussion
> >> https://lists.ozlabs.org/pipermail/openbmc/2016-April/thread.html#2738
> >> that kernel developers were tftpbooting the userspace image from a
> >> obmc-phosphor-image-<machine>.cpio.lzma.u-boot file.
> >>
> >> 1. How does/did that work? I guess you needed a custom init in the
> >> initrd to load the u-boot container (?) instead of from mtd?
> >>
> >> 2. Are you still using this? Building the extra .cpio.lzma.u-boot is
> >> kind of slow, with an extra ~45 seconds to do 'find | cpio | lzma;
> >> mkimage' every build, and it can't be parallelized.
> >>
> >> I ask because I mailed a change to remove those image products from
> >> the build, then followed the 'blame' to this use case:
> >> https://gerrit.openbmc-project.xyz/#/c/1957/
> >>
> >> cheers
> >> xo
> >> _______________________________________________
> >> openbmc mailing list
> >> openbmc at lists.ozlabs.org
> >> https://lists.ozlabs.org/listinfo/openbmc
>
> cheers
> xo
> _______________________________________________
> openbmc mailing list
> openbmc at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20170123/6783d5cb/attachment.html>