[SOLVED] Release: Slackware AArch64 into -current

kaott · 04-16-2022, 04:05 PM

Quote:

Originally Posted by mralk3

A possible reason you are stuck where you are stuck during boot is probably that your fstab or extlinux.conf are pointed to the wrong spot. This is likely because your ROOT disk is located on the SD card too. You may even be swapping during boot. So the sd card may not be fast enough for that sort of I/O all at once (kernel loading into RAM, swapping, and read/write to ROOT partition).

If you want to keep everything on an SD card, fine. You will need to adjust the fstab and boot loader so the kernel knows where to look for the root disk and swap. The design assumes a boot disk stores the installer and later mounted as /boot. It also assumes you are installing to an external media connected via USB. This would work okay with a USB thumb drive as root disk. I do not recommend running from an SD card if you plan any heavy I/O on the root partition.

Agreed running solely off the SD card isn't a great idea (and my SD cards could be a bit flaky anyways anyways). I don't think this Pi has USB3 so the USB stuff is fairly slow as well, however I don't really need incredible disk performance. I let it sit there for a while (about 10 minutes, but it didn't look like it was getting anywhere).

I took a look at the generated fstab before posting and it seemed reasonable, and it seemed to get fairly far in the boot process so I figured it wasn't an issue. I don't know too much about extlinux so I figured the config (updated with the FDTDIR) was alright as well, since it looked like the boot hand off was successful.

Quote:

---
My RPi 3 b v1.2 boots extremely slow with the default config.txt and append variable in extlinux.conf. I have a USB 3.0 to SATA adapter. An external Kingston A200 120GB SSDs. It boots with a serial console AND with an older Dell HDMI monitor plugged in to test.

Boot speed seems OK for me, seems to be about a minute with the new setup of SD card boot and external USB for root, and I don't think the speeds on either of them are particularly fast. I changed out to a smaller SD card for this setup, which I think is quite a bit slower than the other one I was using previously.

Quote:

I played with the following settings in config.txt:

Code:

[pi3]
gpu_mem=92
#dtoverlay=vc4-fkms-v3d
#hdmi_enable_4kp60=1

and in extlinux.conf:

Code:

APPEND earlyprintk rootfstype=ext4 root=LABEL=SLKroot cma=128

Maybe you can find a happy medium to solve the video problems I'm running into after booting into X11. I wouldn't bother with KDE or KDE + Wayland.

I had better results with the following kernel modules blacklisted:

Code:

cat /lib/modprobe.d/blacklists.conf
blacklist bcm2835_mmal_vchiq
blacklist bcm2835_v4l2
blacklist vchiq

I might mess around with this a bit, though running X/Wayland/graphical stuff isn't a goal for me.

Quote:

The best I achieved suggests that VC4 + v3d OpenGL graphics are okay, but the Pi 3 freezes up. Glxgears segfaults (glxgears -info), USB stops working and the X11 session is frozen. The serial and ssh terminals seem to be intact and I can reboot it from there when it freezes. Same behavior Stuart and I ran into while integrating the Raspberry Pi 4 into Slackware.

I recommend to use your Pi 3 as a headless system for now. The board runs out of GPU memory and RAM after some 30-40 minutes of use. Watched some youtube videos, and left amazon.com open in the background for two tabs in firefox, that will only speed up the time it takes for the frozen state to occur.

It isn't all that practical to use a desktop environment on this board. 1GB of RAM gets eaten up quick, and so does the 128MB GPU memory.

Good to know. I wasn't planning on running X or Wayland on it, strictly headless (mostly want to dink around a bit with some aarch64 stuff like compiling and some microbenchmarks, or possibly migrating some basic services I run normally to it).

kaott · 04-16-2022, 05:08 PM

Quote:

Originally Posted by kaott

Installing to a separate USB drive seems to work (albeit fairly slow) with the SD card handling the boot partitions.

It still has some odd behavior like getting to the bluetooth initialization, then hanging for a bit, rebooting, then working normally after the second boot.

Fixed this by fixing /etc/fstab.

mralk3 · 04-16-2022, 05:28 PM

Quote:

Originally Posted by kaott

Fixed this by fixing /etc/fstab.

You could look into UUID to label the partitions in fstab. The slackware installer creates labels for USB drives with ROOT, and the /boot partition on the SD card. So if you want the right disk to be booted (your sd card), add some disk labels. Just in case you plug in a second drive or thumb drive.

Code:

ls -la /dev/disk/*

Here is a brief document talking about it on Slackware.

https://docs.slackware.com/howtos:sl...91;]=uuid#uuid

I use a UUID on my RockPro64 because I have two of the same disks in the drive bay, so its easy to get them physically confused - especially when Linux decides to skip mounting the unlabeled drive (my /home)

cycojesus · 04-17-2022, 12:57 PM

Quote:

Originally Posted by cycojesus

I think (hope) I finally succeeded installing slackwareaarch64-current onto my Pinebook Pro!

Problems I ran into:

some strangeness about the willingness to boot depending on the charging port used (barrel-port => bad, usb-C => good.) Looks like hardware quirks.
I hoped to be able to keep the emmc enabled to use as storage. Alas warm reboot tries to boot off it so only cold boot is usable. I had to disable as per the tutorial.
having /home encrypted isn't practical as the password is prompted for in the UART console. I chose to keep UART active during installation and can't find how to change this now because
the uSD used as /boot isn't mountable. It boots fine but I can't mount it.

At least it seem to boot reliably, it's stable (had to rsync a lot, compile many things and it did all without a hiccup) and my Pinebook Pro has a purpose in life again!

Follow-up on my Pinebook Pro installation:

the un-mountable SD was likely just bad luck. I dd'd the content to another card and it boots and mounts just fine. Managed the 2 kernel upgrades too.
However "hot" boot (reboot) has consistently failed with the attached message followed by being dropped to u-boot command-line (where `reset` results in the same behavior, a forced shutdown is necessary to get back to a booting state.) It may just be the fault of the card(s)
so it seems the EMMC wasn't the thing preventing hot-reboot after all. I just re-enabled it and it booted fine (the EMMC has been erased before.)

Relevant part (I think) of the message in picture is:

Code:

Card did not respond to voltage select!: -110

glorsplitz · 04-17-2022, 07:43 PM

I can follow instructions to get things installed and resolve issues, but I'm not that bits and bytes technical.

Will there be better throughput armv8 vs armv7?

If rpi4 ran armv7, is that like driving half the speed limit, whereas armv8 is speed limit, in the same car?

mralk3 · 04-18-2022, 12:01 AM

Quote:

Originally Posted by glorsplitz

I can follow instructions to get things installed and resolve issues, but I'm not that bits and bytes technical.

Will there be better throughput armv8 vs armv7?

If rpi4 ran armv7, is that like driving half the speed limit, whereas armv8 is speed limit, in the same car?

Armv8 is significantly faster and allows for higher memory limits. Are you asking if there are benchmarks? You can find those tests online to compare Armv8 to Armv7 if you need a benchmark.

From my own experience as a day to day casual user/tester: I install, break, and reinstall my Rpi 4 and Pi 3 probably a half dozen times a week, maybe more. Lately I haven't had to do so due to the Aarch64 port stabilizing / less change occurring. It takes around 25-30 minutes to install the RPi 4 with all package series depending on whether my network is saturated with other activity. Pi 3, about 45 minutes. I remember it taking much longer with Armv7, so much that I didn't care to keep track.

Installation aside... Code compiles faster and the system boots much faster. I am referring to Armv8 running on Slackware. I run Slackware on all my SBC's and have done so for quite a while now. I cannot compare my experiences with Raspberry Pi OS (and shouldn't, different beasts entirely under the hood, proprietary as well) or any other distribution.

If you are looking for a "this is better than X because...", wrong approach. Run some benchmarks and match up the results with your hardware requirements. If you are looking to replace an aging desktop or laptop with a Raspberry Pi or RockPro64, I highly recommend Armv8.

I use my Pi's as headless servers, in a penetration testing LAB with various network topologies. They have enough I/O and network bandwidth as headless servers for my needs. All that said, Xfce runs well enough on the Pi 4. Pi 3 just doesn't have enough RAM once you open a video / audio file - not to mention a web browser.

I am a firm believer that in all things technical; Find the right tool for the job. I have contributed my time and efforts to Armv8 and so my opinions may be bias. Armv8 will exceed your expectations and surprise you if you are used to Armv7 speeds.

netcrawl · 04-18-2022, 10:56 AM

I've got updated Slackware Aarch64 running well on my RPi4, KDE is reasonably responsive, so far the only issue I've come across is that the X server fails with two monitors connected. X server crashes at startx every time with both HDMI monitors connected, with error message "Fatal server error: AddScreenInit failed for driver 0". Disconnect one and it starts normally. Once the X server is running I can plug in the second monitor.

One monitor is OK, but I prefer using both at times, so any suggestions on how this might be resolved would be great. Thanks!

Edit: I got around to trying a few different options in config.txt and fixed it. Using dtoverlay=vc4-kms-v3d-pi4 and max_framebuffers=2 I can boot the pi4 with both monitors attached, works well, s'all good, man!

glorsplitz · 04-18-2022, 06:18 PM

mralk3, thank you for relating actual experience.

I look forward to smoothing out my Aarch64 installs, rpi4 and rockpro64, I might even Aarch64 my rpi3.

Quote:

I install, break, and reinstall my Rpi 4 and Pi 3 probably a half dozen times a week, maybe more. <-slackware user

Will report back my 'experiences' later. Thanks again.

viel · 04-24-2022, 10:28 AM

I am trying to use slackware on mi pinebook pro. If i success i will try mi rpi4.
Successfully installed slackware aarch64 on pinebook pro whit the instructions and the image from official page. Only the base system. Great work.
Not happy with that, I'm trying to make my own image for SD with i3wm and my package list because i have arch installed on the emmc and mi plan is to run slack as main after try it, I'm at the beginning. In this process, I found some points that maybe can help improve the development and make more people use Slackware aarch64.

This is my feedback:

During this process i see that the official Slackware image make use of all the drivers and modules to make the kernel work and not only the needed for mount the root partition. This makes the startup time longer because the initrd image is about 270M and read it take ~7 seconds on SD. Compared to other distros , the initrd is about 20M and take about ~2 seconds. For now i have reduced the size of initrd removing the unneeded modules manually and i can boot from SD faster.

I don't know if it is planed for aarch64 to have kernels like x86 made, generic and huge, or follow some symmetry on the config files. For now mi iptables tool don't work with the actual aarch64 kernel config because some options like CONFIG_IP_NF_RAW etc.. are not set. i will recompile it or delete raw and security rules.

Cryptsetup fail to ask for password on dev/tty0 and only show on console. Maybe because run on init and tty0 is not set
i debug with a ps -eff | grep tty at rc.S

Quote:

ps -eff | grep tty && /sbin/cryptsetup ${LUKSOPTS} luksOpen $DEV $LUKS </dev/tty0 >/dev/tty0 2>&1

I don't really like to post but I hope this helps something. sorry if my English is bad.

drmozes · 04-25-2022, 03:10 AM

Hi

Thanks for the feedback.

Quote:

Originally Posted by viel

During this process i see that the official Slackware image make use of all the drivers and modules to make the kernel work and not only the needed for mount the root partition. This makes the startup time longer because the initrd image is about 270M and read it take ~7 seconds on SD. Compared to other distros , the initrd is about 20M and take about ~2 seconds. For now i have reduced the size of initrd removing the unneeded modules manually and i can boot from SD faster.

The intention is to provide enough hardware support to support existing Hardware Models and more easily onboard new ones; but presently there's a *lot* of modules that can safely be removed - I just haven't had time to research and test it to pare the list down.

What did you remove?

kernel.SlackBuild presently does this:

Code:

# Slim down the modules within the initrd by removing unnecessary
# major sub systems or drivers for hardware that is not required during
# the initial boot.
# There will be far more that are also surplus to requirements but I'm
# trying to strike a balance between size and enabling the community to
# more easily light up Slackware AArch64 onto new platforms.
#
pushd lib/modules/*/kernel
   rm -rfv sound
   rm -rfv drivers/{bluetooth,interconnect,mailbox}
   rm -rfv drivers/{perf,ptp,soundwire,thermal}
   rm -rfv drivers/net/{wireless,can,ipa}
   rm -rfv drivers/media/{tuners,dvb-core}
   rm -rfv drivers/media/platform/{rcar*,qcom,exynos*,vsp1}
   rm -rfv fs/{ntfs}
   rm -rfv net/{802,8021q,bluetooth,bridge,can,dsa,mac80211,netfilter,nfc,wireless}
popd

Quote:

For now mi iptables tool don't work with the actual aarch64 kernel config because some options like CONFIG_IP_NF_RAW etc.. are not set. i will recompile it or delete raw and security rules.

Ah yes those should definitely be there. I've added a (I think) full complement of ip tables modules and support now, so it'll be in the next kernel update.

Quote:

Cryptsetup fail to ask for password on dev/tty0 and only show on console. Maybe because run on init and tty0 is not set
i debug with a ps -eff | grep tty at rc.S

This is a known issue - if you have a fix for it let us know.
I'm not sure if setting the console= is a work around for this, as I haven't tried yet.
Or it may be as simple as duplicating the password message from cryptsetup onto the console.

viel · 04-25-2022, 04:09 AM

Hi mozes,

Thanks for the reply.

Quote:

Ah yes those should definitely be there. I've added a (I think) full complement of ip tables modules and support now, so it'll be in the next kernel update.

That's great.

Regarding the modules i successfully boot from SD and one ext4 partition (due uboot read ext4) whit the following modules:

Code:

/sbin/modprobe gpio-rockchip
/sbin/modprobe i2c-rk3x
/sbin/modprobe cqhci
/sbin/modprobe sdhci
/sbin/modprobe sdhci-pltfm
/sbin/modprobe sdhci-of-arasan
/sbin/modprobe mmc_block
/sbin/modprobe analogix_dp
/sbin/modprobe cec
/sbin/modprobe drm
/sbin/modprobe drm_kms_helper
/sbin/modprobe drm_panel_orientation_quirks
/sbin/modprobe dw-hdmi
/sbin/modprobe dw-mipi-dsi
/sbin/modprobe fb_sys_fops
/sbin/modprobe panel-simple
/sbin/modprobe pwm_bl
/sbin/modprobe rockchipdrm
/sbin/modprobe rtc-rk808
/sbin/modprobe syscopyarea
/sbin/modprobe sysfillrect
/sbin/modprobe sysimgblt
/sbin/modprobe ext4
/sbin/modprobe dw_mmc
/sbin/modprobe dw_mmc-pltfm
/sbin/modprobe dw_mmc-rockchip
/sbin/modprobe jbd2
/sbin/modprobe phy_rockchip_emmc
/sbin/modprobe drm_cma_helper
/sbin/modprobe mbcache

I removed the rest after installation, that will change for emmc/nve and other filesystems like xfs, etc. of course.
Hope that helps.
I will do more test after install i3 where i am stucked for now.

Quote:

I'm not sure if setting the console= is a work around for this, as I haven't tried yet.

I thin this is the way, i will made some test too.

I will let you know if I move on something of course.

Thanks, Viel.

drmozes · 04-26-2022, 03:10 AM

Hi viel,

You just gave me an idea. What if I added a --optimize option to os-initrd-mgr which simply replaced the full complement of modules with only those that are currently loaded on the running system?

This way you don't need to manually trim it down, and I can't see a reason why it wouldn't work: after the install you'd boot into the full fat OS InitRD.
You'd then run os-initrd-mgr --optimize, which'd slim it down. All of the module loader scripts would continue to work since the appropriate modules would have been loaded already, so would be re-populated into the optimized OS InitRD.

I'll think this through a bit more but it seems like it'd work, and it's similar to how it works on x86.

viel · 04-26-2022, 09:39 AM

Good approach, glad to help.

I am trying console=/dev/null to get cryptsetup to work without the console logs. For now I can boot into dev/tty0 with that and see the password prompt. I think Arch did another approach because he has console=/dev/tty1 in extlinux.conf. The bad news is that this makes the console not work for the UART port. I need to do more tests.

I also have some problems with the speed of the SD because I use it for rooting. I have needed to change "sd-uhs-sdr104;" with "sd-uhs-sdr50;" in the .dtb and now at least it works as discussed on the Pine64 forum https://forum.pine64.org/showthread.php?tid=13402
In case it helps someone.

If I find anything else to comment, I'll post them.

Cheers

drmozes · 04-28-2022, 11:46 AM

Hi viel

On the RockPro64 and Pinebook Pro I've brought the video up earlier in the OS InitRD, so you can now see the password prompt for unlocking LUKS volumes.

This will be baked into the new OS InitRD for the next Kernel package update, but you can try it out first if you like.

Assuming you have installed the latest updates released today, once you've booted into Linux 5.17.5:

Code:

cd /tmp
wget http://armed.slackware.com/tmp/rk3399
su - 

root@wizbit:~# os-initrd-mgr -fM
Scanning for loaded firmware ... 
Firmware is in sync.
Searching for local customisations ... 
Unpacking /boot/initrd-armv8 ...
Processing firmware ... 
Awaiting manual intervention
OS InitRD temporary working directory: /tmp/os-initrd-mgr.vnpRAJ/os-initrd-root
Press ENTER to continue

as root cd into the dir name it provides in another shell:

Code:

cd /tmp/os-initrd-mgr.vnpRAJ/os-initrd-root
cd load_kernel_modules.scr/platform/aarch64
mv -f /tmp/rk3399 .

Return to the other shell:

Code:

## press ENTER 
Repacking /boot/initrd-armv8 ...

And reboot

This should be solved.

Lockywolf · 08-10-2022, 10:09 AM

Not sure where to write about this, but the slarm64-15.0 seems to have some packages from -current.

Look at http://dl.slarm64.org/slarm64/slarm64-15.0/slarm64/a/

There is libblockdev-2.26-aarch64-4.txz , althought in the official slackware64 http://ftp.slackware.com/pub/slackwa...0/slackware/a/ the version is -3

How should I report this to? This is likely to break compatibility.

UPD, although -current even has /libblockdev-2.27-i586-1.txz , so I am even more confused.