Does anyone tftpboot the userspace image?

[Andrew Jeffery]

On Sat, 2017-01-21 at 16:54 +0100, Cédric Le Goater wrote:
> Hello, 
> 
> On 01/21/2017 11:10 AM, Mine wrote:
> > Hi Xo,
> > 
> > 
> > > > On Sat, Jan 21, 2017 at 9:59 AM, 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?
> > 
> > In uboot, we can use tftp to load the kernel and initrd to specific address,
> > and use `bootm` command to start the kernel.
> > E.g. for witherspoon:
> > tftp 0x80001000 kernel
> > tftp 0x81000000 initrd
> > bootm 0x80001000 0x81000000
> 
> yes. There is nothing more to do to use these images. Just replace
> initrd by obmc-phosphor-image-$platform.cpio.lzma.u-boot

Yes, I use this a fair bit. In the past there were image overlap issues
when trying to netboot a kernel using the on-flash userspace, so I was
relocating the generated cpio (with a new u-boot header) and netbooting
that instead.

> 
> > > 
> > > 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 believe someone uses this, since it does not require to flash the image to
> > the NOR flash, and make it easier to test new build.
> 
> yes. You can also use it to test an older build to check for 
> regressions or to restore a system that was trashed by a buggy 
> kernel. I have used it a few times and I still do to boot 
> openbmc-1.0 images. It would be nice to keep these images.

I agree.

Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20170123/1e727c73/attachment.sig>