Am 10.05.2013 um 20:51 schrieb Tom Rini <[email protected]>:
> -----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 mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
