[U-Boot] Beagle-XM: u-boot SPL fat support (was Re: [opensuse-arm] Beagleboard Xm CPU speed)
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.
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
-----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
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
-----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
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
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
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
participants (4)
-
Alexander Graf -
Nishanth Menon -
Tom Rini -
Wolfgang Denk