Action Item #176
PiBox component rev: kernel
|Status:||Closed||Start date:||23 Mar 2013|
|Category:||03 - Linux Kernel|
|Severity:||03 - Medium|
Current version is based on 3.2.27. There is a 3.6.x branch in the git repo that needs to be tested.
RM #176: Add support for 3.10.y kernel tree. This is not the default yet, but it does boot. It needs to be tested with the rest of the rootfs and opkgs to make sure it has the right default kernel config.
#1 Updated by Hammel over 5 years ago
- Tracker changed from Bug to Action Item
Initial tests with a build on 64-bit failed. The kernel couldn't find init. I'm using the same cmdline.txt that was used for the 3.2.27 branch. The root file systems is an ext3 partition and the cmdline.txt references it correctly. Not sure why the newer kernel doesn't work.
#3 Updated by Hammel over 5 years ago
- Status changed from New to In Progress
- Priority changed from Normal to Low
- % Done changed from 10 to 20
- Severity changed from 03 - Medium to 04 - Low
The 3.6.y kernel builds fine and boots, but it doesn't support my wireless keyboard. It also seems to mix the init processing with some usb probing, which causes some things not to happen, like the USB wifi not to get loaded because the USB has not enumerated the dongle when mdev is starting up.
The latter issue might be an "early init" configuration item. I seem to have a vague recollection about hearing about such a feature in the kernel. The former I don't know what the problem is. I ran meld on the two kernel configs (3.6.y and 3.2.27) and dont' see anything missing from the new kernels config that was in the old kernel config. But there are lots of changes so maybe I missed something.
For now, I'm falling back to 3.2.27 until I get a public release of PiBox out the door.
#4 Updated by Hammel almost 5 years ago
- % Done changed from 20 to 50
Ran a test today with the kernel from the Raspberry Pi kernel repo on github using GIT id rpi-3.10.y. This was built using the current PiBox xcc, based on Crosstool-NG 1.15.2. The rootfs is the same with only a minor change to cleaning up the lib/modules/.../ symlinks to support kernel versions that don't match the kernel release names.
The system boots just fine. In fact, it seems to boot rather fast in comparison to the 3.2.27 tree. Also, the keyboard is available on boot (at least with the initial test). Not sure if that was a fluke or they fixed something with the USB handling.
I will checkin the changes to buildroot.mk and the new kernel configuration file for rpi-3.10.y. I'll also add commented out configuration support for the new kernel, but won't make it the default yet. I need to verify that all required components (re: opkgs) are working with the new kernel first.
#6 Updated by Hammel almost 5 years ago
Also, add usr/bin/mdevdebug.sh (from my sandbox) and add it to /etc/mdev.conf as the first command that executes and falls through to the other commands. This should really be an opkg that patches mdev.conf on install and unpatches on uninstall.
#7 Updated by Hammel almost 5 years ago
Inittab tries to mount /proc/bus/usb as usbfs. This directory doesn't exist with this kernel using the default RPi kernel config (not my config, the default one).
The reason no mdev-based driver loading occurs is because the usbfs isn't mounted. It's deprecated after kernel 3.5. See this discussion:
One solution that seems to also be deprecated was CONFIG_USB_DEVICE_CLASS (it's not in the 3.10.25 configuration). See http://www.libusb.org/ticket/119
I might get more info from https://wiki.gentoo.org/wiki/Mdev/Automount_USB
#8 Updated by Hammel almost 5 years ago
Both listen to the netlink socket for events and pass them to mdev.
#11 Updated by Hammel almost 5 years ago
- Status changed from In Progress to Closed
- % Done changed from 50 to 100
After finding a working branch from the RPi kernel repo, which is not the latest but is merge with kernel.org's 3.10.31, and updating the rootfs to properly load usb drivers using lsusb as a front end in an init script, PiBox is now rev'd to a 3.10.x kernel.
This means we can integrate with the mainline fbtft drivers for the touchscreen display and can properly support BLE.
This issue can be closed.