A. This is the most frequently asked question.

The answer is "Probably".

Slackware ARM *user land* (all of the *packages*) will run on any ARM cpu which is an armv4t or higher. For Slackware ARM 13.1 and onwards, you need to ensure that your CPU supports the thumb instruction set which is necessary to support the EABI. Most CPUs meet these requirements - especially *new* ARM devices.

If your CPU doesn't support the thumb instruction set then you'll have to use Slackware ARM version 12.2 which is "old ABI". However, old ABI is unsupported and shouldn't be used. If this is the case, get a new ARM device.

It is impossible for Slackware ARM to support each ARM device out of the box. Unlike in the x86 world where one Kernel can be used for all machines, in the ARM world we need one kernel per ARM architecture (hence why Slackware ARM has two kernel packages - one for the 'Kirkwood' System On Chip architecture and another for the 'ARM Versatile' board), so unless your device is currently supported by Slackware ARM, you'll need to compile your own kernel and determine how to adjust the boot loader used on the device (u-boot is the most common choice). Don't confuse the user land (the packages) support with the Kernel. There's no need to "port" Slackware ARM to another ARM architecture (unless you want to recompile some packages for better efficiency when executing on a higher grade CPU than ARMv5) - usually you will just need a new kernel and that kernel's modules, and maybe some additional driver modules for X.org. If you're new to Linux and ARM, this presents a huge learning opportunity for which you will need to set aside a large slice of time, tenacity, curiosity and interest!

One of the easiest ways to check whether your device has any semblance of Linux community support is to check whether Debian ARM runs upon it. If so, many of the Debian users tend to write excellent documentation describing how they installed Linux upon their device. Most of this information can be used to assist with shoehorning Slackware ARM on to the device.

A. You may have used ASCII transfer mode if you downloaded via FTP. Re-download using BINARY transfer mode.

A. This is usually because the kernel you're running is older than 2.6.31 (Slackware ARM's glibc is compiled to require a kernel version 2.6.31 or greater).

You need to upgrade the kernel on your existing ARM Linux installation.

A. Slackware ARM aims to follow as many kernel configuration options in x86 as possible in order to provide a consistent user experience, but the ARM port uses which ever kernel is the most appropriate at the time with regard to the ARM architecture (usually the latest kernel is preferred, or necessary to provide support for a newly supported architecture).

A. This READ ME file explains the process.

A. Not directly. The packages are all built natively on a running Slackware ARM OS, but use distcc to a bunch of x86/x86_64 machines that runs a basic "cross" toolchain that match the versions of the toolchain et al present in slackwarearm-current. The cross toolchain can be found here. It's usually been tested and builds on slackware-current but is unsupported.

A. Slackware ARM used ScratchBox back in 2002 to originally build the first batch of packages in order to bootstrap the port, and some effort was made in producing scripts to help setup a Slackware-like environment. However, this work was abandoned shortly after the port was able to be self supporting.

A. If you wish, you can cross compile software using a suitable cross compiler that outputs ARM binaries. There are a number of cross compilers available in binary form, or you can build your own (although that's much more work but you'll learn a lot!). The reason that Slackware ARM packages are built natively is because many packages aren't suitable for cross compilation without making many manual adjustments to Makefiles and configure scripts. Also, if your package is linking against system libraries, it can be tricky to get this working properly in a cross compiler environment. In my experience, it's far easier to get a fast ARM machine (an OpenRD Client with an internal SATA or external eSATA drive) and use distcc. The amount of time you spend waiting for the build to finish is far off set by the amount of time hacking build systems to work properly in a "cross" environment.