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?

[mbien]

just a heads up: if i upgrade the package udev the Pi does not boot anymore from USB. It gets stuck when it tries to mount the raspbiroot partition. Haven't investigated any further, just excluding the package for now.

details: libudev1/testing 239-11 arm64 [upgradable from: 239-10] udev/testing 239-11 arm64 [upgradable from: 239-10]

[st-ashcroft]

The fix to get wifi support working in a 4.18 kernel is to revert the following:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/bcm2835-rpi.dtsi?id=b0c07c5af6d286f3d3b907743998e9d41f6ab042

commit.

I figured this out by using dtc to turn the working dtb files back into dts and then using diff. I wish I knew more about devicetree and what the original commit was trying to do.

[licaon-kter]

Is the missing /sys/devices/system/cpu/cpu*/cpufreq/ folder a known thing?

Even at idle it stays at 60deg C, I'm thinking that it never changes the frequency, but I can't check it.

cpufreq_powersave module is loaded.

[gwolf]

Licaon_Kter dijo [Tue, Dec 18, 2018 at 06:43:06AM -0800]:

Is the missing /sys/devices/system/cpu/cpu*/cpufreq/ folder a known thing?

Even at idle it stays at 60deg C, I'm thinking that it never changes the frequency, but I can't check it.

cpufreq_powersave module is loaded.

I don't know if it should be available - ARM systems are quite different from x86 ones. I just checked on my Cubox-i (i.MX6 quad, ARMv7/ARM32, Debian Stretch, 4.9.0-8, armhf), it also does not present the mentioned directory.

But, on x86, CPUs often have different running speeds. In the ARM world, that's not always the case. The Raspberry configures clock speed as a boot parameter, as "arm_freq" in the boot partition's config.txt. You can also install cpufrequtils, and use cpufreq-set / cpufreq-info, but TTBOMK it does not have much of an effect:

root@cubox『18』~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: no or unknown cpufreq driver is active on this CPU maximum transition latency: 0.00 ms. analyzing CPU 1: no or unknown cpufreq driver is active on this CPU maximum transition latency: 0.00 ms. analyzing CPU 2: no or unknown cpufreq driver is active on this CPU maximum transition latency: 0.00 ms. analyzing CPU 3: no or unknown cpufreq driver is active on this CPU maximum transition latency: 0.00 ms. root@cubox『19』~# cpufreq-aperf CPU doesn't support APERF/MPERF

[gwolf]

Gunnar Wolf dijo [Tue, Dec 18, 2018 at 02:53:34PM -0600]:

I don't know if it should be available - ARM systems are quite different from x86 ones. I just checked on my Cubox-i (i.MX6 quad, ARMv7/ARM32, Debian Stretch, 4.9.0-8, armhf), it also does not present the mentioned directory.

Then again, you might want to refer to this page:

https://haydenjames.io/raspberry-pi-3-overclock/

[jlu5]

AFAIK cpufreq and thermal have not been upstreamed yet and are only in the RPi kernel right now? https://elinux.org/RPi_Upstreaming#Status

[licaon-kter]

I don't know if it should be available - ARM systems are quite different from x86 ones.

RPi1B w/ Raspbian has it.

@jlu5 Looks like it`s at the bottom of some TODO, if ever: https://lists.infradead.org/pipermail/linux-rpi-kernel/2018-April/

That's unfortunate.

One solution would be to compile their kernel for arm64 https://github.com/raspberrypi/linux then?

[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 https://github.com/raspberrypi/linux/issues/2177#ref-issue-415030094 (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!