Hi Peter,
On 05/05/2014 04:51 PM, Peter Robinson wrote:
> I have had erratic results with recent Fedora 20 kernels and a
Beagle Bone
> Black, with some kernels failing to even boot. The latest kernel -
> 3.14.2-200.fc20.armv7hl - seems to be in generally good shape. Ethernet, USB
> and the XFCE desktop all seem to be working well. However, one regression
> seems to have occurred. With older kernels I got the following:
Interesting on the desktop side of things, I was certain I would need
a patch for the panel support for it to work. What xorg conf do you
have?
I updated an install from the XFCE image.When I rebooted the XFCE
desktop just worked.
> modprobe cpufreq-cpu0
> cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
> 300000 600000 800000 1000000
>
> which I think is the correct set of frequencies for this board. Certainly
> the highest speed should be 1GHz. With3.14.2-200.fc20.armv7hl I get the
> following:
>
> modprobe cpufreq-cpu0
> cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
> 275000 500000 600000 720000
Yes, in <= 3.13 we needed patches for the BBBlack but with 3.14 it
mostly works fine without but it seems the bits for 1ghz haven't
landed upstream. Can you file a RHBZ against the kernel for this
regression, reply here for the number and I'll sort out a patch.
Bug report
submitted.
> If a kernel fails to boot is there a simple way to be able to boot the
> previous kernel? So far I haven't found the right procedure, and I have been
> restoring from a backup copy of the SD card each time.
I would suggest moving to rawhide as Dennis has done some awesome work
with extlinux to give us a menu (and you no longer need a vfat
partition) to select the kernel. The f-21 u-boot might work this way
with F-20 but it's untested and if it breaks you get to keep both
pieces.
[1]
https://fedoraproject.org/wiki/Architectures/ARM/Rawhide/Installation#For...
Regards,
Steve