Report: FreeBSD on Rpi4 8 GB model

[Robert Crowston]

A fix for the XHCI firmware loading is here: https://reviews.freebsd.org/D25261
(It requires working PCI-E, which is in progress, here: https://reviews.freebsd.org/D25068)

A fix for the change to the phy-mode on the genet driver is here: https://reviews.freebsd.org/D25251

-- RHC.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, 10 June 2020 14:37, Klaus Küchemann <maciphone2 at googlemail.com> wrote:

>
>
> > Am 10.06.2020 um 01:16 schrieb Robert Crowston via freebsd-arm freebsd-arm at freebsd.org:
> > I figured out how to start the xhci driver.
> > The snag is, it seems the message to the VC to reinstall the xhci firmware has to be delivered after the bridge memory window is configured on the controller by the pci_pci bridge, and before the xhci controller is started.
> > That kind of ordering is not straightforward to arrange, as far as I can see: I cannot hack the message onto the end of the pcie attach function, since we need the bridge child to have attached, but not the xhci grandchild.
> > I think the best way then is to create a shim driver for the xhci controller whose probe() is designed only to succeed on the Rpi4. The shim's attach() will instruct the VC to load the xhci firmware, and then defer to the generic xhci_pci_attach(). All other methods will be inherited from the xhci_pci driver.
> > Another idea is to put the logic directly in the xhci_pci.c file, but I think creating a dependency out to the Rpi4 mailbox API from the generic XHCI framework is quite a hack.
> > Anyone have any thoughts?
>
> Since your driver is dedicated RPi4_ONLY your shim-if_bcm_thing sounds logical.
> Especially when we consider that you think that this is the best way,
> because nobody knows more about your driver than you :-)