In D36744#844436, @andrew wrote:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Apr 17 2024
Apr 17 2024
maciphone2_googlemail.com added reviewers for D44823: Enable L1SS handling on RPI4 pcib: β’ karels, crowston_protonmail.com.
Oct 28 2022
Oct 28 2022
In D36744#844436, @andrew wrote:In D36744#844334, @maciphone2_googlemail.com wrote:after bisecting it seems this commit causes RPI4b (early model) to hang on (pxe-)boot short before starting CPUs :
I've hopefully disabled building hyperv support in the kernel until the boot issue on non-hyperv is fixed.
after bisecting it seems this commit causes RPI4b (early model) to hang on (pxe-)boot short before starting CPUs :
Oct 26 2022
Oct 26 2022
maciphone2_googlemail.com added a comment to rG92e190f11fe8: netinet*: remove unneeded headers from files that just declare domains.
Hi,
reverting this commit 92e190f11fe8 fixed the build for me.
Regards
K.
maciphone2_googlemail.com added a comment to rG92e190f11fe8: netinet*: remove unneeded headers from files that just declare domains.
--- 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
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 (git@github.com: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
Jan 14 2022
I made an issue-request to the upstream :
https://github.com/riscv-software-src/opensbi/issues/239
.. in the hope that I haven't misunderstood the context of D33845
In D33845#766038, @maciphone2_googlemail.com wrote:....
Hunk #1 failed at 1.
1 out of 1 hunks failed--saving rejects to sysutils/opensbi/files/patch-platform_generic_platform.c.rej
...
Hunk #1 failed at 0.
1 out of 1 hunks failed--saving rejects to sysutils/opensbi/files/patch-platform_sifive_fu540_platform.c.rej
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
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
Jan 11 2022
In D33845#765344, @mhorne wrote:@maciphone2_googlemail.com please test this update on your Unleashed board when possible, to ensure the workaround still works correctly.
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 ...
thanks
Dec 14 2021
Dec 14 2021
In D33360#755946, @pauamma_gundo.com wrote:...Art reviews are ----> over that way.
good point . for amazed screenreaders : the ASCII art in @pauamma_gundo.com`s comment
is an invalid access operator sign.
In D33360#755717, @danfe wrote:Technically, it was not ASCII art, it was UTF-8 art (and not very good one).
since not accepted as it landed I abandone that revision
Dec 13 2021
Dec 13 2021
In D33360#755573, @pauamma_gundo.com wrote:ObAccessibility; in case anyone visits this (now or later) using a screenreader and is wondering, the ASCII art in maciphone2_googlemail.com's comment earlier is a thumb-up sign.
π
In D33360#755447, @karels wrote:Added copyright; touched up hardware info
βββββββββ²
βββββββββ
ββββββββββββ
βββββββ±ββββββ
βββββββββββββ
βββββββββββββ
βββββββ²βββββI
Dec 9 2021
Dec 9 2021
In D33360#754185, @karels wrote:...mention the RPi 4, as that is the most common.
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
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 17 2021
Jan 15 2021
Jan 15 2021
Jan 14 2021
Jan 14 2021
In D28151#629277, @mhorne wrote:Of course. I am planning to come back to that thread and try to help you get it running,...
thank you!... sidenote: also doesn't work with BBL/ u-boot-payload .. we`ll talk about it in the mailing list, Regards
In D28151#629249, @mhorne wrote:Hi, there is an open review in D28054, ......
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
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 3 2021
maciphone2_googlemail.com updated the test plan for D26853: RPI4: enable USB-boot for the 8GB-model etc.
Jan 2 2021
Jan 2 2021
In D26853#623381, @manu wrote:Does the pristine DTB from gnu/dts works ?
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
EMBEDDEDPORTS="sysutils/u-boot-rpi-arm64 sysutils/rpi-firmware"
in https://github.com/freebsd/freebsd-src/release/arm64/RPI.conf
didn't work in release for the user who reported the issue on the mailing lists...
`will continue testing..
In D26853#623381, @manu wrote:I obviously forgot that u-boot on RPI uses the DTB loaded by the firmware.
to view what is loaded testers can use : uart_2ndstage=1 in config.txt
In D26853#623381, @manu wrote:Does the pristine DTB from gnu/dts works ?
no, as far as I know (didn`t look into the tux-upstream the last weeks).
In D26853#623381, @manu wrote:If not what changes are needed to make it work ?
related to the error "Bus xhci_pci: probe failed, error -110 No working controllers foundβ :
good described by Mark Millard :
https://reviews.freebsd.org/D26853#598685
of course you could create an overlay of it if you don't want to overwrite sys/gnu/dts/
@manu ,
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
solution.
In D26853#623275, @manu wrote:...
.......since this dtb isn't used for the images.
...
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
Dec 16 2020
In D25737#617462, @mhorne wrote:@maciphone2_googlemail.com thank you for the thorough testing. I'll have to look into why gpart(8) can't generate partitions starting at LBA 34, but it was the reason my instructions differed from the ones provided by u-boot. Did you find the required alignment documented anywhere? So far I have not found it.
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.
Hi,
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
Dec 12 2020
In D25737#616152, @mhorne wrote:Rebase and fix up the fu540 port. I will see about getting someone to test this with the new GENERICSD image.
Oct 20 2020
Oct 20 2020
In D26853#599350, @kevans wrote:As a side note, this is not commitable... sys/gnu/dts is vendored and pristine from upstream. You'll probably need to accomplish what you >want with an overlay instead.
In D26853#599130, @crowston_protonmail.com wrote:As far as I see this "reset cell" is just a trigger for the real logic that must be expressed in u-boot; it does not encode the necessary information to load the firmware.
exactly , it triggers
RASPBERRYPI_FIRMWARE_RESET_ID_USB: bcm2711_notify_vl805_reset();
in u-boot : https://github.com/u-boot/u-boot/commit/f676eb217bdff3bd734a42c8f9bbc58c9100055c , to straight boot from USB(WITHOUT any SD-card).
Oct 19 2020
Oct 19 2020
In D26853#598984, @markmi_dsl-only.net wrote:But the FreeBSD kernel does need to deal with the VL805-firmware issue in that context and does so without the .dtb file change.
So why would u-boot need the change when the kernel does not? (Again: out of my depth here.) Are you saying that the FreeBSD kernell is doing something wrong >currently and needs to be fixed once the .dtb adjustment is in place?
In D26853#598685, @markmi_dsl-only.net wrote:reset = "/soc/firmware/reset";. . .
maciphone2_googlemail.com added a reviewer for D26853: RPI4: enable USB-boot for the 8GB-model etc: markmi_dsl-only.net.
this is a little abnormality in the dmesg, :
Sep 24 2020
Sep 24 2020
maciphone2_googlemail.com removed a reviewer for D26344: bcm2838_pci.c: Respect DMA limits of controller.: β’ karels.
In D26344#591180, @markmi_dsl-only.net wrote:As I have just reported on the arm list, the checked-in patch fails the huge file duplicate and diff/cmp test. xhci
DMA is still a problem.(I finally got things updated past head -r363590 to head -r365932 and finally re-ran the test in the new context.)
Sep 10 2020
Sep 10 2020
maciphone2_googlemail.com added a comment to D26344: bcm2838_pci.c: Respect DMA limits of controller..
In D26344#586745, @markmi_dsl-only.net wrote:.........
What OpenBSD did for the size of the DMA area for XHCI looks to be unusual (relative to NetBSD and Linux). But the next-to-last "node 0:" line above >does show not using the whole DMA32 range. (I do not now why they had it do that.)
Sep 9 2020
Sep 9 2020
maciphone2_googlemail.com added a comment to D26344: bcm2838_pci.c: Respect DMA limits of controller..
In D26344#585901, @crowston_protonmail.com wrote:I am very happy if there is a working alternative to this patch: it is probable that there is some further nuance of configuration around the >PCI-e DMA that I do not know.
Jun 25 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 16 2020
In D25068#553366, @andrew wrote:I've created D25121 to translate addresses in the base pci host generic driver. It also cleans up other memory management while there.
you both already know that D25068 is not yet compatible with D25121, right?
Jun 6 2020
Jun 6 2020
maciphone2_googlemail.com added a comment to D24085: sysutils/u-boot-rpi{3,4}: Add patch to fix PSCI stub reservation.
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
May 12 2020
Closed due to lack of interest on the part of the German translation project.
Apr 19 2020
Apr 19 2020
In D24436#538847, @karels wrote:Is there an existing example of FDT / ACPI split to use as a model?
Mar 15 2020
Mar 15 2020
maciphone2_googlemail.com added a comment to D24080: update java documentation / German translation.
Hi Greg,
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 .
Regards
Klaus
Mar 11 2020
Mar 11 2020
In D24003#527953, @glewis wrote:Thanks for doing this! Do you need help getting it committed?
Mar 9 2020
Mar 9 2020
Feb 9 2020
Feb 9 2020
5.5 dts import will be added in bulk by manu soon
In D23592#517717, @manu wrote:Note that we also use dtb from the rpi-firmware package for RPI* board.
Feb 1 2020
Feb 1 2020
In D15955#514299, @kevans wrote:Downloading last week's image, I'm actually seeing similar on a recent non-MMCCAM kernel. =-( Can you try that same revision with just GENERIC and see if you can reproduce these results?
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 31 2020
In D15955#514181, @kevans wrote:I don't follow this- how are you expecting it to work? What driver specifically are you referring to? I'm not aware of a proprietary brcmfmac driver for FreeBSD.
Jan 30 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
Dec 24 2019
maciphone2_googlemail.com updated the diff for D22360: initial linker support userland-DTrace aarch64.
from absolute to relative relocation type :
R_AARCH64_PREL64 instead of R_AARCH64_ABS64
as recommended by markj@
Dec 23 2019
Dec 23 2019
maciphone2_googlemail.com added a comment to D22360: initial linker support userland-DTrace aarch64.
In D22360#501797, @markj wrote:I tested the change and I can at least compile the USDT tests. There's no way to run them though since we do not have a fasttrap implementation for arm64. Do you have any plan to add one? It should be relatively straightforward to support USDT probes. (pid provider is more work.)
If you change the relocation type I'll commit.
maciphone2_googlemail.com added inline comments to D22360: initial linker support userland-DTrace aarch64.
maciphone2_googlemail.com added a reviewer for D22360: initial linker support userland-DTrace aarch64: glewis.
Nov 14 2019
Nov 14 2019
maciphone2_googlemail.com updated the diff for D22360: initial linker support userland-DTrace aarch64.
maciphone2_googlemail.com added inline comments to D22360: initial linker support userland-DTrace aarch64.
maciphone2_googlemail.com updated the diff for D22360: initial linker support userland-DTrace aarch64.
correction of missing leading tab (mentioned by Warner Losh, thank you )