[fedora-arm] BeagleBone Black cannot boot with Fedora 34/35

2021-10-22 Thread Zamir SUN

Hi,

Recently I reflashed my BeagleBone Black. However, I find it simply 
cannot go beyond uboot with Fedora 34 or Fedora 35.


Images I tried:
Fedora-Minimal-35-20211020.n.0.armhfp.raw.xz
Fedora-Minimal-34-1.2.armhfp.raw.xz

If I press the button when plug the power cable, it will loop forever 
like the following


U-Boot SPL 2021.10 (Oct 14 2021 - 00:00:00 +)
Trying to boot from MMC1

U-Boot SPL 2021.10 (Oct 14 2021 - 00:00:00 +)
Trying to boot from MMC1

U-Boot SPL 2021.10 (Oct 14 2021 - 00:00:00 +)
Trying to boot from MMC1

U-Boot SPL 2021.10 (Oct 14 2021 - 00:00:00 +)
Trying to boot from MMC1

If I don't press the button it will boot directly to the system in emmc.

I've tried different tf cards and concluded it's not the card issue.

The latest image that works for me on BBB is
Fedora-Minimal-armhfp-33-1.2-sda.raw.xz

It's interesting that the image has a different name schema that F34/F35 
ones(the sda in filename). I roughly remember I also tried F33 without 
'sda' - Fedora-Minimal-33-1.3.armhfp.raw.xz and IIRC this also cannot boot.


So is there any different for images with or without -sda ? Can anyone 
offer some suggestions how I can test or boot F35 on BBB?


Thanks in advance!

--
Zamir SUN
GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E
Want to know more about Fedora?
Visit https://fedoraproject.org/wiki/
Ready to contribute? See https://whatcanidoforfedora.org/
想了解更多中文资讯,访问 https://zh.fedoracommunity.org/
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


[fedora-arm] Beaglebone Black Support

2020-08-10 Thread Pete Bowden
Hi All - What's the status of support for Fedora on Beaglebone Black? I find 
references to a old version working on BBB, but nothing recently. Anyone 
working on making it function?
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org


[fedora-arm] BeagleBone Black status on Rawhide-20170223

2017-02-24 Thread Zamir SUN

Hi,
I tried BB Black again on Rawhide, with compose 20170223.

In short GNOME/LXDE still not showing up after boot.

I did not find anything useful in the LXDE image boot log, but see many 
tilcdc error in Workstation image boot log like the following

tilcdc 4830e000.lcdc: failed to allocate buffer with size 8294400

Most of the console logs are recorded to the following link

https://zsun.fedorapeople.org/pub/bugs/Fedora-Workstation-armhfp-Rawhide-20170223-log.txt

I find this link when googling for the tilcdc line
http://www.spinics.net/lists/dri-devel/msg102380.html

Is this relevant?

HTH.
--
Ziqian SUN (Zamir)
z...@fedoraproject.org
GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E
Want to know more about Fedora?
Visit https://fedoraproject.org/wiki/
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org


[fedora-arm] BeagleBone Black status on Rawhide-20170120

2017-02-23 Thread Zamir SUN

Hi,

So recently I tried armhfp of Rawhide-20170120.
Things did not go smooth. First I tried Workstation, but GNOME did not 
show up. I thought it is simply because BeagleBone Black is not strong 
enough so I tried LXDE instead. However still no lucky after a long wait 
(more than 20 minutes).


During the LXDE image boot, I find a lot of
"alloc_contig_range: [94bfc, 94c00) PFNs busy"

I just updated uboot, so it should not be things related with uboot.
Is this a known bug? If needed I can file a bug to track this.

I uploaded part my boot log (on serial console) here
https://zsun.fedorapeople.org/pub/bugs/Fedora-LXDE-armhfp-Rawhide-20170120-log.txt
--
Ziqian SUN (Zamir)
z...@fedoraproject.org
GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E
Want to know more about Fedora?
Visit https://fedoraproject.org/wiki/
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org


[fedora-arm] Beaglebone Black

2015-12-28 Thread Robert Moskowitz

I am trying to help out someone that has a BBB.  I am looking at:

https://fedoraproject.org/wiki/Architectures/ARM/F23/Installation

and the files referred to at:

http://pwhalen.fedorapeople.org/Fedora/23/Beta/beaglebone/

do not exist.

What is the current status for BBB and F23?

thank you.

And is it covered in the fedora-installer-script?  I don't see it in the 
board.d directory.  I do see some uboot files in the F23 image.


thank you

___
arm mailing list
arm@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org


Re: [fedora-arm] beaglebone black GPIO questions

2015-01-23 Thread Bram Van Steenlandt

op 22-01-15 18:01, Peter Robinson schreef:

On Thu, Jan 22, 2015 at 4:48 PM, Bram Van Steenlandt b...@diomedia.be wrote:

Hi,

I installed fedora 21 on a beaglebone black, I was amazed how easy this was
and how well most things work.

Good news.


I can't seem to get GPIO working, first dtc needed a patch for the -@
option, after I finally seem to got that working
I now find I have no
/sys/devices/bone_capemgr* directory.

The capemgr bits are a custom kernel from BBone that never made it
upstream. The ability to do DeviceTree overlays only landed mainline
in 3.19 so you would need at 3.19rc5 [1] or later Fedora kernel. I've
got as far as testing that the kernel boots on the BBB with the kernel
with overlays enabled but not had enough time to test them.
Ok, then I would like to avoid them, I'm hoping to also run freebsd in 
the future and I don't think they they will have the device tree overlay 
stuff.



Can anyone here confirm the status of GPIO (and other cape features) ? does
it require a custom kernel ? Am I missing someting ?

GPIO works, it doesn't need capes to do that. Basically overlays are
just a means of automating the configuration of all features on a
particular addon card whether you call it a cape, a hat or an
expansion board.

Depending on what device you're trying to configure you might just be
able to do it with a basic script.

output works by doing:
echo 48  /sys/class/gpio/export
echo out   /sys/class/gpio/gpio48/direction
echo 1  /sys/class/gpio/gpio48/value

however, for the input I need to enable the pull up resistor ( I think).

cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins | grep pin 46
pin 46 (44e108b8.0) 0008 pinctrl-single
I need to change this (0008) but can't seem to figure out how.
The board I'm trying to use has a dts file saying:
0x030 0x37 /* INPUT MODE7 pullup */
Is there an equivalent to achieve this without a dts file ?

All information I found seems to point either to the device tree overlay 
stuff

or /sys/kernel/debug/omap_mux/gmpc*
all I have here is a subdirectory board which is empty.

Thx



Peter

[1] http://koji.fedoraproject.org/koji/buildinfo?buildID=604938


___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] beaglebone black GPIO questions

2015-01-22 Thread Peter Robinson
On Thu, Jan 22, 2015 at 4:48 PM, Bram Van Steenlandt b...@diomedia.be wrote:
 Hi,

 I installed fedora 21 on a beaglebone black, I was amazed how easy this was
 and how well most things work.

Good news.

 I can't seem to get GPIO working, first dtc needed a patch for the -@
 option, after I finally seem to got that working
 I now find I have no
 /sys/devices/bone_capemgr* directory.

The capemgr bits are a custom kernel from BBone that never made it
upstream. The ability to do DeviceTree overlays only landed mainline
in 3.19 so you would need at 3.19rc5 [1] or later Fedora kernel. I've
got as far as testing that the kernel boots on the BBB with the kernel
with overlays enabled but not had enough time to test them.

 Can anyone here confirm the status of GPIO (and other cape features) ? does
 it require a custom kernel ? Am I missing someting ?

GPIO works, it doesn't need capes to do that. Basically overlays are
just a means of automating the configuration of all features on a
particular addon card whether you call it a cape, a hat or an
expansion board.

Depending on what device you're trying to configure you might just be
able to do it with a basic script.

Peter

[1] http://koji.fedoraproject.org/koji/buildinfo?buildID=604938
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] beaglebone black GPIO questions

2015-01-22 Thread Bram Van Steenlandt

Hi,

I installed fedora 21 on a beaglebone black, I was amazed how easy this 
was and how well most things work.


I can't seem to get GPIO working, first dtc needed a patch for the -@ 
option, after I finally seem to got that working

I now find I have no
/sys/devices/bone_capemgr* directory.

Can anyone here confirm the status of GPIO (and other cape features) ? 
does it require a custom kernel ? Am I missing someting ?


Thx
Bram
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] BeagleBone Black CPU speed

2014-01-22 Thread Robert Nelson
On Tue, Jan 21, 2014 at 10:09 PM, Steve Underwood ste...@coppice.org wrote:
 Hi Peter,


 On 01/22/2014 04:14 AM, Peter Robinson wrote:

 It looks like the BeagleBone Black is still running at 550MHz with the
 latest Fedora 20. Does anyone know what is holding it back from running
 at
 1GHz? Is the a uboot thing, or a kernel thing, or something else? I saw
 a
 version of uboot referred to as making the BBB run at 1GHz, but when I
 tried
 experimenting with that I got the same 550MHz clock speed.

 If you're interested could you try the kernel-3.13.0-1.1.fc20 scratch
 kernel [1] on your BBBlack. It should add freq scaling support and you
 should be able to tell if it detects it appropriately if the
 cpufreq-cpu0 module loads. Feedback welcome.

 So that kernel works with my testing but the module doesn't auto load
 the cpufreq-cpu0 module. If you do:

 modprobe cpufreq-cpu0

 You then get:
 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
 30 60 80 100

 Even with 3.12.8 you can manually load that module and it works but
 you only get up to 720mhz.

 Peter

 [1]
 http://pbrobinson.fedorapeople.org/arm-kernel/kernel-3.13.0-1.1.fc20.armv7hl.rpm

 Earlier Jos Vos reported the following results for his BeagleBoneBlack
 running pystone.py

 Fedora:
 Pystone(1.1) time for 5 passes = 10.9073
 This machine benchmarks at 4584.1 pystones/second

Which governor are you using?  It seems to be definitely stuck at 300Mhz

3.13.0-bone4 (what i'm shipping to debian bone users..)

# cpufreq-set --freq 30
# /usr/lib/python2.7/test/pystone.py
Pystone(1.1) time for 5 passes = 11.37
This machine benchmarks at 4397.54 pystones/second

# cpufreq-set --freq 60
# /usr/lib/python2.7/test/pystone.py
Pystone(1.1) time for 5 passes = 5.67
This machine benchmarks at 8818.34 pystones/second

# cpufreq-set --freq 80
# /usr/lib/python2.7/test/pystone.py
Pystone(1.1) time for 5 passes = 4.28
This machine benchmarks at 11682.2 pystones/second

# cpufreq-set --freq 100
# /usr/lib/python2.7/test/pystone.py
Pystone(1.1) time for 5 passes = 3.35
This machine benchmarks at 14925.4 pystones/second

When just leaving the ondemand govenor set:

cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpuf...@vger.kernel.org, please.
analyzing CPU 0:
  driver: generic_cpu0
  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 - 1000 MHz
  available frequency steps: 300 MHz, 600 MHz, 800 MHz, 1000 MHz
  available cpufreq governors: conservative, ondemand, userspace,
powersave, performance
  current policy: frequency should be within 300 MHz and 1000 MHz.
  The governor ondemand may decide which speed to use
  within this range.
  current CPU frequency is 1000 MHz (asserted by call to hardware).
  cpufreq stats: 300 MHz:0.00%, 600 MHz:0.00%, 800 MHz:0.00%, 1000 MHz:100.00%

# /usr/lib/python2.7/test/pystone.py
Pystone(1.1) time for 5 passes = 3.39
This machine benchmarks at 14749.3 pystones/second

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] BeagleBone Black CPU speed

2014-01-22 Thread Peter Robinson
Hi Robert,

 Fedora:
 Pystone(1.1) time for 5 passes = 10.9073
 This machine benchmarks at 4584.1 pystones/second

 Which governor are you using?  It seems to be definitely stuck at 300Mhz

# cpupower frequency-info
analyzing CPU 0:
  driver: generic_cpu0
  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 - 1000 MHz
  available frequency steps: 300 MHz, 600 MHz, 800 MHz, 1000 MHz
  available cpufreq governors: conservative, userspace, powersave,
ondemand, performance
  current policy: frequency should be within 300 MHz and 1000 MHz.
  The governor ondemand may decide which speed to use
  within this range.
  current CPU frequency is 300 MHz (asserted by call to hardware).

 3.13.0-bone4 (what i'm shipping to debian bone users..)

kernel-3.13.0-1.1.fc20.armv7hl

[root@bblack ~]# cpupower frequency-info
analyzing CPU 0:
  driver: generic_cpu0
  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 - 1000 MHz
  available frequency steps: 300 MHz, 600 MHz, 800 MHz, 1000 MHz
  available cpufreq governors: conservative, userspace, powersave,
ondemand, performance
  current policy: frequency should be within 300 MHz and 1000 MHz.
  The governor ondemand may decide which speed to use
  within this range.
  current CPU frequency is 300 MHz (asserted by call to hardware).
[root@bblack ~]# /usr/lib/python2.7/test/pystone.py
Pystone(1.1) time for 5 passes = 6.20305
This machine benchmarks at 8060.55 pystones/second
[root@bblack ~]# cpupower frequency-set -f 60
Setting cpu: 0
[root@bblack ~]# /usr/lib/python2.7/test/pystone.py
Pystone(1.1) time for 5 passes = 10.6237
This machine benchmarks at 4706.45 pystones/second
[root@bblack ~]# cpupower frequency-set -f 80
Setting cpu: 0
[root@bblack ~]# /usr/lib/python2.7/test/pystone.py
Pystone(1.1) time for 5 passes = 7.76076
This machine benchmarks at 6442.67 pystones/second
[root@bblack ~]# cpupower frequency-set -f 100
Setting cpu: 0
[root@bblack ~]# /usr/lib/python2.7/test/pystone.py
Pystone(1.1) time for 5 passes = 6.16087
This machine benchmarks at 8115.74 pystones/second
[root@bblack ~]# cpupower frequency-info
analyzing CPU 0:
  driver: generic_cpu0
  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 - 1000 MHz
  available frequency steps: 300 MHz, 600 MHz, 800 MHz, 1000 MHz
  available cpufreq governors: conservative, userspace, powersave,
ondemand, performance
  current policy: frequency should be within 300 MHz and 1000 MHz.
  The governor userspace may decide which speed to use
  within this range.
  current CPU frequency is 1000 MHz (asserted by call to hardware).

So it appears to work but the results are some what variable. Also I
presume you've got the cpufreq driver built in rather than a module as
it doesn't auto load.

Peter
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] BeagleBone Black CPU speed

2014-01-22 Thread Robert Nelson
On Wed, Jan 22, 2014 at 10:32 AM, Peter Robinson pbrobin...@gmail.com wrote:
 Hi Robert,

 Fedora:
 Pystone(1.1) time for 5 passes = 10.9073
 This machine benchmarks at 4584.1 pystones/second

 Which governor are you using?  It seems to be definitely stuck at 300Mhz

 # cpupower frequency-info
 analyzing CPU 0:
   driver: generic_cpu0
   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 - 1000 MHz
   available frequency steps: 300 MHz, 600 MHz, 800 MHz, 1000 MHz
   available cpufreq governors: conservative, userspace, powersave,
 ondemand, performance
   current policy: frequency should be within 300 MHz and 1000 MHz.
   The governor ondemand may decide which speed to use
   within this range.
   current CPU frequency is 300 MHz (asserted by call to hardware).

 3.13.0-bone4 (what i'm shipping to debian bone users..)

 kernel-3.13.0-1.1.fc20.armv7hl

 [root@bblack ~]# cpupower frequency-info
 analyzing CPU 0:
   driver: generic_cpu0
   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 - 1000 MHz
   available frequency steps: 300 MHz, 600 MHz, 800 MHz, 1000 MHz
   available cpufreq governors: conservative, userspace, powersave,
 ondemand, performance
   current policy: frequency should be within 300 MHz and 1000 MHz.
   The governor ondemand may decide which speed to use
   within this range.
   current CPU frequency is 300 MHz (asserted by call to hardware).
 [root@bblack ~]# /usr/lib/python2.7/test/pystone.py
 Pystone(1.1) time for 5 passes = 6.20305
 This machine benchmarks at 8060.55 pystones/second
 [root@bblack ~]# cpupower frequency-set -f 60
 Setting cpu: 0
 [root@bblack ~]# /usr/lib/python2.7/test/pystone.py
 Pystone(1.1) time for 5 passes = 10.6237
 This machine benchmarks at 4706.45 pystones/second
 [root@bblack ~]# cpupower frequency-set -f 80
 Setting cpu: 0
 [root@bblack ~]# /usr/lib/python2.7/test/pystone.py
 Pystone(1.1) time for 5 passes = 7.76076
 This machine benchmarks at 6442.67 pystones/second
 [root@bblack ~]# cpupower frequency-set -f 100
 Setting cpu: 0
 [root@bblack ~]# /usr/lib/python2.7/test/pystone.py
 Pystone(1.1) time for 5 passes = 6.16087
 This machine benchmarks at 8115.74 pystones/second
 [root@bblack ~]# cpupower frequency-info
 analyzing CPU 0:
   driver: generic_cpu0
   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 - 1000 MHz
   available frequency steps: 300 MHz, 600 MHz, 800 MHz, 1000 MHz
   available cpufreq governors: conservative, userspace, powersave,
 ondemand, performance
   current policy: frequency should be within 300 MHz and 1000 MHz.
   The governor userspace may decide which speed to use
   within this range.
   current CPU frequency is 1000 MHz (asserted by call to hardware).

 So it appears to work but the results are some what variable. Also I
 presume you've got the cpufreq driver built in rather than a module as
 it doesn't auto load.

Yeap, it's built in..

https://github.com/RobertCNelson/linux-dev/blob/am33x-v3.13/patches/defconfig#L574

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] BeagleBone Black CPU speed

2014-01-22 Thread Steve Underwood

Hi Robert,

On 01/22/2014 10:59 PM, Robert Nelson wrote:

On Tue, Jan 21, 2014 at 10:09 PM, Steve Underwood ste...@coppice.org wrote:

Hi Peter,


On 01/22/2014 04:14 AM, Peter Robinson wrote:

It looks like the BeagleBone Black is still running at 550MHz with the
latest Fedora 20. Does anyone know what is holding it back from running
at
1GHz? Is the a uboot thing, or a kernel thing, or something else? I saw
a
version of uboot referred to as making the BBB run at 1GHz, but when I
tried
experimenting with that I got the same 550MHz clock speed.

If you're interested could you try the kernel-3.13.0-1.1.fc20 scratch
kernel [1] on your BBBlack. It should add freq scaling support and you
should be able to tell if it detects it appropriately if the
cpufreq-cpu0 module loads. Feedback welcome.

So that kernel works with my testing but the module doesn't auto load
the cpufreq-cpu0 module. If you do:

modprobe cpufreq-cpu0

You then get:
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
30 60 80 100

Even with 3.12.8 you can manually load that module and it works but
you only get up to 720mhz.

Peter


[1]
http://pbrobinson.fedorapeople.org/arm-kernel/kernel-3.13.0-1.1.fc20.armv7hl.rpm

Earlier Jos Vos reported the following results for his BeagleBoneBlack
running pystone.py

Fedora:
Pystone(1.1) time for 5 passes = 10.9073
This machine benchmarks at 4584.1 pystones/second

Which governor are you using?  It seems to be definitely stuck at 300Mhz

3.13.0-bone4 (what i'm shipping to debian bone users..)

# cpufreq-set --freq 30
# /usr/lib/python2.7/test/pystone.py
Pystone(1.1) time for 5 passes = 11.37
This machine benchmarks at 4397.54 pystones/second

# cpufreq-set --freq 60
# /usr/lib/python2.7/test/pystone.py
Pystone(1.1) time for 5 passes = 5.67
This machine benchmarks at 8818.34 pystones/second

# cpufreq-set --freq 80
# /usr/lib/python2.7/test/pystone.py
Pystone(1.1) time for 5 passes = 4.28
This machine benchmarks at 11682.2 pystones/second

# cpufreq-set --freq 100
# /usr/lib/python2.7/test/pystone.py
Pystone(1.1) time for 5 passes = 3.35
This machine benchmarks at 14925.4 pystones/second

When just leaving the ondemand govenor set:

cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpuf...@vger.kernel.org, please.
analyzing CPU 0:
   driver: generic_cpu0
   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 - 1000 MHz
   available frequency steps: 300 MHz, 600 MHz, 800 MHz, 1000 MHz
   available cpufreq governors: conservative, ondemand, userspace,
powersave, performance
   current policy: frequency should be within 300 MHz and 1000 MHz.
   The governor ondemand may decide which speed to use
   within this range.
   current CPU frequency is 1000 MHz (asserted by call to hardware).
   cpufreq stats: 300 MHz:0.00%, 600 MHz:0.00%, 800 MHz:0.00%, 1000 MHz:100.00%

# /usr/lib/python2.7/test/pystone.py
Pystone(1.1) time for 5 passes = 3.39
This machine benchmarks at 14749.3 pystones/second

Regards,


On my BeagleBoneBlack running Peter's new Linux 3.13.0 RPM I get:

[root@beagle]# cpupower frequency-info
analyzing CPU 0:
  driver: generic_cpu0
  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 - 1000 MHz
  available frequency steps: 300 MHz, 600 MHz, 800 MHz, 1000 MHz
  available cpufreq governors: conservative, userspace, powersave, 
ondemand, performance

  current policy: frequency should be within 300 MHz and 1000 MHz.
  The governor userspace may decide which speed to use
  within this range.
  current CPU frequency is 300 MHz (asserted by call to hardware).

[root@beagle]# cpupower frequency-set -f 300MHz
[root@beagle]# ./pystone.py
Pystone(1.1) time for 5 passes = 22.0034
This machine benchmarks at 2272.37 pystones/second

[root@beagle]# cpupower frequency-set -f 600MHz
[root@beagle]# ./pystone.py
Pystone(1.1) time for 5 passes = 10.4669
This machine benchmarks at 4776.98 pystones/second

[root@beagle]# cpupower frequency-set -f 800MHz
[root@beagle]# ./pystone.py
Pystone(1.1) time for 5 passes = 7.81685
This machine benchmarks at 6396.44 pystones/second

[root@beagle]# cpupower frequency-set -f 1000MHz
[root@beagle]# ./pystone.py
Pystone(1.1) time for 5 passes = 6.36032
This machine benchmarks at 7861.24 pystones/second

So, the results scale nicely with the clock speed, but all the results 
are around half as fast as your result at the same clock speed.


Regards,
Steve

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] BeagleBone Black CPU speed

2014-01-21 Thread Peter Robinson
Hi Steve,

 It looks like the BeagleBone Black is still running at 550MHz with the
 latest Fedora 20. Does anyone know what is holding it back from running at
 1GHz? Is the a uboot thing, or a kernel thing, or something else? I saw a
 version of uboot referred to as making the BBB run at 1GHz, but when I tried
 experimenting with that I got the same 550MHz clock speed.

If you're interested could you try the kernel-3.13.0-1.1.fc20 scratch
kernel [1] on your BBBlack. It should add freq scaling support and you
should be able to tell if it detects it appropriately if the
cpufreq-cpu0 module loads. Feedback welcome.

Peter

[1] 
http://pbrobinson.fedorapeople.org/arm-kernel/kernel-3.13.0-1.1.fc20.armv7hl.rpm
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] BeagleBone Black CPU speed

2014-01-21 Thread Peter Robinson
 It looks like the BeagleBone Black is still running at 550MHz with the
 latest Fedora 20. Does anyone know what is holding it back from running at
 1GHz? Is the a uboot thing, or a kernel thing, or something else? I saw a
 version of uboot referred to as making the BBB run at 1GHz, but when I tried
 experimenting with that I got the same 550MHz clock speed.

 If you're interested could you try the kernel-3.13.0-1.1.fc20 scratch
 kernel [1] on your BBBlack. It should add freq scaling support and you
 should be able to tell if it detects it appropriately if the
 cpufreq-cpu0 module loads. Feedback welcome.

So that kernel works with my testing but the module doesn't auto load
the cpufreq-cpu0 module. If you do:

modprobe cpufreq-cpu0

You then get:
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
30 60 80 100

Even with 3.12.8 you can manually load that module and it works but
you only get up to 720mhz.

Peter

 [1] 
 http://pbrobinson.fedorapeople.org/arm-kernel/kernel-3.13.0-1.1.fc20.armv7hl.rpm
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] BeagleBone Black CPU speed

2014-01-21 Thread Steve Underwood

Hi Peter,

On 01/22/2014 04:14 AM, Peter Robinson wrote:

It looks like the BeagleBone Black is still running at 550MHz with the
latest Fedora 20. Does anyone know what is holding it back from running at
1GHz? Is the a uboot thing, or a kernel thing, or something else? I saw a
version of uboot referred to as making the BBB run at 1GHz, but when I tried
experimenting with that I got the same 550MHz clock speed.

If you're interested could you try the kernel-3.13.0-1.1.fc20 scratch
kernel [1] on your BBBlack. It should add freq scaling support and you
should be able to tell if it detects it appropriately if the
cpufreq-cpu0 module loads. Feedback welcome.

So that kernel works with my testing but the module doesn't auto load
the cpufreq-cpu0 module. If you do:

modprobe cpufreq-cpu0

You then get:
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
30 60 80 100

Even with 3.12.8 you can manually load that module and it works but
you only get up to 720mhz.

Peter


[1] 
http://pbrobinson.fedorapeople.org/arm-kernel/kernel-3.13.0-1.1.fc20.armv7hl.rpm
Earlier Jos Vos reported the following results for his BeagleBoneBlack 
running pystone.py


Fedora:
Pystone(1.1) time for 5 passes = 10.9073
This machine benchmarks at 4584.1 pystones/second

Debian:
Pystone(1.1) time for 5 passes = 4.38
This machine benchmarks at 11415.5 pystones/second


Before this latest kernel I was getting results a few percent slower than he 
reported for Fedora. With this new kernel RPM I get

Pystone(1.1) time for 5 passes = 6.23986
This machine benchmarks at 8013.01 pystones/second

That speed is very consistent across runs of the test. The speed has increased, 
but it seems to still be well below that of Debian. If I use

cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq

While the machine is idle it says 300MHz. While pystone.py is running it says 
1GHz. When the machine is idle, top says the CPU is around 1% loaded. When 
pystone.py is running it says it is 99.x% loaded. As far as I can tell the 
clock jumps from 300MHz to 1GHz as pystone.py starts up - i.e there is no 
substantial lag, resulting in half the test running at 300MHz and half at 1GHz.

If my board really is now running pystone.py at 1GHz, I wonder what else could 
be causing this test to be around 50% slower than with Debian.

Regards,
Steve

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] BeagleBone Black CPU speed

2014-01-17 Thread Peter Robinson
On Sun, Dec 29, 2013 at 7:14 PM, Robert Nelson robertcnel...@gmail.com wrote:
 On Sun, Dec 29, 2013 at 12:10 PM, Steve Underwood ste...@coppice.org wrote:
 Hi,

 It looks like the BeagleBone Black is still running at 550MHz with the
 latest Fedora 20. Does anyone know what is holding it back from running at
 1GHz? Is the a uboot thing, or a kernel thing, or something else? I saw a
 version of uboot referred to as making the BBB run at 1GHz, but when I tried
 experimenting with that I got the same 550MHz clock speed.

 with v3.12.x:
 These 5 patches are needed:
 https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.12/patches/cpufreq

 or with v3.13-rcX:
 https://github.com/RobertCNelson/linux-dev/blob/am33x-v3.13/patches/dts/0002-arm-dts-am335x-boneblack-add-cpu0-opp-points.patch

I've enabled the generic cpufreq support, we had it disabled as when
it first landed it had problems.

The BBB is booting with 3.13rc8 with no patches but there's a few
issues I need to resolve this week with USB so I'll review that for
the BB patchset to make sure it's there. Is it queued to go upstream
for 3.14?

Peter
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] BeagleBone Black CPU speed

2014-01-17 Thread Robert Nelson
On Fri, Jan 17, 2014 at 3:52 AM, Peter Robinson pbrobin...@gmail.com wrote:
 On Sun, Dec 29, 2013 at 7:14 PM, Robert Nelson robertcnel...@gmail.com 
 wrote:
 On Sun, Dec 29, 2013 at 12:10 PM, Steve Underwood ste...@coppice.org wrote:
 Hi,

 It looks like the BeagleBone Black is still running at 550MHz with the
 latest Fedora 20. Does anyone know what is holding it back from running at
 1GHz? Is the a uboot thing, or a kernel thing, or something else? I saw a
 version of uboot referred to as making the BBB run at 1GHz, but when I tried
 experimenting with that I got the same 550MHz clock speed.

 with v3.12.x:
 These 5 patches are needed:
 https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.12/patches/cpufreq

 or with v3.13-rcX:
 https://github.com/RobertCNelson/linux-dev/blob/am33x-v3.13/patches/dts/0002-arm-dts-am335x-boneblack-add-cpu0-opp-points.patch

 I've enabled the generic cpufreq support, we had it disabled as when
 it first landed it had problems.

 The BBB is booting with 3.13rc8 with no patches but there's a few
 issues I need to resolve this week with USB so I'll review that for
 the BB patchset to make sure it's there. Is it queued to go upstream
 for 3.14?

3.14 is closed, I'm cleaning my patches listed in that repo and
planning to post to l-a/l-o after v3.14-rc1 hits..

Talking with CircuitCo, they would prefer the default pinmux to be
setup like so:

http://elinux.org/Basic_Proto_Cape

So i'm adding those changes to the push too..

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] BeagleBone Black CPU speed

2013-12-29 Thread Steve Underwood

Hi,

It looks like the BeagleBone Black is still running at 550MHz with the 
latest Fedora 20. Does anyone know what is holding it back from running 
at 1GHz? Is the a uboot thing, or a kernel thing, or something else? I 
saw a version of uboot referred to as making the BBB run at 1GHz, but 
when I tried experimenting with that I got the same 550MHz clock speed.


Regards,
Steve
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] BeagleBone Black CPU speed

2013-12-29 Thread Robert Nelson
On Sun, Dec 29, 2013 at 12:10 PM, Steve Underwood ste...@coppice.org wrote:
 Hi,

 It looks like the BeagleBone Black is still running at 550MHz with the
 latest Fedora 20. Does anyone know what is holding it back from running at
 1GHz? Is the a uboot thing, or a kernel thing, or something else? I saw a
 version of uboot referred to as making the BBB run at 1GHz, but when I tried
 experimenting with that I got the same 550MHz clock speed.

with v3.12.x:
These 5 patches are needed:
https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.12/patches/cpufreq

or with v3.13-rcX:
https://github.com/RobertCNelson/linux-dev/blob/am33x-v3.13/patches/dts/0002-arm-dts-am335x-boneblack-add-cpu0-opp-points.patch

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] BeagleBone Black CPU speed

2013-12-29 Thread Robert Nelson
On Sun, Dec 29, 2013 at 1:14 PM, Robert Nelson robertcnel...@gmail.com wrote:
 On Sun, Dec 29, 2013 at 12:10 PM, Steve Underwood ste...@coppice.org wrote:
 Hi,

 It looks like the BeagleBone Black is still running at 550MHz with the
 latest Fedora 20. Does anyone know what is holding it back from running at
 1GHz? Is the a uboot thing, or a kernel thing, or something else? I saw a
 version of uboot referred to as making the BBB run at 1GHz, but when I tried
 experimenting with that I got the same 550MHz clock speed.

 with v3.12.x:
 These 5 patches are needed:
 https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.12/patches/cpufreq

 or with v3.13-rcX:
 https://github.com/RobertCNelson/linux-dev/blob/am33x-v3.13/patches/dts/0002-arm-dts-am335x-boneblack-add-cpu0-opp-points.patch

ps, while your at it, also add:
https://github.com/RobertCNelson/linux-dev/blob/am33x-v3.13/patches/dts/0001-arm-dts-am335x-boneblack-lcdc-add-panel-info.patch

to get the full kms experience over hdmi with the
CONFIG_DRM_TILCDC/CONFIG_DRM_I2C_NXP_TDA998X

Since they are both dts patches, you don't even have to rebuild the
kernel, just patch the dtb file..

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] BeagleBone Black CPU speed

2013-12-29 Thread Nigel Sollars
Hi all,

Hey Robert do you have a rc ( 3.13 ) kernel rolled?.

Regards


On Sun, Dec 29, 2013 at 2:18 PM, Robert Nelson robertcnel...@gmail.comwrote:

 On Sun, Dec 29, 2013 at 1:14 PM, Robert Nelson robertcnel...@gmail.com
 wrote:
  On Sun, Dec 29, 2013 at 12:10 PM, Steve Underwood ste...@coppice.org
 wrote:
  Hi,
 
  It looks like the BeagleBone Black is still running at 550MHz with the
  latest Fedora 20. Does anyone know what is holding it back from running
 at
  1GHz? Is the a uboot thing, or a kernel thing, or something else? I saw
 a
  version of uboot referred to as making the BBB run at 1GHz, but when I
 tried
  experimenting with that I got the same 550MHz clock speed.
 
  with v3.12.x:
  These 5 patches are needed:
 
 https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.12/patches/cpufreq
 
  or with v3.13-rcX:
 
 https://github.com/RobertCNelson/linux-dev/blob/am33x-v3.13/patches/dts/0002-arm-dts-am335x-boneblack-add-cpu0-opp-points.patch

 ps, while your at it, also add:

 https://github.com/RobertCNelson/linux-dev/blob/am33x-v3.13/patches/dts/0001-arm-dts-am335x-boneblack-lcdc-add-panel-info.patch

 to get the full kms experience over hdmi with the
 CONFIG_DRM_TILCDC/CONFIG_DRM_I2C_NXP_TDA998X

 Since they are both dts patches, you don't even have to rebuild the
 kernel, just patch the dtb file..

 Regards,

 --
 Robert Nelson
 http://www.rcn-ee.com/
 ___
 arm mailing list
 arm@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/arm




-- 
“Science is a differential equation. Religion is a boundary condition.”

  Alan Turing
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] BeagleBone Black CPU speed

2013-12-29 Thread Robert Nelson
On Sun, Dec 29, 2013 at 4:13 PM, Nigel Sollars nsoll...@gmail.com wrote:
 Hi all,

 Hey Robert do you have a rc ( 3.13 ) kernel rolled?.

I do..

https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.13

Just waiting for rc6 to fall, before i push it out to building farm..

The config is really minimal right now, going to throw the kitchen
sink at it tomorrow so v3.12.x users won't be missing stuff.

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Beaglebone Black

2013-05-27 Thread Matthias Runge
On 05/06/2013 08:52 PM, Peter Robinson wrote:
 Does anyone have Fedora running on the new Beaglebone Black board?
 
 Not yet but I've begun working on the kernel and uboot side of things
 and I should have mine this week so watch this space.
 
Hey,

this is great news. Any updates here?

Matthias
-- 
Matthias Runge mru...@matthias-runge.de
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] Beaglebone Black

2013-05-06 Thread Steve Underwood

Hi,

Does anyone have Fedora running on the new Beaglebone Black board?

Steve
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Beaglebone Black

2013-05-06 Thread Peter Robinson
On Mon, May 6, 2013 at 7:40 PM, Steve Underwood ste...@coppice.org wrote:
 Hi,

 Does anyone have Fedora running on the new Beaglebone Black board?

Not yet but I've begun working on the kernel and uboot side of things
and I should have mine this week so watch this space.

Peter
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm