[2024-feb-29] Sad news: Eric Layton aka Nocturnal Slacker aka vtel57 passed away on Feb 26th, shortly after hospitalization. He was one of our Wiki's most prominent admins. He will be missed.

Welcome to the Slackware Documentation Project

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
slackwarearm:faq [2017/08/09 13:01 (UTC)] – mozesslackwarearm:faq [2017/11/15 09:16 (UTC)] (current) – Added FAQ about detecting soft vs hard float mozes
Line 15: Line 15:
 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! 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.+One of the easiest ways to check whether your device has any semblance of Linux community support is to check whether Debian or Fedora 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. 
 + 
 + 
 +//Q. Why does Slackware ARM support device X but not Y? // 
 + 
 +A.  This question is often asked in reference to the Raspberry Pi, which by far has the most wide spread mind share. 
 +Slackware ARM is developed by [[http://www.slackware.com/~mozes/|one person]] whose interest in ARM is very specific.  ARM devices have to have Real Time Clocks, preferably SATA support and most importantly have support in the mainline Kernel.  It's impossible to progress an Operating System if you're tied to a specific version of the Kernel (even if it's for a short period) because it slows down the development cycle. 
 +In addition, the devices targeted for "official" support (devices supported directly from the Slackware ARM tree) need to be open and not require propitiatory/licenced firmware and hacking in order to permit boot of an alternative OS. 
 +The Slackware ARM community fills in gaps where there is demand. 
 + 
  
 ===== Installation specifics  ===== ===== Installation specifics  =====
Line 49: Line 59:
 // //
  
-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 slackware64-current but is unsupported.+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 [[ftp://ftp.arm.slackware.com/slackwarearm/slackwarearm-devtools/x-toolchain/|here]]. It's usually been tested and builds on slackware64-current but is unsupported.
  
 //Q. Does Slackware ARM use Scratchbox? //Q. Does Slackware ARM use Scratchbox?
Line 55: Line 65:
  
 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. 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.
 +
 +==== 3rd party SlackBuild scripts ====
 +
 +//Q. As a maintainer of SlackBuild scripts, how can I differentiate between Slackware 14.2 (Software Floating Point) and Slackware 15.0 (Hardware Floating Point) and greater?
 +//
 +
 +A. [[http://armed.slackware.com/scripts/cflagsarm|This code snippet]] checks the target quadlet from gcc and sets the default compiler flags.
  
 ==== Cross compiling software ==== ==== Cross compiling software ====
Line 61: Line 78:
  
  
-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.+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 (a quad core Orange Pi) 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.
  
 ===== General ===== ===== General =====
Line 68: Line 85:
 // //
  
-A. Originally the ARM port was named ARMedslack because it was not an official port, and as such could not have the hold Slackware name. In 2009, ARMedslack became the official port but continued with the ARMedslack name until 2012 when it was renamed Slackware ARM in time for the release of Slackware 14.00. The delay in changing the name was simply due to the amount of work required in doing so!+A. Originally the ARM port was named ARMedslack because it was not an official port, and as such could not hold Slackware name. In 2009, ARMedslack became the official port but continued with the ARMedslack name until 2012 when it was renamed Slackware ARM in time for the release of Slackware 14.00. The delay in changing the name was simply due to the amount of work required in doing so!
  
  

Trace:

slackwarearm:faq ()