Hi,

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?

Thanks, Tim

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.

Thanks, Tim

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.

1 members found this post helpful.

Ok thanks for the clarification.

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

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.

Not sure if this clarifies ... if not have a look in the Slackware ARM supported devices section for starters.

1 members found this post helpful.

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.

1 members found this post helpful.

Thanks Stuart for this! I'll have a go on the weekend; will give me something to do with all this rain coming ;-).

Cheers, Tim

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.

So, do I understand correctly that one can remove the slackware kernel-* packages? Or should one keep the kernel-source and kernel-headers?

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.

1 members found this post helpful.

Cheers!

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.