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

[Tom Rini]

-----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.

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRjUGdAAoJENk4IS6UOR1W8nYP+gPArBP31donUe0TZfPsC0ef
aHwe7shOJp6ZGWMeRii9wzkByYXo2MlFvNyYALEm7cl9PYmngCILuLpQDerhKTFZ
G6CQbUSyYhENj5eWQJWZJwFfO58nfVdDTXYT6yFjLGMeZI7bE+khGFsAtounR5Ag
XtNUfVbRh9KxS0SJ+kE2uYjfi/BmW2eru8L+Z4Em0jb+Od1HsOVqIlNUOKkb/XEo
ZLNuAqRr20ysu3EwF9j0VLBjFNNuR+cGceWJZGRY8u+Xkd/3eCzIRs8m4Gge/ePn
XqDEmQZpCeFxosYCfSvmLvp26rTUVZm8oCBTMfCWXOn1Mx9AMmbbg1jnPNENY3Xk
ck8+Wy8AmZ+JVAi33v8otdmHeeXoTW4QGpL2ZnG45rOkGoRAxEgL75ARCAYFSEax
nk+nvIu6+xnPm8af0UzW1FkO3qkYuId0Wr+WGIPkkGQJu2PthEFgTIY4+aIv+/x8
31pvXFXgVIFubCue47OzR6vBkqvoeK9ZSU0XmGgsEPgOksZ1xI4xs4/5pmDW94yF
rmNlhG3mFRv1kiNkUCObXfNuhvSFQNhe/E56cquoHRzuE61rRtWn0dL5rBhKmruB
e5QQG8PDuLcUuUqfrFA009qW0cqDFw38Aqobrm+R6LygPeWSpIBQarhCrpkkjKxO
AyXKj8GUHAHJH0Kqu/HY
=GpkC
-----END PGP SIGNATURE-----