Raspberry Pi 3 B+ incompatibilities

[jcberthon]

I was trying to use your build image from January 2018 on my Raspberry Pi 3 B+.

Simply putting the image on a USB stick and trying it did not work. I see the red LED, then the green LED blink, and then the green LED enter a loop state with 4 long pulse followed by 4 short pulse.

I've tried to edit the config.txt file to change the device tree entry to bcm2837-rpi-3-b-plus.dtb and duplicated the existing bcm2837-rpi-3-b.dtb as bcm2837-rpi-3-b-plus.dtb (simply cp to the new name), as suggested for Fedora 28 beta. But I end up in the same error.

I wanted to regenerate the image because perhaps the uboot needs an update, but I do not manage to build it on my platform (see #11). Would you have any advice on how to proceed?

[stapelberg]

You’ll need version 1.20180316-3 or newer of the https://packages.debian.org/sid/raspi3-firmware package. You can simply extract that package and copy the files to the first partition of the image after writing it to an SD card.

Note that while this makes the device boot, there is some (intermittent?) trouble with the network interface, hence I haven’t uploaded a new image yet.

[jcberthon]

I've seen your issue on the Raspberry Pi firmware project about the LAN device.

Thanks for the tip with the newer firmware!

I will for the time being install Raspbian and wait for this issue to be solved. I would like this RPi to be a DHCP/DNS server, so if the ethernet port is not working great that's a bit of a problem ;-)

[stapelberg]

Let’s keep this open until we have a new image out which works on the B+

[plugwash]

My experiance on the b+

I was able to get it to boot by manually updating the firmware files, specifically copying start*.elf fixup*.dat and bootcode.bin from https://github.com/raspberrypi/firmware . I also had to use hdmi_force_hotplug=1 to make it see my monitor but that is an issue with the kvm switch I use.

Unfortunately I was not able to get a working network, the onboard Ethernet wouldn't see a link at all. I then tried an asix based USB hub with Ethernet, that saw the link but I got errors about USB resources when I tried to actually bring it up.

[st-ashcroft]

The 4.16 kernel which is currently in experimental makes the onboard ethernet work.

https://packages.debian.org/experimental/arm64/linux-image-4.16.0-trunk-arm64-unsigned/download

The critical patch appears to be:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/drivers/net/usb/lan78xx.c?h=v4.16&id=e69647a19c870c2f919e4d5023af8a515e8ef25f

Unfortunately the MAC address assigned appears to be random and the LEDs don't work.
The raspberry pi kernel has additional patches to allow those settings to be passed via device tree but those have not hit an upstream kernel yet. However, they are in net-next so should get there in the end.

[stapelberg]

Unfortunately the MAC address assigned appears to be random and the LEDs don't work.
The raspberry pi kernel has additional patches to allow those settings to be passed via device tree but those have not hit an upstream kernel yet. However, they are in net-next so should get there in the end.

For the record, https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/drivers/net/usb/lan78xx.c?id=760db29bdc97b73ff60b091315ad787b1deb5cf5 is the commit in question.

Unfortunately, 4.17-rc5 doesn’t carry the patch (see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/net/usb/lan78xx.c?h=v4.17-rc5), so possibly 4.18 will be the first usable upstream kernel (unless we decide to go with patches in the interim).

[widar]

Ethernet works like a charm with 4.18.0-rc2.
BTW, does anyone know why bcm2837-rpi-3-b-plus.dtb only seems to work when renamed to bcm2710-rpi-3-b-plus.dtb? Is that a bootloader quirk?

[jlu5]

I managed to get Debian working on a RPi 3 B+ after a fair bit of tinkering: https://code.overdrivenetworks.com/blog/2018/07/03/debian-buster-on-a-raspberry-pi-3-model-b-plus/

Here are my general takeaways, which I hope might help anyone else trying to set this up:

• raspberrypi/firmware and the official Linux sources ship different .dtb files, and it seems these shouldn't be mixed (it caused a boot failure for me at least). With a mainline kernel using the .dtb at arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b-plus.dtb in the kernel source worked, while bcm2710-rpi-3-b-plus.dtb from raspberrypi/firmware worked OK with a custom build of the raspberrypi kernel fork.
• USB, HDMI video, and Ethernet just about worked out of the box, though I had a minor issue with the default firewall provided in the the image (the -m comment module for iptables didn’t load with my custom kernel for some reason, causing ifup to fail).
• HDMI audio required adding dtparams=audio=on to config.txt
• For the Wi-Fi driver to load I needed to copy brcmfmac43455-sdio.txt (NVRAM config file) from the RPi-Distro/firmware-nonfree repository into /lib/firmware/brcm/, since Debian does not ship it in firmware-brcm80211. Similar bugs are https://bugs.debian.org/844056 and https://bugs.debian.org/797779, which affect other models that basically load the driver in the same way
• I had issues with Xorg showing only a cursor on startx and crashing a few seconds later. dmesg showed me errors like “vc4: Failed to allocate from CMA”, which I worked around by adding cma=256M to cmdline.txt

In order to run a custom kernel I purged raspi3-firmware so that it wouldn't overwrite config.txt. This is probably less necessary as 4.18.x is in experimental now, though I've heard that the arm64 build is actually failing atm.

[chschlue]

raspberrypi/firmware and the official Linux sources ship different .dtb files, and it seems these shouldn't be mixed (it caused a boot failure for me at least). With a mainline kernel using the .dtb at arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b-plus.dtb in the kernel source worked, while bcm2710-rpi-3-b-plus.dtb from raspberrypi/firmware worked OK with a custom build of the raspberrypi kernel fork.

Mine works with the vanilla bcm2837-rpi-3-b-plus.dtb but does not boot with the Raspi-dtb.

[...] issue with the default firewall provided in the the image (the -m comment module for iptables didn’t load with my custom kernel for some reason, causing ifup to fail).

There is an open pull request to replace iptables in the default install, the current solution appears needlessly convoluted to me anyway.

HDMI audio required adding dtparams=audio=on to config.txt

Worked out of the box for me.

For the Wi-Fi driver to load I needed to copy brcmfmac43455-sdio.txt [...]

Same here.

worked around by adding cma=256M to cmdline.txt

Same. Kodi even seems to need cma=512M, else vc4 crashes after some time.

This is probably less necessary as 4.18.x is in experimental now, though I've heard that the arm64 build is actually failing atm.

It compiles fine apparently, there just seem to be duplicate modules in -di packages.

[chschlue]

In order to run a custom kernel I purged raspi3-firmware so that it wouldn't overwrite config.txt.

The raspi3-firmware package needs to be updated.
/etc/kernel/postinst.d/raspi3-firmware should allow for configuration of cma and such, maybe through /etc/default/raspi3-firmware or something. Also brcmfmac43430-sdio.txt is in the package source but not in the package.

Either I am to stupid to find the current source repo or the migration from Alioth to Salsa isn't finished yet.

[bioxz]

Hey, I've got my Pi 3 B+ today and went directly for Debian arm64. After changing this build to fetch the latest 4.18 kernel from experimental (rc5) I was able to boot and connect via ssh, USB and HDMI video are also working fine.

But what exactly do I have to do to get audio working at all? I'm quite confused where the problem is. Do I need a newer raspy3-firmware package? A different dtb file? Do I just have to modprobe a missing module?

Also I read I have to add dtparams=audio=on to the /boot/config.txt, while I only have a /boot/firmware/config.txt and changes to that file seem to be gone after a second reboot (and audio still isn't working).

aplay -l   
**** List of PLAYBACK Hardware Devices ****
card 0: vc4hdmi [vc4-hdmi], device 0: MAI PCM vc4-hdmi-hifi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

[chschlue]

Are you lacking HDMI audio or analog audio?
In any case, as long as you are using a Debian kernel, dtparams have nothing to do with it as the accompanying DT blobs don't use parameters.
/boot/firmware/config.txt gets rewritten every time you install a kernel image, basically because there isn't much to configure outside of Raspbian.

[bioxz]

In any case, as long as you are using a Debian kernel, dtparams have nothing to do with it as the accompanying DT blobs don't use parameters.

Ah, that's good to know. Every tutorial in the internet seems to assume that you're running raspbian without ever mentioning it.

Are you lacking HDMI audio or analog audio?

I seem to be missing both output devices. There is only that vc4hdmi card in alsa which didn't seem to work. When I try to use aplay or speaker-test, I get this message:

ALSA lib pcm_direct.c:1193:(snd1_pcm_direct_initialize_slave) requested or auto-format is not available
ALSA lib pcm_dmix.c:1111:(snd_pcm_dmix_open) unable to initialize slave

For now I only want to get the HDMI output working.

[chschlue]

Are you sure this isn't a configuration problem, like PulseAudio blocking ALSA?
VC4 is apparently working correctly, otherwise you wouldn't have HDMI video either, and the same module also manages audio.

[bioxz]

I don't have pulseaudio installed, just alsa (libasound2, alsa-utils). I can see that some modules for audio are loaded

snd_soc_core          180224  1 vc4
snd_pcm_dmaengine      16384  1 snd_soc_core
snd_pcm               106496  3 vc4,snd_soc_core,snd_pcm_dmaengine
snd                    81920  3 snd_timer,snd_soc_core,snd_pcm
soundcore              16384  1 snd

and there is a device showing as posted above. But when I open alsamixer, there are no controls. It might be a stupid configuration mistake on my side, maybe I forgot to install something that is required? Alsa can see a device, but there doesn't seem to be any output sinks in it.

[chschlue]

Please try playing white noise with a supported sample rate, e.g.
aplay -c 2 -r 48000 /dev/urandom

[bioxz]

That brings me to the same error:

# aplay -c 2 -r 48000 /dev/urandom                                                                                                                                                                                                                         
ALSA lib pcm_direct.c:1193:(snd1_pcm_direct_initialize_slave) requested or auto-format is not available
ALSA lib pcm_dmix.c:1111:(snd_pcm_dmix_open) unable to initialize slave
aplay: main:828: audio open error: Invalid argument

I tried it as root and as a user in the audio group, the output is the same. Do you have manually created a asoundrc?

Edit: I got some sounds out of my system. I added this .asoundrc

pcm.!default {
        type hw
        card 0
}

ctl.!default {
        type hw
        card 0
}

and got a different error, saying I'm using a unsupported format. With
aplay -c 2 -f IEC958_SUBFRAME_LE -r 48000 /dev/urandom
I finally got some sounds. I think this could have something to do with my problems: https://patchwork.kernel.org/patch/9600017/.

tl;dr: I could say my problem is solved. It has nothing to do with arm64 or such, it's just that ALSA can't do the steps necessary to convert the audio to IEC958_SUBFRAME_LE. With pulseaudio, you just skip that problem as pulseaudio is handling such conversions. So HDMI sound is running fine, but not with bare metal ALSA. Maybe this information should be added somewhere, as pulseaudio isn't in the build by default and other people might end with this problem.

[st-ashcroft]

I think it really is an issue with the driver: # dmesg | grep vc4 [ 8.447485] vc4_hdmi 3f902000.hdmi: ASoC: Failed to create component debugfs directory [ 8.462766] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-> 3f902000.hdmi mapping ok [ 8.479599] vc4_hdmi 3f902000.hdmi: ASoC: no DMI vendor name! [ 8.490586] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4]) [ 8.500857] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4]) [ 8.510764] vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4]) [ 8.520592] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 8.530974] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 8.541256] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 8.575488] vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops [vc4]) [ 8.584670] fb: switching to vc4drmfb from simple [ 8.600493] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0 [ 8.675829] vc4-drm soc:gpu: fb0: frame buffer device [ 57.309661] vc4_hdmi 3f902000.hdmi: ASoC: can't open interface 3f902000.hdmi: -19 That last line will be repated for every attempt to play sound.

[gwolf]

FWIW - I have held off producing a new image until I get some important issues ironed out - Most important, getting the wireless interface working.
I will be uploading today the raspi3-firmware 20180619, for which at least my eth0 interface works reliably (using the 4.18 kernel, currently in experimental only). I am still trying to get the wireless working...

[bioxz]

For those who didn't notice, since a few days the 4.18 kernel went into unstable. Changing my current installation to the linux-image-arm64 meta-package from unstable went fine, the new current package is linux-image-4.18.0-1-arm64 (which is 4.18.6).

For new installations experimental won't be needed anymore, the kernel can be installed via

apt install -t unstable linux-image-arm64

Maybe there are some relevant fixes in the new version.

https://tracker.debian.org/news/985488/accepted-linux-4186-1-all-source-into-unstable-unstable/

[perezmeyer]

FWIW: as bioxz says the kernel landed in unstable. I reverted HEAD and built the image. It boots, but hangs for me in "random: crng init done"

I'm trying now building the image with haveged in it.

[LorenzoAncora]

[...] hangs for me in "random: crng init done"

@perezmeyer happened to me too on a Raspberry Pi 3 B.
I've resolved by editing config.txt to match the version of the initial ramdisk with the version of the loaded kernel.

[perezmeyer]

I'm trying now building the image with haveged in it.

Or mounting the SD card and do the right foo to install it, but no changes I'm afraid.

[perezmeyer]

[...] hangs for me in "random: crng init done"

@perezmeyer happened to me too on a Raspberry Pi 3 B.
I've resolved by editing config.txt to match the version of the initial ramdisk with the version of the loaded kernel.

Thanks! But in my case it seems to match what I have in the boot partition:

kernel=vmlinuz-4.18.0-1-arm64
initramfs initrd.img-4.18.0-1-arm64

[LorenzoAncora]

I've resolved by editing config.txt to match the version of the initial ramdisk with the version of the loaded kernel.

Thanks! But in my case it seems to match what I have in the boot partition

@perezmeyer wait an hour and then press ENTER: if it does nothing, you found a known bug. :-(

• You should still have the previous ramdisk: replace the new version number with the previous one and boot.
• Other Raspberry Pi users have told me about strange waiting on boot that can last up to two hours when you install a new kernel. One possible explanation is that these devices have difficulty collecting entropy and this can cause a strong lag during boot, probably due to the lack of components suitable for collecting random values. One solution is to install haveged.

[jlu5]

@licaon-kter I've experimented with using the Raspbian kernel on a Debian userland with mixed results... Things got a bit out of sync in the matter of months: iptables broke with the nftables migration and more even recently, my Ethernet link disappeared! (In other words, I wouldn't vouch for the stability of such a setup...)

I want to try 4.18 again some time, but having an always hot Pi is not that great either :(

[mbien]

I updated to 4.19.0-1-arm64 from the buster repository (updated all other packages too, including raspberry firmware) and everything seems to be working fine so far.

Had to fix the cmdline.txt since it overwrote it to boot from SD card (i am booting via USB). And it also removed the device tree property from config.txt. But this doesn't seem to be needed anymore since it seems to work fine now (with and without the property). Although i only use network and USB.

so i am wondering, is copying the file and setting device_tree=bcm2837-rpi-3-b-plus.dtb still recommended?

another question: since the mainline kernel can't change the CPU frequency yet as mentioned in this thread before, i am wondering what frequency the Pi3 B+ is running on when nothing is configured. I haven't found a way to query the freq values.

[licaon-kter]

@mbien

what frequency the Pi3 B+ is running on when nothing is configured

https://www.raspberrypi.org/documentation/hardware/raspberrypi/frequency-management.md

FYI, I'm running the Raspbian kernel + nf_table modules and it's ok, downclocks to 600MHz as needed.

[mbien]

@mbien

what frequency the Pi3 B+ is running on when nothing is configured

https://www.raspberrypi.org/documentation/hardware/raspberrypi/frequency-management.md

FYI, I'm running the Raspbian kernel + nf_table modules and it's ok, downclocks to 600MHz as needed.

well yes. You would need the raspbian kernel for it to be working - thats what i assumed. I am running debian buster + mainline.

[mbien]

after a few days uptime i am getting the following msg in the kernel log as my USB drive disconnects.

Jan 21 03:14:38 kernel: [ 3181.031839] dwc2 3f980000.usb: dwc2_hc_chhltd_intr_dma: Channel 7 - ChHltd set, but reason is unknown
Jan 21 03:14:38 kernel: [ 3181.041577] dwc2 3f980000.usb: hcint 0x00000002, intsts 0x04600029

Jan 21 08:47:12 kernel: [23134.804744] dwc2 3f980000.usb: dwc2_hc_chhltd_intr_dma: Channel 1 - ChHltd set, but reason is unknown
Jan 21 08:47:12 kernel: [23134.814469] dwc2 3f980000.usb: hcint 0x00000002, intsts 0x04600029

Jan 21 14:43:44 kernel: [44526.562061] dwc2 3f980000.usb: dwc2_hc_chhltd_intr_dma: Channel 0 - ChHltd set, but reason is unknown
Jan 21 14:43:44 kernel: [44526.571787] dwc2 3f980000.usb: hcint 0x00000002, intsts 0x04600029

Jan 21 16:51:39 kernel: [52202.131084] dwc2 3f980000.usb: dwc2_hc_chhltd_intr_dma: Channel 4 - ChHltd set, but reason is unknown
Jan 21 16:51:39 kernel: [52202.140810] dwc2 3f980000.usb: hcint 0x00000002, intsts 0x04600029

the USB drive has the OS and swap on it so i don't get any more logs (system halts obviously). Sometimes there is a day between a channel message, but after 4 channels break, its over.

anyone else seeing something like this in their logs?

I assume the dwc2 USB driver is part of the mainline kernel. I checked my old Pi2 with raspbian and it is using a custom "dwc_otg" driver. (however after searching a bit i found that you can apparently use dwc2 too if you set a flag https://raspberrypi.stackexchange.com/questions/77059/what-does-dtoverlay-dwc2-really-do )

uname -a
Linux 4.19.0-1-arm64 #1 SMP Debian 4.19.12-1 (2018-12-22) aarch64 GNU/Linux

edit: fixed formatting

[schubter]

after a few days uptime i am getting the following msg in the kernel log as my USB drive disconnects.

Jan 21 03:14:38 kernel: [ 3181.031839] dwc2 3f980000.usb: dwc2_hc_chhltd_intr_dma: Channel 7 - ChHltd set, but reason is unknown
Jan 21 03:14:38 kernel: [ 3181.041577] dwc2 3f980000.usb: hcint 0x00000002, intsts 0x04600029

Jan 21 08:47:12 kernel: [23134.804744] dwc2 3f980000.usb: dwc2_hc_chhltd_intr_dma: Channel 1 - ChHltd set, but reason is unknown
Jan 21 08:47:12 kernel: [23134.814469] dwc2 3f980000.usb: hcint 0x00000002, intsts 0x04600029

Jan 21 14:43:44 kernel: [44526.562061] dwc2 3f980000.usb: dwc2_hc_chhltd_intr_dma: Channel 0 - ChHltd set, but reason is unknown
Jan 21 14:43:44 kernel: [44526.571787] dwc2 3f980000.usb: hcint 0x00000002, intsts 0x04600029

Jan 21 16:51:39 kernel: [52202.131084] dwc2 3f980000.usb: dwc2_hc_chhltd_intr_dma: Channel 4 - ChHltd set, but reason is unknown
Jan 21 16:51:39 kernel: [52202.140810] dwc2 3f980000.usb: hcint 0x00000002, intsts 0x04600029

the USB drive has the OS and swap on it so i don't get any more logs (system halts obviously). Sometimes there is a day between a channel message, but after 4 channels break, its over.

anyone else seeing something like this in their logs?

I assume the dwc2 USB driver is part of the mainline kernel. I checked my old Pi2 with raspbian and it is using a custom "dwc_otg" driver. (however after searching a bit i found that you can apparently use dwc2 too if you set a flag https://raspberrypi.stackexchange.com/questions/77059/what-does-dtoverlay-dwc2-really-do )

uname -a
Linux 4.19.0-1-arm64 #1 SMP Debian 4.19.12-1 (2018-12-22) aarch64 GNU/Linux

edit: fixed formatting

strangly i have the same issue on one pi 3b+ rev 1.3
all together i have 4 raspberry pi 3b+ rev 1.3 running with the same buster image, all booting from usb and are connected via ethernet. 3 are up and running for almost 3 weeks while one of them is having the same dwc2 errors until a deadlock happens.

i've loaded on a different stick an libreelec and this thing runs without issue

[ammoniak]

ATM, I need to run Debian with a Raspbian kernel because of the hardware supported. F.ex. my touch display is only working with a Raspbian kernel 4.14.y using bcmrpi3_defconfig. The problem seems to be device tree related, but I don't have much experience in debugging device tree issues so far.
…
On 2018/11/05 21:31, widar wrote: Why would you want to run Debian with a Raspbian kernel or vice versa? Kareema0 @.> schrieb am Mo., 5. Nov. 2018 um 14:24 Uhr: > @chschlue https://github.com/chschlue : > > You can also just rename it to bcm2710-rpi-3-b-plus.dtb and the bootloader > will load it automatically. > A proposed fix to have raspi3-firmware take care of that is here > https://salsa.debian.org/debian/raspi3-firmware/merge_requests/2 > > Just a remark to the proposed fix - but I'm new to the Raspberry Pi, so a > could be wrong: > > It's the default for the Raspbian bootloader to use the bcm27 device tree > files, if not overridden by device_tree in config.txt. This is because the > bcm27 device tree files correspond to their upstream kernel (which is used > in Raspbian) while the bcm28 device tree files correspond to the > downstream kernel (which we use in the Debian image). > > For most people, the proposed fix may be a good idea, to get the image > working "out of the box". But for people using both, upstream and > downstream kernel with the corresponding device tree, this fix will cause a > mess. So far you can install both kernels with their device tree alongside > and point to the right device tree via the config.txt. But after this fix, > the upstream device tree files will get overwritten. And you can no longer > distinguish the device tree files (upstream or downstream) by name. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#12 (comment)>, > or mute the thread > https://github.com/notifications/unsubscribe-auth/AAtj1F0CZkOoeavn3-7XJwe5Vji0dMH3ks5usDwTgaJpZM4S58OO > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#12 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/AGsODGJSKnNjYwVFqBessN5ygyQ3rs-Fks5usKAfgaJpZM4S58OO.

same here, the touch screen it self works, but I can't get the X11/Xorg configuration to work.

[mbien]

strangly i have the same issue on one pi 3b+ rev 1.3
all together i have 4 raspberry pi 3b+ rev 1.3 running with the same buster image, all booting from usb and are connected via ethernet. 3 are up and running for almost 3 weeks while one of them is having the same dwc2 errors until a deadlock happens.

i've loaded on a different stick an libreelec and this thing runs without issue

after reading your reply i decided to try a different SSD USB adapter (from a different vendor) but with no luck, it only took a few hours with the new adapter until i got the first two msgs in the kernel log. (Maybe i am unlucky and both vendors use the same hardware but i don't think this is likely - one is externally powered and universal, the other is not)

not quite sure how to proceed from here. As i understand it dwc2 is part of the mainline kernel and raspbian maintains a different driver called dwc_otg. Assuming this issue does not happen on dwc_otg getting it to run with a mainline kernel is probably not trivial. I might have to give up here and just run raspbian :(

[licaon-kter]

@mbien or, keep the distro but compile only the Raspbian kernel, less hassle imho.

[schubter]

strangly i have the same issue on one pi 3b+ rev 1.3
all together i have 4 raspberry pi 3b+ rev 1.3 running with the same buster image, all booting from usb and are connected via ethernet. 3 are up and running for almost 3 weeks while one of them is having the same dwc2 errors until a deadlock happens.
i've loaded on a different stick an libreelec and this thing runs without issue

after reading your reply i decided to try a different SSD USB adapter (from a different vendor) but with no luck, it only took a few hours with the new adapter until i got the first two msgs in the kernel log. (Maybe i am unlucky and both vendors use the same hardware but i don't think this is likely - one is externally powered and universal, the other is not)

not quite sure how to proceed from here. As i understand it dwc2 is part of the mainline kernel and raspbian maintains a different driver called dwc_otg. Assuming this issue does not happen on dwc_otg getting it to run with a mainline kernel is probably not trivial. I might have to give up here and just run raspbian :(

i recently ordered a new pi and this one runs without issue, a few days ago i've rebuild an image and put it on the pi that was crashing constantly which is now running perfectly fine. not sure what's different other then the build dates. i haven't checked yet if there is a new kernel.

[gwolf]

Great news — I just built an image with today's Buster, and the wireless works! :-D

[OneTinSoldier66]

Hello,

I’m using a Raspberry Pi 3 B+ Rev. 1.3. I downloaded the 20190206(with linux-image-4.19.0-2) image, checked it with the “sha256 -c” command, then wrote the image to a microSD card. When I boot it up it seems to get pretty far into the boot up process, but then I get a kernel panic. After sitting there for a few minutes it then spits out a stack(?) trace.

I don’t know what to do about that, but I wanted to let someone know in case it helps. I can try to give whatever info that might be helpful.

[madler]

As a counter-example, I just put the Feb 6 image on my RPi 3B+, and it booted like a champ. (Thank you gwolf!)

[OneTinSoldier66]

@madler Nice. I suppose I did something wrong but I'm not sure. Did you ssh into it? Or did you boot up to a console login prompt on a screen?

[gwolf]

@OneTinSoldier66, please confirm your image was correctly downloaded (check the SHA256 matches, https://people.debian.org/~gwolf/raspberrypi3/20190206/20190206-raspberry-pi-3-buster-PREVIEW.img.xz.sha256.asc ; follow https://wiki.debian.org/RaspberryPi3 if you need help to do it.
Make sure you followed the process to call dd. Also, try to do this from a different SD card, in case yours has some kind of problem. Please report!

[OneTinSoldier66]

@gwolf

EDIT: It’s working fine now. I have a login prompt on-screen now after using a different SD card. Maybe it was a bad microSD card but I’m going to try it again since it’s a brand new one.

Thank you!

————————————————

As I stated in my original post, the sha256 checksum matched when I first checked it.

With the same files still on my hard drive, I booted up my PC, ran the sha256 checksum again and it reported back ‘OK’ just like it did when I ran it yesterday. Then I took out a different microSD card, deleted all partitions on it, and then I ran the dd command to extract and write the 20190206 image onto it --> xzcat 20190206-raspberry-pi-3-buster-PREVIEW.img.xz | dd of=/dev/sdb bs=64k oflag=dsync status=progress

Is there anything else I need to do before trying to boot with it? I would like to boot up to a console login screen, on the monitor that I have hooked up to the Raspberry Pi. I’m not trying to ssh in over a network.

[SuperSandro2000]

@jlu5 I am the guy you linked months ago that noticed that iptables and ufw is broken.
freeipmi is broken, too btw.

Edit: That solves the ufw/iptables problems. Not ideal but it works.

 sudo update-alternatives --set iptables /usr/sbin/iptables-legacy
 sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy

then sudo reboot, sudo ufw enable.

[softdream1981]

@jlu5 I am the guy you linked months ago that noticed that iptables and ufw is broken.
freeipmi is broken, too btw.

Edit: That solves the ufw/iptables problems. Not ideal but it works.

 sudo update-alternatives --set iptables /usr/sbin/iptables-legacy
 sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy

then sudo reboot, sudo ufw enable.

Work for me!

[SuperSandro2000]

Still I wouldn't recommend it for production use.

[mbien]

ip tables is basically deprecated in modern linux. Debian buster is transitioning to nftables. Newer kernels already use the netfilter module and emulate iptables on top via the userspace programs.

If you have problems with iptables it can be that the userspace programs no longer fit to the kernel interface. Both iptables and ip6tables userspace programs are replaced by "nft".

Make sure that you are not using both at the same time.

more info:
https://wiki.debian.org/nftables
https://wiki.archlinux.org/index.php/Nftables

[SuperSandro2000]

I am only using it with ufw and that is probably not updated.

[Vincent14]

nftables is the way to go now, if you hare to create a new set of configuration there is no reason to use iptables.

You can revert previous commands with:

update-alternatives --set iptables /usr/sbin/iptables-nft
update-alternatives --set ip6tables /usr/sbin/ip6tables-nft

[SuperSandro2000]

@Vincent14 I am glad that you understand my issue. Ufw is totally going work with nftables currently. Not.

If Ubuntu had proper hardware accerlation and would be more up to date then I would never ever use that Debian piece of dinosaur named Raspian. Basically everything I want to do requires me to get pre compiled binaries somewhere else or wait an hour for the Pie to compile them.

[Vincent14]

The problem is nftables is broken on Raspbian Buster raspberrypi/linux#2177 (reference) (just see it from few minutes)

[SuperSandro2000]

Well. Didn't expect anything else really.

[SuperSandro2000]

Building an image with the official building Repo https://github.com/RPi-Distro/pi-gen seems to work very good. UFW works. I am still going to ubuntu.

[gwolf]

This issue has conflated too many different issues - Some of them remain open, some of them are long closed. But as a way to track something specific, this issue is too long and no longer useful ☹
I am closing the issue now. Please, feel free to open new issues with specific issues, requiring less than a year worth of comments to understand!