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

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

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

iQIcBAEBAgAGBQJRSOK8AAoJENk4IS6UOR1WXc8QAJzBskxLej6HvMizXpG/g2ob
YiYwGJnzoJ5lng1UReQKEMnVgwYIx1tLSzvq0Y0zxDIucgKkfnSJPajHgwEeAJAy
mhVQTR2vPq6CZpqWSed/bY0uvr1z713gwlhDz6ep2pnPIHK0UTmNw6L0EuaKQ5tw
CkFoEEhVBdfkqxtsheKVZmH33WgzSDad84ohdI6Lmgx3yMYshCRU2J5bZ8cwxu/6
rxQ45lS5TX3V6RfpyAHm20xk7NYNHewQagulZ4IOsFCN627+wYIDqAcNwplr4W3Z
97Izu0IILcH9i/ayiAKjbK6/TSO7GG4zvM5jXqRrfyHOBp5t9nle7HpT4AKaa07+
KwypNQdRKHmhlqCq3nqM7rz6S0ZeTku5rruTYo443B3Vk43saAplOBPpJgSfsRAO
O6zsJe34fEMa1vy6IvZFul1cRC9n9yWrCANj3ip0pLcOE2s7DRjYWA+lrAKkwDNk
tA2hEzdxd/jnlsm6PpAQ4liDmvTlSe8BzSuQhhalC+Mq5QnTvmQwmIPsRWooFjhs
BjxCkfrtZkixNitxMB0Rax8ziGa3LWBpp2R70qoKhH1a9zQo2kVWzlS1GBB69aV+
DIQR/TmCfBH4IbXe+5itG70fCGUBx8amBHvzN4MXiuI3NY56hR2s2gUZLw5pA9HA
3yLW06fCHx93o54KLLRH
=HmdZ
-----END PGP SIGNATURE-----