-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 08 Mar 2012 13:12:39 -0500 Jon Masters <jcm@xxxxxxxxxx> 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk9ZAS0ACgkQkSxm47BaWffSTgCdFAx2m39a7LuXJ+XxzRZrSPJ7 wIIAn3fH34QdJ/52QGg32qtKjjFlK9JS =VDOa -----END PGP SIGNATURE----- _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm