Go figure, now I can not make it fail. So ignore this mess, sorry for the false alarm.
My guess is interference from somewhere. Even your monitor can cause interference.
One big Please. On every occasion where the config,txt file is overwritten, (kernel rc update, or even first boot) hdmi_drive=2 is preconfigured. I’m using DVI monitor and, normally, booting to black screen. So, I must change it on another system. If you just comment that line both tv users or dvi users can boot and further changes are easy. Thanx.
I got back to the office and hooked things back up and lo and behold, the error is back! I fiddle with stuff and it turns out that if I replace the Apple keyboard with a Logitech keyboard, the SSD works again. Odd that a device on the USB 2.0 controller causes an issue on the the USB 3.0 controller. But I am not a Electrical Engineer, so who knows. And I have used this keyboard on this same RPi4 since I began working with them, very weird.
Edit: Then I remembered that I loaned out the USB extension cable that comes with the keyboard. I hunt down a replacement and hook it up… and now the RPI4 will boot with both the Apple keyboard and the SSD once again.
Just wanted to update the raspberrypi/firmware repository had an issue which caused PoE hat fans to stop working recently (around mid jan) Rpi PoE hat goes brrrrr on Rpi 4b · Issue #1531 · raspberrypi/firmware · GitHub
They’ve fixed the issue with this commit kernel: Bump to 5.10.14 · raspberrypi/firmware@f11bc13 · GitHub
As I mentioned above I was holding back the latest 2 raspberrypi-bootloader packages as it broke bluetooth. I told them and they responded with a confusing answer which took me a couple of days to figure out what they meant and at the same time I was having to put out some other fires:
“The only change vaguely UART-related - at least on the firmware side - in the last week or so is the removal of the code that automatically converts an old cmdline.txt reference to ttyAMA0 to
ttyS0 in the event that
ttyS0 is the primary (console) UART. All new images for years have used “serial0” as an alias, and now all
cmdline.txts have to either do the same or get it write and use
Long story short I tried several combinations with cmdline.txt and the attach-bluetooth service. arch-arm uses ttyAMA0 in the /boot/cmdline.txt file and this has to be changed in 2 places in the file to have bluetooth:
console=ttyAMA0,115200 ==> console=serial0,115200 kgdboc=ttyAMA0,115200 ==> kgdboc=serial0,115200
The latest 2 raspberry-pi bootloader files has been pushed to the unstable branch when the mirrors sync. Be sure to make the 2 adjustments above in /boot/cmdline.txt to have bluetooth.
raspberrypi-bootloader 20210208-1 raspberrypi-bootloader-x 20210208-1
Did you make the changes in /boot/cmdline.txt I posted above?
From looking at the posted image, I think maybe he has the same issue I had… twice.
brcm_patchram at 100%
If he has blocked bluetooth in config.txt like you did that prevents brmcm_patchram from loading but that would be with any bootloader.
Oh, so not making the edits causes a similar looking issue. Good to know, because you know I will forget to edit also. And I would have tried to “fix it”, convinced I had the same issue again.
You would have been ok since you disabled attach-bluetooth.service and bluetooth.service.
Thanks Darksky I didn’t. But now, back to normal!
I’m really impress how well RPI4 works with latest kernel 5.11.0 RC6 on KDE release with KMS and Vulkan enabled.
last bootloader update, lost wifi connect.
does disable BT matter?
Wifi works here. Do you have crda installed and the Regulatory Domain set for your country.
BT matters to a lot of people. I personally like to use my BT headphones and also have internet backup by doing a bluetooth tether from my phone.
wifi work before last bootloader update.
does disable-bt matter wifi dead.
btw, test kernel-rc then audio dead.
All of the above works here. I am leaning towards some issue on your end with:
pi wifi router relationship and or config and the same with your sound with a config.
I got home and booted my unstable image, and it was minus the wifi device. I rolled back the linux-firmware and wifi was restored. Then reinstaleld the new linux-firmware, rebooted and wifi device was gone again. Rolled back again and the wifi device was back. So currently I am running on the previous version as I need wifi.
Not sure why I just now noticed this. Maybe I forgot to reboot after the update last night? Sorry I did not find this sooner.
Interesting that my wifi works on the stable branch. To be clear it was the linux-firmware package and not firmware-raspberrypi.
pacman -U linux-firmware-20201218.646f159-1-any.pkg.tar.xz
That is my exact roll-back command. There is no reference to wlan0 in dmesg or journalctl -b with the new linux-firmware installed.
I just found that dracut is indeed passing a kernel command line, and it is my old one. So I am investigating that. But I don’t think the cmdline.txt changes has any effect on the wifi.
$ cat /boot/cmdline.txt
root=LABEL=MNJRO_ROOT rw rootfstype=btrfs rootwait console=serial0,115200 console=tty1 selinux=0 plymouth.enable=0 smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 kgdboc=serial0,115200 usbhid.mousepoll=8 snd-bcm2835.enable_compat_alsa=0 audit=0 usb-storage.quirks=152d:1561:u
$ cat /proc/cmdline
coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 video=HDMI-A-1:1920x1080M@60 smsc95xx.macaddr=DC:A6:32:C1:E1:C7 vc_mem.mem_base=0x3eb00000 vc_mem.mem_size=0x3ff00000 root=LABEL=MNJRO_ROOT rw rootfstype=btrfs rootwait console=ttyAMA0,115200 console=tty1 selinux=0 plymouth.enable=0 smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 kgdboc=ttyAMA0,115200 usbhid.mousepoll=8 snd-bcm2835.enable_compat_alsa=0 audit=0 usb-storage.quirks=152d:1561:u
So I made the change to cmdline.txt, but dracut is biting me now.
I will boot my arm-testing and grab the new firmware and try that.
Edit: this will take a several minutes due to download time. But I wanted to say no Dracut on my arm-testing, so this will be a better test.