[fedora-arm] ARM and shipping of various binary firmware / boot bits

[Dennis Gilmore]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 8 Mar 2012 12:57:44 -0600
Dennis Gilmore <dennis at ausil.us> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Thu, 08 Mar 2012 13:12:39 -0500
> Jon Masters <jcm at redhat.com> wrote:
> 
> > On 03/08/2012 01:07 PM, Jon Masters wrote:
> > 
> > > Anyway. All this means that on ARM, in some cases (won't be true
> > > on servers), especially inexpensive dev boards, we become the
> > > distributor of the U-Boot bits if we want to ship whole SD Card
> > > images (which we think we do - otherwise installation on Panda or
> > > Pi becomes harder, on servers and other systems we'll do x86-like
> > > Anaconda and PXE later). I think we could build U-Boot ourselves,
> > > especially in the case of boards where we can't brick them just by
> > > having a bad build. Generally, I don't want to distribute "BIOS"
> > > code in the longer term beyond those cases where we need to shove
> > > something on an SD Card image by nature of the way that the cards
> > > boot. In other cases, I prefer we don't build or ship something,
> > > e.g. for U-Boot where it is shipped in flash on the board or in
> > > cases where we might be able to brick a board.
> > 
> > So I can get behind (reluctantly) us building e.g. a uboot package
> > with subpackages for e.g. OMAP boards like Panda, Beagle, etc. and
> > then pulling in the result. Since we're constraining the number of
> > "whole disk" images we want to make (these are an installation
> > convenience) we can keep the set of U-Boot bits we actually build
> > fairly small. If someone has a funky board, then can put this stuff
> > together. Until we get to the future bigger ARM systems, where this
> > is a non-issue.
> > 
> > Jon.
> 
> while a bit ugly 
> http://ausil.us/packages/x-loader-1-1.fc15.src.rpm
> http://ausil.us/packages/x-loader.spec
> 
> and a binary compiled version 
> http://ausil.us/packages/x-loader-1-1.fc15.armv7hl.rpm
> 
> ive not yet tested that the built versions will actually load uboot to
> boot a system
> 
> it builds and packages up the MLO x-load.bin x-load.bin.ift for the
> supported boards from the git tree at
> git://gitorious.org/x-loader/x-loader.git
> 
> two of the boards failed to build. likely this will need a little work
> still and we probably only want to build the beagle and panda board
> versions since they are hardware we intend to support.
> 
> But the raspberry pi is a different beast and will likely need the
> board to grant an exception.
> 
> Dennis

also a quick hack on the uboot-tools spec to have it just build a
panda board uboot

http://ausil.us/packages/uboot-panda-2011.03-1.fc18.src.rpm
http://ausil.us/packages/uboot-panda.spec

and a scratch build of it 
http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=578299

realistically we only need to build uboot for the dev boards where they
cheaped out and did not install some kind of nvflash storage to boot
from

so in these packages i put everything into %{_datadir}/%{name}/

im envisioning then that the the compose tool would make a empty vfat
filesystem at the start of its rawdisk image that the deployment tool
can populate. so something like 

Partition table on image:
msdos label
part 1: 256mb vfat at start of disk (created by compose tool but empty)
part 2: rest of 2gb space all packages get installed here, including
all the kernels we install

the deployment tool can then copy the right MLO if its needed sync it,
then copy u-boot.bin run mkimage on the kernel and intramfs, and write
out boot.scr onto the vfat partition,  while many devices support ext3
for booting vfat is the most generic and universally supported. we
could even not format the boot partition that fstab would actually
mount at /boot/uboot/ then if the target device supports ext3 we could
use that instead and setup fstab appropriately there really is no need
for a separate /boot thats not going to be used for booting.  if we
make a 2gb raw disk image, in essence its the same as a livecd but can
be dd'd onto a sdcard and just boot the filesystem can be resized to
use the whole of the card. we can sparsify it and ship it compressed. 

mkimage can be run anywhere. and it doesnt need to mess with the rpmdb
on the image.  we could setup something to set a flag and remove the
unused kernels from the image on firstboot. maybe also automatically
resize the / filesystem. or add swap to the end of the partition also. 

i see this as a way we can ship something easily consumed that can be
supported by the dev boards, and other targets like the plugs where you
really dont want to or its not really feasable to run a traditional
anaconda install process.  we still need to work out how to do a
anaconda install for consumer and enterprise type devices. 


Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAk9ZCCgACgkQkSxm47BaWfeJLwCfSHEYir3JIi6h2gQxgq0SPcxG
920Anj89uLIHhbQC9TDi/BCm9biLio3R
=+5Ua
-----END PGP SIGNATURE-----