search

Debian / raspi3-image-spec

contains the files to build the https://wiki.debian.org/RaspberryPi3 image
127 stars 32 forks source link

Raspberry Pi 3 B+ incompatibilities #12

Closed jcberthon closed 5 years ago

jcberthon commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

plugwash commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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:

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

bioxz commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

[...] 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 commented 6 years ago

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 commented 6 years ago

[...] 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 commented 6 years ago

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

perezmeyer commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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: https://github.com/Debian/raspi3-image-spec/pull/33

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

Hope that helps!

perezmeyer commented 6 years ago

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

KaliszAd commented 6 years ago

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

gwolf commented 6 years ago

KaliszAd dijo [Thu, Oct 11, 2018 at 11:14:52AM -0700]:

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

Yes... Yes, there definitively will be. I promised to adopt this, and have worked a bit, but September and October were quite hard on me. I will be back on track soon.

As soon as I can produce an image with a working WiFi, I think I'll push it up.

mbien commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

/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 commented 6 years ago

Michael Bien dijo [Fri, Oct 12, 2018 at 08:42:37PM +0000]:

is there no way to automate that with a package which would fix that on kernel update?

I plan to incorporate it (or something quite similar, at least) into raspi3-firmware, so that the manual step is no longer required.

mbien commented 6 years ago

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

st-ashcroft commented 6 years ago

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 commented 6 years ago

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

muammar commented 5 years ago

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 commented 5 years ago
muammar commented 5 years ago
  • 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 commented 5 years ago

@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 commented 5 years ago

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 notifications@github.com 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

https://github.com/Debian/raspi3-image-spec/issues/12#issuecomment-435872110, 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 https://github.com/Debian/raspi3-image-spec/issues/12#issuecomment-436024343, or mute the thread https://github.com/notifications/unsubscribe-auth/AGsODGJSKnNjYwVFqBessN5ygyQ3rs-Fks5usKAfgaJpZM4S58OO.

bioxz commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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.