On Thu, Mar 8, 2012 at 4:01 PM, Dennis Gilmore <dennis@xxxxxxxx> wrote: > -----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 Some pretty important beagle cherry picks, you guys should look at for the Beagle family: support the real c4: (this was missed in the X-Loader -> U-boot conversion..) http://git.denx.de/?p=u-boot.git;a=commit;h=223b8aa42c0f4bf9b4a7a71c16d0f67b5faf5045 fix mmc timeout messages on the xM: http://git.denx.de/?p=u-boot.git;a=commit;h=a7778f8fbee098c78b1fa1e1331313a7e217fb30 leave cache enabled (there's about a 50% speed hit without this patch, kernel 3.2.x, gcc regression testing) http://git.denx.de/?p=u-boot.git;a=commit;h=f1f2c3ca9f837985cc1f4bc3821ac1763430cdcf Regards, -- Robert Nelson http://www.rcn-ee.com/ _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
