[opensuse-arm] Beagleboard Xm CPU speed
I can't seem to get past 800MHz on the Beagleboard XM cpu clock, though the part is rated for 1GHz. The 800MHz limit can't be exceeded. Anyway around this? linux:/proc # cpufreq-info -m cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to http://bugs.opensuse.org, please. analyzing CPU 0: driver: omap CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 300 us. hardware limits: 300 MHz - 800 MHz available frequency steps: 300 MHz, 600 MHz, 800 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance current policy: frequency should be within 300 MHz and 800 MHz. The governor "userspace" may decide which speed to use within this range. current CPU frequency is 800 MHz (asserted by call to hardware). cpufreq stats: 300 MHz:0.25%, 600 MHz:0.00%, 800 MHz:99.75% (53) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi, Le 19/03/2013 08:36, gary a écrit :
I can't seem to get past 800MHz on the Beagleboard XM cpu clock, though the part is rated for 1GHz. The 800MHz limit can't be exceeded. Anyway around this?
Have a look here: * [0] : http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm... * [1] : http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm... In [0], you can modify the following lines: if (mpurate < 1000) mpurate *= 1000000; with: if (mpurate <= 1000) mpurate *= 1000000; In [1] : In omap36xx_opp_def_list[], OPP-Turbo and OPP-SB are disabled for MPU and IVA (DSP). I think it is like this in the kernel because some of TI DM3730 (ARM SoC used in BB xM) are 800 MHz and others are 1 GHz. Are all Beagleboard xM 1GHz? I do not know. Guillaume
linux:/proc # cpufreq-info -m cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to http://bugs.opensuse.org, please. analyzing CPU 0: driver: omap CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 300 us. hardware limits: 300 MHz - 800 MHz available frequency steps: 300 MHz, 600 MHz, 800 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance current policy: frequency should be within 300 MHz and 800 MHz. The governor "userspace" may decide which speed to use within this range. current CPU frequency is 800 MHz (asserted by call to hardware). cpufreq stats: 300 MHz:0.25%, 600 MHz:0.00%, 800 MHz:99.75% (53)
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 10:22-20130319, Guillaume Gardet wrote:
Hi,
Le 19/03/2013 08:36, gary a écrit :
I can't seem to get past 800MHz on the Beagleboard XM cpu clock, though the part is rated for 1GHz. The 800MHz limit can't be exceeded. Anyway around this?
Have a look here: * [0] : http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm... * [1] : http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm...
In [0], you can modify the following lines: if (mpurate < 1000) mpurate *= 1000000; with: if (mpurate <= 1000) mpurate *= 1000000;
In [1] : In omap36xx_opp_def_list[], OPP-Turbo and OPP-SB are disabled for MPU and IVA (DSP).
I think it is like this in the kernel because some of TI DM3730 (ARM SoC used in BB xM) are 800 MHz and others are 1 GHz. Are all Beagleboard xM 1GHz? I do not know. We need support of Adaptive Body Bias (ABB) and Automatic Voltage Scaling (AVS) to support 1GHz completely. ABB is mandatory and the support is not available upstream. -- Regards, Nishanth Menon -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 19/03/2013 15:38, Nishanth Menon a écrit : > On 10:22-20130319, Guillaume Gardet wrote: >> Hi, >> >> Le 19/03/2013 08:36, gary a écrit : >>> I can't seem to get past 800MHz on the Beagleboard XM cpu clock, though the part is rated for 1GHz. The 800MHz limit can't be exceeded. Anyway around this? >> Have a look here: >> * [0] : http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/clock.c >> * [1] : http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/opp3xxx_data.c >> >> In [0], you can modify the following lines: >> if (mpurate < 1000) >> mpurate *= 1000000; >> with: >> if (mpurate <= 1000) >> mpurate *= 1000000; >> >> In [1] : >> In omap36xx_opp_def_list[], OPP-Turbo and OPP-SB are disabled for MPU and IVA (DSP). >> >> I think it is like this in the kernel because some of TI DM3730 (ARM SoC used in BB xM) are 800 MHz and others are 1 GHz. Are all Beagleboard xM 1GHz? I do not know. > We need support of Adaptive Body Bias (ABB) and Automatic Voltage > Scaling (AVS) to support 1GHz completely. ABB is mandatory and the > support is not available upstream. Interesting. Is there any patch available around to enable it? Did you notice that CPU bogomips of 3.7* kernel felled down? Any idea why? Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 15:42-20130319, Guillaume Gardet wrote: > > Le 19/03/2013 15:38, Nishanth Menon a écrit : > >On 10:22-20130319, Guillaume Gardet wrote: > >>Hi, > >> > >>Le 19/03/2013 08:36, gary a écrit : > >>>I can't seem to get past 800MHz on the Beagleboard XM cpu clock, though the part is rated for 1GHz. The 800MHz limit can't be exceeded. Anyway around this? > >>Have a look here: > >>* [0] : http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/clock.c > >>* [1] : http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/opp3xxx_data.c > >> > >>In [0], you can modify the following lines: > >> if (mpurate < 1000) > >> mpurate *= 1000000; > >>with: > >> if (mpurate <= 1000) > >> mpurate *= 1000000; > >> > >>In [1] : > >>In omap36xx_opp_def_list[], OPP-Turbo and OPP-SB are disabled for MPU and IVA (DSP). > >> > >>I think it is like this in the kernel because some of TI DM3730 (ARM SoC used in BB xM) are 800 MHz and others are 1 GHz. Are all Beagleboard xM 1GHz? I do not know. > >We need support of Adaptive Body Bias (ABB) and Automatic Voltage > >Scaling (AVS) to support 1GHz completely. ABB is mandatory and the > >support is not available upstream. > > Interesting. Is there any patch available around to enable it? There was an RFC patch which steve did mention in the passing that it had'nt worked on overo http://marc.info/?l=linux-arm-kernel&m=135040721419073&w=2 I have'nt dug there yet. We are working to move to DTS based solution - hopefully we'd have ABB as part of that. > > Did you notice that CPU bogomips of 3.7* kernel felled down? Any idea why? I have'nt noticed that yet :( -> might be good to provide your observations on linux-omap@vger.kernel.org -- Regards, Nishanth Menon -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 19/03/2013 16:02, Nishanth Menon a écrit : > On 15:42-20130319, Guillaume Gardet wrote: >> Le 19/03/2013 15:38, Nishanth Menon a écrit : >>> On 10:22-20130319, Guillaume Gardet wrote: >>>> Hi, >>>> >>>> Le 19/03/2013 08:36, gary a écrit : >>>>> I can't seem to get past 800MHz on the Beagleboard XM cpu clock, though the part is rated for 1GHz. The 800MHz limit can't be exceeded. Anyway around this? >>>> Have a look here: >>>> * [0] : http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/clock.c >>>> * [1] : http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/opp3xxx_data.c >>>> >>>> In [0], you can modify the following lines: >>>> if (mpurate < 1000) >>>> mpurate *= 1000000; >>>> with: >>>> if (mpurate <= 1000) >>>> mpurate *= 1000000; >>>> >>>> In [1] : >>>> In omap36xx_opp_def_list[], OPP-Turbo and OPP-SB are disabled for MPU and IVA (DSP). >>>> >>>> I think it is like this in the kernel because some of TI DM3730 (ARM SoC used in BB xM) are 800 MHz and others are 1 GHz. Are all Beagleboard xM 1GHz? I do not know. >>> We need support of Adaptive Body Bias (ABB) and Automatic Voltage >>> Scaling (AVS) to support 1GHz completely. ABB is mandatory and the >>> support is not available upstream. >> Interesting. Is there any patch available around to enable it? > There was an RFC patch which steve did mention in the passing that it > had'nt worked on overo > http://marc.info/?l=linux-arm-kernel&m=135040721419073&w=2 > I have'nt dug there yet. We are working to move to DTS based solution - > hopefully we'd have ABB as part of that. Ok. Is there a place to know the support status of device tree boards? For beagleboard (xM) for example. >> Did you notice that CPU bogomips of 3.7* kernel felled down? Any idea why? > I have'nt noticed that yet :( -> might be good to provide your > observations on linux-omap@vger.kernel.org > Done right now. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 16:21-20130319, Guillaume Gardet wrote: > > Le 19/03/2013 16:02, Nishanth Menon a écrit : > >On 15:42-20130319, Guillaume Gardet wrote: > >>Le 19/03/2013 15:38, Nishanth Menon a écrit : > >>>On 10:22-20130319, Guillaume Gardet wrote: > >>>>Hi, > >>>> > >>>>Le 19/03/2013 08:36, gary a écrit : > >>>>>I can't seem to get past 800MHz on the Beagleboard XM cpu clock, though the part is rated for 1GHz. The 800MHz limit can't be exceeded. Anyway around this? > >>>>Have a look here: > >>>>* [0] : http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/clock.c > >>>>* [1] : http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/opp3xxx_data.c > >>>> > >>>>In [0], you can modify the following lines: > >>>> if (mpurate < 1000) > >>>> mpurate *= 1000000; > >>>>with: > >>>> if (mpurate <= 1000) > >>>> mpurate *= 1000000; > >>>> > >>>>In [1] : > >>>>In omap36xx_opp_def_list[], OPP-Turbo and OPP-SB are disabled for MPU and IVA (DSP). > >>>> > >>>>I think it is like this in the kernel because some of TI DM3730 (ARM SoC used in BB xM) are 800 MHz and others are 1 GHz. Are all Beagleboard xM 1GHz? I do not know. > >>>We need support of Adaptive Body Bias (ABB) and Automatic Voltage > >>>Scaling (AVS) to support 1GHz completely. ABB is mandatory and the > >>>support is not available upstream. > >>Interesting. Is there any patch available around to enable it? > >There was an RFC patch which steve did mention in the passing that it > >had'nt worked on overo > >http://marc.info/?l=linux-arm-kernel&m=135040721419073&w=2 > >I have'nt dug there yet. We are working to move to DTS based solution - > >hopefully we'd have ABB as part of that. > > Ok. Is there a place to know the support status of device tree boards? For beagleboard (xM) for example. Nothing other than what you'd find in arch/arm/boot/dts - there is unfortunately no elinux.org or equivalent wiki anyone seems to be maintaining :( > > >>Did you notice that CPU bogomips of 3.7* kernel felled down? Any idea why? > >I have'nt noticed that yet :( -> might be good to provide your > >observations on linux-omap@vger.kernel.org > > > > Done right now. Thanks. -- Regards, Nishanth Menon -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
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 U-Boot 2011.09 (Sep 08 2012 - 02:13:25) OMAP36XX/37XX-GP ES1.2, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz OMAP3 Beagle board + LPDDR/NAND I2C: ready DRAM: 512 MiB WARNING: Caches not enabled NAND: 0 MiB MMC: OMAP SD/MMC: 0 *** Warning - readenv() failed, using default environment In: serial Out: serial Err: serial Beagle xM Rev C No EEPROM on expansion board Die ID #67dc00029ff80000016849a90401601a Net: No ethernet found. Hit any key to stop autoboot: 0 The user button is currently NOT pressed. SD/MMC found on device 0 Loading file "uEnv.txt" from mmc device 0:1 (xxa1) ** File not found uEnv.txt Loading file "boot.scr" from mmc device 0:1 (xxa1) 711 bytes read Loaded script from boot.scr Running bootscript from mmc0 ... ## Executing script at 80200000 ## Error: "kerneladdr" not defined ## Error: "ramdiskaddr" not defined Loading file "uImage" from mmc device 0:1 (xxa1) 4242344 bytes read Loading file "initrd" from mmc device 0:1 (xxa1) 12464100 bytes read ## Booting kernel from Legacy Image at 88000000 ... Image Name: Linux-3.7.9-0-omap2plus Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 4242280 Bytes = 4 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 81600000 ... Image Name: Initrd Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 12464036 Bytes = 11.9 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
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. using my DTS cpufreq series (which I am about to post to linux-omap): https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-oma... and a test script: http://pastebin.com/zrr8ptge
I See (3.9-rc3): http://pastebin.com/4JCV3dnX bogomips@ boot: BogoMIPS : 395.67 Boot scaling frequency =600000 TESTING for 1 seconds at 300000 current scaling frequency(for 300000) =300000 bogomips@ frequency 300000: BogoMIPS : 197.83 TESTING for 1 seconds at 600000 current scaling frequency(for 600000) =600000 bogomips@ frequency 600000: BogoMIPS : 395.67 TESTING for 1 seconds at 800000 current scaling frequency(for 800000) =800000 bogomips@ frequency 800000: BogoMIPS : 527.56 -- Regards, Nishanth Menon -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
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.
using my DTS cpufreq series (which I am about to post to linux-omap): https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-oma... and a test script: http://pastebin.com/zrr8ptge
I See (3.9-rc3): http://pastebin.com/4JCV3dnX
bogomips@ boot: BogoMIPS : 395.67 Boot scaling frequency =600000 TESTING for 1 seconds at 300000 current scaling frequency(for 300000) =300000 bogomips@ frequency 300000: BogoMIPS : 197.83 TESTING for 1 seconds at 600000 current scaling frequency(for 600000) =600000 bogomips@ frequency 600000: BogoMIPS : 395.67 TESTING for 1 seconds at 800000 current scaling frequency(for 800000) =800000 bogomips@ frequency 800000: BogoMIPS : 527.56
Still lower than 3.4.6 kernel but higher than 3.7.10. Strange. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
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 -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
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 -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-----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----- -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
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 -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-----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----- -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 10.05.2013 um 20:51 schrieb 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.
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 -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
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@denx.de Always try to do things in chronological order; it's less confusing that way. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 11.05.2013 um 02:08 schrieb 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.
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 -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 3/19/2013 9:04 AM, Nishanth Menon wrote:
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. using my DTS cpufreq series (which I am about to post to linux-omap): https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-oma... and a test script: http://pastebin.com/zrr8ptge
I See (3.9-rc3): http://pastebin.com/4JCV3dnX
bogomips@ boot: BogoMIPS : 395.67 Boot scaling frequency =600000 TESTING for 1 seconds at 300000 current scaling frequency(for 300000) =300000 bogomips@ frequency 300000: BogoMIPS : 197.83 TESTING for 1 seconds at 600000 current scaling frequency(for 600000) =600000 bogomips@ frequency 600000: BogoMIPS : 395.67 TESTING for 1 seconds at 800000 current scaling frequency(for 800000) =800000 bogomips@ frequency 800000: BogoMIPS : 527.56
------------------------------- linux:~/Documents # ./cputest memtester: no process found 300000 600000 800000 is the available freqs bogomips@ boot: BogoMIPS : 169.35 Boot scaling frequency =300000 TESTING for 1 seconds at 300000 current scaling frequency(for 300000) =300000 bogomips@ frequency 300000: BogoMIPS : 169.35 TESTING for 1 seconds at 600000 current scaling frequency(for 600000) =600000 bogomips@ frequency 600000: BogoMIPS : 338.70 TESTING for 1 seconds at 800000 current scaling frequency(for 800000) =800000 bogomips@ frequency 800000: BogoMIPS : 450.61 Clearly I don't get the same specs for the same clock rates. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 19/03/2013 17:25, gary a écrit :
On 3/19/2013 9:04 AM, Nishanth Menon wrote:
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. using my DTS cpufreq series (which I am about to post to linux-omap): https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-oma... and a test script: http://pastebin.com/zrr8ptge
I See (3.9-rc3): http://pastebin.com/4JCV3dnX
bogomips@ boot: BogoMIPS : 395.67 Boot scaling frequency =600000 TESTING for 1 seconds at 300000 current scaling frequency(for 300000) =300000 bogomips@ frequency 300000: BogoMIPS : 197.83 TESTING for 1 seconds at 600000 current scaling frequency(for 600000) =600000 bogomips@ frequency 600000: BogoMIPS : 395.67 TESTING for 1 seconds at 800000 current scaling frequency(for 800000) =800000 bogomips@ frequency 800000: BogoMIPS : 527.56
------------------------------- linux:~/Documents # ./cputest memtester: no process found 300000 600000 800000 is the available freqs bogomips@ boot: BogoMIPS : 169.35 Boot scaling frequency =300000 TESTING for 1 seconds at 300000 current scaling frequency(for 300000) =300000 bogomips@ frequency 300000: BogoMIPS : 169.35 TESTING for 1 seconds at 600000 current scaling frequency(for 600000) =600000 bogomips@ frequency 600000: BogoMIPS : 338.70 TESTING for 1 seconds at 800000 current scaling frequency(for 800000) =800000 bogomips@ frequency 800000: BogoMIPS : 450.61
Clearly I don't get the same specs for the same clock rates.
Me either, here are my results: linux:~ # ./cputest memtester: no process found 300000 600000 800000 is the available freqs bogomips@ boot: BogoMIPS : 175.65 Boot scaling frequency =300000 TESTING for 1 seconds at 300000 current scaling frequency(for 300000) =300000 bogomips@ frequency 300000: BogoMIPS : 175.65 TESTING for 1 seconds at 600000 current scaling frequency(for 600000) =600000 bogomips@ frequency 600000: BogoMIPS : 350.31 TESTING for 1 seconds at 800000 current scaling frequency(for 800000) =800000 bogomips@ frequency 800000: BogoMIPS : 467.41 Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 17:31-20130319, Guillaume Gardet wrote:
Le 19/03/2013 17:25, gary a écrit :
On 3/19/2013 9:04 AM, Nishanth Menon wrote:
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. using my DTS cpufreq series (which I am about to post to linux-omap): https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-oma... and a test script: http://pastebin.com/zrr8ptge
I See (3.9-rc3): http://pastebin.com/4JCV3dnX
bogomips@ boot: BogoMIPS : 395.67 Boot scaling frequency =600000 TESTING for 1 seconds at 300000 current scaling frequency(for 300000) =300000 bogomips@ frequency 300000: BogoMIPS : 197.83 TESTING for 1 seconds at 600000 current scaling frequency(for 600000) =600000 bogomips@ frequency 600000: BogoMIPS : 395.67 TESTING for 1 seconds at 800000 current scaling frequency(for 800000) =800000 bogomips@ frequency 800000: BogoMIPS : 527.56
------------------------------- linux:~/Documents # ./cputest memtester: no process found 300000 600000 800000 is the available freqs bogomips@ boot: BogoMIPS : 169.35 Boot scaling frequency =300000 TESTING for 1 seconds at 300000 current scaling frequency(for 300000) =300000 bogomips@ frequency 300000: BogoMIPS : 169.35 TESTING for 1 seconds at 600000 current scaling frequency(for 600000) =600000 bogomips@ frequency 600000: BogoMIPS : 338.70 TESTING for 1 seconds at 800000 current scaling frequency(for 800000) =800000 bogomips@ frequency 800000: BogoMIPS : 450.61
Clearly I don't get the same specs for the same clock rates.
Me either, here are my results: linux:~ # ./cputest memtester: no process found 300000 600000 800000 is the available freqs bogomips@ boot: BogoMIPS : 175.65 Boot scaling frequency =300000 TESTING for 1 seconds at 300000 current scaling frequency(for 300000) =300000 bogomips@ frequency 300000: BogoMIPS : 175.65 TESTING for 1 seconds at 600000 current scaling frequency(for 600000) =600000 bogomips@ frequency 600000: BogoMIPS : 350.31 TESTING for 1 seconds at 800000 current scaling frequency(for 800000) =800000 bogomips@ frequency 800000: BogoMIPS : 467.41
Here are some of the platform bogomips I collected no SMP: beaglebone(rev A6a) - AM33xx compatible - http://pastebin.com/PUx5h6Jy beagleboard (rev C1D) - OMAP3430 compatible - http://pastebin.com/SycCinFb (DT) http://pastebin.com/qwJHw9Ev (no DT) omap3-beagle-xm -OMAP3630 compatible - http://pastebin.com/tVEXeVZC SMP systems: Pandaboard -(OMAP4430 ES2.2) verified with omapconf - http://pastebin.com/cAtytfW0 Pandaboard-ES -(OMAP4460 ES1.1) verified with omapconf - http://pastebin.com/3EymNTMp Seems like SMP systems give closer-to-expected-data.. funny behavior though.. -- Regards, Nishanth Menon -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (7)
-
Alexander Graf -
gary -
gary -
Guillaume Gardet -
Nishanth Menon -
Tom Rini -
Wolfgang Denk