[U-Boot] Beagle-XM: u-boot SPL fat support (was Re: [opensuse-arm] Beagleboard Xm CPU speed)

[Alexander Graf]

On 19.03.2013, at 23:12, Tom Rini wrote:

> On 03/19/2013 03:53 PM, Alexander Graf wrote:
> > 
> > On 19.03.2013, at 18:01, Nishanth Menon wrote:
> > 
> >> Change in subject. Original thread start: 
> >> http://lists.opensuse.org/opensuse-arm/2013-03/msg00076.html
> >> 
> >> On 17:15-20130319, Guillaume Gardet wrote:
> >>> 
> >>> Le 19/03/2013 17:04, Nishanth Menon a йcrit :
> >>>> On 08:47-20130319, gary wrote:
> >>>>> Just a FYI, here is the the boot text dumped to the serial
> >>>>> port. It indicates a 1GHz max clock rate, but maybe that is
> >>>>> just a "capability" of the board (as in a designation) and
> >>>>> not a parameter that has been set.
> >>>>> 
> >>>>> I see in the boot text there is a way to interrupt the
> >>>>> automatic boot, which I presume is a way to set parameters.
> >>>>> Could someone give me what such a line would look like for
> >>>>> forcing the mpurate?
> >>>>> 
> >>>>> --------------------------------------- Texas Instruments
> >>>>> X-Loader 1.5.0 (Sep  8 2012 - 02:21:18) Beagle xM Reading
> >>>>> boot sector Error: reading boot sector fat load failed,
> >>>>> trying ext2 Loading u-boot.bin from mmc
> >>>> Why are we still using old x-loader - we should be using SPL
> >>>> MLO from u-boot master - it works straight on beagleXM.
> >>> 
> >>> Our last tests with SPL and latest u-boot were unsuccessful!
> >>> And we have to port ext2 support to it because we have no FAT
> >>> partition.
> >> Quote from an internal query I just did: "There shouldn't be a 
> >> case where xM has memory that X-Loader works for that SPL did
> >> not.
> > 
> > The issue was that with SPL and proper upstream u-boot from ~fall
> > last year, my beagleboard xm was unstable. It constantly crashed.
> > So I reverted back to the old x-loader booting, as that kept things
> > stable.
> 
> If you can try current U-Boot or provide more details about the
> instability I'd appreciate it.

Alrighty, we switched all images to upstream SPL now. Let's see what happens :).

> 
> > 
> >> There _may_ be a UART issue that needs work-arounding however.
> >> And of course if they used mainline they could pretty easily do
> >> RAW for SPL/U-Boot.img and then do everything else with ext2/3/4
> >> and ignore FAT.
> > 
> > The "default" that we stuck with so far (though we can certainly
> > change that) is to keep u-boot as a file in ext2, so that it can
> > easily be updated. That maybe wasn't the most clever decision and
> > going with raw is the way to go, but it's what we do today.
> 
> That's fine and a decent idea.  I'd be happy to review patches to make
> this a clean option in SPL, even.  A plus of moving to mainline would
> be that ext4 is supported now too.

Oh, with recent u-boot and the SPL approach for OMAP this already is a pretty clean option. You only need to enable the CMD defines and change the default bootcmd :).


Alex