agherzan
dunfell firmware files too old for newer revisions of 3B+
https://github.com/agherzan/meta-raspberrypi/blob/dunfell/recipes-bsp/common/raspberrypi-firmware.inc
https://pip.raspberrypi.com/categories/797-pcn
The firmware seems to be dated before this PMIC change and the 3B+ will not boot (4 long flashes followed by 7 short flashes)
I am experiencing the same problems. Any news on this?
Will it be a problem to just use a newer version of the FW (e.g. same as used on kirkstone brach), without changing anything else?
Will it be a problem to just use a newer version of the FW (e.g. same as used on kirkstone brach), without changing anything else?
No. It's completely independent of kernel etc.
just add recipes-bsp/bootfiles/bootfiles.bbappend with:
RPIFW_DATE = "20220830"
RPIFW_SRC_URI = "https://archive.raspberrypi.com/debian/pool/main/r/raspberrypi-firmware/raspberrypi-firmware_1.${RPIFW_DATE}.orig.tar.xz"
RPIFW_S = "${WORKDIR}/raspberrypi-firmware-1.${RPIFW_DATE}"
SRC_URI[sha256sum] = "2b27e4b3c4d2664a0a1d0dd8602bd80ea41dd006eb0ad9c67d7b659c9c8bb4e5"
It's a hard one to decide on. 3B+ was released before dunfell. Is this a board revision change?
It's a hard one to decide on. 3B+ was released before dunfell. Is this a board revision change?
Yes as mentioned in the first post it's a PMIC hardware update which requires new firmware on the newer 3B+ 1st release 1.0 4th March 2022, Transition Date(s) October/November 2022
I see. I am happy, in this case, to accept a fix to dunfell that bumps the firmware version. Hopefully, it won't break other use-cases - if it does, I'll revert it.
I had the same problem with a Compute Module 4 Rev. 1.1, which is similarly not supported by current dunfell, despite the no longer available Compute Module 4 Rev. 1.0 being supported.
I have updated the raspberrypi-firmware in dunfell to the latest revision of today. Please check my PR #1241 This puts dunfell ahead of master, so somebody should probably update master as well once my PR is merged.
CC @agherzan
Process is otherway around. Where it goes into master first ( if its needed there ) and then backported into release branches. So please propose it for master first.
But also, this proposes a bump for the firmware blobs in a long-term supported branch. This needs to be a very detailed rationale, and we need to decide on the risk of regressions as opposed to the gain in the fixes.