Hello

Slackware ARM v14.0 will become EOL (End of Life) on 5th May 2015 which means that it'll no longer receive any security patches. Please plan to upgrade your 14.00 installations to Slackware ARM 14.1 for continued support.

Thanks! I'm going to upgrade the installation on my Raspberry Pi.

Slackware ARM 14.1 needs gcc 4.8.4 packages built for it. The current 4.8.2 ones have been blacklisted by the kernel development team (Oct 2014). Making it impossible to update the kernel to 3.18. Ontop of which they've broken kirkwood_defconfig on some systems (the ones I have) by removing support for some boards, it'll still compile cleanly, and produce a uImage, but that image won't boot, claiming you're trying to run it on an unsupported machine id. I fixed that, I bricked the system, and discovered u-boot have removed the board specific support for it as well. Be careful when testing new u-boot/kernel versions on your stuff.

I'm not sure what you've found regarding u-boot, but what's happened in the kernel is that they've moved the support for most of the armv5 systems into Flattened Device Tree.
Some versions of U-Boot support loading FTD 'blobs' directly, but others don't. In Slackwarearm-current for the Kirkwood devices I've modified the installation instructions and kernel package scripts to deal with it.
If the version of U-Boot you have does not support FDT then you need to append the DTB to the end of the zImage prior to making a u-boot.
This is the script I wrote that is to be run on the x86 machine where your tftp server is. You choose which Kirkwood device you want, and it'll append it and re-create the uImage. It does need the device tree compiler though - a URL for which is in the script itself.

ftp://ftp.arm.slackware.com/slackwar...k/fdt-selector


Regarding the kernel - I didn't know about that. I'll look at making some updated packages.

1 members found this post helpful.

I've bricked it, it was my own mistake, trying to update u-boot to get FTD support. I put 2015.01 on it and then discovered that it wouldn't boot the kernel 3.16.7 because the kirkwood_defconfig kernel I'd compiled didn't support the machine type u-boot reported to it. I tried to move it backwards to a lower version of u-boot, and screwed that up. It was an Iomega iConnect, now it's a brick. I've been wondering whether I want to bother trying to recover it, or whether I should just move to a new box. I've had at least 5 years of service out of them (I have two of them, and everything is replicated across them, so I haven't lost anything, just the box itself).

The Details.
I went to u-boot 2015.01, that requires the GENERIC_BOARD be defined in the board header file, as the board specific support for the board I have was removed. That passed a machine id of 0xb36 to the 3.16.7 kernel I'd compiled with kirkwood_defconig. The kernel reported the machine id wasn't supported (despite the kirkwood_defconfig supposedly supporting the iconnect)(complete with a list of supported machine ids). I tried to boot it using the Kirkwood development board machine id (ffffffff)(that was in the list of supported machine ids 3.16.7 reported when it failed to boot), the kernel just hung. At which point I wondered what I might get if I went back to a 2014 version of u-boot. Then I bricked it. Now I'm looking at a Gigabyte Brix, and wondering if an x86 box might be a suitable replacement.

The default configs often are not uptodate, in my experience.

The u-boot upgrades scared me off - I always try to avoid it unless I can recover. Fortunately for the Plug devices it's normally do-able and the Trimslice can always be recovered back to the factory version with the reset button.
I don't dare touch the OpenRD client though!

The notes I made to recover the Gurugplus are here:
http://ftp.arm.slackware.com/slackwa...va/unbrick.txt

I don't know if those would be helpful.

One of the things I found out was that you can load a new u-boot binary and boot it from u-boot itself so that you can test it in advance - although I'm not sure it can be done with all versions of u-boot.

I read that as well, but I couldn't get it to work, hence my lovely new brick :-)

You haven't got rid of me btw, I'm using Slackware ARM on Raspberry Pis as appliances for the company I work for. We put them in customer sites. They're currently running the 14.0 release, but I'm moving them up slowly to 14.1. They're solid, I've got appliances which have been running for two years without any problem. Thank you for all your efforts. It makes putting a platform ontop so much easier.

Thanks!

gcc 4.8.4 packages are now available for 14.1