Slackware Aarch64: Raspberry Pi 400 hardware support
by mralk3 from LinuxQuestions.org on (#6J0ZN)
From a previous thread where the Raspberry Pi 400 hardware support is discussed.
(https://www.linuxquestions.org/quest...ml#post6478305)
Quote:
Can you please reply with the output of slk-hwm-discover?
If you are still feeling adventurous, the Slackware source code has a file to edit. Here is my source tree and the location of what you need to edit:
Code:/home/x/PRIVATE_slackwareaarch64-current/source/k/SlkOS-initrd-overlay/load_kernel_modules.scr/platform/aarch64
[ x@darkcomet ~/PRIVATE_slackwareaarch64-current/source/k/SlkOS-initrd-overlay/load_kernel_modules.scr/platform/aarch64 ]$ ls
baseline_aarch64 bcm2711 bcm2837 lx2160acex7 rk3399 virt-kvm virt-qemuMake sure you have downloaded the Slackware-current Aarch64 tree or you will not find this file.
It contains the file bcm2711, which is the SoC for the Raspberry Pi 400.
Assuming the slk-hwm-discover output is "Raspberry Pi 400", the following adjustments need to be made:
Code:--- bcm2711.orig 2024-01-21 04:44:51.275481398 -0700
+++ bcm2711 2024-01-21 04:53:29.542588199 -0700
@@ -5,6 +5,7 @@
# and the Slackware installer.
# Currently supported Hardware Models:
# * Raspberry Pi 4
+# * Raspberry Pi 400
# This script is sourced from '/load_kernel_modules'
# Author.......: Stuart Winter <mozes@slackware.com>
# Date.........: 30-Mar-2021
@@ -39,7 +40,7 @@
# (such as QEMU), see the 'virt-qemu' loader script for the other Hardware
# Model detection method.
case $HWM in
- "Raspberry Pi 4"*|PLATWALK)
+ "Raspberry Pi 400"*|"Raspberry Pi 4"*|PLATWALK)
platform_detected=1
SOC_NAME=bcm2711
# Set the short name that is used by /load_kernel_modules to install
@@ -51,8 +52,7 @@
# within the OS InitRD or Installer. Within the OS the regular location of
# /lib/modprobe.d/ is used and has no connection to the content of the
# OS InitRD/Installer.
- HWM_SHORTNAME=rpi4
-
+
echo "Architecture: ${ARCH}, Hardware model: ${HWM}, SoC: ${SOC_NAME}"
# If one of the modules within the base list is causing problems on
# your platform, here are the options laid out as examples:
@@ -142,5 +142,15 @@
;;
esac
+case $HWM in
+ "Raspberry Pi 4"*|PLATWALK)
+ HWM_SHORTNAME=rpi4 ;;
+esac
+
+case $HWM in
+ "Raspberry Pi 400"*|PLATWALK)
+ HWM_SHORTNAME=rpi400 ;;
+esac
+
# The '/load_kernel_modules' script will load the modules
# set above.This file loads the kernel modules required by the Raspberry Pi 4. Since you say in the other thread that the two boards are very similar there is a chance that nothing else needs to be edited. Missing wifi or other components will require you to find the kernel module name. Then add it into that file under the correct section. It is mine or Stuarts job to add it if a module or some firmware is missing from the kernel packages.
Now you can rebuild the raspberry pi kernel fork and the bcm2711 file will be included automatically.
This is the fully edited version of bcm2711.
Code:################################################################################
# Helper script: /load_kernel_modules.scr/platform/aarch64/bcm2711
# Purpose......: Set the Kernel modules for Hardware Models that use the BCM2711
# SoC within the Slackware initial RAM disk ('OS initrd')
# and the Slackware installer.
# Currently supported Hardware Models:
# * Raspberry Pi 4
# * Raspberry Pi 400
# This script is sourced from '/load_kernel_modules'
# Author.......: Stuart Winter <mozes@slackware.com>
# Date.........: 30-Mar-2021
# Maintainer...: Stuart Winter, Brent Earl.
#
# Please use this as an reference and example of how to add support for
# a new Hardware Model to Slackware ARM/AArch64.
#
# Important Note:
# * You must _append_ to the module lists (as this script does)
# otherwise the base set of modules will not be loaded and would result in
# a Kernel panic.
# * The initrd uses the 'bash' shell, rather than 'busybox'
# (as in upstream/x86 Slackware). This allows you (for example)
# to use 'fallthrough' (case statements terminated with ';&'
# rather than ';;') within case statements and regular expression
# matches within 'if' statements.
# This permits the 'c'-style switch statements where you can
# 'inherit' the previous matches as you move down the cases.
# This enables you to match on varients of boards, and inherit
# a 'baseline' of platform modules for that board.
#
# The 'PLATWALK' match is to enable build scripts to process these
# scripts outside of the initrd environment and determine which
# modules will be loaded by a particular Hardware Model. This must remain
# in place for all scripts.
################################################################################
# $HWM is set by the caller ('/load_kernel_modules') of this helper script
# and the value is taken from /proc/device-tree/model.
# If your Hardware Model does not have a /proc/device-tree/model interface
# (such as QEMU), see the 'virt-qemu' loader script for the other Hardware
# Model detection method.
case $HWM in
"Raspberry Pi 400"*|"Raspberry Pi 4"*|PLATWALK)
platform_detected=1
SOC_NAME=bcm2711
# Set the short name that is used by /load_kernel_modules to install
# the appropriate configuration for modprobe for this Hardware Model.
# These files are stored within the source tree:
# source/k/SlkOS-initrd-overlay/usr/share/hwm-configure/platform/aarch64/modprobe.d/
#
# Note: Typically these are only used to blacklist particular modules from loading
# within the OS InitRD or Installer. Within the OS the regular location of
# /lib/modprobe.d/ is used and has no connection to the content of the
# OS InitRD/Installer.
echo "Architecture: ${ARCH}, Hardware model: ${HWM}, SoC: ${SOC_NAME}"
# If one of the modules within the base list is causing problems on
# your platform, here are the options laid out as examples:
# USB="${USB/ehci_orion/differentmodule}" # Substitute module 'ehci_orion' with 'differentmodule'
# USB="${USB/ehci_orion/}" # Remove the 'ehci_orion' module from the list
MOD_GPIO+=" "
# Drivers for PCI and other core sub systems:
MOD_PHY+=" bcm_phy_lib phy_generic"
# MFD (Multi Functional Devices) drivers:
MOD_MFD+=" "
# Video drivers:
MOD_VIDEO+=" simpledrm v3d"
# sdhci-iproc caused crash in 5.19 taking down the SD subsystem:
# Seems to work in 6.1.
MOD_CARDS+=" sdhci-iproc"
MOD_USB+=" dwc2 dwc3"
MOD_NET+=" "
MOD_CMP+=" "
MOD_CRYPTO+=" "
# Example to detect hardware at runtime:
#{ lspci 2>/dev/null | grep -q 'SATA cont.*ATA' ;} && MOD_XX+=" yyy"
# The following modules do not inherit:
MOD_RTC="rtc-ds1307 rtc-pcf8523"
# Modules for the peripherals on the Hardware Model's main board
# (outside of the SoC itself)
# Note: the distinction between the SoC and HWM is blurred presently
# This needs organising according to the hardware - TODO!
MOD_HWM="pcie_brcmstb mdio_bcm_unimac iproc_rng200 pwrseq_simple crct10dif_ce"
# Modules for the IP blocks/peripherals embedded within the SoC:
MOD_SOC="broadcom clk_raspberrypi pwm-bcm2835 raspberrypi-hwmon i2c-bcm2835 i2c_brcmstb"
# /load_kernel_modules provides the ability to run a defined function
# just prior to loading the Linux Kernel module lists that have been
# defined in the base set + directly above these lines.
# There's no current use case for this - it's here to expose it as
# an option should it be useful at some future time.
#function hwm_hook_pre-modload() {
#}
#
# And the same functionality once the Kernel modules have been loaded.
# This allows us to set up the RTC, which we cannot do at the time this
# script is loaded initially, as the RTC device is only addressable upon
# having loaded the driver into the Kernel.
# To achieve this effect locally, users should look at
# /boot/local/README.txt
# and create /boot/local/load_kernel_modules.post from the sample file.
# This is a shell script in which you can 'modprobe' additional modules,
# and run shell code as we do below to write a value into the RTC's
# Kernel interface to initialise it.
#
# This function is here because this particular RTC is officially
# supported by Slackware AArch64, as it's connected to this author's
# RPi4.
#
function hwm_hook_post-modload() {
# Initialise a DS1307 RTC without Device Tree Overlay.
#
# When booting Slackware directly from the RPi's native Boot Loader,
# we add a Kernel command line operator 'slkrpinbl' which enables
# these types of conditional actions:
grep -iq "slkrpinbl" /proc/cmdline 2> /dev/null || {
# Silently detect peripherals on bus 1.
# Something like this, self-contained would be ideal:
#sensors-detect --auto > /dev/null 2>&1
i2cdetect -y 1 > /dev/null 2>&1
# Unless you change this setting, it'll appear as position 68.
[ -f /sys/class/i2c-adapter/i2c-1/new_device ] && \
echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device
}
}
# Define a function to run from the OS InitRD's '/init' immediately prior
# to switching into the Slackware OS proper.
# This is after any software RAID arrays et al have been initialised.
# There's no current use case for this, but it may be useful in the future.
#
# At this stage, the following paths for Slackware OS are mounted:
# /proc, /sys, /run, /dev
# The root file system ('/') is mounted under /mnt
#
#function hwm_hook_pre_switch_root() {
# echo "Just about to switch into the Slackware OS proper, leaving the OS InitRD"
# sleep 4
#}
# End of stanza - the ';;' below must be the last line:
;;
esac
case $HWM in
"Raspberry Pi 4"*|PLATWALK)
HWM_SHORTNAME=rpi4 ;;
esac
case $HWM in
"Raspberry Pi 400"*|PLATWALK)
HWM_SHORTNAME=rpi400 ;;
esac
# The '/load_kernel_modules' script will load the modules
# set above.
(https://www.linuxquestions.org/quest...ml#post6478305)
Quote:
Originally Posted by pchristy(Post 6478305)OK. well I got a completely fresh install (on an sd card) to boot from the stock kernel, although there were some hardware issues, as expected. Once it was up and running, I then installed the Pi-fork kernel over it and rebooted and - nothing! The monitor comes out of standby, but that's it. No boot text, no sign of life at all. Keyboard unresponsive, the only way out is to remove the power. It appears that the 6.6 Pi-fork is completely broken. I've tried everything I can think of with minimal success. It has to be something to do with the initial boot process, right from the very start, rather than the kernel itself, because at one point - and after a LOT of time spent - I did manage to get it to boot. However, I have no idea how I managed it. I hadn't changed anything of significance that I recall. I'm now completely stumped. Luckily I still have a working SARPi installation on another card. Looks like, at present, that is the only way to get Slackware running on a Pi. Thanks all for your help and suggestions, sorry its come to nothing. -- Pete |
If you are still feeling adventurous, the Slackware source code has a file to edit. Here is my source tree and the location of what you need to edit:
Code:/home/x/PRIVATE_slackwareaarch64-current/source/k/SlkOS-initrd-overlay/load_kernel_modules.scr/platform/aarch64
[ x@darkcomet ~/PRIVATE_slackwareaarch64-current/source/k/SlkOS-initrd-overlay/load_kernel_modules.scr/platform/aarch64 ]$ ls
baseline_aarch64 bcm2711 bcm2837 lx2160acex7 rk3399 virt-kvm virt-qemuMake sure you have downloaded the Slackware-current Aarch64 tree or you will not find this file.
It contains the file bcm2711, which is the SoC for the Raspberry Pi 400.
Assuming the slk-hwm-discover output is "Raspberry Pi 400", the following adjustments need to be made:
Code:--- bcm2711.orig 2024-01-21 04:44:51.275481398 -0700
+++ bcm2711 2024-01-21 04:53:29.542588199 -0700
@@ -5,6 +5,7 @@
# and the Slackware installer.
# Currently supported Hardware Models:
# * Raspberry Pi 4
+# * Raspberry Pi 400
# This script is sourced from '/load_kernel_modules'
# Author.......: Stuart Winter <mozes@slackware.com>
# Date.........: 30-Mar-2021
@@ -39,7 +40,7 @@
# (such as QEMU), see the 'virt-qemu' loader script for the other Hardware
# Model detection method.
case $HWM in
- "Raspberry Pi 4"*|PLATWALK)
+ "Raspberry Pi 400"*|"Raspberry Pi 4"*|PLATWALK)
platform_detected=1
SOC_NAME=bcm2711
# Set the short name that is used by /load_kernel_modules to install
@@ -51,8 +52,7 @@
# within the OS InitRD or Installer. Within the OS the regular location of
# /lib/modprobe.d/ is used and has no connection to the content of the
# OS InitRD/Installer.
- HWM_SHORTNAME=rpi4
-
+
echo "Architecture: ${ARCH}, Hardware model: ${HWM}, SoC: ${SOC_NAME}"
# If one of the modules within the base list is causing problems on
# your platform, here are the options laid out as examples:
@@ -142,5 +142,15 @@
;;
esac
+case $HWM in
+ "Raspberry Pi 4"*|PLATWALK)
+ HWM_SHORTNAME=rpi4 ;;
+esac
+
+case $HWM in
+ "Raspberry Pi 400"*|PLATWALK)
+ HWM_SHORTNAME=rpi400 ;;
+esac
+
# The '/load_kernel_modules' script will load the modules
# set above.This file loads the kernel modules required by the Raspberry Pi 4. Since you say in the other thread that the two boards are very similar there is a chance that nothing else needs to be edited. Missing wifi or other components will require you to find the kernel module name. Then add it into that file under the correct section. It is mine or Stuarts job to add it if a module or some firmware is missing from the kernel packages.
Now you can rebuild the raspberry pi kernel fork and the bcm2711 file will be included automatically.
This is the fully edited version of bcm2711.
Code:################################################################################
# Helper script: /load_kernel_modules.scr/platform/aarch64/bcm2711
# Purpose......: Set the Kernel modules for Hardware Models that use the BCM2711
# SoC within the Slackware initial RAM disk ('OS initrd')
# and the Slackware installer.
# Currently supported Hardware Models:
# * Raspberry Pi 4
# * Raspberry Pi 400
# This script is sourced from '/load_kernel_modules'
# Author.......: Stuart Winter <mozes@slackware.com>
# Date.........: 30-Mar-2021
# Maintainer...: Stuart Winter, Brent Earl.
#
# Please use this as an reference and example of how to add support for
# a new Hardware Model to Slackware ARM/AArch64.
#
# Important Note:
# * You must _append_ to the module lists (as this script does)
# otherwise the base set of modules will not be loaded and would result in
# a Kernel panic.
# * The initrd uses the 'bash' shell, rather than 'busybox'
# (as in upstream/x86 Slackware). This allows you (for example)
# to use 'fallthrough' (case statements terminated with ';&'
# rather than ';;') within case statements and regular expression
# matches within 'if' statements.
# This permits the 'c'-style switch statements where you can
# 'inherit' the previous matches as you move down the cases.
# This enables you to match on varients of boards, and inherit
# a 'baseline' of platform modules for that board.
#
# The 'PLATWALK' match is to enable build scripts to process these
# scripts outside of the initrd environment and determine which
# modules will be loaded by a particular Hardware Model. This must remain
# in place for all scripts.
################################################################################
# $HWM is set by the caller ('/load_kernel_modules') of this helper script
# and the value is taken from /proc/device-tree/model.
# If your Hardware Model does not have a /proc/device-tree/model interface
# (such as QEMU), see the 'virt-qemu' loader script for the other Hardware
# Model detection method.
case $HWM in
"Raspberry Pi 400"*|"Raspberry Pi 4"*|PLATWALK)
platform_detected=1
SOC_NAME=bcm2711
# Set the short name that is used by /load_kernel_modules to install
# the appropriate configuration for modprobe for this Hardware Model.
# These files are stored within the source tree:
# source/k/SlkOS-initrd-overlay/usr/share/hwm-configure/platform/aarch64/modprobe.d/
#
# Note: Typically these are only used to blacklist particular modules from loading
# within the OS InitRD or Installer. Within the OS the regular location of
# /lib/modprobe.d/ is used and has no connection to the content of the
# OS InitRD/Installer.
echo "Architecture: ${ARCH}, Hardware model: ${HWM}, SoC: ${SOC_NAME}"
# If one of the modules within the base list is causing problems on
# your platform, here are the options laid out as examples:
# USB="${USB/ehci_orion/differentmodule}" # Substitute module 'ehci_orion' with 'differentmodule'
# USB="${USB/ehci_orion/}" # Remove the 'ehci_orion' module from the list
MOD_GPIO+=" "
# Drivers for PCI and other core sub systems:
MOD_PHY+=" bcm_phy_lib phy_generic"
# MFD (Multi Functional Devices) drivers:
MOD_MFD+=" "
# Video drivers:
MOD_VIDEO+=" simpledrm v3d"
# sdhci-iproc caused crash in 5.19 taking down the SD subsystem:
# Seems to work in 6.1.
MOD_CARDS+=" sdhci-iproc"
MOD_USB+=" dwc2 dwc3"
MOD_NET+=" "
MOD_CMP+=" "
MOD_CRYPTO+=" "
# Example to detect hardware at runtime:
#{ lspci 2>/dev/null | grep -q 'SATA cont.*ATA' ;} && MOD_XX+=" yyy"
# The following modules do not inherit:
MOD_RTC="rtc-ds1307 rtc-pcf8523"
# Modules for the peripherals on the Hardware Model's main board
# (outside of the SoC itself)
# Note: the distinction between the SoC and HWM is blurred presently
# This needs organising according to the hardware - TODO!
MOD_HWM="pcie_brcmstb mdio_bcm_unimac iproc_rng200 pwrseq_simple crct10dif_ce"
# Modules for the IP blocks/peripherals embedded within the SoC:
MOD_SOC="broadcom clk_raspberrypi pwm-bcm2835 raspberrypi-hwmon i2c-bcm2835 i2c_brcmstb"
# /load_kernel_modules provides the ability to run a defined function
# just prior to loading the Linux Kernel module lists that have been
# defined in the base set + directly above these lines.
# There's no current use case for this - it's here to expose it as
# an option should it be useful at some future time.
#function hwm_hook_pre-modload() {
#}
#
# And the same functionality once the Kernel modules have been loaded.
# This allows us to set up the RTC, which we cannot do at the time this
# script is loaded initially, as the RTC device is only addressable upon
# having loaded the driver into the Kernel.
# To achieve this effect locally, users should look at
# /boot/local/README.txt
# and create /boot/local/load_kernel_modules.post from the sample file.
# This is a shell script in which you can 'modprobe' additional modules,
# and run shell code as we do below to write a value into the RTC's
# Kernel interface to initialise it.
#
# This function is here because this particular RTC is officially
# supported by Slackware AArch64, as it's connected to this author's
# RPi4.
#
function hwm_hook_post-modload() {
# Initialise a DS1307 RTC without Device Tree Overlay.
#
# When booting Slackware directly from the RPi's native Boot Loader,
# we add a Kernel command line operator 'slkrpinbl' which enables
# these types of conditional actions:
grep -iq "slkrpinbl" /proc/cmdline 2> /dev/null || {
# Silently detect peripherals on bus 1.
# Something like this, self-contained would be ideal:
#sensors-detect --auto > /dev/null 2>&1
i2cdetect -y 1 > /dev/null 2>&1
# Unless you change this setting, it'll appear as position 68.
[ -f /sys/class/i2c-adapter/i2c-1/new_device ] && \
echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device
}
}
# Define a function to run from the OS InitRD's '/init' immediately prior
# to switching into the Slackware OS proper.
# This is after any software RAID arrays et al have been initialised.
# There's no current use case for this, but it may be useful in the future.
#
# At this stage, the following paths for Slackware OS are mounted:
# /proc, /sys, /run, /dev
# The root file system ('/') is mounted under /mnt
#
#function hwm_hook_pre_switch_root() {
# echo "Just about to switch into the Slackware OS proper, leaving the OS InitRD"
# sleep 4
#}
# End of stanza - the ';;' below must be the last line:
;;
esac
case $HWM in
"Raspberry Pi 4"*|PLATWALK)
HWM_SHORTNAME=rpi4 ;;
esac
case $HWM in
"Raspberry Pi 400"*|PLATWALK)
HWM_SHORTNAME=rpi400 ;;
esac
# The '/load_kernel_modules' script will load the modules
# set above.