Slackware - ARMThis forum is for the discussion of Slackware ARM.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Sorry for the noob question (I did my homework but can't find the answer).
I recently installed Slackware-current on my RasPi2 using the Fatdog.eu method. It works flawlessly. Clearly Slackware is the only sensible choice of OS on the pi ;-)
However I'm struggling to understand how to get the current kernel to run. After the update "uname -r" yields the 3.18 series. How do I get the new kernel installed? Is there an equivalent way to sbin/lilo and point to the new kernel image?
Ok update. I installed and ran rpi-update but that only bumped the kernel version up to 4.1.17-v7+. Grateful if someone would guide me on how to get the latest 4.3.3 to run.
As far as I know kernel sources for RPi is not off kernel.org but off a RPi foundation git forked from mainstream kernel.
Their newest version available is somewhere in the 4.1 range ... if you feel like compiling your own you could git clone from there.
If you want it already build ither go with what fatdog has or ripp it off raspbian like I suggest in the Manual installation method which works on both RPi and RPI2.
I'm not entirely clear though why the raspberry pi can't run a vanilla kernel i.e. one found on the Slackware ARM tree? Does there need to be some low level customization for the kernel to run on a pi? I thought that the structure of loadable kernel modules meant that a vanilla kernel is fully comparable with virtually any hardware.
I refer to kernels compiled from unpatched source out of kernel.org as vanilla kernels (but I may be wrong in doing that).
As far as I know Slackware on Intel runs on vanilla kernels ... now ARM is not like Intel so it is more common that any specific ARM based soc has several patches that have not made their way to mainstream ... hence the need for having forked so many kernel development branches for such a variety of ARM soc's. This is why Slackware arm cannot officially support every ARM device it could run on ... but the Slackware ARM userland can run most of them provided you can find a kernel for whatever hardware you want to run it in.
I'm not entirely clear though why the raspberry pi can't run a vanilla kernel i.e. one found on the Slackware ARM tree? Does there need to be some low level customization for the kernel to run on a pi? I thought that the structure of loadable kernel modules meant that a vanilla kernel is fully comparable with virtually any hardware.
Cheers, Tim
The ARM kernel is mostly vanilla apart from 2-3 patches to fix issues that will never be fixed upstream (such as the awful hack for the Tegra to prevent USB disconnects of the internal hard drive).
I try to avoid all patches unless necessary - generally if the support for a device does not make it upstream, it will get locked at a particular version of the kernel (because nobody is interested in developing the support enough to get it merged upstream). That's why I only carry patches that are absolutely necessary and won't be taken upstream, and that don't change much.
I *think* that the armv7 kernel in -current can run on the RPI2 but I don't know and I don't have a RPi2. I'm pretty sure that I added the required SoC support a few kernels ago.
Linux 4.3.5 kernel packages will be uploaded today so if you know how to make the RPi boot this kernel, give it a go.
Last edited by drmozes; 02-03-2016 at 12:34 PM.
Reason: kernel packages are being uploaded today
I'm not entirely clear though why the raspberry pi can't run a vanilla kernel i.e. one found on the Slackware ARM tree? Does there need to be some low level customization for the kernel to run on a pi? I thought that the structure of loadable kernel modules meant that a vanilla kernel is fully comparable with virtually any hardware
This is more for general information rather than something specific to your case (since I am not familiar enough with your hardware support in the kernel). But support for hardware needs to be added to the kernel. This can occur directly in the kernel or via 3rd-party modifications (this could be modifications to the kernel itself, or providing you with source that can be built against your current kernel to create the needed modules/drivers).
To (hopefully) simplify, the kernel has the drivers for 95% of the hardware out there, but some hardware will require drivers that are not available in the official kernel.org kernel. The manufacturers can either provide you a completely separate kernel that has the modifications needed to support your hardware, or they can release the drivers as downloadable source, that you would then compile against your current kernel to provide you the needed modules.
This is more for general information rather than something specific to your case (since I am not familiar enough with your hardware support in the kernel). But support for hardware needs to be added to the kernel. This can occur directly in the kernel or via 3rd-party modifications (this could be modifications to the kernel itself, or providing you with source that can be built against your current kernel to create the needed modules/drivers).
To (hopefully) simplify, the kernel has the drivers for 95 of the hardware out there, but some hardware will require drivers that are not available in the official kernel.org kernel. The manufacturers can either provide you a completely separate kernel that has the modifications needed to support your hardware, or they can release the drivers as downloadable source, that you would then compile against your current kernel to provide you the needed modules.
The issue at hand is usually due to the SoC (System on Chip) itself: there is no "generic ARM" - each device has to have its own support in the Kernel. Even if one ARM device is very similar to another (e.g. the Banana Pi vs Banana Pi Pro), there has to be a Flattened Device Tree for it to detail the layout of the hardware on the board since there is no such thing as a BIOS on ARM.
Usually the developers work on them in their own git repo and eventually push the support to the kernel.org tree, but not always; or they push some but never complete the support for the remaining things such as audio.
I had to deal with this quite a bit with Android devices and their kernels... I was just trying to give a broad explanation on why "I thought that the structure of loadable kernel modules meant that a vanilla kernel is fully comparable with virtually any hardware" doesn't mean that every device will have full support within the vanilla kernel. But thanks for the additional information... it never clicked in my head that ARM devices lack a BIOS or something similar.
If you're not going to compile the kernel, or at least from the sources that come with slackware, you can remove kernel-source ... I'd keep the kernel headers because you might need them for compiling other stuff.
If you're not going to compile the kernel, or at least from the sources that come with slackware, you can remove kernel-source ... I'd keep the kernel headers because you might need them for compiling other stuff.
Originally every arm device added patches and additions to the kernel but then Linus had a big dummy spit over it because it was getting absurd and insisted arm devices use device tree files. That has made things better but it still requires a fair amount of work to port a kernel version to a new arm device.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.