On 2014-12-06, Karsten Merker wrote: > On Wed, Dec 03, 2014 at 03:10:37PM -0800, Vagrant Cascadian wrote: > > [providing u-boot images for armhf platforms that do not have > u-boot in non-volatile storage] ... > I guess it would make sense to provide both the "naked" u-boot > binaries for people who want to manually write them to an SD card > that already contains a partition table without destroying it, > and an additional tiny disk image (<1MB) that contains u-boot at > the proper place (but nothing else, i.e. no partition table if > not needed for u-boot), which can be written with common disk > image handling tools. The latter would make life a lot easier > for people setting up the installer from Windows for example. > >> Providing complete u-boot images for each platform would be 19 images >> for jessie, though each one is fairly small (each between >> 0.5-1M). Though I don't think we've consolidated all documentation >> needed to generate all those platforms with the correct offsets (though >> many are all the same, such as sunxi). > > I only know those for sunxi and i.MX6: > > - sunxi: > combined image (SPL + main image) at offset 8kB > > - i.MX6: > SPL at offet 1kB > main image at offset 42kB Unfortunately, mainline u-boot doesn't necessarily support SPL for all i.MX6 platforms, so that's a case by case basis. > @debian-arm: Could somebody provide this information for i.MX53 > and OMAP? There are README.Debian entries in the u-boot-imx, u-boot-omap, and u-boot-sunxi packages describing the known ones so far: MX53LOCO: dd bs=1024 if=u-boot.imx of=/dev/sdX seek=1 wandboard_quad: dd if=/usr/lib/u-boot/wandboard_quad/u-boot.imx of=/dev/mmcblkX bs=512 seek=2 mx6_cubox-i: dd if=/usr/lib/u-boot/mx6_cubox-i/SPL of=/dev/mmcblk0 bs=1k seek=1 dd if=/usr/lib/u-boot/mx6_cubox-i/u-boot.img of=/dev/mmcblk0 bs=1k seek=42 The BeagleBone Black (am335x_boneblack) can be flashed to microSD or eMMC directly: dd if=/usr/lib/u-boot/am335x_boneblack/MLO of=/dev/mmcblkX count=1 seek=1 conv=notrunc bs=128k dd if=/usr/lib/u-boot/am335x_boneblack/u-boot.img of=/dev/mmcblkX count=2 seek=1 conv=notrunc bs=384k Many sunxi boards (Bananapi, Cubieboard) can be written to SD directly: dd if=/usr/lib/u-boot/BOARD/u-boot-sunxi-with-spl.bin of=/dev/mmcblkX bs=1024 seek=8 Those don't cover all the shipped armhf platforms, but it does cover most of them. >> For images such as hd-media, we'd ideally want to provide complete >> u-boot + kernel + initrd ( + gtk initrd) images, which would grow each >> image considerably. > > I know of no armhf system that can load its u-boot from a USB mass > storage device, so AFAICS such a full image could only be written to > an SD card. This setup would therefore only be useful if the intended > installation target is something else than the SD card, because > otherwise one would have to install to the medium containing the > installer and would therefore not be able to use the space used by the > installer and the CD/DVD ISO image for the installed system. I think > that for most systems the primary installation target is the SD card, > so I think that we should use the "tiny SD card image with only u-boot > on it" + "USB stick with hd-media tarball and CD/DVD ISO" model > instead of building "full" hd-media images. I'm not sure I agree here, if the goal is ease-of-use for installing on these platforms. You still need to load the kernel, initrd and fdt once u-boot is loaded, and having kernel, initrd and fdt on the SD image means you'll be able to boot the installer regardless of weather u-boot supports the media you have the ISO images on. Not all u-boot variants support loading the kernel, initrd and fdt off of USB, and even if they do, may not support it in the default boot options... You can easily install to the media you booted from, once the kernel, initrd and fdt file are loaded off the boot media, you don't need the SD media to be present... even if it wipes out the files used to boot debian-installer ... so I don't quite see the problem in that. To me, the question is simply a matter of how many images are we willing to support with simple instructions for out-of-the box, or what is the compromise between simple instructions and number of images is? live well, vagrant
Attachment:
signature.asc
Description: PGP signature