-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 8 Mar 2012 13:27:36 -0600 Dennis Gilmore <dennis@xxxxxxxx> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Thu, 8 Mar 2012 12:57:44 -0600 > Dennis Gilmore <dennis@xxxxxxxx> wrote: > > > -----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 > > 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 > to further follow up ive updated uboot to 2011.12 release from 2011.03 tools have been built on primary arches uboot-panda: http://ausil.us/packages/uboot-panda-2011.12-1.fc18.src.rpm http://ausil.us/packages/uboot-panda.spec http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=578641 uboot-origen: http://ausil.us/packages/uboot-origen-2011.12-1.fc18.src.rpm http://ausil.us/packages/uboot-origen.spec http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=578843 uboot-beagle: http://ausil.us/packages/uboot-beagle-2011.12-1.fc18.src.rpm http://ausil.us/packages/uboot-beagle.spec http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=578937 Dennis -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk9ZLDEACgkQkSxm47BaWfcY6wCdHOhCVgC4+yGiRK57oi7I7bxs VRUAnifZk+ITjHGAcJv7JuBiTlE0z1V4 =M8sj -----END PGP SIGNATURE----- _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
