In the following releases, the system boots up to prompt enter user - Alas the keyboard, doesn't have any lights on, and isn't working. [ Note the same keyboard, works just fine under Linux, and other OS. ] FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210218-fa3bd463cee-256776.img.xz FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210225-bf667f282a7-256946.img.xz
Hi, There is very little detail here. Is this a regression issue? Does other keyboards work? --HPS
HPS, I assume it's the rpi-firmware-thing that was fixed months ago but didn't make it in fbsd-release. port-maintenance will change. but for a quick fix fore affected users: https://sourceforge.net/projects/d26853-bcm2711-rpi-4-b-dtb/ overwrite fixup4.dat & start4.elf(rpi4_pack_freebsd.zip) & bcm2711-rpi-4-b.dtb in the msdos-partition, that should normally help immediately until the port will be updated, although I don't know what happened to the msdos-partiton the last days in the port.
well....beside the fw-issues... of course possible that some keyboards don't work...
Thanks for the clarification!
(In reply to Nathan Tice from comment #0) as HPS asked you, : does other keyboard work? you also could plug your keyboard in fbsd-amd64(machine or VM) , if not detected in amd64 , it's one of the few incompatible. before the fw-patch some months ago I noticed reset-loops in USB(pcie) when hotplugging keyboard/mouse.. but that should have gone since . do you see xhci-reset-loops in the console?
(In reply to Hans Petter Selasky from comment #1) I just have the one. Happy to buy another if you'd recommend - Do you have any that you know to be working and if so which one? Here's the one I have. Works with Linux on this Pi, and other machines. https://www.amazon.com/Rii-Ultra-Slim-Compact-Keyboard-Windows/dp/B077P45VND/
(In reply to Klaus Küchemann from comment #5) As for resetting - I don't see any changes reconnecting it. I've tried unplugging, and in all four of the ports, nothing anywhere - booting or hot-plug, do not get any response, from the device. Nothing on console changes with it in or out or reconnected. I have a trackball, it's an older Logitech corded USB. It's fine on Linux using exact same hardware and other machines. I've tested with that, booting, unplug, and re-plug - no signs on console.
(In reply to Hans Petter Selasky from comment #1) My R-Pi 3+ using the same keyboard works using this image FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210225-bf667f282a7-256946.img.xz
(In reply to Hans Petter Selasky from comment #1) My apologies, regarding lack of details, I somehow missed that the broken system is new Raspberry Pi 4 with 8gigs of RAM.
(In reply to Nathan Tice from comment #9) can you please download startup4.elf, fixup4.dat and bcm2711-rpi-4-b-11.dtb from https://sourceforge.net/projects/d26853-bcm2711-rpi-4-b-dtb/ and overwrite those files to the msdos-partition of your boot-disk ? while your keyboard should have been detected by the pcie-driver itself, there were perhaps changes in the firmware which could have caused this issue. if detected on your rpi3 there's no other reason for the problem, with 1 exception : if the 8GB-model is an older one you should perform an eeprom-ugrade: can be done easily e.g. with the Raspberry Pi Imager.app - if the eeprom is brand new and changing the firmware doesn't help, we would have an unknown issue.
https://github.com/raspberrypi/rpi-eeprom , if necessary
(In reply to Klaus Küchemann from comment #2) Thank you for the patch! The keyboard works on both Pis after it's in place! One thing I noticed, which may be worth reporting, is it's much slower. Pre-patch Pi 4 boot, takes a minute-fourtyfive, from power to prompt. Pi 3+ with patch, takes a minute and thirty, for the same result. Pi 4 with the patch, took an entire 5 minutes, to do the same thing. Any ideas when the patch will be added to distribution?
(In reply to Nathan Tice from comment #12) glad to hear it works for you... it only seems to be slower, now you have a new option since your keyboard is detected: press `Enter` and it will boot like a rocket(specially when booting from USB-SSD(which should also work now) . Regards K.
(In reply to Klaus Küchemann from comment #13) That is much faster, but alas then it crashes, and system reboots - so no prompt that way, but it is quite a speed up the short time it works... Want those details here, or where is better for those, a fresh bug report?
(In reply to Nathan Tice from comment #14) should not crash , perhaps you now have a "poisoned" mix of firmware-files in the msdos-partition. not necessary to open a new bug-report,.. I could send you a whole msdos-partiton , which is known working, if you want until the firmware -isuues will be fixed in the fbsd-upstream--port...... K.
(In reply to Klaus Küchemann from comment #15) I've tried this two ways, booting via USB 3.0 card key. With pressing enter, it gets to the login prompt within a minute! Using the same card, in the SD card reader, doing the same things - it ends up crashing, here is the error message, I have been getting : " Using DTB provided by EFI at 0x7ef0000. WARN halted endpoint queueing URB anyway. Unexpected XHCI event TRB, skipping... (3afe60f0 0000000 13000000 02000840 1) BUG at drivers/usb/host/xhci-ring.c:498/abort_td()? BUG! " Noting that sometimes, the line where it says "1)", is sometimes "0)" And those two "BUG" lines, last for less than a second, and sometimes don't show. It boots the 'slow' way, or if I wait 'til it says to press [Enter] key.
(In reply to Nathan Tice from comment #16) since we don't have an "xhci-ring.c" afaik, that message comes from elsewhere... glad to hear that you can boot via USB. if you have an older fbsd-rpi-image available (e.g. end last year), you can overwrite the msdos-partition with it and apply the firmware-patches again, that should fix the uSD-issue. but I guess you won`t find a reason to boot from uSD if USB works. but to avoid "poisoned" fw-mix , use an older rpi-image(only for the msdos-part) or I could upload that if you're interested in until the sysutils-rpi-port will be fixed.
(In reply to Klaus Küchemann from comment #17) If you could post that, as you have kindly offered, I would enjoy that.
A commit references this bug: Author: manu Date: Fri Mar 5 10:32:15 UTC 2021 New revision: 567376 URL: https://svnweb.freebsd.org/changeset/ports/567376 Log: sysutils/rpi-firmware: Update to 20210303 Fix USB on RPI4 PR: 252971, 253981, 253983 MFH: 2021Q1 Changes: head/sysutils/rpi-firmware/Makefile head/sysutils/rpi-firmware/distinfo head/sysutils/rpi-firmware/pkg-plist
A commit references this bug: Author: manu Date: Fri Mar 5 10:33:54 UTC 2021 New revision: 567377 URL: https://svnweb.freebsd.org/changeset/ports/567377 Log: MFH: r567376 sysutils/rpi-firmware: Update to 20210303 Fix USB on RPI4 PR: 252971, 253981, 253983 Changes: _U branches/2021Q1/ branches/2021Q1/sysutils/rpi-firmware/Makefile branches/2021Q1/sysutils/rpi-firmware/distinfo branches/2021Q1/sysutils/rpi-firmware/pkg-plist
There's a new update that was posted Thursday in the releases https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/14.0/FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210304-483c6da3a20-257149.img.xz So I tried it out, on the Pi 3+ and 4, and here's what I found. On the Pi3+, same card in the SD slot and in adapter - boots through to login, with the keyboard functional, as one would expect. On the R-Pi 4 with unmodified image does boot to the prompt - in the USB MicroSD adapter that I used before, there's a quick page fault, at the start of boot process, and then it reboots. In the ssd slot, using the same SD card, it boots to login : Alas at that point, the keyboard is dead to the world, no signs of response.
(In reply to Nathan Tice from comment #21) can you please try the files from : https://github.com/raspberrypi/firmware/archive/1.20210303.zip (overwrite the files from the unzipped boot-folder to your msdos-partition). that should be the version which was updated in the ports-tree(probably not yet in your image from Thursday). If that doen`t help out please tell us. Regards
(In reply to Klaus Küchemann from comment #22) forgot to say: overwrite all boot-files which contain the number '4' in it, although you can experiment with overlays, you can leave the overlays- folder as is for now.
(In reply to Klaus Küchemann from comment #22) This patch has more files which threw me off some at first, so here is a list : FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210304-483c6da3a20-257149.img.xz + fixup4.dat fixup4cd.dat fixup4db.dat fixup4x.dat start4.elf start4cd.elf start4db.elf start4x.elf The errors I got with slot booting quickly did not reproduce. Pi 4 boots to prompt, card in slot, and USB, as one would expect. :)
Created attachment 223025 [details] fast boot error message On the R-Pi4, pressing enter too early, leads to crash / reset. The attached image is console error message before it reboots. If one waits until one sees the press [Enter] text before pressing it - then it boots up fine, but if it's pressed too early, it gave me this crash.
(In reply to Nathan Tice from comment #24) My apologies, it looks like I spoke too soon, with that boot error. I've attached image, of what the console looks like, before it reboots. This newer version boots noticaebly faster so it's less likely.
(In reply to Nathan Tice from comment #24) please don't forget bcm2711-rpi-4-b.dtb ( there's a number '4' in it ;-) if then fixed by 1.20210303-update you could close the PR for now. thanks, Regards
(In reply to Klaus Küchemann from comment #27) I added that file, and another one near it... here is the new list : FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210304-483c6da3a20-257149.img.xz + bcm2711-rpi-4-b.dtb bcm2711-rpi-cm4.dtb fixup4.dat fixup4cd.dat fixup4db.dat fixup4x.dat start4.elf start4cd.elf start4db.elf start4x.elf Has the same results; Crashes if sped up too soon, but otherwise boots.
Created attachment 223082 [details] u-boot-2021.04-rc3-rpi4 u-boot-2021.04-rc3-rpi4 (In reply to Nathan Tice from comment #28) thanks for reporting, ... (In reply to Nathan Tice from comment #16) <<...BUG at drivers/usb/host/xhci-ring.c:498/abort_td()? BUG!>> it's a u-boot-bug we have encountered in other context(depending on what devices you have plugged in USB). while the here attached new u-boot-compilation won't fix all related issues you can test it if you want.: override attachment u-boot.bin to your msdos-partition. if e.g. unplugging other USB-devices fixes the uSD-boot: it would be interesting to know which gadgets you had plugged.
(In reply to Klaus Küchemann from comment #29) I have tried the patch, still getting the same error in same conditions. I do recognize, that's a different issue, As for devices, I've only tried a trackball, which does seem to work. It shows as a mouse, and has normal behavior on the console text. Will we be seeing the Pi-4 patches offered that fixed USB added to image so a patch isn't needed before the release?
(In reply to Nathan Tice from comment #28) It is unlikely that: FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210304-483c6da3a20-257149.img.xz contains the updated firmware: the ports builder had not finished building sysutils/rpi-firmware as of 20210304, much less finished with all the rest of its port builds. =>> Building sysutils/rpi-firmware build started at Sat Mar 6 06:00:58 UTC 2021 port directory: /usr/ports/sysutils/rpi-firmware package name: rpi-firmware-1.20210303.g20210303 building for: FreeBSD main-arm64-default-job-12 14.0-CURRENT FreeBSD 14.0-CURRENT 1400005 arm64 maintained by: uboot@FreeBSD.org Makefile ident: $FreeBSD: head/sysutils/rpi-firmware/Makefile 567376 2021-03-05 10:32:14Z manu $ Poudriere version: 3.2.8-8-gaf08dbda Host OSVERSION: 1300139 Jail OSVERSION: 1400005 Job Id: 12 . . . ===> Cleaning for rpi-firmware-1.20210303.g20210303 build of sysutils/rpi-firmware | rpi-firmware-1.20210303.g20210303 ended at Sat Mar 6 06:01:42 UTC 2021 build time: 00:00:44 However, this presumes that the snapshot builds do not do their own port builds, instead using the official ones. Do not expect new firmware to be in the snapshot until the 2021-Mar-11 or later snapshot (unless we find out the ports are built by the snapshot build). Whatever firmware can be checked for matching the following . . . (The below presumes that the msdosfs file system involved is mounted on /boot/efi . Adjust as needed for your context.) # strings /boot/efi/start4.elf | grep VC_BUILD_ID_ VC_BUILD_ID_USER: dom VC_BUILD_ID_TIME: 12:10:40 VC_BUILD_ID_VARIANT: start VC_BUILD_ID_TIME: Feb 25 2021 VC_BUILD_ID_BRANCH: bcm2711_2 VC_BUILD_ID_HOSTNAME: buildbot VC_BUILD_ID_PLATFORM: raspberrypi_linux VC_BUILD_ID_VERSION: 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean) That strings and grep can be used locally to see if the start4.elf matches the above. fixup4.dat *.dtb's and such do not seem to contain such identification information. Full checking requires getting a full copy and diffing the result (or just replacing). But if one has been careful to not mix and match files, the above should be a good cross check.
(In reply to Nathan Tice from comment #18) I`ll upload the promised mostly working complete msdos-partition tonight or in some minutes, because I could reproduce the issues you've reported. `hope that will help for the 1st. many thanks for reporting ! K.
(In reply to Mark Millard from comment #31) FYI the 2021-Mar-04 snapshot: FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210304-483c6da3a20-257149.img contains: # strings /mnt/start4.elf | grep VC_BUILD_ID_ VC_BUILD_ID_USER: dom VC_BUILD_ID_TIME: 22:19:57 VC_BUILD_ID_VARIANT: start VC_BUILD_ID_TIME: Jan 27 2021 VC_BUILD_ID_BRANCH: bcm2711_2 VC_BUILD_ID_HOSTNAME: buildbot VC_BUILD_ID_PLATFORM: raspberrypi_linux VC_BUILD_ID_VERSION: 99d9a48302e4553cff3688692bb7e9ac760a03fa (clean) and so is not yet based on the 1.20210303 tagged firmware. It matches my build of the early Feb update to sysutils/rpi-firmware : # strings /usr/local/share/rpi-firmware/start4.elf | grep VC_BUILD_ID_ VC_BUILD_ID_USER: dom VC_BUILD_ID_TIME: 22:19:57 VC_BUILD_ID_VARIANT: start VC_BUILD_ID_TIME: Jan 27 2021 VC_BUILD_ID_BRANCH: bcm2711_2 VC_BUILD_ID_HOSTNAME: buildbot VC_BUILD_ID_PLATFORM: raspberrypi_linux VC_BUILD_ID_VERSION: 99d9a48302e4553cff3688692bb7e9ac760a03fa (clean)
(In reply to Klaus Küchemann from comment #32) (In reply to Nathan Tice from comment #18) https://sourceforge.net/projects/freebsd-rpi4-msdos-partition please close the bug if fixed(only then of course) and please visit us here : freebsd-arm@freebsd.org if you have any further question related to the RPI4, thanks very much for your bug-report !
(In reply to Klaus Küchemann from comment #17) We do have xhci-ring.c but in u-boot, not in FreeBSD: /wrkdirs/usr/ports/sysutils/u-boot-rpi4/work/u-boot-2020.10/drivers/usb/host/xhci-ring.c: puts("WARN halted endpoint, queueing URB anyway.\n"); (I just used grep on a version of source that I happened to still have around.)
(In reply to Mark Millard from comment #35) <<We do have xhci-ring.c but in u-boot, not in FreeBSD:>> yes, ( sidenote: xhci-ring.c in u-boot also had to do with the geekworm-board-thing) but: "our" missing "firmware-selfcontrol" in sysutils triggered this xhci-bug in u-boot. so should been fixed with my above fw-upload. if not permanently: then it's time to test every OS-releases-versions vs. hw-versions as you began with in the ML. I think we have to have a fixed fw in msdos-part because we never needed those crappy fw-updates from rpi-org. for the cm4 we will see... at least that's the experience that I (and others in bug-reports) have made.. indeed there're u-boot things unfixed , but on the u-boot-dev-side(as e.g. the multi--lun-thing) K.
(In reply to Klaus Küchemann from comment #34) Starting with image : FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210304-483c6da3a20-257149.img.xz delete files in DOS boot drive, then put these files there : https://sourceforge.net/projects/freebsd-rpi4-msdos-partition One big difference, output now in high-res text, like on the Pi3+ ... As for the keyboard, it is also functional with the new boot files. The speedup error, pressing enter too early, crashes the same way.
(In reply to Nathan Tice from comment #37) thanks for testing, 14-current is mostly used if you want the latest changes. means that e.g. you could try to make a non-debug build( GENERIC-NODEBUG) or simply `git pull`, then GENERIC - build and hope that your keyboard-issue went away. I have tested again with the files from my above link by hammering the keyboard like a woodpecker during boot :-) `cannot see any crash-problem with the keyboard no more. for the high-res on boot: IIRC Mark Millard had a hint on the mailing list , for the case that you want to use the files from rpi-firmware-upstream instead of the ones I posted: hdmi_safe=1 in config.txt well, in theory issues like yours can also have their root in broken cables , damaged uSD(then reformat) or similar... another hint is that you could test on another USB-port. for all other rpi-things you could subscribe to freebsd-arm@freebsd.org, if you want. Regards K.
I'm pleased to announce that I've tried the new snapshot, and the keyboard works. FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20210311-15565e0a217-257277.img.xz [ There's the same issue, where a key press too early leads to a reset. I note that issue is not the subject of this bug report topic. ] If the user waits 'til it says to press Enter to press enter key, or waits the whole time without accelerating it is working now. I'm marking this fixed... thank you for all of your help! Keep up the great work!
(In reply to Nathan Tice from comment #39) I'll note that it is not fixed in 13.0-RC2, in that the RPi* firmware is still an older version for 13.0, so far anyway. As the original report was for 13.0 this defect should likely not be in a closed state unless Version is update to indicate main (14) instead of 13.0-???? . As no snapshots are being made of 13.0-STABLE, the report should probably report in Version something that is being built and has the problem (if such is possible).