Slackware ARM -current & 'Kirkwood' devices - must read

In a nut shell, you probably have some work to do if you want your non-(sheeva|guru|openrd) device to work with -current, and the next release of Slackware.

Essentially, the Kernel developers have moved most of the 'built-in' board support from the kernel into the FTDs (Flattened Device Tree) system.
This is good when your device supports it, but given that most of the versions of U-Boot available for the Kirkwood (usually some name about gurus, dreams or fictional martial artist characters) don't actually support FTD, this becomes a new challenge. Even if there is a version of U-Boot for your device, it doesn't mean you fancy risking 'bricking it' (although it's actually pretty easy to recover a bricked Sheevaplug as I found out last weekend when my youngest managed to derail my concentration, which resulted in wiping the firmware and rebooting immediately afterwards).

I'd climbed the mountain of FTD a while ago when I implemented it for the Trimslice, so the ground work is complete. However, the Trimslice has a version of U-Boot that supports supplying FTD to the Kernel.
If your device has not got a suitable U-Boot available, the only other option is to append the DTB to the kernel (cat dtb >> zImage; mkimage ...--> uImage).
This is how I'm currently running -current with Linux 3.15.2 on my SheevaPlug. The approach Debian have taken is to determine (via some platform-specific stuff in /proc) the device and append the appropriate FTD to the zImage.
This I can accommodate in the kernel's 'install/doinst.sh' once I determine a solid way to differentiate devices (/proc/cpuinfo is too generic when using FTD, unfortunately). I should be able to do this for Sheeva, OpenRD and Guruplug (assuming I can convince the owner of the Guru to 'lend' it to me).
The booting of the installer would be set via a 'dialog' script on the x86 after putting 'u-boot-tools' into 'extra' in x86/64.

Does anybody care about any other Kirkwood devices other than those?
Does anybody care about Kirkwood devices at all anymore? ;-)

I run Slackware ARM on a Kirkwood, a ix2-200; it's my main backup/printserver. I'm running 13.37 on it, though, not -current. I suppose at some point I might need to update the OS, but there has been no need to date. Thanks for the info though.

Might be a good thing to have this "Sticky" at the top ... just in case someone misses this important information in the near future.

Stuart: what are the chances that u-boot for the trimslice works for the AC100 ?

Originally Posted by louigi600 Might be a good thing to have this "Sticky" at the top ... just in case someone misses this important information in the near future. Stuart: what are the chances that u-boot for the trimslice works for the AC100 ?

Each U-Boot is configured specifically for each device. When you build it you specify a board config file.
Therefore the U-Boot binary for the Trimslice will not be of use for anything other than a Trimslice.

The support I added for FDT is around adding the dtb files to the kernel packages, and setting them up to be versionless so a kernel can be upgraded without having to modify the u-boot config (in the same was as the uImage or uinitrd is loaded). The Trimslice needs no further work since its u-boot has support for FDT.

For other devices with U-boot, you may find that they don't boot any kernels past version 3.12 regardless of FDT. I don't recall what the change was in the kernel to cause this, but it affected the 'Plug' computers that had the original Marvell branded u-boot. However, my OpenRD client has the original Marvell branded u-boot and it works fine with Linux 3.15.

If you're not using U-Boot then you'd still need either that alternative boot loader to be upgraded to support FDT (the best choice) or you'd need to append the FDT to the zImage (and in u-boot's case, you'd make the uImage file from the zImage with the appended FDT).

I had what I think is the best idea to handle this. The correct FDT can be supplied as a kernel parameter and the doinst.sh script in the kernel package can handle it correctly without having to rely on some (most likely incorrect) guesses about what the architecture is. I can work around devices that don't need an FDT appending (such as the OpenRD client), and try and guess the device if the kernel parameter isn't present.

I'm not sure this will make a lot of sense if you haven't done any reading about FDT and so on, but it will if you ever upgrade and your kernel spits out that your board isn't supported, or halts at 'Uncompressing Linux.....'.

Originally Posted by drmozes Does anybody care about any other Kirkwood devices other than those? Does anybody care about Kirkwood devices at all anymore? ;-)

I do! I have three Dockstars and two PogoPlug E02s. I use this uboot from Doozan http://forum.doozan.com/read.php?3,12381, supports FTD, but I'm still running Slackwarearm 14.1. In the next few weeks I'll give current a try in one of these devices and report back.

I've 2 dockstars and 2 goflexnets and all 4 of them run vital services to my home network, two of which are on 24x7.
They all have dozan's uboot, but never tester thd FDT stuff, and thee all run on Slackware ARM 14.1 with varying amount of custom work on them. There's no plan for replacing the hardware so I do care a lot for my kirkwood devices ... just not interested at the moment in running newer releases on them.