> 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? > 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. > 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_the_BeagleBone_.28_Black_.26_White_.29 _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm