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

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

[Nishanth Menon]

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

I am ccying u-boot Mailing list to see how we can help.
-- 
Regards,
Nishanth Menon

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

[Alexander Graf]

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.

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


Alex

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

[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

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

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

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

[Wolfgang Denk]

Dear Alexander,

In message <154A1277-6344-4AB8-9D98-58BBCC38C0F3@suse.de> you wrote:
> 
> 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 :).

Well, this all depends on which resources are available on the SoC
in question.  If all you have is 4 kB on chip memory, then you will
not be able to load the file system code at all.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Always try to do things in chronological order; it's  less  confusing
that way.

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

[Alexander Graf]

Am 11.05.2013 um 02:08 schrieb Wolfgang Denk <wd@denx.de>:

> Dear Alexander,
> 
> In message <154A1277-6344-4AB8-9D98-58BBCC38C0F3@suse.de> you wrote:
>> 
>> 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 :).
> 
> Well, this all depends on which resources are available on the SoC
> in question.  If all you have is 4 kB on chip memory, then you will
> not be able to load the file system code at all.

Sure, and different boards also have different IO channels. But couldn't we define at least some tiers, with capable enough boards to run standard distros at least getting unified?

If you need to tailor the OS you want to execute there's little point in unifying the boot method for it. It's very valuable to have defaults across the board once you can run the same kernel and user space though.


Alex