Re: Providing (armhf) u-boot images together with d-i images?
On Wed, 2014-12-31 at 01:59 +0100, Karsten Merker wrote:
> > 0001-Add-boot-arm-u-boot-image-config.patch
> >
> > Seems fine.
> >
> > 0002-Provide-u-boot-binaries-for-armhf-systems-without-u-.patch
>
> > I think this isn't actually publishing the u-boot binaries, but
> > rather sd-card images with the u-boot inlined, is that right? Is
> > there any use in shipping the raw binaries too?
>
> It provides both
Sorry, I must have misread.
> > 0003-Add-utils-gen-hd-image.patch
> >
> > I didn't review in detail, but perhaps the functionality of
> > patch 0002 could be folded in? TBH I'm not sure what the
> > distinction is between what 0002 does and what this script would
> > produce (except I can see the script clearly has more
> > functionality)
>
> It depends :-).
>
> gen-hd-image can provide different types of images - full images
> (SD card image including partition table, u-boot, kernel, initrd
> and dtbs) and concatenateable images, which is effectively a
> full image split up into a device-specific part (containing the
> partition table and u-boot) and a device-independent part
> (containing kernel, initrd and dtbs).
>
> If one decides to build concatenateable images, the
> device-specific part is mostly the same as the ready-to-copy SD
> card image generated by patch 2, with the difference that it
> contains a filled partition table with a predefined geometry and
> medium size.
>
> My original idea was to build u-boot-only images from patch 2 for
> people who want to install by TFTP or from USB-Stick using the
> existing hd-media tarball. This was the first thing I
> implemented. Vagrant proposed also building full images (u-boot,
> kernel, initrd and dtbs) similar to the images we build for
> i386/amd64, so I implemented that. As full images need a bit of
> space, the idea of providing concatenateable images instead of
> full images came up, but doing that is dependent on solving the
> "one boot script for all platforms" issue, for which we do not
> yet have a proper solution, therefore I implemented that as an
> option for testing this approach.
Does using the extlinux.conf stuff (mentioned in my reply to Vagrant)
help here?
> > 0004-Add-SD-card-image-build-support-for-hd-media-builds-.patch
> >
> > I don't think we need all of (.gz|.bz2|.xz) (like the README
> > suggests, although it's not clear these are all actually
> > present). Just one would do IMHO.
>
> Only the gzipped variant is actually built, the README just
> covers the possible options (when calling gen-hd-image with
> -z/-j/-J).
This README is installed in the output directory, I think? IMHO it
should document only the compression type actually used in that
directory and we should provide at most one version of each file (either
compressed or not) using a single consistent compression algorithm for
all such files.
Talking about other compression schemes or providing multiple versions
of the same file will just confuse users. It looks like someone has
commented on the duplicated concat examples in v3 too.
>
> > 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.
>
> The dtbs are only inside the generated images, they are not
> copied elsewhere as files.
My mistake, I thought they were ending up unpacked in the output too.
> Having all of them inside the image
> is a necessity if we want to have the option of using
> concatenateable builds as in this case they are in the
> device-independent part. The size of the dtbs inside the
> image is less than 900kB, so I do not think that is much of
> an issue size-wise.
Agreed.
> The previous patch produces hd-media builds for use with CD/DVD
> iso images (equivalent to the i386/amd64 hd-media
> boot.img.gz). This patch produces a netboot SD card (equivalent to
> the i386/amd64 netboot mini.iso), plus a netboot.tar.gz which
> contains everything needed to be put onto a tftp server for
> tftp-booting the installer (equivalent to the i386/amd64
> PXE netboot.tar.gz).
netboot.tar.gz sounds fine. What I don't get (see my reply to Vagrant)
is what the practical difference to the user is between the hd-media
builds and the netboot "mini.iso" ones, given that for ARM each is just
an sd-card image.
> > 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?
>
> I have not in detail checked the pxelinux.cfg support in u-boot
> yet, but as we unfortunately have to build special-casing into the
> boot script for several platform (such as the i.MX6 console
> baudrate issue), I do not see how to implement that with the
> pxelinux.cfg syntax. Pointers welcome :).
IMHO we should be moving towards using this way of doing things, which
might mean fixing things like the i.MX6 issue at source. Too late for
Jessie of course.
BTW our kernel now supports the /chosen/stdout-path property in fdt and
will automatically put a console on it.
Anyway, my preference would be to provide the pxelinux.cfg stuff as the
"right way" which is usable on whichever platforms work and provide
variants for things which don't, with the aim of removing as many
variants as possible over time post Jessie.
> > 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 never intended to actually build all options the patchset
> provides (and tried to state that in my previous mails, but
> perhaps I should have been more explicit). The patchset offers
> various possibilities for testing out of which we should choose
> a suitable set. My intention for the daily builds was to enable
> exactly two options:
>
> - u-boot-only for people using tftpboot or the existing hd-media
> tarball.
>
> - full images (in the hd-media and netboot variants) for people
> who prefer just copying a single image to an SD card and have a
> working installer as proposed by Vagrant. Those could possibly
> later be replaced by the concatenateable variant, if the full
> images should use too much space/bandwidth and we have solved
> the "one-bootscript-for-all" problem.
With the exception of my not grokking the functional difference between
the hd-media and netboot variants and therefore not seeing the point in
both, that sounds reasonable.
>
> > Perhaps a summary of the new toplevel output directories (i.e. things
> > added alongside netboot, hd-media, network-console etc) describing what
> > each one is would help?
>
> The patchset creates only one additional top-level directory,
> which is the "u-boot-only" one:
[...]
Thanks, this clarified things a lot. Sounds good.
> Inside the existing hd-media and netboot directories, a
> subdirectory "SD-card-images" gets created, which then contains
> the created images. These have the following sizes:
>
> option "netboot full image":
> 18568 A10-OLinuXino-Lime.img.gz
> 18572 A20-OLinuXino-Lime.img.gz
> 18572 BananaPi.img.gz
> 18640 BeagleBoneBlack.img.gz
> 18572 Cubieboard2.img.gz
> 18568 Cubieboard.img.gz
> 18572 Cubietruck.img.gz
> 18564 MX53LOCO.img.gz
> 18568 MX6_Cubox-i.img.gz
> 18560 PandaBoard.img.gz
> 18552 Wandboard_Quad.img.gz
>
So around 200M in total? I haven't checked but I would imagine that was
an order of magnitude more than d-i produces for any other arch in the
d-i builds.
I suppose though that it is pretty negligible (even when doubled by the
hd-media variant) compared with the full size of a mirror, but it is
getting towards 0.5G. I'm not sure who should be consulted about that.
If these images were built separately from the main d-i build then we
could e.g. mirror them via the debian-cd mechanisms instead of the main
mirror, where they would feel like a better fit.
(Do your patches end up adding the correct Built-Using on u-boot?)
Ian.
Reply to: