In D36744#844436, @andrew wrote:

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 :

Hi,
reverting this commit 92e190f11fe8 fixed the build for me.
Regards
K.

ouch, my bad , sorry, accidentally was set to clang 6 :-)... upgrading now

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

@mhorne

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)

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 ...

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

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

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

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)

fixed in https://reviews.freebsd.org/R10:0b92d1dd18c148740cf00b985e8641ad1670ba87

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.

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.. .

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 :-)

@mhorne

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)

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.

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).

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";

. . .

this is a little abnormality in the dmesg, :

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.)

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.)

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.

... 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)

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?

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....

Closed due to lack of interest on the part of the German translation project.

In D24436#538847, @karels wrote:

Is there an existing example of FDT / ACPI split to use as a model?

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

In D24003#527953, @glewis wrote:

Thanks for doing this! Do you need help getting it committed?

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.

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..

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.

(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.

from absolute to relative relocation type :
R_AARCH64_PREL64 instead of R_AARCH64_ABS64
as recommended by markj@

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.

correction of missing leading tab (mentioned by Warner Losh, thank you )