On 2014-12-23, Karsten Merker wrote:
> Attached is a set of patches to implement building bootable
> d-i images for armhf systems. It offers various options:
>
> - provide binary "u-boot-only" images for people who want to
> manually install u-boot and e.g. run the rest of the setup via
> tftpboot
>
> - build "full" installer images in the variants netboot und
> hd-media, which contain u-boot, kernel, initrd and dtbs.
>
> - build "concatenateable" installer images in the variants
> netboot and hd-media. These have the same contents as the
> "full" images but are split into a device-specific and a
> device-independent part to save space and must be decompressed
> and then concatenated together by the user.
Thanks so much for your work on this!
> If space and bandwidth use is too high
> for the "full" images, we could use the "concatenateable"
> variant, although this makes installing the images more
> complicated for the end user and is only possible if we can
> manage to boot _all_ armhf platforms with a single boot script,
> as this boot script is in the device-independent part.
I don't think it's possible yet to have the device-independent parts
working with *all* platforms (at least for Jessie), but we can get close
with a few relatively simple workarounds:
Some of the issues with "bootscr.mainline_common" are inconsistancies
across platforms with the u-boot console settings (particularly the baud
rate not being appended) not actually being consistant with the kernel
boot argument for "console=", or for doing a framebuffer console install
vs. a serial console install. This affects both the wandboard and
cubox-i platforms, but can be worked around with a uEnv.txt file or
setting directly from the u-boot prompt.
The beaglebone black and I suspect mx53loco don't have patches to
emulate the variables (${boot_targets}, ${devtype}, ${devnum} ...)
needed to work with "bootscr.mainline_common". This might be possible to
work around with a uEnv.txt file, but may require some know-how on the
user's part to set appropriately the emulated variables.
Given that several workarounds could be implemented in uEnv.txt, it
might be worth shipping a uEnv.txt with some commented out workarounds,
and the user could edit it to enable the appropriate workarounds.
At the very least, workarounds could be documented in the installation
manual or release notes.
> The latter is a point that still needs checking and for which I need
> testers who have access to the respective systems.
Happy to test for several of the mentioned boards, and there is also a
list of testers for various platforms in the u-boot source package in
debian/targets.
The netboot images here seem more like the mini.iso netboot images on
x86, though I've tested several armhf installs with the boot.scr,
kernel, initrd, dtb all downloaded via TFTP (more like the pxe boot
images on x86).
I see both use-cases as valid, as a few boards have broken networking
support within u-boot, and some users might not want to set up a TFTP
server.
> diff --git a/build/boot/arm/u-boot-image-config b/build/boot/arm/u-boot-image-config
> new file mode 100644
> index 0000000..1d0208a
> --- /dev/null
> +++ b/build/boot/arm/u-boot-image-config
...
> +# Images from u-boot-omap
> +BeagleBoneBlack /usr/lib/u-boot/am335x_boneblack/MLO 256 /usr/lib/u-boot/am335x_boneblack/u-boot.img 768
> +PandaBoard /usr/lib/u-boot/am335x_boneblack/MLO 256 /usr/lib/u-boot/omap4_panda/u-boot.bin 768
I suspect this is a cut-and-paste typo and you want omap4_panda for both
the MLO and u-boot.bin. :)
live well,
vagrant
Attachment:
signature.asc
Description: PGP signature