LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM
User Name
Password
Slackware - ARM This forum is for the discussion of Slackware ARM.

Notices


Reply
  Search this Thread
Old 01-21-2024, 06:17 AM   #1
mralk3
Slackware Contributor
 
Registered: May 2015
Distribution: Slackware
Posts: 1,900

Rep: Reputation: 1050Reputation: 1050Reputation: 1050Reputation: 1050Reputation: 1050Reputation: 1050Reputation: 1050Reputation: 1050
Lightbulb Slackware Aarch64: Raspberry Pi 400 hardware support


From a previous thread where the Raspberry Pi 400 hardware support is discussed.
(https://www.linuxquestions.org/quest...ml#post6478305)
Quote:
Originally Posted by pchristy View Post
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
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-qemu
Make 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.

Last edited by mralk3; 01-21-2024 at 06:19 AM.
 
Old 01-21-2024, 11:04 AM   #2
pchristy
Senior Member
 
Registered: Oct 2012
Location: South Devon, UK
Distribution: Slackware
Posts: 1,119

Rep: Reputation: Disabled
Hi Brent,
Apologies for the delayed reply. I decided to re-create the initial Slackwareaarch64-current install yet again to ensure I got a clean system to try. As I'm sure you are aware, this takes a while!

Yes, slk-hwm-discover reports "Raspberry Pi 400 Rev 1.0". And yes, I have the full Slackwareaarch64-current tree, though this does not include the Pi-fork kernel, which is supplied seperately. (I have that too, but in a separate folder.)

A couple of questions: The first file you have offered above looks like a patch file, and the second looks like the bcm2711 after its been patched. Is this correct? If so, that implies that I should just be able to replace the current bcm2711 with your second example from above?

Looking at that file does explain one thing - I kept wondering why my system kept trying to install a ds1307 RTC, when my system has a ds3231! Now I know! Perhaps I should comment that bit out, or amend it, for tidiness. But then that also suggests that the file I have is already patched to the level described above. I'll do a diff and check.

Its early evening here in the UK, so some of this will have to wait until tomorrow, now. Also, we have visitors coming tomorrow, so my time will be more restricted until Tuesday.

Watch this space....

--
Pete
 
Old 01-21-2024, 11:43 AM   #3
pchristy
Senior Member
 
Registered: Oct 2012
Location: South Devon, UK
Distribution: Slackware
Posts: 1,119

Rep: Reputation: Disabled
One more question (and sorry if this sounds dumb!): I've applied the diff to the bc2711 file, but this is all living in the stock Slackwareaarch64 kernel tree. You say
Quote:
Now you can rebuild the raspberry pi kernel fork and the bcm2711 file will be included automatically
Doesn't this mean that the modified file should be placed in the Pi-fork source - and if so where? There doesn't seem to be the same folder structure in the Pi-fork source.

Cheers,

--
Pete
 
Old 01-21-2024, 02:03 PM   #4
mralk3
Slackware Contributor
 
Registered: May 2015
Distribution: Slackware
Posts: 1,900

Original Poster
Rep: Reputation: 1050Reputation: 1050Reputation: 1050Reputation: 1050Reputation: 1050Reputation: 1050Reputation: 1050Reputation: 1050
I am looking at the source tree that both Stuart and I work on. We haven't added support for it in the way I mentioned above. The second example is what your system needs. The Rev 1.0 is not necessary to include in the file. The script will take care of that. Just make sure to add the asterisks. All revisions of the Pi 400 should be found with those changes.

The first example is a diff. The second example should be (more or less) what is necessary to get your Pi 400 up and running with Slackware Aarch64.

The kernel packages built using the RPi kernel fork scripts will include the "bcm2711" within the initial ramdisk embedded in the kernel_armv8 package. Which is why you will not see it in your boot partition. If you extract the initial ramdisk (NOT initrd-armv8.img) you can edit stuff and reboot your system after repacking it up.

The "os-initrd-mgr" utility that is present in Slackware Aarch64, can be configured to unpack the initial ramdisk, to make changes within it's directory. Once you exit the script, it will repack the ramdisk.

The build scripts are designed this way so that multiple hardware models can be supported with drivers compiled as modules in the kernel. That way all Stuart and I have to do for various devices is edit a text file. This lowers the RAM requirement for the installer and systems that have been installed.

It is important to note: To the best of my knowledge, Slarm64 and Sarpi do not include these utilities or scripts. If they do, they likely do not make use of them. Mixing your system with slarm64 packages and sarpi kernels is a recipe for disaster- just like mixing ubuntu with debian. It's best to install Slackware Aarch64, to use the RPi kernel scripts provided by Stuart, and to build a better integrated system.

If something is broken, let us know as soon as you can. In some cases it will likely be broken for Stuart and I, we just haven't noticed it yet. My honeycomb workstation can build all the kernel packages and the installer in about 2 hours or so. Stuart recently purchased a honeycomb as well, so the turn around time to fix stuff is much less.
 
1 members found this post helpful.
Old 01-22-2024, 09:01 AM   #5
pchristy
Senior Member
 
Registered: Oct 2012
Location: South Devon, UK
Distribution: Slackware
Posts: 1,119

Rep: Reputation: Disabled
OK, so here's what I've tried, and the results:

1) Clean install of Slackwareaarch64 on SD card, stock kernel, init3 (command line).

Use "os-initrd-mgr -M" to open the initrd. Open a second terminal (alt+F2). Use mc to copy the new bcm2711 file into the initrd, deleting the original. Check ownership and permissions of new file. Go back to the original terminal and press enter to re-pack the initrd.

Reboot.

Xfce now works reasonably well. KDE still crashes. All ancillaries seem to be working (wifi, sound & blutooth) or at least are present (didn't test everything).

2) Existing installation on SSD, Pi-fork kernel. (Boots, but KDE and XFCE broken)

Repeat above procedure, but have to use "os-initrd-mgr -FM" to force unpacking.

Reboot.

Boots OK, but KDE and XFCE still broken.

3) Back to the SD card. Upgrade to Pi-fork kernel. Unpack initrd using "os-initrd-mgr -FM" (had to force, as otherwise it wouldn't unpack). Open second terminal and replace bcm2711, check ownership and permissions. Back to terminal one, press enter to repack.

Reboot

Nothing! Screen goes blank and computer is unresponsive.

The fact that somehow I've got the SSD install to boot implies that the Pi-fork kernel may have an issue, but is basically capable of booting. I'm sure the issue that prevents booting is right at the start of the boot process. When running the stock kernel I see messages about reading extlinux.conf and unpacking the kernel and intrd. When running the Pi-fork, I don't see anything at all. Nada. Zip. Nothing. This makes it quite difficult to diagnose!

I don't know if any of the above helps at all. The new bcm2711 does show an improvement with the stock kernel, but not with the Pi-fork.

Cheers,

--
Pete
 
Old 01-24-2024, 06:22 AM   #6
mralk3
Slackware Contributor
 
Registered: May 2015
Distribution: Slackware
Posts: 1,900

Original Poster
Rep: Reputation: 1050Reputation: 1050Reputation: 1050Reputation: 1050Reputation: 1050Reputation: 1050Reputation: 1050Reputation: 1050
Did you check the serial console output while booting the Rpi kernel fork? Did you try enabling sshd and connecting in a secure shell? Is the screen off or is it just "black" without output?

This part could be wrong but I am trying to exhaust all possibilities. I've had issues with the Rpi 4 (before mine burned up) and having the boot text output to the wrong video devices. Sometimes this is indicated in the u-boot console prior to selecting the boot option menu. SSH is the easiest way to diagnose the scenario without messing with U-boot or a serial console.
 
Old 01-24-2024, 08:14 AM   #7
pchristy
Senior Member
 
Registered: Oct 2012
Location: South Devon, UK
Distribution: Slackware
Posts: 1,119

Rep: Reputation: Disabled
Yes, I know what you are suggesting. I tried ssh-ing into the machine, but no response. I'm not sure how to "read" the serial output (suggestions welcome!). It never gets as far as the boot option menu. Once you reboot, the machine shuts down, and never comes back up. The lights are on, indicating it has power, the monitor comes out of standby, indicating the GPU has power, but absolutely nothing else. There is no response from the keyboard. Ctl-alt-delete does nothing, neither does Fn-F10 (the power switch on the 400). Nether the Slackware logo screen, nor any of the text that accompanies it appears. It looks as if it never gets as far as even retrieving the kernel, let alone booting it.

If you can advise how to read the serial output (the 400 only has HDMI and USB ports) I will happily give it a try, but I don't think it gets that far!

As an aside - which may (or may not!) offer a clue, here's what I did to get the 6.6 Pifork to boot on the SSD.

This install had been running perfectly with the 6.1 PiFork kernels, but stopped after upgrading to 6.6. I did the upgrade in two stages, doing all the other packages first, rebooting to check for problems. I didn't find any, so I upgraded the kernel and everything stopped booting completely. In an attempt to get it running by any available means, I copied the contents of the SLKboot and SLKhwm_bw partitions from a freshly (stock kernel) prepared SD card. That got it to boot, although with the stock kernel wifi doesn't work, and KDE and Xfce only partly work. After messing around with it for a bit, I re-installed the PiFork 6.6 kernel, and to my amazement, it booted! Wifi works, but kde and xfce are still mostly broken. I haven't messed with it since, as its the only working 6.6 PiFork I've achieved. I haven't persuaded it to boot - or even start to boot - on an SD card at all.

Now I think about it, way back when I started trying to get Slackware running on the Pi-400, I do remember running into an issue that might be relevant. I think it might have been on Slarm64, but the boot would hang just after it tried to initialise the SD card (probing for the right voltage?). It seemed as if instead of selecting the correct voltage, it was switching it off altogether. This caused an immediate stall of the boot process. This was a long time ago, so my memory is hazy. I don't think slarm64 was using u-boot at this time. Is there anything in that early part of the u-boot process that tries to detect parameters for the SD card, and set things like voltage? If so, that could be the culprit!

I have to go out shortly for an hour or so, but when I get back, I'll have a trawl through the archives and see what I can find. Also, I will be away from home tomorrow, not returning until late on Friday, so I may not be able to do much more in the short term. Normal service should be restored by the week-end, though.

Cheers,

--
Pete
 
Old 01-24-2024, 08:47 AM   #8
mralk3
Slackware Contributor
 
Registered: May 2015
Distribution: Slackware
Posts: 1,900

Original Poster
Rep: Reputation: 1050Reputation: 1050Reputation: 1050Reputation: 1050Reputation: 1050Reputation: 1050Reputation: 1050Reputation: 1050
From what I can tell here: https://www.raspberrypi.com/products...pecifications/

It looks like connecting the serial console is the same process as the other raspberry pi models. The Rpi 400 GPIO pins on the back of the keyboard, a set of 3 dupont cables, and a serial to usb adapter for another machine are what you will need. Unfortunately I cannot find the directions to do so on the raspberry pi site. So again, I reference the SA64 install docs:https://docs.slackware.com/slackware...l_uart_adapter

You may need a GPIO adapter for the 400, like this one: https://thepihut.com/products/gpio-a...spberry-pi-400

Down the page a little on the same site, they show advertisements for dupont cables.

Here is a site to determine your GPIO pinout configuration: https://pinout.xyz/pinout/uart

I bought my serial adapter from amazon.com: https://www.amazon.com/gp/product/B075N82CDL/

I found it to be very frustrating to debug new hardware without a serial adapter. If for some reason the video driver or hdmi driver or sd card driver... do not work, you will see it on a serial console. You will know why it's missing or broken as well.
 
Old 01-24-2024, 10:39 AM   #9
pchristy
Senior Member
 
Registered: Oct 2012
Location: South Devon, UK
Distribution: Slackware
Posts: 1,119

Rep: Reputation: Disabled
OK, thanks for that Brent! Naturally, I don't have any of that hardware, and even if I order today, with the state of the postal service here in the UK, I'm unlikely to see anything until next week!

In the meantime, I did find that reference to the sd card having its power removed, and it was slackwareaarch64, not slarm64 as I incorrectly remembered! Indeed, you contributed to the thread! https://www.linuxquestions.org/quest...7/#post6381339 Check post #7.

I've just tried some of the suggestions from there, but unfortunately it still all fails at the first hurdle. The stock kernel on an SD card hangs if I append slkpbs to the extlinux.conf file - just as it did back then.

In fact, the situation now is even worse, because back then, I at least got some initial messages on the screen, so I could see where it appeared to be failing. Now I get nothing at all.

It is getting late in the day here now, and there are other things I must attend to. It will be a couple of days before I can back to this (as I explained earlier). Perhaps sleeping on it for a bit might give me a flash of inspiration.....

Thanks for your continued support and advice!

--
Pete
 
Old 01-30-2024, 02:36 PM   #10
mralk3
Slackware Contributor
 
Registered: May 2015
Distribution: Slackware
Posts: 1,900

Original Poster
Rep: Reputation: 1050Reputation: 1050Reputation: 1050Reputation: 1050Reputation: 1050Reputation: 1050Reputation: 1050Reputation: 1050
That post #7 was from 2022 and does not apply to the current status of the Aarch64 port. It was an unrelated bug and was fixed long ago.

The slkpbs boot flag is best used with a serial console adapter. It is mentioned in the installation docs, in the 2022 thread, and in this very thread that a serial adapter will save your efforts. You can of course configure the Pi 400 during installation to output all of the boot messages to an external monitor. By default Slackware Aarch64 outputs only part (if any) of the boot messages to an external screen and debugging output to the serial device. During the installation process there is a dialog window that mentions just that. See here

Quote:
In the context of the Broadcom iProc platform, the SDHCI-IPROC is a specific implementation of the SD Host Controller Interface. This controller facilitates the transfer of data between the host system and SD/MMC cards, allowing for storage and retrieval of information.
The Sdhci-iproc is a SD card host controller. It governs how the Broadcom SoC talks to the SD card slot. It has nothing to do with power, powering on, or powering off the hardware on your device. Changing your SD card brand or version is not a factor either.
 
Old 01-31-2024, 06:35 AM   #11
pchristy
Senior Member
 
Registered: Oct 2012
Location: South Devon, UK
Distribution: Slackware
Posts: 1,119

Rep: Reputation: Disabled
Brent: PM sent.
 
Old 02-04-2024, 08:58 AM   #12
pchristy
Senior Member
 
Registered: Oct 2012
Location: South Devon, UK
Distribution: Slackware
Posts: 1,119

Rep: Reputation: Disabled
Seeing a new version of the Pi-fork kernel, I thought I would give it a try. No joy, exactly the same symptoms. The only thing different that I did notice was a load of missing modules when upgrading the stock kernel to the Pi-fork (screenshot attached).

Does this help? I don't recall seeing it previously.
Attached Thumbnails
Click image for larger version

Name:	Pi400.jpg
Views:	29
Size:	130.1 KB
ID:	42515  
 
Old 03-13-2024, 07:23 AM   #13
pchristy
Senior Member
 
Registered: Oct 2012
Location: South Devon, UK
Distribution: Slackware
Posts: 1,119

Rep: Reputation: Disabled
Hi Brent,

Sorry for the long delay in following this up, but I've had other things that required my attention that kept getting in the way!

Digging through my Arduino box, I found an FTDI adapter and a crossover cable that I'd used for another project ages ago, and forgotten about! Thus armed, I set about having yet another go at getting the Pi kernel to load. All to no avail! It never even tries to boot, and there is no output at all to/from the UART - much as I expected!

Here's what I tried:

1) Create a new SD card installation, update to the current status (as of the 12th March) and get it running on the stock kernel. As expected, it loads and runs, but both KDE and XFCE are virtually unuseable. CLI is fine.

2) Clone the SD card, and check it out. Connect the FTDI and monitor the UART on my desktop machine, as described in the instructions. Yes, I see the same boot messages as I see on the HDMI output up until the login prompt. This proves my hardware connection is fine.

3) Upgrade to the Pi kernel fork and reboot.

4) Nothing on either the UART or HDMI. It doesn't even attempt to boot anything. No error messages, nothing at all - just blank screens.

One thing I did notice is that following the recommended installation procedure, you end up with two bootable partitions - SLKboot and SLKroot.

I'm sure this isn't right, and other Pi systems only have the boot partition marked bootable. Although it works fine with the stock kernel, I did wonder if it was confusing the Pi kernel, so I tried unsetting the boot flag on the SLKroot partition. The stock kernel still booted fine, but the Pi fork is as dead as ever, so its not that.

I'm now even more stumped than I was previously!

Fortunately the slaarch64 packages work perfectly on top of the SARPI kernels, so that's what I'm currently using.

I'm going to send Stuart a copy of this as well, as I know he doesn't visit the forum often any more.

I don't think there's anything more I can do from my end. It appears that the Pi fork is just completely broken - at least as far as the Pi-400 is concerned. I would be surprised if its any different on a 4, as the differences seem minor, but if anyone has tried it and got it to work, I would like to hear.

Cheers,

--
Pete
 
Old 03-13-2024, 11:39 AM   #14
drmozes
Slackware Contributor
 
Registered: Apr 2008
Distribution: Slackware
Posts: 1,543

Rep: Reputation: 1313Reputation: 1313Reputation: 1313Reputation: 1313Reputation: 1313Reputation: 1313Reputation: 1313Reputation: 1313Reputation: 1313Reputation: 1313
Quote:
Originally Posted by pchristy View Post

3) Upgrade to the Pi kernel fork and reboot.

4) Nothing on either the UART or HDMI. It doesn't even attempt to boot anything. No error messages, nothing at all - just blank screens.
There won't be any output on the UART, as stated in the RPi kernel fork doc.
The picture of the modprobe errors provided above is also described in that document.

There should be a display on the HDMI though, at least on the RPi4.

Quote:
Originally Posted by pchristy View Post
One thing I did notice is that following the recommended installation procedure, you end up with two bootable partitions - SLKboot and SLKroot.


I'm sure this isn't right, and other Pi systems only have the boot partition marked bootable
This is correct, and having it marked bootable makes no difference. It's an x86 thing that I just like doing.

Quote:
Originally Posted by pchristy View Post
Fortunately the slaarch64 packages work perfectly on top of the SARPI kernels, so that's what I'm currently using.
The SARPi Kernel is probably configured almost identically to the RPi Kernel fork (we drop the Kernel cmdline settings and rename the Kernel name to match the Slackware ARM standard), so it might be a missing/different DTB or something.


Quote:
Originally Posted by pchristy View Post
It appears that the Pi fork is just completely broken - at least as far as the Pi-400 is concerned. I would be surprised if its any different on a 4..
It works fine on my RPi4.
Neither Brent nor I have any RPi400, so I suggest you use SARPi - it's great for unsupported RPi models.
 
Old 03-13-2024, 12:17 PM   #15
pchristy
Senior Member
 
Registered: Oct 2012
Location: South Devon, UK
Distribution: Slackware
Posts: 1,119

Rep: Reputation: Disabled
Hi Stuart, and thanks for the response!

I appreciate that you don't have a 400, but I would have expected anything that works on a 4 to work on a 400. What I find puzzling is that it never even gets out of the gate!

I'm pretty convinced its a u-boot problem. None of the "working" installs I've tried use it, and it boots just fine. I did try to modify config.txt to by-pass u-boot with partial success (https://www.linuxquestions.org/quest...0/#post6477869), but never got any further. Maybe I need to revisit that.

What I really don't understand is why everything grinds to a halt instantly, without a single message appearing anywhere. Whatever it is, it must be happening right at the very start of the boot process.

--
Pete
 
  


Reply

Tags
aarch64, hardware, raspberry pi, slackware, support



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Raspberry Pi 4 bcm2711 / Raspberry Pi 3 bcm2837 (aarch64) sndwvs slarm64 145 03-16-2024 05:05 AM
LXer: Raspberry Pi OS Is Now Powered by Linux Kernel 5.10 LTS, Improves Support for Raspberry Pi 400 LXer Syndicated Linux News 0 03-27-2021 11:04 AM
LXer: openSUSE Tumbleweed ARM Adds Support for Raspberry Pi 400 and Raspberry Pi 4 CM LXer Syndicated Linux News 0 01-13-2021 07:12 PM
[VPS] 4 load page = 100 MB RAM loaded? do i need 100x 400 mb ram for next 400 page? vaporizel Linux - Server 1 03-14-2011 08:40 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM

All times are GMT -5. The time now is 03:08 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration