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

SCerovec · 03-17-2019, 05:37 AM

Quote:

Originally Posted by abga

@SCerovec
https://www.linuxquestions.org/quest...5/#post5959522
[snip]

I guess i'm still due that VPN report?

drmozes · 03-18-2019, 10:01 AM

Quote:

Originally Posted by abga

Personally, I'm thankful for your efforts and for sharing your work with the Slackware community, compiling,[..]

Thanks

Quote:

mainly because the ARM stuff (latest HW developments) started to become uninteresting for me.

Now just wind forwards to when it's entirely uninteresting, and as you do so, think of Raspberry Pi's, and you will have that understanding you wanted, as to why I don't want them :-)

abga · 03-18-2019, 06:19 PM

I started the compilation for the 5.0 kernel on this Pi2B test machine and my SDCard blew up

It lasted more than 2 years of constant Slackware ARM -current updates, a lot of personal hammering and small compilations, a dozen Kodi compilations and several kernel compilations.
Frankly, I recommend Samsung EVO cards, true heroes, it also failed gracefully - got stuck in read-only mode, no data corruption/loss. Will put it in a frame...

I took this as a sign "from above" or "below", depending on your beliefs, and used the mainstream 4.19.28 kernel instead.
Did some changes to the kernel config - basically including the CPU frequency governors in the kernel and compiling cpufreq-dt as a module, just to have some more control over it.

Code:

diff old-kernel-config new-kernel-config
< # Linux/arm 4.19.25 Kernel Configuration
---
> # Linux/arm 4.19.28 Kernel Configuration
524,525c524,525
< CONFIG_CPU_FREQ_GOV_POWERSAVE=m
< CONFIG_CPU_FREQ_GOV_USERSPACE=m
---
> CONFIG_CPU_FREQ_GOV_POWERSAVE=y
> CONFIG_CPU_FREQ_GOV_USERSPACE=y
527c527
< CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m
---
> CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
533c533
< CONFIG_CPUFREQ_DT=y
---
> CONFIG_CPUFREQ_DT=m

I figured out the bcm2835-cpufreq-add-CPU-frequency-control-driver.patch only applies to the RPi3B(+), that's bcm2837.dtsi, in order to apply it also for my Pi2B I had to hack the bcm2836.dtsi, inspired by the changes in bcm2837.dtsi
The Pi2B switches between 600Mhz and 900Mhz.
- cat bcm2836.dtsi-patch

Code:

--- bcm2836.dtsi.orig   2019-03-17 10:11:43
+++ bcm2836.dtsi        2019-03-17 10:43:29
@@ -44,6 +44,9 @@
                        compatible = "arm,cortex-a7";
                        reg = <0xf00>;
                        clock-frequency = <800000000>;
+                       clocks = <&arm_clk>;
+                       clock-names = "cpu";
+                       operating-points-v2 = <&cpu0_opp_table>;
                };

                v7_cpu1: cpu@1 {
@@ -51,6 +54,9 @@
                        compatible = "arm,cortex-a7";
                        reg = <0xf01>;
                        clock-frequency = <800000000>;
+                       clocks = <&arm_clk>;
+                       clock-names = "cpu";
+                       operating-points-v2 = <&cpu0_opp_table>;
                };

                v7_cpu2: cpu@2 {
@@ -58,6 +64,9 @@
                        compatible = "arm,cortex-a7";
                        reg = <0xf02>;
                        clock-frequency = <800000000>;
+                       clocks = <&arm_clk>;
+                       clock-names = "cpu";
+                       operating-points-v2 = <&cpu0_opp_table>;
                };

                v7_cpu3: cpu@3 {
@@ -65,10 +74,33 @@
                        compatible = "arm,cortex-a7";
                        reg = <0xf03>;
                        clock-frequency = <800000000>;
+                       clocks = <&arm_clk>;
+                       clock-names = "cpu";
+                       operating-points-v2 = <&cpu0_opp_table>;
                };
        };
+
+       cpu0_opp_table: opp_table0 {
+               compatible = "operating-points-v2";
+               opp-shared;
+
+               opp@600000000 {
+               opp-hz = /bits/ 64 <600000000>;
+                       clock-latency-ns = <355000>;
+                       opp-suspend;
+               };
+
+               opp@900000000 {
+                       opp-hz = /bits/ 64 <900000000>;
+                       clock-latency-ns = <355000>;
+               };
+
+       };
 };

+
+
+
 /* Make the BCM2835-style global interrupt controller be a child of the
  * CPU-local interrupt controller.
  */

Results:

Code:

bcmstat.sh A
  Config: v0.5.1, args "A", priority lowest (+19)
   Board: 4 x ARMv7 cores available, ondemand governor (Pi1 Model B rev 1.1, BCM2835 SoC with 256MB RAM by Sony UK)
  Memory: 1024MB (split 896MB ARM, 128MB GPU) plus 200MB Swap
HW Block: |   ARM   |  Core  |  H264  |    SDRAM    |
Min Freq: |  600MHz | 250MHz |   0MHz |    450MHz   |
Max Freq: |  900MHz | 250MHz | 250MHz |    450MHz   |
Voltages: |         0, 1.3125V        | +1, 1.2250V |
   Other: temp_limit=85, disable_auto_turbo=1
Firmware: Nov 4 2018 16:31:07, version ed5baf9520a3c4ca82ba38594b898f0c0446da66 (clean) (release)
  Codecs: H264 H263 MPG4 MPG2 MJPG PCM
  Booted: Sun Mar 17 11:53:42 2019

Time         ARM    Core    H264 Core Temp (Max)  IRQ/s     RX B/s     TX B/s GPUMem Free Mem Free / %used(SwUse) Accum  GPU B     Mem kB
======== ======= ======= ======= =============== ====== ========== ========== =========== ======================= =======================
12:02:43  900Mhz  250Mhz    0Mhz 50.84C (50.84C) 10,778     14,188     14,878 107M ( 99%) 899,184 kB/18.3%( 0.0%)            0     -1,020
12:02:45  600Mhz  250Mhz    0Mhz 50.31C (50.84C) 10,495     27,336     21,168 107M ( 99%) 898,896 kB/18.3%( 0.0%)            0     -1,308
12:02:47  900Mhz  250Mhz    0Mhz 49.77C (50.84C) 10,523     28,773     21,023 107M ( 99%) 898,588 kB/18.3%( 0.0%)            0     -1,616
12:02:49  900Mhz  250Mhz    0Mhz 49.77C (50.84C) 10,518     29,703     20,828 107M ( 99%) 898,848 kB/18.3%( 0.0%)            0     -1,356
12:02:51  900Mhz  250Mhz    0Mhz 49.77C (50.84C) 10,526     29,499     29,252 107M ( 99%) 897,572 kB/18.4%( 0.0%)            0     -2,632
12:02:54  900Mhz  250Mhz    0Mhz 50.31C (50.84C)  9,715     33,456     22,773 107M ( 99%) 897,804 kB/18.4%( 0.0%)            0     -2,400
12:02:56  900Mhz  250Mhz    0Mhz 51.38C (51.38C) 10,488     29,627     20,771 107M ( 99%) 889,180 kB/19.2%( 0.0%)            0    -11,024
12:02:58  900Mhz  250Mhz    0Mhz 51.92C (51.92C) 10,539     28,967     20,789 107M ( 99%) 887,416 kB/19.4%( 0.0%)            0    -12,788
12:03:00  900Mhz  250Mhz    0Mhz 53.00C (53.00C) 10,532     27,712     19,834 107M ( 99%) 886,444 kB/19.4%( 0.0%)            0    -13,760
12:03:02  900Mhz  250Mhz    0Mhz 53.00C (53.00C) 10,512     27,254     20,036 107M ( 99%) 885,616 kB/19.5%( 0.0%)            0    -14,588
12:03:04  900Mhz  250Mhz    0Mhz 53.00C (53.00C) 10,521     26,082     19,948 107M ( 99%) 885,108 kB/19.6%( 0.0%)            0    -15,096
12:03:06  600Mhz  250Mhz    0Mhz 53.00C (53.00C) 10,605     47,654    194,487 107M ( 99%) 897,868 kB/18.4%( 0.0%)            0     -2,336
12:03:08  600Mhz  250Mhz    0Mhz 51.92C (53.00C) 10,588     38,511    105,732 107M ( 99%) 897,708 kB/18.4%( 0.0%)            0     -2,496
12:03:10  600Mhz  250Mhz    0Mhz 51.38C (53.00C) 10,495     24,875     20,199 107M ( 99%) 897,608 kB/18.4%( 0.0%)            0     -2,596

Note the high IRQ count /s ~ 8000 IRQ/s in idle mode.
Taking a closer look:

Code:

cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3
 17:       2041          0          0          0  ARMCTRL-level   1 Edge      3f00b880.mailbox
 18:        410          0          0          0  ARMCTRL-level   2 Edge      VCHIQ doorbell
 27:          1          0          0          0  ARMCTRL-level  35 Edge      timer
 33:    1861979          0          0          0  ARMCTRL-level  41 Edge      3f980000.usb, dwc2_hsotg:usb1
 .....

It's the mainstream USB driver dwc2 and it looks like a childhood disease Raspberry Foundation also suffered from with their dwc_otg driver:
https://www.raspberrypi.org/forums/v...ic.php?t=13058
https://www.raspberrypi.org/forums/v...7866&start=125
Raspberry Foundation - dwc_otg downstream Fix:
https://www.raspberrypi.org/forums/v...ic.php?t=70437
Commits:
https://github.com/raspberrypi/linux...b98e5df9585550
https://github.com/raspberrypi/linux...0c4a990efb0877

Personally, I can live with this, not sensing a huge overhead because of it and my DVB tuners and Ethernet adapter are doing great. BTW, absolutely no "Continuity counter error" on my DVB adapters and the channels switching is faster.

There's another cosmetic issue you might encounter:
- dmesg:

Code:

[    1.629795] dwc2 3f980000.usb: 3f980000.usb supply vusb_d not found, using dummy regulator
[    1.643897] dwc2 3f980000.usb: Linked as a consumer to regulator.0
[    1.653056] dwc2 3f980000.usb: 3f980000.usb supply vusb_a not found, using dummy regulator
[    1.719030] dwc2 3f980000.usb: dwc2_check_params: Invalid parameter lpm=1
[    1.728833] dwc2 3f980000.usb: dwc2_check_params: Invalid parameter lpm_clock_gating=1
[    1.742483] dwc2 3f980000.usb: dwc2_check_params: Invalid parameter besl=1
[    1.752362] dwc2 3f980000.usb: dwc2_check_params: Invalid parameter hird_threshold_en=1

Fix - usb: dwc2: suppress confusing warnings on BCM2835
https://patchwork.kernel.org/patch/10820563/

In my post #5 I presented a patch for the Makefile.dtbinst, inspired by the Raspberry Foundation kernel source, to enable the automatic installation of the overlays files by using the make target: make dtbs_install
Never tested it, but copied the files manually. I did stress @Dunc. with a lot of questions, presuming he used the "make dtbs_install" because he followed the gentoo wiki howto, but I doubt he used the overlays.
Now I got my own answers and patching Makefile.dtbinst seems futile:

make dtbs_install
- copied dtb files in:
/boot/dtbs/4.19.28/
- & overlays in:
/boot/dtbs/4.19.28/overlays/

Learned that the overlays are not relative (subfolder) to the dtb files, but must reside in /boot/overlays . I had to manually move them there.
Therefore, instead of "make dtbs_install", backup & move (clean) your actual /boot stuff and better use the sequence:

Code:

cp -f arch/arm/boot/dts/bcm283*.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/

I re-uploaded the updated patched files archive: patched-files-kernel-config-mainstream-4-19-28.tgz
https://www57.zippyshare.com/v/BSda25AY/file.html

Code:

sha256sum patched-files-kernel-config-mainstream-4-19-28.tgz
06ab12fb62cb05f365a34dbb1d313464c0843431ac9bd7b31dd7d317ffa0f9b8  patched-files-kernel-config-mainstream-4-19-28.tgz
tar -tvf patched-files-kernel-config-mainstream-4-19-28.tgz
drwxr-xr-x root/root         0 2019-03-18 22:21 patches/
-rw-r--r-- root/root     31578 2019-03-11 21:54 patches/arch-arm-boot-dts-Makefile (overlays integration)
-rw-r--r-- root/root      2626 2019-03-17 10:32 patches/arch-arm-boot-dts-bcm2836.dtsi (Pi2B CPU frequency change)
-rw-r--r-- root/root     13545 2019-03-11 21:53 patches/arch-arm-Makefile (overlays integration)
-rw-r--r-- root/root    159800 2019-03-17 10:37 patches/kernel-dot-config-multi_v7_defconfig-SlackwareARM-current-FINAL-OK-4-19-28 (kernel .config file armv7 Pi2B&Pi3B(+))
-rw-r--r-- root/root     15953 2019-03-11 21:55 patches/arch-arm-boot-dts-bcm283x.dtsi (sound driver - bcm2835-audio)
-rw-r--r-- root/root     15386 2019-03-11 21:55 patches/scripts-Makefile.lib (overlays integration)
-rw-r--r-- root/root      1307 2019-03-11 21:55 patches/scripts-Makefile.dtbinst (overlays integration)

Some graphs with the mainstream 4.19.28 kernel on the Pi2B, just hourly, the daily graphs were full of gaps because of the tests I ran - many reboots.
Don't mind the CPU frequency graph, it mainly stays at 600Mhz, Monitorix creates itself some overhead when gathering the stats - it runs a perl script that pushes the CPU briefly at 900Mhz...
https://imgur.com/a/jdsnkj8

@drmozes
Your kernel doesn't boot because you're compiling the SDCard driver as a module, so it gets stuck while trying to mount the root partition and load the modules ...
You should fully respect the list I provided - I just took it myself from the Raspberry Foundation default kernel config.

Related to the bcm2835-cpufreq-add-CPU-frequency-control-driver.patch . After you apply it, you'll find the CONFIG_CLK_RASPBERRYPI_CPU=y in menuconfig:
Device Drivers ---> Common Clock Framework --->[*] Raspberry Pi CPU clock driver (CONFIG_CLK_RASPBERRYPI_CPU=y)
This is the only CPU frequency scaling method that works ATM and it's apparently using:
https://www.kernel.org/doc/Documenta...cpufreq-dt.txt

Regarding the ARM future, I'm waiting for the Raspberry Pi4 and hope they'll fit it with something like:
https://www.theregister.co.uk/2018/1...napdragon_8cx/
https://www.pcworld.com/article/3325...mance-gap.html
and keep the price at 35 quid. Actually I'll pay 50 for it...just saying

@SCerovec
Nope, I would've insisted on that VPN test, but the youtube review I posted there was convincing. That SoC starts to overheat & throttle in seconds. Not interested, thank you.

drmozes · 03-19-2019, 05:52 AM

Quote:

Originally Posted by abga

@drmozes
Your kernel doesn't boot because you're compiling the SDCard driver as a module, so it gets stuck while trying to mount the root partition and load the modules ...
You should fully respect the list I provided - I just took it myself from the Raspberry Foundation default kernel config.

Normally vendors make a monolithic kernel probably because it's less effort than writing documentation and the concomitant support to build an initial RAM risk.
I don't know about the boot loader for the RPi but if it's capable of loading an initial RAM risk from the SD card (it has to be), then the modules can be loaded from the initial RAM disk - as happens for the USB and SCSI support for the devices I support. You have to be judicious about what's added, as the Kernel simply won't boot after it reaches a certain size (unless that's changed, but I used to have difficulties managing the size of the Kernel until I switched to the initrd).

If you were only talking about CONFIG_MMC=y with the individual drivers as modules, that's ok - I've changed that.

Quote:

Related to the bcm2835-cpufreq-add-CPU-frequency-control-driver.patch . After you apply it, you'll find the CONFIG_CLK_RASPBERRYPI_CPU=y in menuconfig:
Device Drivers ---> Common Clock Framework --->[*] Raspberry Pi CPU clock driver (CONFIG_CLK_RASPBERRYPI_CPU=y)

Found it!

SCerovec · 03-19-2019, 08:21 AM

Quote:

Originally Posted by abga

[snip]
@SCerovec
Nope, I would've insisted on that VPN test, but the youtube review I posted there was convincing. That SoC starts to overheat & throttle in seconds. Not interested, thank you.

As the matter of fact i do run it underclocked (1.2 GHz --> 0.8 GHz) but still as quad core.
I guess it could be set up to run as single core as well, maybe even handle it at 1.2GHz then?

I see your point, tho.

abga · 03-19-2019, 12:21 PM

I just compiled the mainstream 4.19.28 on Slackware ARM 14.2 for Pi Zero - I have two live boards that I use for Kodi.
Used the Pi1 kernel config defaults:

Code:

make bcm2835_defconfig

The Pi Zero, unlike the normal Pi1, has CPU frequency scaling, it stays at 700MHz when idle/low load and jumps at 1GHz under heavy load. I had to do some extra hacking after applying the bcm2835-cpufreq-add-CPU-frequency-control-driver.patch
Adapted bcm2835.dtsi for the 700MHz-1GHz CPU frequency scaling:
- cat bcm2835.dtsi-pi-zero-patch :

Code:

--- bcm2835.dtsi.orig   2019-03-19
+++ bcm2835.dtsi        2019-03-19
@@ -12,9 +12,29 @@
                        device_type = "cpu";
                        compatible = "arm,arm1176jzf-s";
                        reg = <0x0>;
+                       clocks = <&arm_clk>;
+                       clock-names = "cpu";
+                       operating-points-v2 = <&cpu0_opp_table>;
                };
        };

+       cpu0_opp_table: opp_table0 {
+               compatible = "operating-points-v2";
+               opp-shared;
+
+               opp@700000000 {
+               opp-hz = /bits/ 64 <700000000>;
+                       clock-latency-ns = <355000>;
+                       opp-suspend;
+               };
+
+               opp@1000000000 {
+                       opp-hz = /bits/ 64 <1000000000>;
+                       clock-latency-ns = <355000>;
+               };
+
+       };
+
        soc {
                ranges = <0x7e000000 0x20000000 0x02000000>;
                dma-ranges = <0x40000000 0x00000000 0x20000000>;

Results:

Code:

bcmstat.sh A
  Config: v0.5.1, args "A", priority lowest (+19)
   Board: 1 x ARMv6 core available, ondemand governor (Pi1 Model B rev 1.1, BCM2835 SoC with 256MB RAM by Sony UK)
  Memory: 512MB (split 384MB ARM, 128MB GPU) plus 200MB Swap
HW Block: |   ARM   |  Core  |  H264  |    SDRAM    |
Min Freq: |  700MHz | 250MHz |   0MHz |    450MHz   |
Max Freq: | 1000MHz | 400MHz | 300MHz |    450MHz   |
Voltages: |         0, 1.3500V        | +1, 1.2250V |
   Other: temp_limit=85, disable_auto_turbo=1
Firmware: Nov 4 2018 16:31:07, version ed5baf9520a3c4ca82ba38594b898f0c0446da66 (clean) (release)
  Codecs: H264 H263 MPG4 MPG2 MJPG PCM
  Booted: Tue Mar 19 16:24:43 2019

Time         ARM    Core    H264 Core Temp (Max)  IRQ/s     RX B/s     TX B/s GPUMem Free Mem Free / %used(SwUse) Accum  GPU B     Mem kB
======== ======= ======= ======= =============== ====== ========== ========== =========== ======================= =======================
16:30:03 1000Mhz  400Mhz    0Mhz 39.01C (39.55C)  8,121        371      3,773 105M ( 97%) 539,156 kB/ 7.2%( 0.1%)            0        -60
16:30:05  700Mhz  400Mhz  300Mhz 37.93C (39.55C)  8,001         56        201 105M ( 97%) 539,156 kB/ 7.2%( 0.1%)            0        -60
16:30:07 1000Mhz  400Mhz  300Mhz 37.93C (39.55C)  8,001         28        201 105M ( 97%) 539,156 kB/ 7.2%( 0.1%)            0        -60
16:30:09  700Mhz  400Mhz  300Mhz 37.93C (39.55C)  8,001         28        201 105M ( 97%) 539,156 kB/ 7.2%( 0.1%)            0        -60
16:30:11  700Mhz  400Mhz  300Mhz 38.47C (39.55C)  8,001         28        201 105M ( 97%) 539,148 kB/ 7.2%( 0.1%)            0        -68
16:30:14  700Mhz  400Mhz  300Mhz 37.93C (39.55C)  8,002         84        248 105M ( 97%) 539,156 kB/ 7.2%( 0.1%)            0        -60
16:30:16  700Mhz  400Mhz  300Mhz 37.93C (39.55C)  8,001         28        201 105M ( 97%) 539,156 kB/ 7.2%( 0.1%)            0        -60
16:30:18 1000Mhz  400Mhz  300Mhz 37.93C (39.55C)  8,001         28        201 105M ( 97%) 539,156 kB/ 7.2%( 0.1%)            0        -60
16:30:20  700Mhz  400Mhz  300Mhz 37.93C (39.55C)  8,001         28        201 105M ( 97%) 539,156 kB/ 7.2%( 0.1%)            0        -60
16:30:22  700Mhz  400Mhz  300Mhz 37.93C (39.55C)  8,001         28        201 105M ( 97%) 539,156 kB/ 7.2%( 0.1%)            0        -60

- note that the core stays always at 400MHz, which is not bad after all, more processing power and no overheating.

There are two issues I can't resolve ATM. I cannot use the sound adapters I manufactured (copied the schematics from Pi3B and attached them over the GPIO) and the mainstream GL enabled Broadcom VC4 DRM Driver (graphics) doesn't look to be working with Kodi.
First of all, for the analogue sound, I'm rerouting the internal (and not connected on the Pi Zero) SoC PWM pins to the GPIO connector in /boot/config.txt with the following line (calling the pwm-2chan overlay):

Code:

dtoverlay=pwm-2chan,pin=18,func=2,pin2=13,func2=4

This doesn't seem to work with the mainstream kernel - dmesg snippet:

Code:

[    0.322727] pinctrl-bcm2835 20200000.gpio: pin gpio18 already requested by 20200000.gpio; cannot claim for 2020c000.pwm
[    0.330063] pinctrl-bcm2835 20200000.gpio: pin-18 (2020c000.pwm) status -22
[    0.337153] pinctrl-bcm2835 20200000.gpio: could not request pin 18 (gpio18) from group gpio18  on device pinctrl-bcm2835
[    0.344309] bcm2835-pwm 2020c000.pwm: Error applying setting, reverse things back
[    0.351588] bcm2835-pwm: probe of 2020c000.pwm failed with error -22

And then the mainstream GL enabled vc4 (Broadcom VC4 DRM Driver v4-drm) is not compatible with Kodi:
- Kodi linked to the GL drivers in /opt/vc, it segfaults and I get:

Code:

failed to add service - already in use?

- and in the kernel log (dmesg):

Code:

[  197.724205] vc4_hdmi 20902000.hdmi: ASoC: can't open interface 20902000.hdmi: -19

- pointing Kodi at the system (Slack ARM provided) MESA, Kodi segfaults again and I get:

Code:

gbm: failed to open any driver (search paths /usr/lib/xorg/modules/dri)
gbm: Last dlopen error: /usr/lib/xorg/modules/dri/vc4_dri.so: cannot open shared object file: No such file or directory
failed to load driver: vc4

Everything else is working fine it seems. Will keep the old and rusty Raspberry provided 4.4.50 kernel together with the last firmware that has the analogue sound OK for these boards.

abga · 03-19-2019, 01:06 PM

Quote:

Originally Posted by drmozes

Normally vendors make a monolithic kernel probably because it's less effort than writing documentation and the concomitant support to build an initial RAM risk.
I don't know about the boot loader for the RPi but if it's capable of loading an initial RAM risk from the SD card (it has to be), then the modules can be loaded from the initial RAM disk - as happens for the USB and SCSI support for the devices I support. You have to be judicious about what's added, as the Kernel simply won't boot after it reaches a certain size (unless that's changed, but I used to have difficulties managing the size of the Kernel until I switched to the initrd).

If you were only talking about CONFIG_MMC=y with the individual drivers as modules, that's ok - I've changed that.

I haven't questioned your judicious/cautious approach, happy that you are willing to support the Pi boards in the kernel. I did a lot of kernel compilations up to the 3.x series on x86 (never thought I'll do it again) and always kept the HW (HW-CPU-architecture & I/O) required drivers included in the kernel, plus the FS for being able to mount the partitions. Keeping the kernel slim, only core stuff included and the rest outside in modules.
I suggested to respect that list I provided, not because it looked "monolithic", but because it looked sane, as previously mentioned, core HW devices shouldn't be subject of external modules, and because I'm not sure if only CONFIG_MMC_BCM2835=y will suffice, might also need the DMA driver CONFIG_DMA_BCM2835=y
Looking at the kernel log:
https://pastebin.com/FACEgjws
I see that it also attaches to the firmware, before mounting the partitions, so CONFIG_RASPBERRYPI_FIRMWARE=y might be also needed for proper functionality of the HW.
I do understand your size concerns, but mine are more related to the compatibility with other ARM platforms if you enable too many Raspberry specific support options. I cannot run any such compat tests because I only own Raspberry ARM boards...
On the initrd/initramfs, it looks possible, never considered it on the Pi until you mentioned it now:
https://www.raspberrypi.org/forums/viewtopic.php?t=7626
https://www.raspberrypi.org/forums/v...c.php?t=100609

Penthux · 03-19-2019, 03:18 PM

Quote:

Originally Posted by abga

I haven't questioned your judicious/cautious approach, happy that you are willing to support the Pi boards in the kernel.

It's good to question the reasoning behind the work, and decision-making methods, of others. When done in an appropriate manner you'll get answers. Which helps us to learn and grow in knowledge and experience.

I believe it would be more accurate to say, "happy that you are willing to 'add support for' the Pi boards in the kernel." That being said, it would be somewhat of a monumental ball-grinding task to fully support all of the Pi boards for someone who has little or no interest in the device(s). Especially for someone who doesn't even own one of them! If MoZes is willing to add support for the RPis then he's doing the Slackware ARM community nothing less than a huge service and big favour. Though he'd be adding support for an ARM device whose creator(s) don't give a flying-FSCK about Slackware ARM. In fact, the Raspberry Pi Trading Ltd are alarmingly silent (i.e. reticent and non-committal) about the best educational Linux OS they could install on their ARM devices. I have much personal experience of this. Sadly.

On compiling the mainstream kernel:
I've done it dozens of times with a multitude of different kernel versions. Sometimes successfully, sometimes not. What I've learned from my experience is; it's not worth the time and effort. Unless you're doing it for educational reasons, or you're a Linux purist who thinks running anything except the mainstream kernel is heresy, then I'd advise that you ARE wasting your time. The RPi GitHub kernel just works without much messing about. It makes sense to use the RPi kernel on the device that the mainstream kernel was intentionally bastardized for. It's as easy to configure and compile as any other kernel - with the added assurance that it will work on the RPis, unless you haphazardly do something to negate that eventuality.

Quote:

Originally Posted by drmozes

I don't know about the boot loader for the RPi but if it's capable of loading an initial RAM risk from the SD card (it has to be), then the modules can be loaded from the initial RAM disk - as happens for the USB and SCSI support for the devices I support.

Yes, you're right of course. The RPi(s) are capable of loading an initial RAM risk from the SD card; initiated via the cmdline.txt file. It used to be possible to do it from the config.txt file in years gone by, but I think thats now been defecated [needs confirmation].

Quote:

Originally Posted by drmozes

You have to be judicious about what's added, as the Kernel simply won't boot after it reaches a certain size (unless that's changed, but I used to have difficulties managing the size of the Kernel until I switched to the initrd).

Hmmm. Are you talking about memory allocation for the modules [i.e. kernel/module.c rejected modules which exceeded 64MB in size]? If so, that changed way back in kernel 3.4. From kernel 3.4 onwards the 64MB limit was removed so now the limit depends only on how much memory vmalloc can allocate. [reference: https://git.kernel.org/pub/scm/linux...0fe7438a2ded3f]

I've had to do quite a bit of messing around with deciding what to add and leave out of the initrd because the size can be an issue. If it's too big there'll be overlap in memory and then the fun and games begin.

drmozes · 03-19-2019, 05:21 PM

Quote:

Originally Posted by abga

I suggested to respect that list I provided, not because it looked "monolithic", but because it looked sane, as previously mentioned, core HW devices shouldn't be subject of external modules

What is the rationale for this? I moved as much support as I could out in to modules before even ARMedslack-11.0 was released in response to having to support a lot of stuff, and hitting the limits of the kernel size.
Whether that limit is now a thing of the past already (I think it is, as I recall noticing an email thread about it years ago) or not, it's ancillary to the fact that a smaller Kernel means smaller RAM footprint, faster to load and potentially is slightly more secure (only due to some module not being loaded, that subsequently presents an attack vector).
Having a single Kernel support multiple hardware groups is what initial RAM disks were created for.

Quote:

, and because I'm not sure if only CONFIG_MMC_BCM2835=y will suffice, might also need the DMA driver CONFIG_DMA_BCM2835=y
Looking at the kernel log:
https://pastebin.com/FACEgjws
I see that it also attaches to the firmware, before mounting the partitions, so CONFIG_RASPBERRYPI_FIRMWARE=y might be also needed..

The Kernel help provides dependencies and how that dependency must be configured (compiled-in vs module). I find it pretty clunky (it'd be better having a tree view that tells you where the damn thing is in the menu, since nothing is ordered alphabetically. Drives me mad momentarily!) but it works.

abga · 03-20-2019, 06:19 AM

Quote:

Originally Posted by drmozes

What is the rationale for this?

You were concerned about monolithic kernels in your other post:

Quote:

Normally vendors make a monolithic kernel probably because it's less effort than writing documentation and the concomitant support to build an initial RAM risk.

And I replied that the kernel configuration Raspberry Foundation (the list I presented) looks sane. Maybe "sane" was not the proper word, but "reasoned" or "consistent" could have been a better wording choice.
Then, based on your size concerns, you added all those kernel options as modules, not providing a SDCard driver included in the kernel, hence the failed boot.
Discussing these options now, I became curious over how these made their way into the mainstream kernel:
https://raw.githubusercontent.com/to...i_v7_defconfig

Code:

# grep -E "BCM2835|RASP" multi_v7_defconfig
CONFIG_ARCH_BCM2835=y
CONFIG_SERIAL_8250_BCM2835AUX=y
CONFIG_I2C_BCM2835=y
CONFIG_SPI_BCM2835=y
CONFIG_SPI_BCM2835AUX=y
CONFIG_SENSORS_RASPBERRYPI_HWMON=m
CONFIG_BCM2835_THERMAL=m
CONFIG_BCM2835_WDT=y
CONFIG_SND_BCM2835_SOC_I2S=m
CONFIG_MMC_BCM2835=y
CONFIG_DMA_BCM2835=y
CONFIG_BCM2835_MBOX=y
CONFIG_RASPBERRYPI_POWER=y
CONFIG_PWM_BCM2835=y
CONFIG_RASPBERRYPI_FIRMWARE=y

Note that the staging drivers (sound&video&co) are not enabled (they are in the original list I provided in my previous post).

Quote:

Originally Posted by drmozes

Having a single Kernel support multiple hardware groups is what initial RAM disks were created for.

I do understand your PoV and size concerns related to supporting many ARM platforms with one kernel. The Raspberry boot loader is closed source (GPU firmware) binary blob, tuned with the help of config.txt & cmdline.txt, and it looks like it offers the choice to use an initramfs:
https://wiki.gentoo.org/wiki/Raspber..._to_Bootloader
I'm happy to test your build on my Pi2B, if you consider such an approach.
There are some U-Boot efforts for the Raspberry Pis, but none look mature enough:
https://elinux.org/RPi_U-Boot#Get_the_source
And I doubt they'll ever be, those Raspberry firmware binary blobs (BIOS) take care of many HW/SoC functions, warranty stuff included.

Quote:

Originally Posted by drmozes

The Kernel help provides dependencies and how that dependency must be configured (compiled-in vs module). I find it pretty clunky (it'd be better having a tree view that tells you where the damn thing is in the menu, since nothing is ordered alphabetically. Drives me mad momentarily!) but it works.

You're not the only one. This increasing complexity, lack of decent human friendly (tree) visualization tools, the fact that the modern kernels contain pretty much what I usually need and that the modern systems have plenty of RAM not to worry about the kernel size anymore, are the reasons I stopped compiling kernels. Back in the day, when I had systems with 32/64 RAM, I was spending a lot of time cutting all the crap I'll never use in the kernel config and enabling the advanced networking options that were not there by default (Slackware included). And you're right, a slimmed down kernel boots faster and the systems ran faster / more responsive with a tailored/slimmed-down kernel.
Even now, much like yourself, I have the tendency to remove all the stuff I identify as not useful.
Making things worse, in my first mainstream kernel compilation for the Raspberry, in the Multimedia Support > DVB section I found an option to let the kernel "automagically" choose the DVB components, must have been inspired by the Redmond philosophy, and used it. Only to find out after the first boot, that one of the DVB tuners I use was not "automagically" chosen... I just went for another compilation and manually enabled all the DVB stuff as modules.
I don't know if this helps, as it doesn't represent the "depends on" tags, but the interactive map, exploring the kernel, looks useful:
http://www.makelinux.net/kernel_map/

drmozes · 03-20-2019, 08:29 AM

Quote:

Originally Posted by abga

You were concerned about monolithic kernels in your other post:

I was referring to the rationale behind why "core" stuff had to be compiled in.

Quote:

And I replied that the kernel configuration Raspberry Foundation (the list I presented) looks sane. Maybe "sane" was not the proper word, but "reasoned" or "consistent" could have been a better wording choice.
Then, based on your size concerns, you added all those kernel options as modules, not providing a SDCard driver included in the kernel, hence the failed boot.

Sure, and you have to understand that giving me a list of things and expecting them to go in verbatim probably isn't going to happen because it's not aligned with what I already do, nor what I intend on doing.
In the end, my approach is straight forward:
Can it be included in the initrd and the system work? Yes, goes in initrd.
If it can't, it's compiled in. I was going to use the example of the filesystem drivers, but even those I have as modules.
If it's going to be a pain in the ass and I'm not interested in it anyway, it gets dumped :-)

Quote:

http://www.makelinux.net/kernel_map/

I need to lie down now after looking at that!! ;-)

abga · 03-21-2019, 01:21 PM

@drmozes

Just tried your latest kernel 4.19.30 and it still won't recognize the SDCard drive.

Normal boot, loading zImage-armv7.
- content of /boot/config.txt

Code:

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

- screenshot - zImage-armv7.jpg
https://www95.zippyshare.com/v/71vBswK6/file.html

Checked the Raspberry bootloader to see if it'll tolerate the initrd-armv7.
- content of /boot/config.txt

Code:

kernel=zImage-armv7
initramfs initrd-armv7
device_tree=bcm2836-rpi-2-b.dtb
avoid_warnings=2

- screenshot - initramfs-initrd-armv7.jpg
https://www50.zippyshare.com/v/2t2Sr6pJ/file.html

But then, you're still loading CONFIG_MMC_BCM2835=m as a module, no SDCard driver included in the kernel and no wonder it cannot mount the partitions...
http://ftp.arm.slackware.com/slackwa...s/armv7/config

Code:

# grep -E "BCM2835|RASP" config
CONFIG_ARCH_BCM2835=y
CONFIG_RASPBERRYPI_FIRMWARE=y
CONFIG_SERIAL_8250_BCM2835AUX=m
CONFIG_HW_RANDOM_BCM2835=m
CONFIG_I2C_BCM2835=m
CONFIG_SPI_BCM2835=m
CONFIG_SPI_BCM2835AUX=m
CONFIG_PINCTRL_BCM2835=y
CONFIG_GPIO_RASPBERRYPI_EXP=m
CONFIG_SENSORS_RASPBERRYPI_HWMON=m
CONFIG_BCM2835_THERMAL=m
CONFIG_BCM2835_WDT=m
CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN=m
CONFIG_SND_BCM2835_SOC_I2S=m
CONFIG_MMC_BCM2835=m
CONFIG_DMA_BCM2835=m
CONFIG_BCM2835_VCHIQ=m
CONFIG_SND_BCM2835=m
CONFIG_VIDEO_BCM2835=m
CONFIG_CLK_RASPBERRYPI_CPU=y
CONFIG_BCM2835_TIMER=y
CONFIG_BCM2835_MBOX=y
# CONFIG_RASPBERRYPI_POWER is not set
CONFIG_PWM_BCM2835=m

With the next kernel update, maybe you could try including all the Raspberry stuff in initrd-armv7, if that makes you happy. At least the drivers that are needed at boot time, the ones with "y" in my original list. As stated before, I'm happy to test it.

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

Just an observation and a workaround for the mainstream kernel and the bcm2835-cpufreq-add-CPU-frequency-control-driver.patch, plus the subsequent bcm2836.dtsi presented in post #33, for the Pi2B dynamic frequency scaling.
I noticed that the core frequency will stay always at the default 250MHz, just the arm frequency will dynamically change based on the load. With the official Raspberry kernel and their frequency scaling driver, this core frequency is dynamically changing: 250MHz-300MHz.
Reference on the different components frequencies:
https://www.raspberrypi.org/document...verclocking.md
(core_freq - "but there is a small benefit for SDRAM on the Pi 2/Pi 3")
I added in /boot/config.txt:

Code:

core_freq=300

and now the core frequency is also dynamically changing together with the arm frequency:
raspberrypi1z.1day.png - the cyan (core) graph
https://www54.zippyshare.com/v/Qx62HZGG/file.html

justwantin · 03-23-2019, 07:35 PM

Slightly off topic but perhaps apropos:

About 5 years ago in a thread on the the raspberry pi forum when looking for help to get a picam working with v4l-utils on a pi running slackware I was told the following by a "Raspberry PI Engineer" & Forum Moderator (quotatoions are mine).

Quote:

Worth noting that we/I only test stuff on Raspbian, since it's the recommended distro. So you may encounter issues with other distros for which you may find it difficult to get help (you might be the only person using that combination!).

Soon thereafter anything pi was gathering dust and except for one which I gave away the other two plus the pi cam were trashed. I suppose they were apt getting a patched version of v4-utils to their hearts content ... no thanks.

Penthux · 03-24-2019, 04:28 AM

Quote:

Originally Posted by justwantin

Slightly off topic but perhaps apropos:

About 5 years ago in a thread on the the raspberry pi forum when looking for help to get a picam working with v4l-utils on a pi running slackware I was told the following by a "Raspberry PI Engineer" & Forum Moderator (quotatoions are mine).Soon thereafter anything pi was gathering dust and except for one which I gave away the other two plus the pi cam were trashed. I suppose they were apt getting a patched version of v4-utils to their hearts content ... no thanks.

LOL! I remember the thread in question, all too well!

Jamesh, the "Raspberry PI Engineer" & Forum Moderator is actually the Principal Software Engineer at Raspberry Pi (Trading) Ltd.

I was a little miffed at James' response to you. Still didn't get any answers to my questions about why they diminish Slackware ARM.