Re: Unable to boot Pi 3b+ SOLVED
- Reply: Mark Millard : "Re: Unable to boot Pi 3b+ SOLVED"
- In reply to: Mark Millard : "Re: Unable to boot Pi 3b+ UPDATED"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 18 Aug 2023 16:41:21 UTC
Mark Millard wrote on 2023-08-17 21:00: > On Aug 17, 2023, at 18:17, Peter G <list-freebsd-arm@box559.com> wrote: > >> Mark Millard wrote on 2023-08-17 12:22: >>> On Aug 17, 2023, at 11:08, Peter G <list-freebsd-arm@box559.com> wrote: >>>> Apologies for top posting, but now that I understand the problem better, most of the stuff below is not relevant. Here's the whole issue: >>>> >>>> Late last year there was a new hardware release of the Raspberry Pi 3B+ board. The PMIC chip was changed; more information is here: >>>> https://pip.raspberrypi.com/categories/797-pcn/documents/RP-003337-PC/Pi3B-Revision-9-PCN.pdf >>>> The new board is Rev. 1.4, a.k.a. a020d4. >>>> >>>> The FreeBSD image at >>>> http://ftp3.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.2/FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img.xz >>>> boots fine on the old Rev. 1.3 version of the board but it fails to boot on the Rev 1.4 version. I have tried it on more than one example of each version of the board. 1.3 boards boot fine, 1.4 boards fail to boot and flash the green LED in 4 long - 7 short pattern. >>>> >>>> Not sure what to do about this. Is it a known problem? Should I file a bug report? >>> From the *.pdf document that you referenced: >>> QUOTE >>> Software/Firmware Changes Required >>> This new product revision is supported in firmware versions from September 2021 onwards. >>> The firmware version . . . It can also be found for an image by running >>> strings /boot/start.elf | grep VC_BUILD >>> END QUOTE >>> (The /boot/ path is not from FreeBSD, so replace >>> with a FreeBSD path. Also, start4.elf is of more >>> direct interest here.) >>> Until the recent change in systuil/rpi-firmware , >>> FreeBSD simply used too old of an RPI* firmware >>> version (over 2 years old) to work for the RPi3B+ >>> Rev 1.4 (or later) parts. >>> I'm not aware of FreeBSD re-releasing the likes of >>> a releng/X.Y with just updated RPi* firmware (or an >>> updated U-Boot since such is also available now). >>> Any solution must involve replacing the older >>> firmware with newer firmware. But the port to >>> package builder is not done yet --and once it >>> is there is also distribution time after that >>> before the update will be available. >>> One way to do that replacement now is to get the >>> material from the msdosfs for one of the snapshot >>> builds that I referenced: >>> http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/14.0/FreeBSD-14.0-ALPHA1-arm64-aarch64-RPI-20230811-136fc495615f-264678.img.xz >> >> As you suggest, I tried substituting the msdos files from this 14.0 image into the 13.2-RELEASE image. >> >> First, I replaced all the files in the first (msdos) partition. That booted, but crashed when the kernel started, which caused it to reboot, and so on in loop. > > Interesting. What was the evidence that it was the kernel > instead of, say, U-Boot or even earlier? > > (Currently working boots are noisy with 150+ extra console > message lines that should be ignored/skipped, unfortunately. > The 150+ is in part because of 3 lines per original example > of the underlying issue. That type of issue ends up being > tried 2*25+ times.) > >> Next, I tried replacing only the start4.elf file, leaving the others alone. > > First off, I'm so used to a RPi4B context that I stupidly referenced > start4.elf despite your RPi3B+ context. Sorry. start.elf and fixup.dat > are appropriate to your context, not start4.elf and fixup4.dat . > > Normally start.elf replaced by itself is incoherent. start.elf > and fixup.dat go together as a pair, for example. But the *.dtb > files are not fully independent of start.elf either. Compatibility > across the 2 years seems unlikely. > > Some files are not RPi* firmware at all: > > Not part of FreeBSD but used in booting FreeBSD . . . > > armstub8-gic.bin (This one is for RPi4B's and the like.) > armstub8.bin > > u-boot.bin > > FreeBSD files used by aarch64 RPi*'s . . . > > EFI/BOOT/bootaa64.efi (The FreeBSD UEFI loader.) > > FreeBSD files not used by RPi*'s . . . > > dtb/* > dtb/*/* > > > > Technically, the FreeBSD sysutils/rpi-firmware port supplied > the config.txt used. It looks like: > > [all] > arm_64bit=1 > dtparam=audio=on,i2c_arm=on,spi=on > dtoverlay=mmc > dtoverlay=disable-bt > device_tree_address=0x4000 > kernel=u-boot.bin > > [pi4] > hdmi_safe=1 > armstub=armstub8-gic.bin > > > >> That didn't boot at all, returning to the now familiar 4 slow - 7 fast pattern of green LED flashes. > > Yea, even ignoring other issues with doing partial replacements, > my referencing start4.elf was wrong and the file would be > ignored on a RPi3B+ . > >> Any thoughts on which files should be substituted for a successful boot? >> >> [...] > > We are driving blind here. Do you have a serial console > setup? If not, can you? If you get to the point of having > a serial console, can you record it and post the content > someplace? > > Recording and posting the output would give evidence: the > the FreeBSD kernel messages (or whatever) as it progresses. > > I'll note that Friday there should be a new 14.0-ALPHA2 > snapshot. It does contain one fix to main's RPi* kernel > code. It might be worth seeing if it boots the RPi3B+ > well or not, separately from the releng/13.2 effort. > > === > Mark Millard > marklmi at yahoo.com Okay, finally working! I replaced start.elf and fixup.dat, and only those two files, in 13.2-RELEASE with the ones from 14.0-ALPHA1, and that boots (usually). I say usually because sometimes the boot hangs indefinitely between loading the keyboard USB device and bringing up the network stuff (lo0, mue0, and ue0), but usually it just pauses there and then continues. When it does hang, ctrl-alt-del works to try again. As expected, once it's up there are no apparent problems. The wired ethernet works fine for ssh and freebsd-update. I haven't stressed the system much so far, but still looks good after half a day of uptime.