OK, well I've been converting to devicetree based kernels for arm. This will allow me to properly support quite a few variations of the kirkwood and dove based devices, others as well (DeviceTree is awesome from a distribution standpoint).

UPDATE-KERNEL.sh will work with the kernel's starting at 3.9.0, for anything prior, continue to use the older scripts.

The UPDATE-KERNEL.sh is a work-in-progress, right now I know it works properly on SheevaPlug's and CuBox's. Theoretically it will work for the other variations as well, feedback would be appreciated.

UPDATE-KERNEL.sh attempts to identify the device based on entries in the /proc filesystem. In those cases where it id's the device correctly, all that is necessary is "sudo ./UPDATE-KERNEL.sh 3.9.0", for devices that aren't id'd correctly "sudo ./UPDATE-KERNEL.sh 3.9.0 device-type" should work.

The earliest version of UPDATE-KERNEL.sh, wasn't optimal (from a distribution standpoint), and I rewrote it to download the zImage and a corresponding .dtb file, that will be the version that you want. You can grab it from http://www.xilka.com/sheeva/tmp/UPDATE-KERNEL.sh (the version in /sheeva should be OK after the web server caches have a chance to update). Keep in mind that I haven't got auto detection setup properly for devices other than SheevaPlug, SheevaPlug-eSATA and CuBox. After you have installed a device-tree kernel, from that point on the auto-detection should work reliably since I can use entries in /proc/device-tree.

Yes, that's correct it created a wrong uImage. I think I need to rewrite it so that a second parameter will always override the assumed device. That should take care of that. I'm sure in the meantime you could patch the script to do that.

I deleted all downloaded files (including the new ones in /boot), edited the script to define AssumedDevice='guruplug-server-plus' and it ran without errors. I copied the new kirkwood-guruplug-server-plus-3.9.0-uImage to /boot/uImage and rebooted but the system froze after booting kernel.

To use device tree on arm, both bootloader (U-Boot) and kernel should be compiled with the support of device tree.U-BootNote Note: The APF27/U-boot 2012.04.01 patch 3.6, APF28/U-Boot 2012.04.01 patch 1.5 and APF51/U-Boot 2012.04.01 patch 1.5 are already configured to support device tree.

To use device tree on arm, both bootloader (U-Boot) and kernel should be compiled with the support of device tree.U-BootNote Note: The APF27/U-boot 2012.04.01 patch 3.6, APF28/U-Boot 2012.04.01 patch 1.5 and APF51/U-Boot 2012.04.01 patch 1.5 are already configured to support device tree.

I have also compiled 3.9.1 for my sheevaplugs with mixed results. Three of my Sheevaplugs use eSata to boot from and 3.9.1 works fine. However I tried the same kernel on a SD card based Sheevaplug and that failed when setting up the sdio subsytem. If I had known, I should have saved the console output but I needed to return the 'plug to service ASAP so reverted to an older kernel. I did notice that the console output differed around the sdio setup between 3.6.10 and 3.9.1. I am using a newer u-boot (2012-??) than stock. I don't think Sheevaplugs use flattened device tree yet (though it seems that Guruplugs may do so). I used the cbxbiker patches (3) and used 'make oldconfig' taking the current '/proc/config.gz' as a base.

So from my limited knowledge, I would say there is a problem with the Marvell sdio in the 3.9+ kernels and looking at the kernel changelogs, plainly there are changes afoot in that area. I think someone has to get the right combination of configuration, modules and possibly code changes in the sdio area to get Sheevaplugs working with 3.9+ kernels.

I have also compiled 3.9.1 for my sheevaplugs with mixed results. Three of my Sheevaplugs use eSata to boot from and 3.9.1 works fine. However I tried the same kernel on a SD card based Sheevaplug and that failed when setting up the sdio subsytem. If I had known, I should have saved the console output but I needed to return the 'plug to service ASAP so reverted to an older kernel. I did notice that the console output differed around the sdio setup between 3.6.10 and 3.9.1. I am using a newer u-boot (2012-??) than stock. I don't think Sheevaplugs use flattened device tree yet (though it seems that Guruplugs may do so). I used the cbxbiker patches (3) and used 'make oldconfig' taking the current '/proc/config.gz' as a base.

So from my limited knowledge, I would say there is a problem with the Marvell sdio in the 3.9+ kernels and looking at the kernel changelogs, plainly there are changes afoot in that area. I think someone has to get the right combination of configuration, modules and possibly code changes in the sdio area to get Sheevaplugs working with 3.9+ kernels.

You're using the kernel's on e-SATA plugs and I'm using them on the original Sheevaplug (booting from SD), so it appears that they work on both.

When you say using the "same" kernel, do you mean the same uImage? If so that would be the wrong thing to do. The uImage is a merged common zImage with the appropriate .dtb appended. The .dtb is what differentiates the different models (see UPDATE-KERNEL.sh).

Yes the same uImage. I really do not want to use different kernel variants for my Sheevaplugs depending on the type of storage used. The built xilka kernels (at least the last time I looked at the xilka .config files) still treated eSata as a module and thus would not boot from disk as I want.

Although I havn't checked yet, yes, I think my problem is use of .dtb (flattened device tree) files for hardware in the new kernel. Taking the .config (/proc/config.gz) file from an older kernel, not using fdt, will try and use the old style hardware setup. As the SDIO is (I think) now set up in fdt, there plainly is an incompatability. With eSata, it does not seem to matter. Obviously this is something I will have to check. As I also want to get newer kernels for Tonidoplug2 (Topkick) and previously had no success with the fdt version, I will have to see how these work in 3.9+. I will also try and understand the use of fdt in u-boot and kernel as documentation is a bit scattered in my opinion.

Yes the same uImage. I really do not want to use different kernel variants for my Sheevaplugs depending on the type of storage used. The built xilka kernels (at least the last time I looked at the xilka .config files) still treated eSata as a module and thus would not boot from disk as I want.

Although I havn't checked yet, yes, I think my problem is use of .dtb (flattened device tree) files for hardware in the new kernel. Taking the .config (/proc/config.gz) file from an older kernel, not using fdt, will try and use the old style hardware setup. As the SDIO is (I think) now set up in fdt, there plainly is an incompatability. With eSata, it does not seem to matter. Obviously this is something I will have to check. As I also want to get newer kernels for Tonidoplug2 (Topkick) and previously had no success with the fdt version, I will have to see how these work in 3.9+. I will also try and understand the use of fdt in u-boot and kernel as documentation is a bit scattered in my opinion.

I've just updated 3.9.2 to build sata_mv into the kernel, this should work fine for sheevaplug-esata boot from sata. The main reason that I didn't build sata_mv into the kernel before was that the standard sheeva's were hanging on boot due to missing sata hardware. That should no longer be the case with .dtb kernels.

Well I tried the precompiled 3.9.2 kernel on my compiler/test eSata Sheevaplug using the script but my system did not boot. It loaded the uImage but then failed to load. I am pretty sure that the problem is that I am using EXT4 on root (/dev/sda1) and by default, I see that EXT4 is not set up either as a module or builtin.

Therefore, I am starting to build a 3.9.2 kernel with Device Tree from scratch! Its edukayshun innit!