[SOLVED] Building a kernel for all Raspberry Pi boards under Slackware ARM 14.2 and -current

abga · 02-08-2019, 11:02 PM

There is already a thread discussing this and a few other complementary threads and posts adding to the subject, none of which having a suggestive enough title and some posts might be obsolete (I wrote one myself related to the kernel firmware) or lacking details. I considered starting this new thread, with a specific subject and put all gathered knowledge and experience in it.
Credits:
https://www.raspberrypi.org/document...el/building.md
https://www.linuxquestions.org/quest...is-4175621155/
https://lemariva.com/blog/2018/07/ra...-kernel-4-14-y

Compiling the Raspberry Pi Foundation-provided kernel for the Raspberry boards under Slackware ARM is mainly a simple process, but there are some details about the structure of the boot process and the required files, the kernel&firmware version choice and the kernel source files source that are worth detailing.

The kernel is floating point "agnostic", which means no binary floating point instructions are generated during the build. But the ARM code - ARMv6/ARMv7 is important and because of that only native builds are accepted. The toolchain from Slackware ARM 14.2 is only able to generate ARMv5/6 code and the one from Slackware ARM -current ARMv7.
I'll cover both Slackware ARM releases and all the existent Raspberry boards - P1 1/0 -ARMv6, Pi2B-ARMv7, Pi3B(+)ARMv8 for 32bit builds:
https://en.wikipedia.org/wiki/Raspbe...Specifications

Using "pi1" will imply Slackware ARM 14.2 - SoftFloat on ARMv6
Using "pi2-3" will imply Slackware ARM current - HardFloat on ARMv7 or ARMv8 (same kernel configuration file provided by Raspberry ATM)

Limitations: I only was able to build for ARMv6 (Pi Zero) and ARMv7 (Pi2B) since I don't own any ARMv8 Raspberry boards (Pi3B(+)), but the instructions are the same for both ARMv7 and ARMv8.

Time and space considerations: the cloned or downloaded&unpacked kernel source takes around 1GB of space, compiled it can grow to around 1,5GB. For both the pi1 & pi2-3 kernel builds I used a Pi2B board, loaded with Slackware ARM 14.2 SF for the pi1 and with Slackware ARM -current HardFloat for the pi2-3, and used 4 make jobs. It took around 3 hours per build and I don't know how much it'll take to build directly on a Pi1 / PiZero with only one make job. Since the kernel source files are pretty small, the RAM requirements are low too - I observed peaks at 500-600MB, even with 4 make jobs.
Again, for consistency considerations I'll use absolute paths and the /kernel-build/ as working directory. If you do not plan to do all the steps as root, chown /kernel-build/ to your user, or work in /tmp if it fits the compilation.

First things first - Always have a backup!

Code:

#as root
cd /
tar -czpf raspberry-boot-stuff-kernel-x-x-x-date-x-x-x.tgz /boot/ /lib/modules/ /lib/firmware/
# save these files again, separetlly
cp /boot/cmdline.txt /boot/config.txt .

- consider copying the archive on an external drive

Prepare the workplace:

Code:

mkdir -p /kernel-build/ && cd /kernel-build/

1. Raspberry Pi Firmware - the firmware Raspberry uses to load into the GPU and boot the board, it's residing in /boot, not to be confused with the (former) kernel in-tree firmware from /lib/firmware.
It's recommended to match the firmware with the kernel release and a good guide for that is:
https://downloads.raspberrypi.org/ra...ease_notes.txt
For the Linux kernel 4.14.79 the firmware is 12e0bf86e08d6067372bc0a45d7e8a10d3113210 and you can get it (unfortunately it comes with a lot of stuff you don't need) with:

Code:

wget https://github.com/raspberrypi/firmware/archive/12e0bf86e08d6067372bc0a45d7e8a10d3113210.zip
#extract only the /boot/ directory into your pi-firmware/ destination
unzip /kernel-build/12e0bf86e08d6067372bc0a45d7e8a10d3113210.zip 'firmware-12e0bf86e08d6067372bc0a45d7e8a10d3113210/boot/*' -d /kernel-build/pi-firmware/
mv -r /kernel-build/pi-firmware/firmware-12e0bf86e08d6067372bc0a45d7e8a10d3113210/boot/* /kernel-build/pi-firmware/
rm -rf /kernel-build/pi-firmware/firmware-12e0bf86e08d6067372bc0a45d7e8a10d3113210/ /kernel-build/pi-firmware/overlays/ /kernel-build/pi-firmware/*.dtb /kernel-build/pi-firmware/*.img /kernel-build/12e0bf86e08d6067372bc0a45d7e8a10d3113210.zip

- the possibility to use an older firmware exists, not officially supported and you might loose some functionality, even not be able to boot if it's too old. Therefore, you can leave the version you already have in /boot and don't care about updating it, if you choose to - on your own risk...
- to obtain the latest development firmware, just clone it from the Raspberry git repo (again, you'll download extra stuff you don't need):

Code:

git clone --depth=1 git://github.com/raspberrypi/firmware.git /kernel-build/pi-firmware/
mv /kernel-build/pi-firmware/boot/* /kernel-build/pi-firmware/
rm -rf /kernel-build/pi-firmware/.git/ /kernel-build/pi-firmware/boot /kernel-build/pi-firmware/documentation/ /kernel-build/pi-firmware/extra/ /kernel-build/pi-firmware/hardfp/ /kernel-build/pi-firmware/modules/ /kernel-build/pi-firmware/opt/ /kernel-build/pi-firmware/overlays/ /kernel-build/pi-firmware/*.dtb  /kernel-build/pi-firmware/*.img

2. Kernel source - the only source you can use for this kernel compilation guide is the official Raspberry Pi Foundation-provided kernel, it contains modifications, adaptations and drivers required for the Raspberry boards. The mainstream source from kernel.org is not suitable for the steps described in this guide! There are choices of kernel versions to use:

a. - the developement "bleeding-edge" master - use on your own risk. Get the code:

Code:

git clone --depth=1 https://github.com/raspberrypi/linux

b. - use a branch of your choice, still the the development "bleeding-edge" master, by looking at the available ones at https://github.com/raspberrypi/linux and using, for example:

Code:

git clone --depth=1 --branch rpi-4.18.y https://github.com/raspberrypi/linux

c. - the stable release, matching the one compiled and released in the official Raspbian images, the recommended one but pretty useless to rebuild, since it can be easily extracted from the Raspbian image. Still, useful if some extra drivers or driver patches are required.
- look at https://downloads.raspberrypi.org/ra...ease_notes.txt first and make your choice, then browse the releases from:
https://github.com/raspberrypi/linux/releases
- click on the commit link for each release to find out the exact kernel version.
The raspberrypi-kernel_1.20181112-1 matches the latest official stable release - Linux kernel 4.14.79 - from release_notes.txt
Grab the code and unpack it:

Code:

wget https://github.com/raspberrypi/linux/archive/raspberrypi-kernel_1.20181112-1.tar.gz
tar -xzpf /kernel-build/raspberrypi-kernel_1.20181112-1.tar.gz
mv /kernel-build/raspberrypi-kernel_1.20181112-1/ /kernel-build/linux/

3. Building the kernel. The Raspberry kernel has ATM (documented) two make targets that will prepare a default .config file for the platform you choose:

a. For pi1 - ARMv6 use:

Code:

cd /kernel-build/linux
KERNEL=kernel
make bcmrpi_defconfig

b. For pi2-3 - ARMv7&ARMv8 use:

Code:

cd /kernel-build/linux
KERNEL=kernel7
make bcm2709_defconfig

- you can add some patches or edit the .config file / configure the kernel and move to the common steps for the building process:

Code:

#on pi1 use only one make job - use make -j1
make -j4 V=1 zImage
make -j4 V=1 modules
make -j4 V=1 dtbs

4. Installing the modules & kernel & dtb & dto files & pi firmware & boot configuration
- once the compilation finishes you'll need to install the modules. If the version you're compiling differs from the one you are running, then you can leave the older modules in /lib/modules, clean them later. Otherwise, make sure you clean the content of /lib/modules and run:

Code:

make modules_install

- then install the kernel. Here you can either choose a different name for it and use /boot/config.txt to point which kernel to load (pretty useless) or (better) create a /boot/backup folder and move there the content of your actual /boot. Leave /boot clean (only the backup folder available).
a. For pi1 - ARMv6 use:

Code:

cp -f arch/arm/boot/zImage /boot/kernel.img

b. For pi2-3 - ARMv7&ARMv8 use:

Code:

cp -f arch/arm/boot/zImage /boot/kernel7.img

- then for both, continue with the following steps:
- copy over the System.map

Code:

cp -f System.map /boot/System.map

- install the device tree binaries *.dtb and device tree overlay *.dto

Code:

cp -f arch/arm/boot/dts/*.dtb /boot/
mkdir -p /boot/overlays/
cp -f arch/arm/boot/dts/overlays/*.dtb* /boot/overlays/
cp -f arch/arm/boot/dts/overlays/README /boot/overlays/

- reference on *dtb & *dto:
https://www.raspberrypi.org/document...device-tree.md
- install the pi firmware

Code:

cp -f /kernel-build/pi-firmware/* /boot/

- put back/overwrite the boot configuration files

Code:

cp -f /cmdline.txt /config.txt /boot/

5. Kernel firmware, residing in /lib/firmware and needed by the kernel + device drivers. Since before the kernel 4.14.x release it was removed from the kernel source tree:
http://lkml.iu.edu/hypermail/linux/k...9.1/04650.html
And there are two ways to obtain an updated version for Raspberry under Slackware ARM.

a) The slimmed down (less than 50MB) standard version obtained from the raspbian image (manual installation method):
https://docs.slackware.com/howtos:ha...rm:raspberrypi

b) Getting it from Raspberry, a little bigger, still under 150MB:

Code:

cd /kernel-build/
git clone --depth 1 https://github.com/RPi-Distro/firmware-nonfree
rm -rf /kernel-build/firmware-nonfree/.git/
rm -rf /kernel-build/firmware-nonfree/.pc/
cp -rf /kernel-build/firmware-nonfree/ /lib/firmware/

- For the Raspberry Pi boards that have a WiFi&Bluetooth module, you also need the firmware for it. The files will reside in /lib/firmware/brcm:

Code:

wget -N -P /lib/firmware/brcm https://raw.githubusercontent.com/RPi-Distro/bluez-firmware/master/broadcom/BCM43430A1.hcd
wget -N -P /lib/firmware/brcm https://raw.githubusercontent.com/RPi-Distro/bluez-firmware/master/broadcom/BCM4345C0.hcd

That's pretty much it, reboot and enjoy your freshly compiled kernel.
It was also my first compilation(s) and I haven't got into any issues.
If you want to revert to your previous version, clean the actual one and restore the backup:

Code:

cd /
rm -rf /lib/modules/ /lib/firmware/ /boot/*
tar -xzpf raspberry-boot-stuff-kernel-x-x-x-date-x-x-x.tgz

Have fun!

P.S. If you want to keep the kernel source tree for future use, archive /kernel-build/linux/ and store it somewhere. At least backup the Module.symvers file if you plan to build some modules in the future, the source archive you can always download again if needed.

abga · 02-08-2019, 11:12 PM

Interesting sites where you can grab official Raspberry "stuff" without having to download the Raspbian image and extract the "stuff" from it:
https://github.com/RPi-Distro
https://archive.raspberrypi.org/debian/pool/main/r/
https://archive.raspberrypi.org/debi...rypi-firmware/

Useful info about the boot sequence on the Raspberry Pi boards:
https://www.raspberrypi.org/document...es/bootflow.md
https://raspberrypi.stackexchange.co...-boot-sequence

SCerovec · 02-09-2019, 04:02 PM

subscribed

abga · 02-09-2019, 09:00 PM

The mainstream kernel can also be used as source, but I didn't test it with the steps presented in the first post from this thread, nor am I interested about it ATM. A partially working kernel is no good for me. That doesn't mean that you cannot play with it, if you have some spare time to kill.
For the history and status of the support for the Raspberry boards in the mainstream kernel, follow:
https://github.com/raspberrypi/linux/wiki/Upstreaming
What works and what doesn't is not yet clear and there are very recent issues, like:
https://github.com/raspberrypi/firmware/issues/957
Plus, the Raspberry folks are "encouraging" you that you're on your own if you get into issues with the mainstream kernel, like:
https://www.raspberrypi.org/forums/v...c.php?t=203923

There are some mainstream kernel compilation guides that can be used for inspiration:
https://elinux.org/RPi_Upstream_Kernel_Compilation
(try to omit the cross-compilation requirements and switches)
https://wiki.gentoo.org/wiki/Raspber...ainline_Kernel
(covering only Pi2 and Pi3)

The kernel configuration defaults required by the Raspberry boards do exist in the mainline:
https://github.com/torvalds/linux/tr...ch/arm/configs
bcm2835_defconfig - Raspberry Pi1
multi_v7_defconfig - Raspberry Pi2 and Pi3

To play with the mainstream kernel you'll need the following amendments to the guide from the first post:
Step 2 - Get the source (don't know for sure what branch to use, but the latest master might be more appropriate):

Code:

git clone --depth=1 git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

Step 3 - Building the kernel
a. For pi1 - ARMv6 use:

Code:

cd /kernel-build/linux
KERNEL=kernel
make bcm2835_defconfig

b. For pi2-3 - ARMv7&ARMv8 use:

Code:

cd /kernel-build/linux
KERNEL=kernel7
make multi_v7_defconfig

The rest of the steps should be the same.

Good luck!

abga · 03-09-2019, 01:31 AM

Some interesting updates...

In my first post I've documented the build process for the official and stable Raspberry Foundation provided kernel source release, which ATM is 4.14.79
On the Raspberry Pi 2B board under Slackware ARM -current, with this 4.14.79 release, both official compilation (extracted from Raspbian) and my own build, I'm experiencing (apparently still haunting me) the same USB issues I documented in the following (old) post:
https://www.linuxquestions.org/quest...rm-4175609456/
& last update I cared about:
https://forum.kodi.tv/showthread.php...232#pid2720232

I lost the track of the kernel mitigations on this USB issue, I only remember it was somehow resolved (offending commit reverted), although there were a few variants and discussions on how to correct the softirq.c engine for good. Considered that maybe the Raspberry Foundation haven't patched their stable/older source trees, thus, went on and tried the newer official development branch, cloned the source - at that time it was on 4.19.25 - from:
https://github.com/raspberrypi/linux
That didn't help either, I got into the same USB issues. To sum up, with both Raspberry Foundation kernel sources 4.14.79 & 4.19.25 I get the USB continuity issues like:

Code:

....
Feb 14 10:32:50 pi2s1 tvheadend[29564]: TS: Astra/11302.75H/ServusTV HD Deutschland: H264 @ #4920 Continuity counter error (total 1)
Feb 14 10:32:51 pi2s1 tvheadend[29564]: TS: Astra/11302.75H/ServusTV HD Deutschland: AC3 @ #4924 Continuity counter error (total 1)
Feb 14 10:32:54 pi2s1 tvheadend[29564]: TS: Astra/11302.75H/ServusTV HD Deutschland: TELETEXT @ #4925 Continuity counter error (total 1)
Feb 14 10:32:55 pi2s1 tvheadend[29564]: TS: Astra/11302.75H/ServusTV HD Deutschland: MPEG2AUDIO @ #4922 Continuity counter error (total 1)
Feb 14 10:32:59 pi2s1 tvheadend[29564]: TS: Astra/11302.75H/ServusTV HD Deutschland: MPEG2AUDIO @ #4921 Continuity counter error (total 1)
Feb 14 10:33:00 pi2s1 tvheadend[29564]: TS: Astra/11302.75H/ServusTV HD Deutschland: H264 @ #4920 Continuity counter error (total 139)
Feb 14 10:33:01 pi2s1 tvheadend[29564]: tbl-eit: eit: 11302.75H in Astra: invalid checksum (len 2752, errors 1)
Feb 14 10:33:03 pi2s1 tvheadend[29564]: TS: Astra/11302.75H/ServusTV HD Deutschland: AC3 @ #4924 Continuity counter error (total 9)
Feb 14 10:33:06 pi2s1 tvheadend[29564]: tsfix: transport stream AC3, DTS discontinuity. DTS = 8697600, last = 8544960
Feb 14 10:33:07 pi2s1 tvheadend[29564]: TS: Astra/11302.75H/ServusTV HD Deutschland: TELETEXT @ #4925 Continuity counter error (total 5)
Feb 14 10:33:09 pi2s1 tvheadend[29564]: TS: Astra/11302.75H/ServusTV HD Deutschland: MPEG2AUDIO @ #4922 Continuity counter error (total 5)
Feb 14 10:33:10 pi2s1 tvheadend[29564]: TS: Astra/11302.75H/ServusTV HD Deutschland: H264 @ #4920 Continuity counter error (total 269)
Feb 14 10:33:11 pi2s1 tvheadend[29564]: TS: Astra/11302.75H/ServusTV HD Deutschland: MPEG2AUDIO @ #4921 Continuity counter error (total 5)
Feb 14 10:33:12 pi2s1 tvheadend[29564]: TS: Astra/12460.5H/N24 DOKU: MPEG2VIDEO @ #511 Continuity counter error (total 1)
Feb 14 10:33:23 pi2s1 tvheadend[29564]: TS: Astra/12460.5H/N24 DOKU: MPEG2VIDEO @ #511 Continuity counter error (total 25)
....

The (second) interesting part, I considered giving the mainstream official source code a try, I only need the SoC support (incl. audio + video). USB & Ethernet for my Pi Zero & Pi2B boards, and noticed that Slackware ARM is on the same 4.19.25 release ATM.
Got the sources and prepared the build (excerpt from history):

Code:

cd /kit/kernel-build/
wget http://ftp.arm.slackware.com/slackwarearm/slackwarearm-current/source/k/sources/linux-4.19.25.tar.xz
wget http://ftp.arm.slackware.com/slackwarearm/slackwarearm-current/source/k/sources/patches/bcm2835-cpufreq-add-CPU-frequency-control-driver.patch.xz
tar -xzpf linux-4.19.25.tar.xz
mv linux-4.19.25/ linux/
cd /kit/kernel-build/linux/
# applied the only relevant patch I found:
xzcat ../bcm2835-cpufreq-add-CPU-frequency-control-driver.patch.xz | patch -p1
# get the missing (from mainstream kernel) overlays folder from the Raspberry Foundation repo:
cd /kit/kernel-build/linux/arch/arm/boot/dts
svn export https://github.com/raspberrypi/linux.git/trunk/arch/arm/boot/dts/overlays/

Manually patch - add this to the end of arch/arm/boot/dts/Makefile:

Code:

targets += dtbs dtbs_install
targets += $(dtb-y)

subdir-y        := overlays

# Enable fixups to support overlays on BCM2835 platforms
ifeq ($(CONFIG_ARCH_BCM2835),y)
        DTC_FLAGS ?= -@
endif

Manually patch - add the extra dtbo code in bold just after the dtb section in arch/arm/Makefile:

Code:

%.dtb: | scripts
	$(Q)$(MAKE) $(build)=$(boot)/dts MACHINE=$(MACHINE) $(boot)/dts/$@

%.dtbo: | scripts
	$(Q)$(MAKE) $(build)=$(boot)/dts MACHINE=$(MACHINE) $(boot)/dts/$@

For building the overlays you need to patch the scripts/Makefile.lib with the following Makefile.lib-patch:

Code:

--- Makefile.lib        2019-02-23
+++ Makefile.lib-raspberry      2019-03-07
@@ -248,6 +248,7 @@
 ifeq ($(findstring 1,$(KBUILD_ENABLE_EXTRA_GCC_CHECKS)),)
 DTC_FLAGS += -Wno-unit_address_vs_reg \
        -Wno-unit_address_format \
+       -Wno-gpios_property \
        -Wno-avoid_unnecessary_addr_size \
        -Wno-alias_paths \
        -Wno-graph_child_address \
@@ -292,6 +293,18 @@
 $(obj)/%.dtb: $(src)/%.dts $(DTC) FORCE
        $(call if_changed_dep,dtc)

+quiet_cmd_dtco = DTCO    $@
+cmd_dtco = mkdir -p $(dir ${dtc-tmp}) ; \
+       $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $< ; \
+       $(DTC) -@ -H epapr -O dtb -o $@ -b 0 \
+               -i $(dir $<) $(DTC_FLAGS) \
+               -Wno-interrupts_property \
+               -d $(depfile).dtc.tmp $(dtc-tmp) ; \
+       cat $(depfile).pre.tmp $(depfile).dtc.tmp > $(depfile)
+
+$(obj)/%.dtbo: $(src)/%-overlay.dts FORCE
+       $(call if_changed_dep,dtco)
+
 dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp)

 # Bzip2

Code:

cd scripts/
patch Makefile.lib < Makefile.lib-patch
cd ..

Some optional stuff to consider for the device tree installation automation -> dtbs_install target fix
- patch /kit/kernel-build/linux/scripts/Makefile.dtbinst with the following patch Makefile.dtbinst-patch:

Code:

--- Makefile.dtbinst    2019-02-23
+++ Makefile.dtbinst-raspberry  2019-03-07
@@ -20,6 +20,7 @@
 include $(src)/Makefile

 dtbinst-files  := $(sort $(dtb-y) $(if $(CONFIG_OF_ALL_DTBS), $(dtb-)))
+dtboinst-files := $(sort $(dtbo-y) $(if $(CONFIG_OF_ALL_DTBS), $(dtb-)))
 dtbinst-dirs   := $(subdir-y) $(subdir-m)

 # Helper targets for Installing DTBs into the boot directory
@@ -31,10 +32,13 @@
 $(dtbinst-files): %.dtb: $(obj)/%.dtb
        $(call cmd,dtb_install,$(install-dir))

+$(dtboinst-files): %.dtbo: $(obj)/%.dtbo
+       $(call cmd,dtb_install,$(install-dir))
+
 $(dtbinst-dirs):
        $(Q)$(MAKE) $(dtbinst)=$(obj)/$@

-PHONY += $(dtbinst-files) $(dtbinst-dirs)
-__dtbs_install: $(dtbinst-files) $(dtbinst-dirs)
+PHONY += $(dtbinst-files) $(dtboinst-files) $(dtbinst-dirs)
+__dtbs_install: $(dtbinst-files) $(dtboinst-files) $(dtbinst-dirs)

 .PHONY: $(PHONY)

Code:

cd scripts/
patch Makefile.dtbinst < Makefile.dtbinst-patch

Reference:
https://www.raspberrypi.org/forums/v...67903#p1135453
(I actually diffed the Makefile.dtbinst files from mainstream and Raspberry Foundation github repo)

For the Raspberry Pi2B I used the mainstream kernel config target multi_v7_defconfig :

Code:

cd /kit/kernel-build/linux
KERNEL=kernel7
make multi_v7_defconfig
make menuconfig

Spent some time disabling all the SoC&platforms support I didn't need, enabled multimedia (DVB) stuff and some extra networking options... and mistakenly enabled BTRFS

The final .config I used for the Slackware ARM "mainstream" kernel 4.19.25 is to be found at the end of this post: config-multi_v7_defconfig-Slackware-Mainstream-Kernel-4-19-25.txt
Run menuconfig if you want to remove/add stuff and start building the kernel. Follow the compilation & installation steps from post #1 , point 3. - "common steps for the building process"
Err!
- somehow I enabled the creation of all device tree files, so I had to only copy the bcm283* relevant ones to /boot

Code:

cp -f arch/arm/boot/dts/bcm283*.dtb /boot/

- will need to compare my config with the one from Raspberry and disable the other dtb files.

Bootig:
The first result - a beautiful rainbow - it won't boot.
Looking for answers, I got confused by the "popular belief" that a mainstream kernel would require U-Boot:
https://elinux.org/RPi_Upstream_Kern...our_bootloader
And then found the right answers:
https://wiki.gentoo.org/wiki/Raspber...ing_bootloader
Used the following boot configuration files in /boot:

- /boot/config.txt

Code:

kernel=kernel7.img
device_tree=bcm2836-rpi-2-b.dtb
avoid_warnings=2

hdmi_drive=1
framebuffer_depth=32
#dtoverlay=gpio-ir,gpio_pin=17,rc-map-name=rc-empty
dtparam=audio=on
gpu_mem=32
max_usb_current=1
audio_pwm_mode=2

- /boot/cmdline.txt

Code:

dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

Results - I am using a very old firmware (2017), the last one that has the analogue sound generation not broken and because of this I might have some kernel unrelated issues.

Working:
- console graphics (text mode)
- ethernet
- usb

Not working:
- sound card (firmware?)
- the vc utilities (/opt/vc) - might need a newer firmware or rebuild them
- IR (commented out in /boot/config.txt - need to uncomment and check again)
- Green LED is blinking constantly, not representing the SDCard activity (might be something I enabled/disabled in the kernel or the old firmware)
- Red LED is blinking on power down (signalling it's safe to remove the power cord) instead of green one

Not sure yet:
- vc4 graphics
- DVB drivers - softirq.c - Continuity counter error issue - what actually drove me to try the mainstream kernel

- config-multi_v7_defconfig-Slackware-Mainstream-Kernel-4-19-25.txt - kernel .config used for this build
https://www91.zippyshare.com/d/cSuf1...el-4-19-25.txt
- dmesg.txt successful boot with the mainstream 4.19.25 kernel
https://pastebin.com/vK3rhDWy
- config-bcm2709_defconfig-Raspberry-Kernel-4-19-25.txt - kernel .config I used for the Raspberry kernel source tree 4.19.25 and as inspiration for cleaning up the SoC support I didn't need
https://www98.zippyshare.com/d/4f3F8...el-4-19-25.txt

abga · 03-11-2019, 05:11 PM

Some progress with the mainstream kernel 4.19.25, enabled some more Raspberry specific kernel config options and used the latest released Raspberry firmware (Nov 2018).
- dmesg output:
https://pastebin.com/FACEgjws

Working on Raspberry Pi2B:
- console graphics (text mode) and X (vc4)
- ethernet
- usb
- the vc utilities (/opt/vc)
- GPIO & IR (IR sensor directly connected over GPIO)
- sound card analogue out and hdmi - tested only the analogue out with aplay - got some loud static noise, blaming pulseaudio 12 (last version working OK was pulseaudio 9/10)
- the sound driver needs to be enabled in the kernel config - staging drivers section:
Broadcom VideoCore support --->
- and to patch arch/arm/boot/dts/bcm283x.dtsi
- source for the patch:
https://bugs.debian.org/cgi-bin/bugr...?bug=856505#47
- bcm283x.dtsi-patch:

Code:

--- bcm283x.dtsi.orig   2018-12-03
+++ bcm283x.dtsi        2018-12-05
@@ -634,6 +634,10 @@
                vc4: gpu {
                        compatible = "brcm,bcm2835-vc4";
                };
+audio: audio {
+       compatible = "brcm,bcm2835-audio";
+       brcm,pwm-channels = <8>;
+};
        };
 
        clocks {

- results:

Code:

cat /proc/asound/cards
 0 [ALSA           ]: bcm2835_alsa - bcm2835 ALSA
                      bcm2835 ALSA
 1 [vc4hdmi        ]: vc4-hdmi - vc4-hdmi
                      vc4-hdmi
#...
lsmod | grep snd
snd_soc_core          126976  1 vc4
snd_pcm_dmaengine      16384  1 snd_soc_core
snd_bcm2835            28672  0
vchiq                 233472  1 snd_bcm2835
snd_pcm                77824  4 vc4,snd_pcm_dmaengine,snd_bcm2835,snd_soc_core
snd_timer              28672  1 snd_pcm
snd                    49152  4 snd_timer,snd_bcm2835,snd_soc_core,snd_pcm
soundcore              16384  1 snd

- DVB drivers - Continuity counter error issue resolved. It must be something else in the Raspberry Foundation kernel code causing this issue, since
softirq.c is the same as in mainstream:

Code:

# diff -s softirq-raspberry.c linux/kernel/softirq.c
Files softirq-raspberry.c and linux/kernel/softirq.c are identical

Not working:
- Green LED is not showing the SDCard activity, it lights up when booting and then it only blinks on shut down (normal behavior). The previously reported constant blinking was actually caused by the kernel option CONFIG_LEDS_TRIGGER_HEARTBEAT
I used exactly the same LED configuration as in the kernel config from the live Raspberry Foundation kernel (all LED related sections and config options) and failed to make it work. It might be something in the source code...
- CPU frequency scaling and boot configuration. This is serious / an issue, well, actually a feature for those overheating (& IMO, useless) Pi3 boards. I only got the Pi2B running at its lowest 600MHz arm clock, even by providing the arm clock frequency directive arm_freq=900 in /boot/config.txt

Code:

/opt/vc/bin/vcgencmd measure_clock arm
frequency(45)=600000000
 /opt/vc/bin/vcgencmd measure_clock core
frequency(1)=250000000
#...
/opt/vc/bin/vcgencmd get_config int
aphy_params_current=819
arm_freq=900
audio_pwm_mode=514
avoid_warnings=2
config_hdmi_boost=5
disable_auto_turbo=1

- and there's nothing (not populated) in /sys/devices/system/cpu/ related to cpufreq / scaling & co
- I did apply the bcm2835-cpufreq-add-CPU-frequency-control-driver.patch.xz and also enabled CONFIG_CLK_RASPBERRYPI_CPU=y in the kernel config, however the driver clk-bcm2835.o looks like getting compiled but not built&installed as ko module:

Code:

ls /lib/modules/4.19.25/kernel/drivers/clk/
clk-rk808.ko  clk-s2mps11.ko
ls /kit/kernel-build/linux/drivers/clk/bcm/*.o
/kit/kernel-build/linux/drivers/clk/bcm/clk-bcm21664.o     /kit/kernel-build/linux/drivers/clk/bcm/clk-hr2.o           /kit/kernel-build/linux/drivers/clk/bcm/clk-ns2.o
/kit/kernel-build/linux/drivers/clk/bcm/clk-bcm281xx.o     /kit/kernel-build/linux/drivers/clk/bcm/clk-iproc-armpll.o  /kit/kernel-build/linux/drivers/clk/bcm/clk-nsp.o
/kit/kernel-build/linux/drivers/clk/bcm/clk-bcm2835-aux.o  /kit/kernel-build/linux/drivers/clk/bcm/clk-iproc-asiu.o    /kit/kernel-build/linux/drivers/clk/bcm/clk-raspberrypi.o
/kit/kernel-build/linux/drivers/clk/bcm/clk-bcm2835.o      /kit/kernel-build/linux/drivers/clk/bcm/clk-iproc-pll.o     /kit/kernel-build/linux/drivers/clk/bcm/clk-sr.o
/kit/kernel-build/linux/drivers/clk/bcm/clk-bcm63xx.o      /kit/kernel-build/linux/drivers/clk/bcm/clk-kona-setup.o
/kit/kernel-build/linux/drivers/clk/bcm/clk-cygnus.o       /kit/kernel-build/linux/drivers/clk/bcm/clk-kona.o

- there is no kernel driver available yet, so the patch looks to be the only alternative ATM:
https://github.com/raspberrypi/linux/issues/1918
- the actual discussion around the patch:
http://lists.infradead.org/pipermail...il/thread.html
- crashing on Pi3?:
http://lists.infradead.org/pipermail...il/007528.html
- Fedora looks to have dropped it:
https://github.com/hadess/fedora-sur...base-notes.txt

I don't know how to paste the patches here on LQ without breaking the indentation (tabs), therefore I collected and archived all the properly patched files + the last kernel .config file I used:
- file patched-files-kernel-config.tgz
https://www52.zippyshare.com/v/aiJyDcwI/file.html

Code:

sha256sum patched-files-kernel-config.tgz
fdfeac425ca8afd29c7764193cf307928e7c58dd64188e8ea1646d2cb1817f77  patched-files-kernel-config.tgz

- the paths, relative to the kernel source top tree, for the patched files are embedded in the file names, "-" represents the "/" for the sub folders
- if you like (and know how), you can create one (correct format) patch for all of them
- for the kernel .config file - I disabled pretty much all the other SoCs & platforms, disabled PCI support, enabled all the DVB stuff for my needs (never sure about the i2c/tuners/frontends I need) and enabled a lot of stuff in the Networking section. Compilation time on Raspberry Pi2B 2:30 to 3 hours.

These are the /boot config files I used:
- /boot/config.txt

Code:

kernel=kernel7.img
device_tree=bcm2836-rpi-2-b.dtb
avoid_warnings=2

hdmi_drive=1
framebuffer_depth=32
dtoverlay=gpio-ir,gpio_pin=17,rc-map-name=rc-empty
dtparam=audio=on
gpu_mem=128
max_usb_current=1
audio_pwm_mode=2

- /boot/cmdline.txt

Code:

dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

I mentioned in the other post that I mistakenly left enabled the generation of dtb files for other platforms. Well, I figured out some SoCs were still left enabled in the kernel .config file I used.
Normally, only CONFIG_ARCH_BCM2835=y should be left enabled for Raspberry specific kernel compilations. Nevertheless, generating the other unneeded dtb files is really fast - some seconds.
- kernel .config SoC sections:

Code:

# IPROC architected SoCs
- none enabled
# KONA architected SoCs
- none enabled
# Other Architectures
# - only:
CONFIG_ARCH_BCM2835=y
# TI OMAP Common Features
- none enabled

This mainstream 4.19.25 kernel build should also work on The Raspberry Pi3B (not sure about Pi3B+ - they changed the USB&Ethernet chip). The WiFi & BT drivers are generated & available:

Code:

# find /lib/modules/4.19.25/ -name brcmfmac.ko
/lib/modules/4.19.25/kernel/drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko
# find /lib/modules/4.19.25/ -name btbcm.ko
/lib/modules/4.19.25/kernel/drivers/bluetooth/btbcm.ko

- you'll also need the firmware for the WiFi & BT - described in post #1

The Raspberry Pi2B boots also with the Slackware ARM -current kernel & stuff from:
http://ftp.arm.slackware.com/slackwa...kernels/armv7/
- by providing the following in /boot/config.txt

Code:

kernel=zImage-armv7
device_tree=/dtb/bcm2836-rpi-2-b.dtb

- but it's getting stuck at looking after the root partition

Inspecting the config file:
http://ftp.arm.slackware.com/slackwa...s/armv7/config
I learned that most of the Raspberry specific kernel config options are actually not enabled. Here is a list with the required kernel options (not 100% sure it's complete - just compared it with my kernel .config file):

Code:

+CONFIG_SERIAL_8250_BCM2835AUX=y
+CONFIG_HW_RANDOM_BCM2835=y
+CONFIG_SPI_BCM2835=y
+CONFIG_SPI_BCM2835AUX=y
+CONFIG_BCM2835_WDT=y
+CONFIG_RASPBERRYPI_FIRMWARE=y
+CONFIG_GPIO_RASPBERRYPI_EXP=y
+CONFIG_SENSORS_RASPBERRYPI_HWMON=m
+CONFIG_RASPBERRYPI_POWER=y
+CONFIG_SND_BCM2835_SOC_I2S=m
+CONFIG_MMC_BCM2835=y
+CONFIG_DMA_BCM2835=y
+CONFIG_BCM_VIDEOCORE=y
+CONFIG_BCM2835_VCHIQ=m
+CONFIG_SND_BCM2835=m
+CONFIG_VIDEO_BCM2835=m
+CONFIG_BCM2835_MBOX=y
+CONFIG_PWM_BCM2835=y
#patch 
+CONFIG_CLK_RASPBERRYPI_CPU=y

And then the Raspberry Foundation firmware & overlays are missing. Not sure if enabling CONFIG_RASPBERRYPI_FIRMWARE=y and not providing the firmware files will cause any booting issues for other platforms.
Additionally, haven't checked it, if the overlays are integrated, will bcm2836-rpi-2-b.dtb look after them in /boot/overlays or simply in overlays/ - need to check the source code.

That's pretty much it related to mainstream support for Raspberry - almost 100% supported. I can live without the green LED stuff, but not being able to run the Pi2B CPU at 900Mhz, at least enable it in the firmware -> /boot.config.txt, is an issue ATM. I could also live without a CPU frequency scaling driver and keep the CPU always at 900Mhz, no overheating.
The same mainstream kernel 4.19.25 (or newer) build could be achieved for the Pi1 / Zero boards, by building it natively under Slackware ARM 14.2 SF and using:

Code:

KERNEL=kernel
make bcm2835_defconfig

Dunc. · 03-12-2019, 02:15 AM

A few days ago I took a mainline kernel 5.0.0 and compiled it with multi_v7_defconfig basically following the gentoo wiki. It works with my pi3. I have added broadcom video support which is found in the staging tree. So far all looks good. The vc4 driver for 3d graphics loads and glxgears runs. I tried a video but so far have only tried mpeg2 which worked in software. I have not installed the license so it would not work in hardware. I do miss the 4 raspberries on startup so I might patch the kernel to get that.

Dunc.

abga · 03-12-2019, 12:28 PM

Thanks for sharing your experience @Dunc. I was also considering 5.0, but focused on what Slackware ARM -current is providing ATM, hoping that @drmozes might enable the Raspberry Pi support. It's the 4.19.x kernel the Raspberry Foundation is also focusing on now.
I'm wondering, does your green LED work fine - representing the SDCard storage activity? How about the CPU frequency, is it set at the max? Do you have the possibility to tune it - is there a cpufreq scaling driver available?
Would you mind pasting the output (use pastebin.com ) of your dmesg (clean the MAC address & other serials for privacy considerations) and the list of loaded modules: lsmod ?

Dunc. · 03-12-2019, 04:13 PM

I was shocked that the mainline kernel booted at all. Previous experiences resulted in a black screen.
The green led is a heartbeat. It does not show mmc activity. Cpufreq is not loaded nor is cpuidle. So I guess it runs at whatever the videocore firmware dictates.

Dmesg is here https://pastebin.com/VQXRq3ij
lsmod is here https://pastebin.com/Q5DXH8VV

abga · 03-12-2019, 05:15 PM

Thanks again for the details, as suspected, there is no CPU frequency control even in 5.0, will need to focus on that bcm2835-cpufreq-add-CPU-frequency-control-driver.patch.xz patch that doesn't look working ATM.
For the green LED functionality the Raspberry Foundation source code might provide some answers.

Quote:

So I guess it runs at whatever the videocore firmware dictates.

Well, I wish it would work like that, I tried to define it in /boot/config.txt at 900Mhz for my Pi2B and it got stuck at the lower 600Mhz.

https://www.raspberrypi.org/document...on/config-txt/

Quote:

The system configuration parameters, which would traditionally be edited and stored using a BIOS, are stored instead in an optional text file named config.txt. This is read by the GPU before the ARM CPU and Linux are initialised.

In your dmesg output I noticed some interesting errors related to the firmware files:

Code:

[  127.393698] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1
[  127.394153] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43430-sdio.clm_blob failed with error -2
[  127.394518] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
...
[  137.610864] bluetooth hci0: Direct firmware load for brcm/BCM43430A1.hcd failed with error -2
[  137.610873] Bluetooth: hci0: BCM: Patch brcm/BCM43430A1.hcd not found

First, it looks after brcmfmac43430-sdio, which means the stuff from here needs to be available:
https://github.com/RPi-Distro/firmwa...e/master/brcm/

You could get them with:

Code:

cd /lib/firmware/
svn --force export https://github.com/RPi-Distro/firmware-nonfree.git/trunk/brcm/

And then, I it looks like you also forgot to grab the firmware for your BT:

Code:

wget -N -P /lib/firmware/brcm https://raw.githubusercontent.com/RPi-Distro/bluez-firmware/master/broadcom/BCM43430A1.hcd
wget -N -P /lib/firmware/brcm https://raw.githubusercontent.com/RPi-Distro/bluez-firmware/master/broadcom/BCM4345C0.hcd

I presented all the firmware requirements in my original post.

abga · 03-12-2019, 06:53 PM

@Dunc.

Since you followed the gentoo wiki howto, for installing the device tree files I presume you executed:

Code:

make dtbs_install

Are the resulting device tree files residing in your /boot/dtbs/ folder now? And then in your /boot/config.txt you pointed at them by using device_tree=dtbs/whatever-RPI-model.dtb ?
Are then the overlays files generated and available in /boot/dtbs/overlays/ ?

I'm curious about these details because in my post #6, towards the end, I expressed my concerns about the location of the overlay files and if the device tree binaries would look after these overlays by using an absolute path /boot/overlays/ or just a sub folder overlays/ relative to the parent dtbs/ folder. This is because I never used make dtbs_install, but only copied the device tree files and overlays manually in /boot

Thanks!

abga · 03-12-2019, 09:08 PM

Some small progress, finally got the ACT (green) LED showing the SDCard (mmc0) activity.

First I tried to make use of the act_led_trigger overlay, which should already default on mmc and failed.
Refererence:
https://github.com/Evilpaul/RPi-conf...ter/config.txt

- added the following in /boot/config.txt

Code:

dtparam=act_led_trigger=mmc
dtparam=act_led_activelow=off

- and it didn't work. Removed them.

Learned that you can actually control what triggers the LEDs from within the /sys/class/leds/ - had no experience with these before
References:
https://www.raspberrypi.org/forums/v...136266#p136266
&
https://raspberrypi.stackexchange.co...ng-my-software

Code:

# ls -al /sys/class/leds/
total 0
drwxr-xr-x  2 root root 0 Jan  1  1970 ./
drwxr-xr-x 54 root root 0 Jan  1  1970 ../
lrwxrwxrwx  1 root root 0 Jan  1  1970 ACT -> ../../devices/platform/leds/leds/ACT/
lrwxrwxrwx  1 root root 0 Jan  1  1970 PWR -> ../../devices/platform/leds/leds/PWR/

# cat /sys/class/leds/ACT/trigger
none rc-feedback rfkill-any rfkill-none kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock [mmc0] timer oneshot disk-activity disk-read disk-write ide-disk mtd nand-disk gpio cpu cpu0 cpu1 cpu2 cpu3 default-on
# I guess "[mmc0]" shows that it's already set on it, but it didn't work. I had to (re?)enable it with:
# echo mmc0 | tee /sys/class/leds/ACT/trigger
mmc0

Solution (the green LED will still stay off during the kernel booting and only start when /etc/rc.d/rc.S finishes):
- add the following section to the very end of /etc/rc.d/rc.S :

Code:

# Config ACT (green) LED to show SDCard activity
echo mmc0 | tee /sys/class/leds/ACT/trigger 1> /dev/null 2> /dev/null

Will need to fix the CPU frequency issue (if possible) and I'll be ready to start using the mainstream kernel.
From a broken firmware (analogue sound) and a broken kernel (DVB USB issues), Raspberry is providing me ATM, at least I'll have a working kernel...

'nuff Slackin' for today!

SCerovec · 03-13-2019, 04:09 AM

The trigger of the LEDs can be determined in the device tree file (dte/dts) - this will set the mode upon starting the kernel - much sooner than rc.S

abga · 03-13-2019, 09:09 AM

Quote:

Originally Posted by SCerovec

The trigger of the LEDs can be determined in the device tree file (dte/dts) - this will set the mode upon starting the kernel - much sooner than rc.S

Tried it and it didn't work, see the be beginning of my last post.

Quote:

- added the following in /boot/config.txt

Code:

dtparam=act_led_trigger=mmc
dtparam=act_led_activelow=off

- and it didn't work. Removed them.

Do you happen to know a different way to enable the ACT (green) LED in firmware, before running the kernel and keep it persistent during the kernel LED drivers load? Because it's the kernel that seems to break the LED functionality.

drmozes · 03-13-2019, 09:30 AM

Quote:

Originally Posted by abga

Code:

+CONFIG_SERIAL_8250_BCM2835AUX=y
+CONFIG_HW_RANDOM_BCM2835=y
+CONFIG_SPI_BCM2835=y
+CONFIG_SPI_BCM2835AUX=y
+CONFIG_BCM2835_WDT=y
+CONFIG_RASPBERRYPI_FIRMWARE=y
+CONFIG_GPIO_RASPBERRYPI_EXP=y
+CONFIG_SENSORS_RASPBERRYPI_HWMON=m
+CONFIG_RASPBERRYPI_POWER=y
+CONFIG_SND_BCM2835_SOC_I2S=m
+CONFIG_MMC_BCM2835=y
+CONFIG_DMA_BCM2835=y
+CONFIG_BCM_VIDEOCORE=y
+CONFIG_BCM2835_VCHIQ=m
+CONFIG_SND_BCM2835=m
+CONFIG_VIDEO_BCM2835=m
+CONFIG_BCM2835_MBOX=y
+CONFIG_PWM_BCM2835=y
#patch 
+CONFIG_CLK_RASPBERRYPI_CPU=y

The last config option comes from a patch I assume ? (going by the comment!)
I will look at adding the others, but I won't be adding any patches for the RPi.