CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc.

Jump to Latest
P

paalj

Member
Joined 2005
P

paalj

Member
Joined 2005
paal@paal-desktop:~$ ls /lib/modules
5.10.110-99-rockchip-g 5.15.0-86-generic 6.2.0-1016-gcp
5.10.160-rockchip 5.15.0-88-generic


paal@paal-desktop:~$ uname -a
Linux paal-desktop 5.10.160-rockchip #15 SMP Sun Oct 8 15:01:49 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux

I seem to be running 5.10.160. I guess it should have been 5.10.110-99-rockchip-g. You said find snd-asound, but nothing there. I assume you ment snd-aloop? See below:


paal@paal-desktop:~$ find /lib/modules -name 'snd-aloop.*'
/lib/modules/6.2.0-1016-gcp/kernel/sound/drivers/snd-aloop.ko
/lib/modules/5.10.110-99-rockchip-g/kernel/sound/drivers/snd-aloop.ko
paal@paal-desktop:~$
 
P

phofman

Member
Joined 2005
Very good. As you see, the newly installed 5.10.110-99-rockchip-g kernel does contain the snd-aloop module, unlike the original kernel 5.10.160-rockchip. Now you need to make your board boot into that new kernel. Check your extlinux.conf as in https://wiki.radxa.com/Rock5/guide/build-kernel-on-5b#Install_kernel_packages and set the new kernel as default. Be careful to keep filenames and paths correct in that file, otherwise you may not boot again.
 
P

paalj

Member
Joined 2005
boot is mounted, but could it be that ubuntu has another way of changing kernel?

paal@paal-desktop:~$ ls /boot
config-5.10.110-99-rockchip-g System.map-5.10.110-99-rockchip-g
config-5.10.160-rockchip System.map-5.10.160-rockchip
config-6.2.0-1016-gcp System.map-6.2.0-1016-gcp
firmware vmlinuz
initrd.img vmlinuz-5.10.110-99-rockchip-g
initrd.img-5.10.110-99-rockchip-g vmlinuz-5.10.160-rockchip
initrd.img-5.10.160-rockchip
paal@paal-desktop:~$
 
P

phofman

Member
Joined 2005
Also if you run that ls with -l parameter (to see what those names actually mean), it's likely vmlinuz and initrd.img are just symlinks to the original kernel initrd.img-5.10.160-rockchip ...

Just changing the symlinks to point at the files corresponding to the new kernel (image and initrd) may do. But you would need to change BOTH vmlinuz and initrd.img otherwise you will ruin your installation and would either have to reinstall the image or use serial console at boot (quite a complex procedure).
 
HenrikEnquist

HenrikEnquist

Member
Joined 2016
HenrikEnquist said:
But I had an idea for a different workaround.
Click to expand...
The new idea works! I made a separate sse2-version of the biquad calculations using intrinsics, and this compiles into a trouble free binary. I'll make a new release as soon as I can.

I had a small hope that this hand-optimized version would also run a little faster, but that is not the case. I get exactly the same speed. The compiler is hard to beat!
 
  • Like
Reactions: 1 users
P

paalj

Member
Joined 2005
phofman said:
Also if you run that ls with -l parameter (to see what those names actually mean), it's likely vmlinuz and initrd.img are just symlinks to the original kernel initrd.img-5.10.160-rockchip ...

Just changing the symlinks to point at the files corresponding to the new kernel (image and initrd) may do. But you would need to change BOTH vmlinuz and initrd.img otherwise you will ruin your installation and would either have to reinstall the image or use serial console at boot (quite a complex procedure).
Click to expand...
I do not understand much of the content of ubuntuEnv:

nano /boot/firmware/ubuntuEnv.txt

bootargs=root=UUID=d312d528-2e2f-4044-a702-659ba4cf55d5 rootfstype=ext4 rootwait rw console=ttyS2,1500000 console=tty1 cgroup_enable=cpuset cg>
fdtfile=rk3588-rock-5b.dtb
overlay_prefix=rock-5b
overlays=

Here is the ls -l content of boot dir. looks like symlinks. How do I modify them?
PS: I have reinstalled the image a number of times, so I am not afraid of that risk :)

paal@paal-desktop:~$ ls -l /boot
total 98324
-rw-r--r-- 1 root root 213159 mai 29 15:48 config-5.10.110-99-rockchip-g
-rw-r--r-- 1 root root 223382 sep. 30 18:14 config-5.10.160-rockchip
-rw-r--r-- 1 root root 321487 sep. 29 05:17 config-6.2.0-1016-gcp
drwxr-xr-x 3 root root 16384 jan. 1 1970 firmware
lrwxrwxrwx 1 root root 28 okt. 8 19:06 initrd.img -> initrd.img-5.10.160-rockchip
-rw-r--r-- 1 root root 14391415 okt. 14 09:32 initrd.img-5.10.110-99-rockchip-g
-rw-r--r-- 1 root root 14925175 okt. 14 10:24 initrd.img-5.10.160-rockchip
-rw-r--r-- 1 root root 7222742 mai 29 15:48 System.map-5.10.110-99-rockchip-g
-rw-r--r-- 1 root root 8398813 sep. 30 18:14 System.map-5.10.160-rockchip
-rw------- 1 root root 6352135 sep. 29 05:17 System.map-6.2.0-1016-gcp
lrwxrwxrwx 1 root root 25 okt. 8 19:06 vmlinuz -> vmlinuz-5.10.160-rockchip
-rw-r--r-- 1 root root 10395400 mai 29 15:48 vmlinuz-5.10.110-99-rockchip-g
-rw-r--r-- 1 root root 38203904 sep. 30 18:14 vmlinuz-5.10.160-rockchip
paal@paal-desktop:~$
 
P

phofman

Member
Joined 2005
P

paalj

Member
Joined 2005
Thanks for gudiance. I changed the symlinks, but it seems to be more complicated. The symlinks is now linked to the xxx-99 kernel, but it still boots on the old kernel
paal@paal-desktop:/boot$ ls -l
total 98324
-rw-r--r-- 1 root root 213159 mai 29 15:48 config-5.10.110-99-rockchip-g
-rw-r--r-- 1 root root 223382 sep. 30 18:14 config-5.10.160-rockchip
-rw-r--r-- 1 root root 321487 sep. 29 05:17 config-6.2.0-1016-gcp
drwxr-xr-x 3 root root 16384 jan. 1 1970 firmware
lrwxrwxrwx 1 root root 33 okt. 15 15:47 initrd.img -> initrd.img-5.10.110-99-rockchip-g
-rw-r--r-- 1 root root 14391415 okt. 14 09:32 initrd.img-5.10.110-99-rockchip-g
-rw-r--r-- 1 root root 14925175 okt. 14 10:24 initrd.img-5.10.160-rockchip
-rw-r--r-- 1 root root 7222742 mai 29 15:48 System.map-5.10.110-99-rockchip-g
-rw-r--r-- 1 root root 8398813 sep. 30 18:14 System.map-5.10.160-rockchip
-rw------- 1 root root 6352135 sep. 29 05:17 System.map-6.2.0-1016-gcp
lrwxrwxrwx 1 root root 30 okt. 15 15:15 vmlinuz -> vmlinuz-5.10.110-99-rockchip-g
-rw-r--r-- 1 root root 10395400 mai 29 15:48 vmlinuz-5.10.110-99-rockchip-g
-rw-r--r-- 1 root root 38203904 sep. 30 18:14 vmlinuz-5.10.160-rockchip

The old krenel still is in the firmware dir...

paal@paal-desktop:/boot$ cd /boot/firmware
paal@paal-desktop:/boot/firmware$ ls -l
total 51952
-rwxr-xr-x 1 root root 1883 sep. 14 23:14 boot.cmd
-rwxr-xr-x 1 root root 1955 sep. 14 23:14 boot.scr
drwxr-xr-x 3 root root 40960 okt. 14 10:24 dtbs
-rwxr-xr-x 1 root root 14925175 okt. 14 10:24 initrd.img
-rwxr-xr-x 1 root root 331 sep. 14 23:14 ubuntuEnv.txt
-rwxr-xr-x 1 root root 38203904 okt. 14 10:24 vmlinuz
paal@paal-desktop:/boot/firmware$
 
C

CharlieLaub

Member
Joined 2007
audio.claub.net
Paid Member
I hate to be a Debbie downer but problems like this are why I stopped using ARM boards altogether. The Raspberry Pi platform is pretty good, but when I tried some products from Orange Pi and Tinker I encountered issues with the "custom kernel" that totally wasted time or prevented me from reaching my goal(s) with the boards. Now I stick with Intel based mini PCs. These can run a standard kernel and can be updated without breaking anything and are typically faster than ARM based SBCs. Since making that change I have had zero problems.
 
P

phofman

Member
Joined 2005
paalj said:
The old krenel still is in the firmware dir...

paal@paal-desktop:/boot$ cd /boot/firmware
paal@paal-desktop:/boot/firmware$ ls -l
total 51952
-rwxr-xr-x 1 root root 1883 sep. 14 23:14 boot.cmd
-rwxr-xr-x 1 root root 1955 sep. 14 23:14 boot.scr
drwxr-xr-x 3 root root 40960 okt. 14 10:24 dtbs
-rwxr-xr-x 1 root root 14925175 okt. 14 10:24 initrd.img
-rwxr-xr-x 1 root root 331 sep. 14 23:14 ubuntuEnv.txt
-rwxr-xr-x 1 root root 38203904 okt. 14 10:24 vmlinuz
Click to expand...
What is in those files boot.cmd, boot.scr?

Well then it looks like the boot manager takes the kernel files from the firmware directory. Just try overwriting initrd.img and vmlinuz with the new corresponding files from the /boot , make sure to keep the firmware/names correct, otherwise it may not boot.
 
P

paalj

Member
Joined 2005
boot.cmd
# This is a boot script for U-Boot
#
# Recompile with:
# mkimage -A arm64 -O linux -T script -C none -n "Boot Script" -d boot.cmd boot.scr

setenv load_addr "0x9000000"
setenv overlay_error "false"

echo "Boot script loaded from ${devtype} ${devnum}"

if test -e ${devtype} ${devnum}:${distro_bootpart} /ubuntuEnv.txt; then
load ${devtype} ${devnum}:${distro_bootpart} ${load_addr} /ubuntuEnv.txt
env import -t ${load_addr} ${filesize}
fi

load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} /dtbs/${fdtfile}
fdt addr ${fdt_addr_r} && fdt resize 0x10000

for overlay_file in ${overlays}; do
if load ${devtype} ${devnum}:${distro_bootpart} ${fdtoverlay_addr_r} /dtbs/overlays/${overlay_prefix}-${overlay_file}.dtbo; then
echo "Applying device tree overlay: /dtbs/overlays/${overlay_prefix}-${overlay_file}.dtbo"
fdt apply ${fdtoverlay_addr_r} || setenv overlay_error "true"
elif load ${devtype} ${devnum}:${distro_bootpart} ${fdtoverlay_addr_r} /dtbs/overlays/${overlay_file}.dtbo; then
echo "Applying device tree overlay: /dtbs/overlays/${overlay_file}.dtbo"
fdt apply ${fdtoverlay_addr_r} || setenv overlay_error "true"
elif load ${devtype} ${devnum}:${distro_bootpart} ${fdtoverlay_addr_r} /dtbs/overlays/rk3588-${overlay_file}.dtbo; then
echo "Applying device tree overlay: /dtbs/overlays/rk3588-${overlay_file}.dtbo"
fdt apply ${fdtoverlay_addr_r} || setenv overlay_error "true"
fi
done
if test "${overlay_error}" = "true"; then
echo "Error applying device tree overlays, restoring original device tree"
load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} /dtbs/${fdtfile}
fi

load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} /vmlinuz
load ${devtype} ${devnum}:${distro_bootpart} ${ramdisk_addr_r} /initrd.img

booti ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}


boot.scr

'^E^YVM^A^[Ze^Cw�^@^@^Gc^@^@^@^@^@^@^@^@^Q�:K^E^V^F^@Boot Script^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^G[^@^@^@^@# This is a >
#
# Recompile with:
# mkimage -A arm64 -O linux -T script -C none -n "Boot Script" -d boot.cmd boot.scr

setenv load_addr "0x9000000"
setenv overlay_error "false"

echo "Boot script loaded from ${devtype} ${devnum}"

if test -e ${devtype} ${devnum}:${distro_bootpart} /ubuntuEnv.txt; then
load ${devtype} ${devnum}:${distro_bootpart} ${load_addr} /ubuntuEnv.txt
env import -t ${load_addr} ${filesize}
fi

load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} /dtbs/${fdtfile}
fdt addr ${fdt_addr_r} && fdt resize 0x10000

for overlay_file in ${overlays}; do
if load ${devtype} ${devnum}:${distro_bootpart} ${fdtoverlay_addr_r} /dtbs/overlays/${overlay_prefix}-${overlay_file}.dtbo; then
echo "Applying device tree overlay: /dtbs/overlays/${overlay_prefix}-${overlay_file}.dtbo"
fdt apply ${fdtoverlay_addr_r} || setenv overlay_error "true"
elif load ${devtype} ${devnum}:${distro_bootpart} ${fdtoverlay_addr_r} /dtbs/overlays/${overlay_file}.dtbo; then
echo "Applying device tree overlay: /dtbs/overlays/${overlay_file}.dtbo"
fdt apply ${fdtoverlay_addr_r} || setenv overlay_error "true"
elif load ${devtype} ${devnum}:${distro_bootpart} ${fdtoverlay_addr_r} /dtbs/overlays/rk3588-${overlay_file}.dtbo; then
echo "Applying device tree overlay: /dtbs/overlays/rk3588-${overlay_file}.dtbo"
fdt apply ${fdtoverlay_addr_r} || setenv overlay_error "true"
fi
done
if test "${overlay_error}" = "true"; then
echo "Error applying device tree overlays, restoring original device tree"
load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} /dtbs/${fdtfile}
fi

load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} /vmlinuz
load ${devtype} ${devnum}:${distro_bootpart} ${ramdisk_addr_r} /initrd.img

booti ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}
 
P

phofman

Member
Joined 2005
@CharlieLaub : I absolutely agree, I always prefer x86 unless Arm-only IO features are required (I2S, USB gadget, other interfaces).

The truth is making an ARM board run properly is always a major work. Done by RPi devs for RPi, other board vendor (in better cases) for a single kernel/distribution. Anything outside of that takes major effort for the user where some non-trivial linux skills are required, patching/compiling/deploying kernel, modifying device-tree, etc. etc. It's not for a user, but more like for a developer.

@paalj: Running a third-party distribution on Rock5 is not a trivial task and really does require some linux skills. I will have to go that path for my project, but am aware that it will be a fight. But there are not many other options as I need lots of CPU power with 768kHz multichannel in/out I2S + working usb gadget. RK3588 is one of very few SoCs practically available to try. What is your reason for using this still vastly unexplored path? I am afraid even if you get this kernel work and your snd-aloop module load, what next steps do you plan? Do you have the skills e.g. to make the dwc3 usb gadget or I2S output work? If not, why do you struggle with this unsupported board?
 
You must log in or register to reply here.
Top Bottom