- User Since
- Oct 24 2019, 2:59 PM (162 w, 1 d)
Oct 28 2022
after bisecting it seems this commit causes RPI4b (early model) to hang on (pxe-)boot short before starting CPUs :
Oct 26 2022
reverting this commit 92e190f11fe8 fixed the build for me.
--- in_proto.o --- /usr/src/sys/netinet/in_proto.c:83:19: error: use of undeclared identifier 'in_inithead' --- modules-all --- --- all_subdir_accf_data --- ===> accf_data (all) --- in_proto.o --- .dom_rtattach = in_inithead, ^ /usr/src/sys/netinet/in_proto.c:85:19: error: use of undeclared identifier 'in_detachhead' .dom_rtdetach = in_detachhead, ^ /usr/src/sys/netinet/in_proto.c:87:19: error: use of undeclared identifier 'in_domifattach'; did you mean 'in_ifdetach'? .dom_ifattach = in_domifattach, ^~~~~~~~~~~~~~ in_ifdetach /usr/src/sys/netinet/in.h:690:7: note: 'in_ifdetach' declared here void in_ifdetach(struct ifnet *); ^ /usr/src/sys/netinet/in_proto.c:88:19: error: use of undeclared identifier 'in_domifdetach'; did you mean 'in_ifdetach'? .dom_ifdetach = in_domifdetach, ^~~~~~~~~~~~~~ in_ifdetach /usr/src/sys/netinet/in.h:690:7: note: 'in_ifdetach' declared here void in_ifdetach(struct ifnet *); ^ 4 errors generated. *** [in_proto.o] Error code 1
Jan 18 2022
U-Boot SPL 2021.07 (Jan 18 2022 - 22:58:39 +0000) Trying to boot from MMC1
ouch, my bad , sorry, accidentally was set to clang 6 :-)... upgrading now
root@freebsd:/usr/ports/sysutils/u-boot-sifive-fu540 # uname -a FreeBSD freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #4 main-n250734-2bbaed4d7fca: Tue Nov 16 20:30:28 UTC 2021 root@freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 root@freebsd:/usr/ports/sysutils/u-boot-sifive-fu540 # cc -v FreeBSD clang version 13.0.0 (firstname.lastname@example.org:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a303) Target: x86_64-unknown-freebsd14.0 Thread model: posix InstalledDir: /usr/bin
Jan 14 2022
I made an issue-request to the upstream :
.. in the hope that I haven't misunderstood the context of D33845
well, whatever failed there, I patched (or removed) those files manually but that didn't matter...
I have ensured that every patch has arrived into the files by reading them.
I reverted the patches , installed u-boot : it successfully boots from pxe.
After applying the patch again: I'm so sorry but it failed again as sent in the previous dmesg.(booted into the same pxe-server)
Jan 13 2022
ouch, I see it myself now :
booting into the same pxe-server from the old u-boot(before patch) succeeded while with this patch 1st attempt failed... I will later test again (revert this patch) to ensure that I didn`t something wrong with ports/u-boot(boot parameters) etc.- ... it was patched from a newly and untouched cloned ports-tree from today ...
Jan 11 2022
O.K, I'll take a closer look and test it tonight or tomorrow.
I remember hacking u-boot for overclocking a few weeks or months ago, because overclocking 1GhZ-> 1.4Ghz was only possible directly in u-boot(not from system`s dtb) because of this errata, otherwise the machine would crash beforehand ...
Dec 14 2021
good point . for amazed screenreaders : the ASCII art in @pauamma_gundo.com`s comment
is an invalid access operator sign.
since not accepted as it landed I abandone that revision
Dec 13 2021
Dec 9 2021
of course... e.g. removing the "B" should match, thanks.
should work on all BCM2711xxx SOC-revisions, not only on the mentioned P4b(BCM2711B08)
while not specifically inspected I didn't notice any problem with the CM4(BCM2711C0)
Feb 3 2021
FreeBSD freebsd 13.0-CURRENT FreeBSD 13.0-CURRENT #1 main-c255394-gf20c0e33195: Mon Dec 28 14:14:50 UTC 2020 root@freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 - root@freebsd:/usr/ports # patch < D28471.patch root@freebsd:/usr/local/share/u-boot/u-boot-sifive-fu540 # ls /usr/ports/sysutils/opensbi/files patch-Makefile patch-Makefile.orig patch-Makefile.rej patch-lib_sbi_sbi__hart.c patch-lib_sbi_sbi__hart.c.orig patch-platform_generic_platform.c patch-platform_generic_platform.c.orig patch-platform_sifive_fu540_platform.c patch-platform_sifive_fu540_platform.c.orig root@freebsd:/usr/local/share/u-boot/u-boot-sifive-fu540 #
Jan 17 2021
Jan 15 2021
Jan 14 2021
thank you!... sidenote: also doesn't work with BBL/ u-boot-payload .. we`ll talk about it in the mailing list, Regards
Hi, ah, o.k., didn`t see that. I didn`t make further dtrace-tests because still struggling with
solving the bootup-panic of the HiFiveUnleashed.
Jan 4 2021
as we have extensively discussed and tested on the ML until the doctor comes :-) :
an overlay would again break future versions of bcm2711-rpi-4-b.dtb upstreamed by rpi-org and drivers would have been broken by strange upstreamed versions of this file.
E.g. current upstreamed dtb would break genet.
For now it seems the best to hardlink a compiled dtb of this version for current rpi-releases.
@manu : however, for the case that you're interested in this version of bcm2711-rpi-4-b.dts :
please feel free to give this dts/dtb a "warmer" place than pristine sys/gnu.. .
Jan 3 2021
Jan 2 2021
news on this :
seems that the reset-fix made it upstream meanwhile (18days ago. I didn't know):
https://github.com/raspberrypi/firmware/blob/master/boot/bcm2711-rpi-4-b.dtb. (it boots up)
so I wonder why
didn't work in release for the user who reported the issue on the mailing lists...
`will continue testing..
to view what is loaded testers can use : uart_2ndstage=1 in config.txt
no, as far as I know (didn`t look into the tux-upstream the last weeks).
related to the error "Bus xhci_pci: probe failed, error -110 No working controllers found“ :
good described by Mark Millard :
of course you could create an overlay of it if you don't want to overwrite sys/gnu/dts/
so if you don't believe this dtb/dts works and own an RPI4 8GB-model,
just try it out.
If you don't own that model, believe the users on the ML who reported it as a working
reclaimed and reopened since, as far as I know and according to the mailing list , this issue isn't yet solved.
if I'm wrong, you can just close it again :-)
Dec 16 2020
yes, after I realized that it needs the 34-start-LBA-alignment I even found it documented (by the SiFive-creators in u-boot) :
well, to add : Warning - bad CRC, using default environment simply means that the next step to do is to fill the freebsd-ufs partition up with the root filesystem and to create an (loader-)env for u-boot. after saveenv the crc-warning will be gone.So maybe the additional creation of an ms-basic-data partition with the content of the loader-env will be needed.
I have created the following installation instruction and extensively tested on the hardware
(gpart failed in the definitely necessary alignment of first-lba: 34) :
- ("typecode=3:a503" is freebsd-ufs (not needed to only boot u-boot))
- boot jumper MSEL2 has to be switched up to boot from u-boot)
Dec 12 2020
Oct 20 2020
exactly , it triggers
in u-boot : https://github.com/u-boot/u-boot/commit/f676eb217bdff3bd734a42c8f9bbc58c9100055c , to straight boot from USB(WITHOUT any SD-card).
Oct 19 2020
this is a little abnormality in the dmesg, :
Sep 24 2020
Sep 10 2020
Sep 9 2020
Jun 25 2020
... companion patch, ....
yes, this driver should land together with D25261, which significantly improves the undesired controller resets, while that reset-issue (very)rarely still appears(specially after the now working reboot-feature)
Jun 16 2020
Jun 6 2020
https://reviews.freebsd.org/p/crowston_protonmail.com/ told to set CONFIG_RPI_EFI_NR_SPIN_PAGES=10 for then new RPI4/8GB-model in u-boot 2020.07 to get SMP-support....
May 12 2020
Closed due to lack of interest on the part of the German translation project.
Apr 19 2020
Mar 15 2020
thanks in advance if you can commit this revision.(if you don't find formatting issue)..
It's a 100% 1:1 (unchanged) German translation of D24003 .
Since this is the No.1 google catch for 'FreeBSD-java' , it looks quite bad
if up-to-date information is directly followed by totally outdated information .
Mar 11 2020
Mar 9 2020
Feb 9 2020
5.5 dts import will be added in bulk by manu soon
Feb 1 2020
I yesterday compiled r357335 (as far as I remember) to GENERIC-NODEBUG and got the same mmc-rescan-issue ... as you assumed..
another user reported similar issue when upgrading from -r356426 to -r357356 on the mailing list.
I don't know if this D15955 could transitionally help out .. I'm a bit running out of time(probably like you:-) to reproduce this issue quickly..
Jan 31 2020
Jan 30 2020
(perhaps with some additions/changes) this patch should give us access
to the proprietary brcmfmac- driver for the RPI4,
so that we could boot the root filesystem from SD-card AND get WIFI over SDIO (GENERIC-MMCCAM(actually logically hangs @ mount root)) for that RPI-board.
Dec 24 2019
from absolute to relative relocation type :
R_AARCH64_PREL64 instead of R_AARCH64_ABS64
as recommended by markj@
Dec 23 2019
Nov 14 2019
correction of missing leading tab (mentioned by Warner Losh, thank you )