-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, 08 Mar 2012 13:12:39 -0500
Jon Masters <jcm(a)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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEARECAAYFAk9ZAS0ACgkQkSxm47BaWffSTgCdFAx2m39a7LuXJ+XxzRZrSPJ7
wIIAn3fH34QdJ/52QGg32qtKjjFlK9JS
=VDOa
-----END PGP SIGNATURE-----