New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Raspberry Pi 3 B+ incompatibilities #12

Open
jcberthon opened this Issue Mar 24, 2018 · 52 comments

Comments

Projects
None yet
@jcberthon

jcberthon commented Mar 24, 2018

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

This comment has been minimized.

Contributor

stapelberg commented Mar 24, 2018

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

This comment has been minimized.

jcberthon commented Mar 25, 2018

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

This comment has been minimized.

Contributor

stapelberg commented Mar 26, 2018

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

@stapelberg stapelberg reopened this Mar 26, 2018

@plugwash

This comment has been minimized.

plugwash commented Apr 5, 2018

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

This comment has been minimized.

st-ashcroft commented Apr 20, 2018

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

This comment has been minimized.

Contributor

stapelberg commented May 14, 2018

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

This comment has been minimized.

widar commented Jun 28, 2018

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

This comment has been minimized.

jlu5 commented Jul 8, 2018

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

This comment has been minimized.

Contributor

chschlue commented Jul 9, 2018

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

This comment has been minimized.

Contributor

chschlue commented Jul 9, 2018

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

This comment has been minimized.

bioxz commented Aug 15, 2018

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

This comment has been minimized.

Contributor

chschlue commented Aug 16, 2018

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

This comment has been minimized.

bioxz commented Aug 16, 2018

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

This comment has been minimized.

Contributor

chschlue commented Aug 16, 2018

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

This comment has been minimized.

bioxz commented Aug 16, 2018

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

This comment has been minimized.

Contributor

chschlue commented Aug 16, 2018

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

@bioxz

This comment has been minimized.

bioxz commented Aug 16, 2018

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

This comment has been minimized.

st-ashcroft commented Aug 17, 2018

@gwolf

This comment has been minimized.

Member

gwolf commented Aug 27, 2018

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

This comment has been minimized.

bioxz commented Sep 9, 2018

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

This comment has been minimized.

perezmeyer commented Sep 21, 2018

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

This comment has been minimized.

LorenzoAncora commented Sep 21, 2018

[...] 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

This comment has been minimized.

perezmeyer commented Sep 21, 2018

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

This comment has been minimized.

perezmeyer commented Sep 21, 2018

[...] 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

This comment has been minimized.

LorenzoAncora commented Sep 21, 2018

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.
@perezmeyer

This comment has been minimized.

perezmeyer commented Sep 21, 2018

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. :-(

Or sends lots of keystrokes and mouse movements. That did not work either.

  • You should still have the previous ramdisk: replace the new version number with the previous one and boot.

No, I don't. Or should I?

  • 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.

Which I did. I'm afraid it does not changes anything :-(

@LorenzoAncora

This comment has been minimized.

LorenzoAncora commented Sep 21, 2018

You should still have the previous ramdisk: replace the new version number with the previous one and boot.

No, I don't. Or should I?

You should still have them if you have not removed the previous kernel via the package manager (an action you should never do, you should always have at least two kernels installed).
Check your /boot directory for vmlinuz and initrd files.

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

Or sends lots of keystrokes and mouse movements. That did not work either.

Useless. The last time it happened to me both keyboard and mouse did not receive current.
Wait an hour and then press ENTER to see if you can get a prompt. If you do not get a prompt you found a known bug and you need to use the previous kernel (+ initrd) to boot and then reconfigure the system.

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.

Which I did. I'm afraid it does not changes anything :-(

Install haveged, enable it (if possible via systemd) and then wait before rebooting.
Reason: haveged needs a lot of time to collect "true randomness".

PS: have you reduced the voltage of the Raspberry Pi? Did you overclock?

@perezmeyer

This comment has been minimized.

perezmeyer commented Sep 21, 2018

You should still have the previous ramdisk: replace the new version number with the previous one and boot.

No, I don't. Or should I?

You should still have them if you have not removed the previous kernel via the package manager (an action you should never do, you should always have at least two kernels installed).
Check your /boot directory for vmlinuz and initrd files.

Except that I created the image from scratch.

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

Or sends lots of keystrokes and mouse movements. That did not work either.

Useless. The last time it happened to me both keyboard and mouse did not receive current.

Oh, that does works for me, I can plug USB devices and see the kernel loading them. I can also hit ctrl+alt+del and "reboot" the Pi. So keyboard is working.

Wait an hour and then press ENTER to see if you can get a prompt. If you do not get a prompt you found a known bug and you need to use the previous kernel (+ initrd) to boot and then reconfigure the system.

Which I don't have :-) Note that I'm trying to solve the issue by creating a new image, not basing myself in previous versions.

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.

Which I did. I'm afraid it does not changes anything :-(

Install haveged, enable it (if possible via systemd) and then wait before rebooting.
Reason: haveged needs a lot of time to collect "true randomness".

Not my experience with other ARM based boards, but I'll just try.

PS: have you reduced the voltage of the Raspberry Pi? Did you overclock?

No, just created the image, loaded in the microSD and booted it.

@LorenzoAncora

This comment has been minimized.

LorenzoAncora commented Sep 21, 2018

Oh, that does works for me, I can plug USB devices and see the kernel loading them. I can also hit ctrl+alt+del and "reboot" the Pi. So keyboard is working.

So you're luckier than me! :-)
Use Alt + SysRq + 9-0 to set the debugging level of the console immediately after the boot (set it to verbose logging) and see what is really going on.
Once the possible error has been identified, edit the boot configuration: pass the init parameter to the kernel with the path of a working shell (bash), in order to directly start that shell and be able to check the system status. Then you can export the kernel ring buffer and the status of the device tree so that the kernel maintainers can detect the problem.

You should still have them if you have not removed the previous kernel via the package manager (an action you should never do, you should always have at least two kernels installed).
Check your /boot directory for vmlinuz and initrd files.

Except that I created the image from scratch.

So you've never been successful before and this is the first time you've tried installing a 64-bit kernel on your Raspberry Pi 3 B+?
I upgraded from two previous versions on the Raspberry Pi 3 B and everything went well.

PS: have you reduced the voltage of the Raspberry Pi? Did you overclock?

No, just created the image, loaded in the microSD and booted it.

Install haveged, enable it (if possible via systemd) and then wait before rebooting.
Reason: haveged needs a lot of time to collect "true randomness".

Not my experience with other ARM based boards, but I'll just try.

So you've had similar problems on other boards. Interesting: altered hardware can affect both the firmware and the OS.
Have you ever overclocked, downclocked or otherwise altered the hardware operating parameters of the boards that gave you problems (or of the Raspberry Pi B+)? Have you used standard power supplies recommended by the manufacturer?

@perezmeyer

This comment has been minimized.

perezmeyer commented Sep 21, 2018

So you're luckier than me! :-)

;-)

Use Alt + SysRq + 9-0 to set the debugging level of the console immediately after the boot (set it to verbose logging) and see what is really going on.
Once the possible error has been identified, edit the boot configuration: pass the init parameter to the kernel with the path of a working shell (bash), in order to directly start that shell and be able to check the system status. Then you can export the kernel ring buffer and the status of the device tree so that the kernel maintainers can detect the problem.

ACK, will do that.

[snip]

So you've never been successful before and this is the first time you've tried installing a 64-bit kernel on your Raspberry Pi 3 B+?

Right.

[snip]

Install haveged, enable it (if possible via systemd) and then wait before rebooting.
Reason: haveged needs a lot of time to collect "true randomness".

Not my experience with other ARM based boards, but I'll just try.

So you've had similar problems on other boards.

Right, but definitely not as bad as this one.

Interesting: altered hardware can affect both the firmware and the OS.
Have you ever overclocked, downclocked or otherwise altered the hardware operating parameters of the boards that gave you problems (or of the Raspberry Pi B+)?

No.

Have you used standard power supplies recommended by the manufacturer?

Adjustable DC power supplies with current limitation set at the board's specifications levels. I do this as my day job.

@LorenzoAncora

This comment has been minimized.

LorenzoAncora commented Sep 21, 2018

Install haveged, enable it (if possible via systemd) and then wait before rebooting.
Reason: haveged needs a lot of time to collect "true randomness".

Not my experience with other ARM based boards, but I'll just try.

So you've had similar problems on other boards.

Right, but definitely not as bad as this one.

Have you used standard power supplies recommended by the manufacturer?

Adjustable DC power supplies with current limitation set at the board's specifications levels. I do this as my day job.

Even if you are an expert, this is not a good practice. Unfortunately modern computers and SoCs are very sensitive to alterations in the power system.
The use of non-certified power supplies can cause anomalies in computers, including boards. These problems also affect software and can lead to system instability or corruption of user data. It does not matter if you are thinking of using quality power supplies: if you want to work stably and safely, you should use the hardware certified by the manufacturer.
Follow the official specification and if possible use the official power supply.
I know it's a nuisance, but before you can diagnose the software, make sure it's not a hardware problem (especially if the hardware is cheap as in this case).

[...]

ACK, will do that.

When you're done, enter the logs on a pastebin and post links here or send them directly to the kernel maintainers. If necessary, they will ask you for more logs or to execute a few more commands.
Be optimistic: you are doing a great favor to all users of the B + model and luck is favorable to good men.

Have a good time. :-)

@BClark09

This comment has been minimized.

BClark09 commented Oct 9, 2018

@perezmeyer, I had the same problem and I was able to get it to boot by changing root in cmdline.txt so that:

root=/dev/mmcblk0p2

I believe something of the sort was discussed in: #33

I also changed the labels back in fstab but am not sure if this is needed.

Hope that helps!

@perezmeyer

This comment has been minimized.

perezmeyer commented Oct 9, 2018

@BClark09 whatever it was regenerating the image (after reverting bf61a9b) did the trick.

@KaliszAd

This comment has been minimized.

KaliszAd commented Oct 11, 2018

Will there be a know good (unofficial) image again? The Debian wiki only includes pointers to RaspberryPi 3, not RaspberryPi 3 B+

@gwolf

This comment has been minimized.

Member

gwolf commented Oct 11, 2018

@mbien

This comment has been minimized.

mbien commented Oct 12, 2018

thanks to the great instructions i was able to build an image using the kernel from deb buster without much trouble (Pi 3 B+). Everything works fine and it also boots from usb. (i only edited a few things in the yaml, using iptable-persistant etc)

i noticed the mac address is randomly generated on each boot however - which isn't the case when using the raspbian image on my other Pi. I thought i could easily fix this by statically assigning a mac but when i do that the pi isn't reachable.

edit: apparently the mac address is passed via a kernel param:
https://www.raspberrypi.org/forums/viewtopic.php?p=284683
edit2: ^^ this is not needed for the 3 B+ see comments below

@st-ashcroft

This comment has been minimized.

st-ashcroft commented Oct 12, 2018

The mac address isn't passed as a kernel param any more.
It is passed via the device tree.

The trick to make this work on the 3 B+ is to make sure you are running at least a 4.18 kernel and copy (change the path to match the kernel you are running):

/usr/lib/linux-image-4.18.0-1-arm64/broadcom/bcm2837-rpi-3-b-plus.dtb

into /boot/firmware

and then edit the device_tree line in config.txt to match i.e.

device_tree=bcm2837-rpi-3-b-plus.dtb

Unfortunately you need to repeat this process if the initrd is updated as config.txt will be overwritten.
This normally only happens during kernel upgrades.

@chschlue

This comment has been minimized.

Contributor

chschlue commented Oct 12, 2018

/usr/lib/linux-image-4.18.0-1-arm64/broadcom/bcm2837-rpi-3-b-plus.dtb

into /boot/firmware

and then edit the device_tree line in config.txt to match i.e.

device_tree=bcm2837-rpi-3-b-plus.dtb

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

@gwolf

This comment has been minimized.

Member

gwolf commented Oct 12, 2018

@mbien

This comment has been minimized.

mbien commented Oct 13, 2018

copying the dtb and adding the device_tree property to config.txt worked perfectly and restored the device mac address. Thanks!

@st-ashcroft

This comment has been minimized.

st-ashcroft commented Oct 15, 2018

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

That's combined with removing the device_tree line from config.txt completely is probably the best fix.
That way we'll end up with a build which works on all models with no modifications.

@chschlue

This comment has been minimized.

Contributor

chschlue commented Oct 15, 2018

Yes, that's exactly what my MR is about.

@muammar

This comment has been minimized.

muammar commented Nov 4, 2018

Hi all. I recently bought a raspberry pi 3 b+. I followed the instructions on the README, and had just to modify this:

diff --git a/raspi3.yaml b/raspi3.yaml
index 86e82fb..d563eec 100644
--- a/raspi3.yaml
+++ b/raspi3.yaml
@@ -85,7 +85,7 @@ steps:
       echo 'APT::Default-Release "buster";' > /etc/apt/apt.conf.d/08default-release
       apt-get update
       apt-get -y --no-show-progress -t unstable install raspi3-firmware
-      apt-get -y --no-show-progress -t experimental install linux-image-4.18.0-rc5-arm64-unsigned
+      apt-get -y --no-show-progress -t experimental install linux-image-4.18.0-trunk-arm64-unsigned

My rpi was able to boot but gets stuck here:

img_20181103_234641

Is this related to hdmi_force_hotplug=1 as it was mentioned by @plugwash?

Edit 1: Ok, the question above was very stupid from me... I unplugged a hub that was causing the issue and now things are stuck here:

img_20181103_235559

Edit 2: After changing the kernel used above in the patch, using the root=/dev/mmcblk0p2, and copying newest files from the raspberry-firmware package I am able to make the rpi to boot until loading vc4 drm soc fb0. Then, the rpi gets stuck there. I have no idea what to do at this point. I would be glad if you could give me any hint :).

@bioxz

This comment has been minimized.

bioxz commented Nov 4, 2018

  • It's super hard to read that post, you may need to reformat it ;)
  • There is no need anymore for experimental sources, the 4.18 already went over unstable into testing.
  • I was unable to boot 4.18.0-2, while 4.18.0-1 is working fine. That's something you could try. Also make sure that the /boot/firmware/config contains the correct image names, mine got messed up at one point, pointing to different kernel versions.
@muammar

This comment has been minimized.

muammar commented Nov 4, 2018

  • It's super hard to read that post, you may need to reformat it ;)

ok. I tried to fix the diff format.

  • There is no need anymore for experimental sources, the 4.18 already went over unstable into testing.

I realized that later, and changed it.

  • I was unable to boot 4.18.0-2, while 4.18.0-1 is working fine. That's something you could try. Also make sure that the /boot/firmware/config contains the correct image names, mine got messed up at one point, pointing to different kernel versions.

This makes sense. I will try this and post back or edit this same message with my findings.

Edit 1: @bioxz using 4.18.0-1 makes things go better (thanks for your suggestion). Now, /boot/firmware/ is empty in my case. When grepping the log file there is this line:

2018-11-04 09:39:53 DEBUG STDERR: b'raspi3-firmware: no initrd found in /boot/initrd.img-*, cannot populate /boot/firmware\n'

Any idea?

@Kareema0

This comment has been minimized.

Kareema0 commented Nov 5, 2018

@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 maybe I'm 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 (or otherwise). This is because the bcm27* device tree files correspond to the Raspberry Pi Foundation kernel config while the bcm28* device tree files correspond to the mainline kernel config (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, Raspbian and mainline 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 with this fix, the device tree files for the Raspbian kernel will get overwritten. And you can no longer distinguish the device tree files (Raspbian/mainlane) by name.

Edit: Sorry, I was a bit confused about down-/upstream terminology. Corrected the text, to make it clearer. I hope it's understandable now, what I meant.

@Kareema0

This comment has been minimized.

Kareema0 commented Nov 6, 2018

@bioxz

This comment has been minimized.

bioxz commented Nov 6, 2018

Edit 1: @bioxz using 4.18.0-1 makes things go better (thanks for your suggestion). Now, /boot/firmware/ is empty in my case. When grepping the log file there is this line:

Any idea?

Obviously it shouldn't be empty. Are you sure the partition is mounted? First partition on your SD card should be a small partition that is mounted to /boot/fimware/, the second partition will contain your /.

@muammar

This comment has been minimized.

muammar commented Nov 6, 2018

Edit 1: @bioxz using 4.18.0-1 makes things go better (thanks for your suggestion). Now, /boot/firmware/ is empty in my case. When grepping the log file there is this line:
Any idea?

Obviously it shouldn't be empty. Are you sure the partition is mounted? First partition on your SD card should be a small partition that is mounted to /boot/fimware/, the second partition will contain your /.

I was reading the /etc/fstab and other configuration files mentioned in this issue but everything looked well. I tried mounting the partition from the rescue shell that appeared after failing to boot and could not make it work. @bioxz I can see the same warning when building the image. Does that happen to you, too?

By the way, I have just checked the raspi3.yaml and for me this is not happening:

sed -i 's/.dev.mmcblk0p2/LABEL=raspiroot/' /boot/firmware/cmdline.txt

What is the content of /boot/firmware?

@Jackfritt

This comment has been minimized.

Jackfritt commented Nov 16, 2018

The only change in raspi3.yaml I had to do after cloning is
from
apt-get -y --no-show-progress -t experimental install linux-image-4.18.0-rc5-arm64-unsigned
to
apt-get -y --no-show-progress -t experimental install linux-image-arm64

Without this change not boot and ERRORS when building with vmdb2 submodule.

HDMI Video output works. Only the LEDs on Network Plug and the Power LEDs dont
work after booting is done. More things to be tested.

@mbien

This comment has been minimized.

mbien commented Nov 17, 2018

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

This comment has been minimized.

st-ashcroft commented Nov 30, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment