Linux kernel 3.2.28 Kirkwood package

I have uploaded a Debian kernel deb package for 3.2.28-kirkwood which I've built with a collection of patches for GoFlex Home/Net, Pogoplug E02/V4, iConnect (Dockstar, Sheevaplug and a few other Kirkwood plugs are already in the mainline 3.2.x).

Dropbox: linux-3.2.28-kirkwood-bodhi.tar.bz2
MD5: 68405b35c38bf9a1522bf63b4c7d5e5c

Note on extracting: I had a typo on the file name (duh!) :) should be linux-3.2.28-kirkwood-bodhi.tar.bz2. However, using tar -xjf will extract it just fine. Thanks chessplayer.


Addendum:
1. I've attached the patch file here. It's seems to build OK, but not tested yet. Please let me know if you used it to build your kernel and whether it's working or not.
2. Attached config file.
3. Add notes on bz2 file name
4. Patch file has been verified to work by shv.
5. Modified Dropbox link to shorten it, and correct the file name extension



Edited 7 time(s). Last edit at 03/09/2013 04:23PM by bodhi.

Thanks for re-uploading it. I am running wheezy, and I get this error when trying to install your kernel:

Running depmod.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.2.28-kirkwood-tld /boot/vmlinuz-3.2.28-kirkwood-tld
update-initramfs: Generating /boot/initrd.img-3.2.28-kirkwood-tld
run-parts: executing /etc/kernel/postinst.d/zz-doozan-flash-kernel 3.2.28-kirkwood-tld /boot/vmlinuz-3.2.28-kirkwood-tld
Kernel /boot/vmlinuz-3.2.28-kirkwood-tld does not match your subarchitecture
kirkwood, therefore not writing it to flash.

That's normal, since the kernel is not named 3.2.28-kirkwood, the uImage and uInitrd are not generated automatically by dpkg (through flash-kernel). The naming is intentional so that it can be recognized as a patched kernel, not a vanilla kernel from mainline. And also the uImage and uInitrd will not be overwritten automatically by flash-kernel without manual action.

I'd suggest saving your current kernel files in /boot so that it can be restored (if x.x.x is the current version number):

config-x.x.x-kirkwood
vmlinuz-x.x.x-kirkwood
System.map-x.x.x-kirkwood
initrd.img-x.x.x-kirkwood
uImage.x.x.x
uInitrd.x.x.x

And then generate new uImage and uInitrd:

mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-3.2.28-tld -d /boot/vmlinuz-3.2.28-kirkwood-tld /boot/uImage
mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs-3.2.28-tld  -d /boot/initrd.img-3.2.28-kirkwood-tld /boot/uInitrd

Also, remember to symlink your vmlinuz and initird.img:

cd /
ln -s boot/vmlinuz-3.2.28-kirkwood-tld vmlinuz
ln -s boot/initrd.img-3.2.28-kirkwood-tld initrd.img

Edited 1 time(s). Last edit at 02/27/2013 02:45PM by bodhi.

Thanks! It's working great.

I am now able to toggle the orange LED with

echo default-on >/sys/class/leds/status\:blue\:health/trigger
echo none >/sys/class/leds/status\:blue\:health/trigger

and the green LED with

echo default-on >/sys/class/leds/status\:green\:health/trigger
echo none >/sys/class/leds/status\:green\:health/trigger

/sys/class/leds/plug:red:misc doesn't appear to do anything.



Edited 1 time(s). Last edit at 02/27/2013 03:53PM by lincomatic.

Cool! yes, I think /sys/class/leds/plug:red:misc was just a remnant of the old patch for machine 2097, where you would mix green and red to get orange. And blue now is actually orange in Pogo E02 :)

If everything is working correctly for your Pogoplug E02, cat /proc/cpuinfo also will identfy the hardware as Pogoplug E02.

bodhi Wrote:
-------------------------------------------------------
> If everything is working correctly for your
> Pogoplug E02, cat /proc/cpuinfo also will identfy
> the hardware as Pogoplug E02.

Hmm. I have arcNumber=2097, it's an E02, and the LED's work as above, but cat /proc/cpuinfo doesn't mention Pogoplug E02:

Processor : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS : 1191.11
Features : swp half thumb fastmult edsp
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant : 0x2
CPU part : 0x131
CPU revision : 1

Hardware : Marvell SheevaPlug Reference Board
Revision : 0000
Serial : 0000000000000000

Besides the LED's, what other E02 functionality is added with this kernel?
Thanks again for the great work.

For the Pogo E02, it's really not much! LEDs settings are the thing that's extra from 2097. For other plugs, a lot more to gain when you use appropriate kernel. For example, Goflex Net has 2 SATA connectors, and whole bunch of LEDs that can be lighted in various ways.

If you're happy with the way the LED work now, then there's no needs to change arcNumber. Much more gain to have since you're running kernel 3.2.x on the wheezy rootfs, such as newer packages that fixed a lot of bugs or provide new capabilities (udev, xfce ...).

OK, great. But just for reference, what's the proper arcNumber for Pogo E02?
I tried 2097 and also 3542 as recommended here: http://archlinuxarm.org/forum/viewtopic.php?t=2780
and it /proc/cpuinfo still shows it as Marvell SheevaPlug Reference Board.

lincomatic Wrote:
-------------------------------------------------------
> OK, great. But just for reference, what's the
> proper arcNumber for Pogo E02?
> I tried 2097 and also 3542 as recommended here:
> http://archlinuxarm.org/forum/viewtopic.php?t=2780
>
> and it /proc/cpuinfo still shows it as Marvell
> SheevaPlug Reference Board.

Using current uBoot, set arcNumber to 3542, you also need to set machid:
http://forum.doozan.com/read.php?3,6965,11171#msg-11171

Thank you, bodhi!

With arcNumber=3542 and machid=dd6,
/proc/cpuinfo now shows Pogoplug E02,
and /sys/class/leds has
status:green:health and status:orange:fault
and the green LED automatically turns on when it's booted, so I don't have to manually fiddle w/ the LED's in /etc/rc.local.
Perfect.

Thank you bodhi for sharing of this kernel. Can you also share the source tree? I might need it if I must compile drivers for some external hardware devices.

@shv, I have consolidate patch that I can post here later, so you can try building your own kernel.

This would be nice.

Updated 1st post to attach the patch file.

Hi bodhi,

without having tried your kernel (though I might still do that): is there a reason you go for 3.2.x instead of 3.3.x like, e.g., davygravy or shyd did? I know, their solution was for Dockstar (and GoFlex, Zyxel), but still, for a kernel illiterate like me, the question remains ...

---
Standart ist der Standardfehler

Hi chessplayer,

There is really no special reason why I'm still on kernel 3.2.x. I tend to upgrade slowly to get the most stable kernel, and still get the latest packages for the OS. IMO, if you run Kirkwood, then you should use Kirwood-patched kernel 3.2.x. or later. This is because of discovery of problem in booting older uBoot with kernel 3.2.x, and also problem with chip timing. These various glitches were found by davygravy, pazos, mugabe, and others here. When I look at kernel 3.3 to 3.5, I did not see any update that I need, so I stay at 3.2.x (I could have missed some new features or bug fixes, but it seems to be OK so far).

-bodhi

EDIT: typos.



Edited 1 time(s). Last edit at 03/03/2013 06:12PM by bodhi.

Hello bodhi,
thank you for uploading the patch file. Can you also provide the kernel configuration file?

Thank you in advance.

-shv

Sure, updated 1st post to attach config file.

Just a quick thank you for this kernel package. Putting lincomatic's toggle into /etc/rc.local now gives me a green LED after boot. Nice, the dockstar feeling on a pink plug ...

---
Standart ist der Standardfehler



Edited 1 time(s). Last edit at 03/06/2013 01:42AM by chessplayer.

Cool :)

Hello bodhi,

Your kernel is working fine on Pogoplug E02 and Pogoplug Series 4, thanks.

I was not successful with building a working kernel. I get a .deb file but the kernel doesn't get access to /dev/root. How can I setup a working cross toolchain on debian or ubuntu?

shv



Edited 1 time(s). Last edit at 03/06/2013 10:29AM by shv.

shv Wrote:
-------------------------------------------------------
> Hello bodhi,
>
> Your kernel is working fine on Pogoplug E02 and
> Pogoplug Series 4, thanks.
>
> I was not successful with building a working
> kernel. I get a .deb file but the kernel doesn't
> get access to /dev/root. How can I setup a working
> cross toolchain on debian or ubuntu?
>
> shv

Hi shv,

I've not used cross toolchain for a while. I built this kernel using a GoFlex Net. But you can search this forum, I recall people have used it recently and discussed about it here.

Did you mean that you saw this error in serial console during mounting rootfs? (i.e. can't access /dev/root). I think it could be the initrd was not built properly when you dpkg it. I would try it with a clean backup rootfs, do apt-get update and apt-get upgrade first before running dpkg. I ran across this error when using a USB stick that I use for testing heavily. Just an idea to try, /dev/root error can occur due to different problems.

Hello bodhi,

Yes, I saw this error in serial console during mounting rootfs. I will try to use a clean backup rootfs and the other recommendations next time. If this will not work my next step will be to compile it natively on the device.

shv

Hello bodhi,

It is working with a different cross tool chain now. Thank you for providing all necessary configurations an patches. I would like to flash such kernel to the NAND of my Pogoplug E02 and to use sd card or USB3.0 stick, USB2.0 stick or SATA as rootfs. How could I do this? Would the rescue kernel already be able to use the rootfs with USB3.0 or SD card? I think chessplayer has already experiences with kernel and rootfs on different partitions.

shv



Edited 1 time(s). Last edit at 03/08/2013 01:41PM by shv.

Regarding the two partitions, I wrote that up in this post for a USB-Stick. Concerning my uBoot environment for this setup, you can find that here. However, if you want boot and rootfs on separate devices, that is going to be tough, I think, since you probably cannot be sure about which gets the "a", which the "b" and so on.

Cheers,

chessplayer

---
Standart ist der Standardfehler

@chessplayer,
I think shv wants to flash the kernel to NAND and put rootfs on a SD or USB drive, so the rootfs label solution will work consistently. Also, regarding to 2 partitions on a drive (or 2 drives). I think you can make sure that the kernel is always loaded correctly from /boot, and then with rootfs label for / , you can make it consistent, too. I used to use 2 partitions, but since I've switch to Ext3 for boot drive, I went back to 1 partition, because it always work even after power failure.

@shv,
Are you thinking about running on the Pogoplug V4? Davy's uBoot supports it only for SD or USB 2.0 (not SATA) for booting. And I've not tried the rescue kernel with many configurations, so I'm not sure if it has enough supports to use in a full-blown Debian system.

-bodhi



Edited 1 time(s). Last edit at 03/08/2013 05:24PM by bodhi.

bodhi Wrote:
-------------------------------------------------------
> @chessplayer,
... snip ...
> with rootfs label for / , you can make it
> consistent, too.
... snip ...

>
> -bodhi

You are, of course, absolutely right. That is what the labels are for. I wasn't thinking straight before.

Cheers,

chessplayer

---
Standart ist der Standardfehler

@bodhi,
Yes I am thinking about running it on Pogoplug V4. I will try to use the ALARM uboot to boot the kernel from one USB drive and to load the rootfs from another drive. If the kernel of the rescue system is to restricted I might replace it with a fully blown kernel if there is enough space. I also compiled davys 3.3.2 kernel with support for the pogoplug devices. How to prevent that a NAND kernel boots the rootfs from the NAND partition? Maybe it works just to change the partition label from rootfs to anything else.



Edited 3 time(s). Last edit at 03/09/2013 02:00PM by shv.

shv Wrote:
-------------------------------------------------------
> How to prevent that a NAND
> kernel boots the rootfs from the NAND partition?
> Maybe it works just to change the partition label
> from rootfs to anything else.

Hi shv,

It's much easier to change bootcmd env to give USB a higher priority:

from

bootcmd=usb start; run force_rescue_bootcmd; run ubifs_bootcmd; run usb_bootcmd; usb stop; run rescue_bootcmd; run pogo_bootcmd; reset

to

bootcmd=usb start; run force_rescue_bootcmd; run usb_bootcmd; usb stop; run ubifs_bootcmd; run rescue_bootcmd; run pogo_bootcmd; reset

This way if you have USB boot drive it will boot the system without accessing the NAND rootfs.

bodhi,

FYI, I just did a native compile with your kernel patch on a pogoplug e02.

The build worked fine after I changed the kernel compression from LZMA to gzip with your .config.

Here is the time it took:

real 468m17.204s
user 387m34.010s
sys 36m4.840s

-syong