c0rnelius

The 6.6.y kernel for reasons I have yet to figure out reads the MEM wrong. 6.7 and up is not affected by this. Nor is 6.1 to 6.5. I would have thought after so many REVS this would have been resolved, but I have yet to see it come up as a topic of discussion. This in my experience is also not PLATFORM specific. It happens on all my boards regardless of SoC and PLATFORM.

I suspect it has to do with the devfreq driver for the MBUS/DRAM controller. https://lore.kernel.org/linux-arm-kernel/a48923b7-12f9-808e-1171-49b826bd5f1c@samsung.com/T/#ma00a3e07248dc7fb2d300b7c9c409f69ffa64c14 In my personal experience this introduces instability into the a64/h5. You could try blacklisting the driver and see if it solves the issue. I personally remove the entry from the DTS and create an overlay to add it back if for some reason I need it. The main issue you reported `Kernel panics with headless boot` in my mind points to it being the driver.

My guess would be this patch; https://github.com/armbian/build/blob/main/patch/u-boot/v2022.10/meson64-boot-usb-nvme-scsi-first.patch But if its a spin up HDD, it could be PREBOOT and it isn't able to spin up the drive in time and halting the boot process.

and a DTS was created?

firefox-esr --kiosk --private-window http://armbian.com I think chromium is better for this, but I suppose it depends on what you are trying to load. If using Xfce4 you could use Settings > Session and Startup. I prefer using Openbox my self, as editing a file `.config/openbox/autostart` is more straight forward and makes it easier to load only the services you want. cat .config/openbox/autostart # Daemon xfsettingsd & # Display xset s off & xset -dpms & xset s noblank & unclutter & # Background feh --bg-fill /home/username/.background.png & # Clean rm -fdr ~/.cache/chromium & rm -fdr ~/.config/chromium & # Kiosk sleep 5s chromium --noerrdialogs --incognito --kiosk --force-device-scale-factor=1 --disk-cache-dir=/tmp/null --enable-features=WebUIDarkMode --force-dark-mode http://yourwebsite.whatever &

If its completely bricked you should be able to short the unit and force it into USB mode. From there you can use either Linux or Windows to re-flash the vendor firmware. I would google the box you have and see if someone else has already done this and if nothing found, do a general search for ideas of where to look. "tvbox short emmc pins" Example: Tin foil seems to work best, but a small flat head will also do the trick.

In my experience, its not just Armbian. I "think" I saw a commit at one point concerning a fix for this over at https://github.com/libre-computer-project. But I can't remember if it was u-boot, linux or boot fip related. I'm leaning towards fip.

Not ideal, but: sudo halt

This works for me. Edit it to fit the commands you want to be able to run. sudo tee /etc/sudoers.d/010_$USER-nopasswd <<EOF ${USER} ${HOSTNAME} = (root) NOPASSWD: /sbin/shutdown ${USER} ${HOSTNAME} = (root) NOPASSWD: /sbin/poweroff ${USER} ${HOSTNAME} = (root) NOPASSWD: /sbin/reboot EOF

Not sure about doing it for just one command, but you can make it so you don't need to authenticate when using sudo. sudo mkdir -p /etc/sudoers.d/ sudo tee /etc/sudoers.d/010_$USER-nopasswd <<EOF $USER ALL=(ALL) NOPASSWD: ALL EOF

I'm using overlay meson-g12a-radxa-zero-i2c-ee-m1-gpiox-10-gpiox-11.dtbo sudo i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- 3c -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- Overlay meson-g12a-radxa-zero-i2c-ee-m3-gpioa-14-gpioa-15.dtbo works for me as well.

Or temporarily patch the driver until a better solution presents its self. diff --git a/drivers/net/wireless/uwe5622/unisocwifi/tx_msg.c b/drivers/net/wireless/uwe5622/unisocwifi/tx_msg.c index 40d51a7130d9..f1c356306c80 100644 --- a/drivers/net/wireless/uwe5622/unisocwifi/tx_msg.c +++ b/drivers/net/wireless/uwe5622/unisocwifi/tx_msg.c @@ -317,7 +317,15 @@ void sprdwl_dequeue_data_list(struct mbuf_t *head, int num) /* seam for tx_thread */ void tx_down(struct sprdwl_tx_msg *tx_msg) { - wait_for_completion(&tx_msg->tx_completed); + int ret; + while (1) { + ret = wait_for_completion_interruptible(&tx_msg->tx_completed); + if (ret == -ERESTARTSYS) { + continue; + } + + return; + } } void tx_up(struct sprdwl_tx_msg *tx_msg) -- 2.39.2 https://github.com/orangepi-xunlong/linux-orangepi/issues/57

sudo nano /etc/asound.conf pcm.!default { type hw card 2 } ctl.!default { type hw card 2 } save and reboot https://www.alsa-project.org/wiki/Asoundrc

Fun read though.

Is there a config.txt? https://www.raspberrypi.com/documentation/computers/configuration.html#part5.5 dtparam=i2c_arm=on If for some reason it still doesn't load sudo modprobe i2c-dev and add i2c-dev to /etc/modules.

What is the PSU AMPS? I would recommend at least 3A if you are attaching an external drive.

`sudo dpkg-reconfigure tzdata` doesn't work for you?

This should correct the audio issue. Run as root `sudo su` and only choose one. # ANALOG amixer -c 0 set 'TOACODEC OUT EN' 'on' amixer -c 0 set 'TOACODEC SRC' 'I2S B' amixer -c 0 set 'TDMOUT_B SRC SEL' 'IN 0' amixer -c 0 set 'FRDDR_A SRC 2 EN' 'on' amixer -c 0 set 'FRDDR_A SINK 1 SEL' 'OUT 0' amixer -c 0 set 'FRDDR_A SINK 2 SEL' 'OUT 1' amixer -c 0 set 'FRDDR_A SINK 3 SEL' 'OUT 2' amixer -c 0 set 'ACODEC' '85%' alsactl store # HDMI amixer -c 0 set 'TOHDMITX' 'on' amixer -c 0 set 'TOHDMITX I2S SRC' 'I2S B' amixer -c 0 set 'TDMOUT_B SRC SEL' 'IN 0' amixer -c 0 set 'FRDDR_A SRC 2 EN' 'on' amixer -c 0 set 'FRDDR_A SINK 1 SEL' 'OUT 0' amixer -c 0 set 'FRDDR_A SINK 2 SEL' 'OUT 1' amixer -c 0 set 'FRDDR_A SINK 3 SEL' 'OUT 2' amixer -c 0 set 'ACODEC' '85%' alsactl store

Try these: https://github.com/pyavitz/debian-image-builder/tree/feature/patches/overlays/arm64 As for them showing up under /dev correctly, I believe we would need to do a PR to add the aliases to the DTS. aliases { serial0 = &uart_AO; + serial1 = &uart_AO_B; + serial2 = &uart_A; + serial3 = &uart_B; + serial4 = &uart_C; + i2c0 = &i2c0; + i2c1 = &i2c1; + i2c2 = &i2c2; + i2c3 = &i2c3; + i2c4 = &i2c_AO; + spi0 = &spicc0; + spi1 = &spicc1; + spi2 = &spifc; }; radxazero: ~ $ ls /dev autofs initctl ram0 snd tty23 tty42 tty61 vcs6 block input ram1 stderr tty24 tty43 tty62 vcsa btrfs-control kmsg ram10 stdin tty25 tty44 tty63 vcsa1 bus kvm ram11 stdout tty26 tty45 tty7 vcsa2 cachefiles log ram12 tty tty27 tty46 tty8 vcsa3 cec0 loop-control ram13 tty0 tty28 tty47 tty9 vcsa4 char mapper ram14 tty1 tty29 tty48 ttyAML0 vcsa5 console mem ram15 tty10 tty3 tty49 ttyAML1 vcsa6 cpu_dma_latency mmcblk1 ram2 tty11 tty30 tty5 ttyAML4 vcsu disk mmcblk1boot0 ram3 tty12 tty31 tty50 udmabuf vcsu1 dma_heap mmcblk1boot1 ram4 tty13 tty32 tty51 uhid vcsu2 dri mmcblk1p1 ram5 tty14 tty33 tty52 uinput vcsu3 fb0 mmcblk1p2 ram6 tty15 tty34 tty53 urandom vcsu4 fd mmcblk1rpmb ram7 tty16 tty35 tty54 userio vcsu5 full mqueue ram8 tty17 tty36 tty55 v4l vcsu6 fuse net ram9 tty18 tty37 tty56 vcs vga_arbiter gpiochip0 null random tty19 tty38 tty57 vcs1 video0 gpiochip1 port rfkill tty2 tty39 tty58 vcs2 watchdog hwrng ppp rtc tty20 tty4 tty59 vcs3 watchdog0 i2c-3 ptmx rtc0 tty21 tty40 tty6 vcs4 zero i2c-5 pts shm tty22 tty41 tty60 vcs5 zram0 radxazero: ~ $ cat /boot/ext*/ext* label default kernel ../Image initrd ../uInitrd fdtdir ../amlogic/ fdt ../amlogic/meson-g12a-radxa-zero.dtb fdtoverlays ../amlogic/overlays/meson-g12a-radxa-zero-gpio-8-led.dtbo ../amlogic/overlays/meson-g12-gxl-cma-pool-896MB.dtbo ../amlogic/overlays/meson-g12a-radxa-zero-uart-ee-c.dtbo ../amlogic/overlays/meson-g12a-radxa-zero-uart-ao-b-on-gpioao-8-gpioao-9.dtbo append earlyprintk console=tty1 console=ttyAML0,115200n8 console=both rw root=PARTUUID=2c552180-02 rootwait rootfstype=xfs fsck.repair=yes loglevel=1 net.ifnames=0 no_console_suspend init=/sbin/init

I'm not 100% on this, but I don't believe there is an easy way to change the order as its hard coded now. Maybe someone else knows better?

It is more than likely a u-boot issue caused by a specific patch; https://github.com/armbian/build/blob/main/patch/u-boot/v2022.10/meson64-boot-usb-nvme-scsi-first.patch https://github.com/armbian/build/blob/main/config/boards/radxa-zero.conf#L17 You would need to build u-boot with this patch disabled, flash it to the unit and see if it solves the problem.

These are my available options / resolutions with the current display I have plugged into it. cat /sys/class/drm/card1-HDMI-A-1/modes 1280x720 1280x720 1280x720 1280x720 1280x720 800x600 800x600 800x600 800x600 720x576 720x576 720x576 720x480 720x480 720x480 640x480 640x480 See what you have available.

The answer is, no. This might be the case on the bsp kernel, but not on mainline. Sure they have a lot in common, but by no means is it the same unit.

Wifi and bluetooth should work out of the box. You also appear to be using the wrong img; 591 Thu Aug 31 03:17:42 PM UTC 2023 | Banana Pi M2S | 23.8.1 | arm64 | aarch64 | 6.1.50-current-meson64 14736 fdtfile=amlogic/meson-g12b-a311d-bananapi-m2s.dtb Aren't you using a CM4?

You should not have these overlays enabled; g12a-radxa-zero-gpio-10-led sm1-bananapi-rtl8822cs