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

[Robert Nelson]

On Thu, Mar 8, 2012 at 4:01 PM, Dennis Gilmore <dennis at ausil.us> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Thu, 8 Mar 2012 13:27:36 -0600
> Dennis Gilmore <dennis at ausil.us> wrote:
>
>> -----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
>>
>
> 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/