Re: Providing (armhf) u-boot images together with d-i images?
On Tue, 2014-12-30 at 13:42 -0800, Vagrant Cascadian wrote:
> On 2014-12-30, Ian Campbell wrote:
>
> > 0004-Add-SD-card-image-build-support-for-hd-media-builds-.patch
> ...
> > It seems to be creating a copy of dtbs again, please lets try
> > and keep it to one set of these files in the top level
> > component.
>
> Well, all the dtb files need to be on the concatenateable images so that
> simply dd'ing the right u-boot files onto the card will be able to
> boot. If the image was only made for a specific system, then it would be
> possible to only include the relevent dtb files.
I thought these were being copied into the output dir, rather than (or
as well as) being encapsulated into the image, doing the latter is fine.
Sounds like I misread the patch and it is infact only doing the latter.
>
>
> > 0005-Add-SD-card-image-and-tftpboot-tarball-build-support.patch
> >
> > What is this providing? Is it a mini.iso like netboot sd image?
>
> I think it is basically like the mini.iso on i386/amd64, yes.
>
>
> > I'm not sure how this is different from what the previous
> > patches introduced.
>
> I think the difference is one is a set of netboot images, and the other
> is a set of hd-media images.
But what is the difference between these two things in this context?
Aren't they functionally identical from the users perspective?
> > For the tftpboot part, u-boot supports standard pxelinux.cfg
> > syntax configuration files -- would it be better to just
> > generate a suitable one of those?
>
> Boot scripts allow the use of ${fdtfile}. As far as I understand, the
> pxelinux.cfg syntax unfortunately lacks the ability to use u-boot
> variables, and thus requires a different pxelinux.cfg for each system
> that uses a different .dtb. Which doesn't seem particularly useful for
> a single config for network booting...
pxelinux.cfg stanzas can include an "fdtdir" directory which is a path
which u-boot will search for ${fdtfile} under.
This isn't terribly well documented, but
http://patchwork.ozlabs.org/patch/423507/ improves things a lot.
Speaking of which, does the extlinux.conf stuff (which also supports
fdtdir) help with the multiple images problem at all?
extlinux.conf (and pxelinux.conf) also has the advantage over boot.scr
that it can offer multiple options (graphical vs text etc etc).
> I also think more systems support booting boot scripts than u-boot's
> "PXE" emulation at this point.
That's true.
Going forward we should try and make it our default option though I
think -- it was basically put together this way by the Fedora guys to
support exactly this sort of scenario.
>
> > I suppose my main overall concern is that this seems to be providing the
> > same thing 3 or 4 times and I'm not sure what the difference between
> > each of those things is (or perhaps as likely I've misunderstood what is
> > going on somewhere along the line). I was already concerned about the
> > proliferation of images which taking this approach was implying in
> > general and adding a multiplier to that just makes me more
> > uncomfortable.
>
> If I'm reading it correctly(perhaps partly based on earlier descriptions
> of the goal), there are several images produced:
>
> 1 u-boot only for each supported platform
>
> 2 hd-media full with u-boot + kernel + initrd + dtbs + bootscript for
> each platform
>
> 3 hd-media concatenateable with kernel + initrd + dtbs + bootscript
>
> 4 netboot full with u-boot + kernel + initrd + dtbs + bootscript for
> each platform (like mini.iso)
>
> 5 netboot concatenateable with kernel + initrd + dtbs + bootscript
>
> 6 netboot boot script for use with TFTP
(I've switched your bullets to numbers for ease of reference).
Are 2+4 and 3+5 not essentially the same things with different names (on
x86 the distinction is iso image vs a f/s image, but on ARM both are
sd-card images).
>
> The netboot/hd-media without u-boot are meant to be concatenated
> together with the appropriate u-boot only images... so yes, there is
> significant overlap between the image types.
>
> The full images are obviously easier for the users to use, as it
> requires writing a single image, but obviously proliferate the number of
> images for each new supported platform.
>
> The concatenateable images obviously save a lot of space, at the expense
> of the user having to do additional steps and more complicated
> documentation (and might be difficult on non-unix-like platforms?).
>
> It probably doesn't make sense to ship both the concatenateable and full
> images. I think Karsten wanted to enable both so that they could be
> tested in the daily images, and then later pick which would ship with
> Jessie?
I'm not so much worried about concatenatable vs non as netboot vs
hd-media, but perhaps I just haven't grokked the difference.
Ian.
Reply to: