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

[Alexander Graf]

Am 10.05.2013 um 20:51 schrieb Tom Rini <trini at ti.com>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 05/10/2013 02:31 PM, Alexander Graf wrote:
>> 
>> 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 :).
> 
> Yay!
> 
>>>>> 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 :).
> 
> You should just be able to provide a uEnv.txt with your custom
> actual-boot command as uenvcmd.  What CMD defines do you need?  I'm
> quite open to enabling more as needed for real world cases.

Well, that would make the situation on OMAP slightly better, but wouldn't help on other SoCs. I think we should rather try and get a reasonably unified boot environment up across the board first :).

Worst case I would only have to s/fat/ext2/g at a single spot then. Or enable dynamic fs detection and use the respective helpers at that one spot.


Alex