the RPI4 is special in behavior on different hardware-revisions , so compiling this dts adds a special dtb to be able to boot from USB on the 8GB-model and fix some other issues like USB-hotplugging which I experienced on the old dtb...
this is for the upcoming u-boot 2020.10 and requires an eeprom - update. an update to the latest RPI-firmware is also required.Driver developers can absolutely feel free to adjust this diff for their needs,
since this is an unchanged decompilation of an existing dtb from another OS.
there was no license added, everybody here who is familiar with licenses can feel free to add any license , which you assume to be right:-)
Because of the special behavior ofnthe RPI4 I thought it's better to overwrite in the arm64-directory to hold the arm-directory rpi4-dtb free for future updates. Since these RPi4-dts wasn't compiled for any FreeBSD-release , this diff doesn't touch any compilation, instead compilation has to be done manually.
Details
https://dmesgd.nycbug.org/index.cgi?do=view&id=5719
also tested by Andy McClements on the mailing list :
https://dmesgd.nycbug.org/index.cgi?do=view&id=5856
https://dmesgd.nycbug.org/index.cgi?do=view&id=5857
https://dmesgd.nycbug.org/index.cgi?do=view&id=5858
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
this is a little abnormality in the dmesg, :
pci0: failed to allocate bus number
device_attach: pci0 attach returned 6
I invite Mark Millard to let go of his merciless huge-file-copy-tests on the poor board if he feels like it :-)
Ignoring what appears to be general, systematic phandle and phy-handle numbering differences, the following appears to be what this has changed vs. a fairly modern firmware's .dtb file. I'll start with the completely new additions it made:
. . .
reset = "/soc/firmware/reset";
. . .
pci@1,0 {
#address-cells = <0x3>;
#size-cells = <0x2>;
ranges;
reg = <0x0 0x0 0x0 0x0 0x0>;
usb@1,0 {
reg = <0x10000 0x0 0x0 0x0 0x0>;
resets = <0x2b 0x0>;
};
};
. . .
reset {
#reset-cells = <0x1>;
compatible = "raspberrypi,firmware-reset";
phandle = <0x2b>;
};
. . .It omits a:
mmc-ddr-3_3v;
that was in the fairly modern firmware's .dtb .
I did the comparison via using the likes of:
dtc -O dtb -I dts -o rpi4-alt-modern.dtb rpi4-alt-modern.dts dtc -o - -O dts -I dtb -s rpi4-alt-modern.dtb > rpi4-alt-modern-sorted.dts
so that the .dts is sorted, making diffing sorted .dts files reasonable for doing comparisons.
I then diff'd that with a previously generated sorted .dts for fairly modern firmware.
(There is also the route of using fdt addr ???; fdt print / in u-boot that shows what firmware, armstub*.bin, and u-boot change/add/remove but sorting is a separate step.)
I'm well outside my depth here, but it seems that Linux and FreeBSD code manage the 8GiByte xHCI/USB3 issue without needing such .dtb file additions. (This is at a later stage, u-boot having used a microsd card to get the OS kernel loaded and the OS kernel then works okay with the 8GiByte RPi4B xHCI/USB3, unlike u-boot, and not needing the updated .dtb file to do so.) This means I'm unsure if the upstream FreeBSD uses would be likely to accept such a change.
I also have no specific clue what the original license terms were for the decompiled .dtb file or which OS the .dtb was from.
https://github.com/u-boot/u-boot/commit/f676eb217bdff3bd734a42c8f9bbc58c9100055c
on newer board revisions a dedicated chip which holded the VL805-firmware was removed,
so u-boot needs to be instructed to reset the controller to load the firmware from the VideoCore in a very early stage(before the OS itself
initializes the driver).that early stage is when bcm2711-rpi-4-b.dtb is loaded.
that`s why we go inside depth here ;-), so : no, it's simply not managed without loaded dtb . the dtb IS the management of DeviceTree , that's why you will see the following without it being loaded :
starting USB... Bus xhci_pci: probe failed, error -110
with this patch there's no SD-card needed, just a straight SSD-bootup, fast as a rocket(fastet ever seen on such cheap boards) .
of course u-boot wouldn`t' need an early stage xhci-reset when it boots from an SD-card :-)
I´m ver sure that such a change is an absolut requirement to manage the machine properly and get the DeviceTree under control by sourceCode instead of loading strange dtbs from anywhere
since almost every dtb uses the GPL 2.0 I would suggest to add that license (while that should be recommended by someone who has a clue about licenses, so I didn't yet do it myself).
. . .
of course u-boot wouldn`t' need an early stage xhci-reset when it boots from an SD-card
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?
the DeviceTree is loaded before u-boot(and the kernel) , so in this case it can trigger the firmware-load.
It's an RPI4 hardware quirk on newer board-revisions.
I know it is specific to the newer RPi4B's. But if the Device Tree the kernel now sees and uses does not have the change for the kernel to deal with VL805 firmware initialization, why can not u-boot do the same with the same device tree? The above does not explain what distinction(s) cause u-boot to need a different Device Tree from what the kernel can work with already.
I wrote the logic to handle the VL805 firmware loading in D25261.
My implementation is hardcoded and only relies on the DTB to determine if the driver is running on a Raspberry Pi 4 computer or not. I do not think much is gained by relying on the DTB for anything else. 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.
It may not be strictly necessary, but I believe that after the PCI controller is reset, the firmware should be reloaded. If using bcm2838_pci, a reset happens early in the driver attach call.
All in all I think this change to the DTB is orthogonal to my approach.
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#599130, @crowston_protonmail.com wrote:
It may not be strictly necessary, but I believe that after the PCI controller is reset, the firmware should be reloaded. If using bcm2838_pci, a reset happens early in the >driver attach call.
side note ..... :
pci0: <PCI bus> on pcib0 pci0: failed to allocate bus number device_attach: pci0 attach returned 6
in https://dmesgd.nycbug.org/index.cgi?do=view&id=5719
! In D26853#599130, @crowston_protonmail.com wrote:
All in all I think this change to the DTB is orthogonal to my approach.
great! side note : after this patch the machine did not freeze anymore by hotplugging e.g. an USB-keyboard.
with the old dtb it crashed.
Ahh, gradual understanding on my part. Thanks.
It looks like the .dts file change was checked into github.com/torvalds/linux/commits/master/arch/arm/boot/dts/bcm2711-rpi-4-b.dts on 2020-Aug-18 as 258f92d (and partially via prior checkins as well?).
It has not made it into Linux 5.9.1 or the like yet from what I can tell. It is normally some time before such things propagate to the rpi distribution materials (or even directly to imported .dts* definitions from Linux). And more time to propagate form rpi materials into the FreeBSD sysutils/rpi-firmware port. But what you report appears to indicate that u-boot 2020.10 looks to be ready for the change as is. Cool if true.
For your side note: A comparison/contrast. Your linked material shows:
pcib0: <BCM2838-compatible PCI-express controller> mem 0x7d500000-0x7d50930f irq 70,71 on simplebus2 pcib0: hardware identifies as revision 0x304. pci1: <PCI bus> on pcib0 pcib1: <PCI-PCI bridge> irq 81 at device 0.0 on pci1 pci2: <PCI bus> on pcib1 bcm_xhci0: <VL805 USB 3.0 controller (on the Raspberry Pi 4b)> irq 82 at device 0.0 on pci2 bcm_xhci0: 32 bytes context size, 64-bit DMA usbus0 on bcm_xhci0 pci0: <PCI bus> on pcib0 pci0: failed to allocate bus number device_attach: pci0 attach returned 6
But what I get from my boot (indirectly via a microsd card and use of modern released-firmware's .dtb) is:
pcib0: <BCM2838-compatible PCI-express controller> mem 0x7d500000-0x7d50930f irq 70,71 on simplebus2 pcib0: hardware identifies as revision 0x304. pci0: <PCI bus> on pcib0 pcib1: <PCI-PCI bridge> irq 81 at device 0.0 on pci0 pci1: <PCI bus> on pcib1 bcm_xhci0: <VL805 USB 3.0 controller (on the Raspberry Pi 4b)> irq 82 at device 0.0 on pci1 bcm_xhci0: 32 bytes context size, 64-bit DMA usbus0 on bcm_xhci0
So the first differences are:
Your context: "pci1: <PCI bus> on pcib0" (no pci0 shown at this stage)
My context has instead: "pci0: <PCI bus> on pcib0"
In general, mine has pci0 and pci1 but yours has pci1 and pci2 --and then later also has a pci0 that gets the complaint. (So 3 pciN's, not 2.)
(Not that I understand any implications of the differences but I thought that the extra context might help someone.)
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.
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 :-)
Still wrong since this dtb isn't used for the images.
Also mail on the ML seems to indicate a u-boot problem and u-boot will never use this DTB.
right, that's why I would recommend to use this or another dtb instead of the one you use,
because it fixes the following error(reported on the mailing list) on the 8GB model :
starting USB... Bus xhci_pci: probe failed, error -110 No working controllers found
@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.
I obviously forgot that u-boot on RPI uses the DTB loaded by the firmware.
Anyway, no way that we're modifying this DTB here and no way that I diff what change is needed.
Does the pristine DTB from gnu/dts works ?
If not what changes are needed to make it work ?
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 :
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/
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..
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.. .