Message ID | 18c2eda6-6989-4b63-9f25-23defa9adf3d@samsung.com |
---|---|
State | New |
Headers | show |
Series | USB patch for rpi4 | expand |
On Mon, 2020-06-15 at 11:28 +0200, Sylwester Nawrocki wrote: > Hi, > > (Cc: Nicolas and Jim) Jim, FYI, this relates to u-boot's pcie-brcmstb implementation. > On 11.06.2020 11:18, Peter Robinson wrote: > > > > > I am trying to test v4 of your patch series for USB support on rpi4: > > > > > I am building u-boot 64-bit. Testing on a rpi4 B 1.2 board. But, USB > > > > > is > > > > > not working for me and wanted to see if you had any ideas. Are there > > > > > other dependencies other than just applying your patch series? > > > > > > > > > > I've pasted the u-boot console output below. > > > > > > > > > > From what I can tell this board does not need the VL805 firmware > > > > > > > > 1.2 rev boards do need the firmware loading patch series, not sure > > > > about any other patches. > > > > > > Are you sure? A colleague of mine said that it was in 1.4 that the flash > > > chip for the VL805 was removed. I can physically see that the flash > > > chip is on my board. > > > > Yes, I am sure, the 1.2 is for the 2/4Gb model with the changes that > > need the firmware loading, the 1.4 according to their rev docs is > > limited to the 8Gb model ATM. > > > > https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md > > I'm also using rev. 1.2 board and it has the flash chip mounted and doesn't > need the VL805 firmware loading patch series. The first comercially available board I've seen without the vl805 eeprom is the new 8GB variant. There should be an unpopulated chip just below the audio Jack. > > > In any case, I did figure out one thing that was going on. I was using > > > the rpi4 DTB as it came shipped with my board. I found that on the I strongly suggest you either use the Linux upstream device-tree or if not possible, the latest device-tree maintained by the rpi guys. For example the one available on their rpi-5.7.y branch. Lots has changed since they released the original device-tree and you're likely to run into issues like this one all over the place, if combining it with upstream code. > > > PCIe node there was a typo in the compatible string. I fixed that: > > > bus-range = <0x0 0x1>; > > > - compatible = "brcm,bcm7211-pcie", > > > "brcm,bcm7445-pcie", "brcm,pci-plat-dev"; > > > + compatible = "brcm,bcm2711-pcie", > > > "brcm,bcm7445-pcie", "brcm,pci-plat-dev"; > > > max-link-speed = <0x2>; > > > > > > ...and USB now starts up and works. > > I'm glad you figured it out. Sorry, I just read your e-mails now, > after 4 days holiday. > > In my patch set I used compatible as in mainline Linux kernel > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/controller/pcie-brcmstb.c#n1025 > > AFAICS there exist BCM7211 and BCM2711 SoCs and instead of modifying > devicetree we could also add another compatible string in the driver, > as shown below. > > There will likely be follow up patches adding proper support for other > Broadcom STB SoCs to the pcie_brcmstb driver, taking care of any possible > differences in the PCIe controller. > > ------8<----- > diff --git a/drivers/pci/pcie_brcmstb.c b/drivers/pci/pcie_brcmstb.c > index dade79e..ceae56a 100644 > --- a/drivers/pci/pcie_brcmstb.c > +++ b/drivers/pci/pcie_brcmstb.c > @@ -608,6 +608,7 @@ static const struct dm_pci_ops brcm_pcie_ops = { > }; > > static const struct udevice_id brcm_pcie_ids[] = { > + { .compatible = "brcm,bcm7211-pcie" }, > { .compatible = "brcm,bcm2711-pcie" }, > { } > }; > ------>8----- FYI There is a series adding bcm7211 support on Linux: https://lkml.org/lkml/2020/5/26/1154 Regards, Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200615/c4b4c069/attachment.sig>
On Mon, Jun 15, 2020 at 4:48 AM Nicolas Saenz Julienne <nsaenzjulienne at suse.de> wrote: > > On Mon, 2020-06-15 at 11:28 +0200, Sylwester Nawrocki wrote: > > Hi, > > > > (Cc: Nicolas and Jim) > > Jim, FYI, this relates to u-boot's pcie-brcmstb implementation. > > > On 11.06.2020 11:18, Peter Robinson wrote: > > > > > > I am trying to test v4 of your patch series for USB support on rpi4: > > > > > > I am building u-boot 64-bit. Testing on a rpi4 B 1.2 board. But, USB > > > > > > is > > > > > > not working for me and wanted to see if you had any ideas. Are there > > > > > > other dependencies other than just applying your patch series? > > > > > > > > > > > > I've pasted the u-boot console output below. > > > > > > > > > > > > From what I can tell this board does not need the VL805 firmware > > > > > > > > > > 1.2 rev boards do need the firmware loading patch series, not sure > > > > > about any other patches. > > > > > > > > Are you sure? A colleague of mine said that it was in 1.4 that the flash > > > > chip for the VL805 was removed. I can physically see that the flash > > > > chip is on my board. > > > > > > Yes, I am sure, the 1.2 is for the 2/4Gb model with the changes that > > > need the firmware loading, the 1.4 according to their rev docs is > > > limited to the 8Gb model ATM. > > > > > > > https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md > > > > I'm also using rev. 1.2 board and it has the flash chip mounted and doesn't > > need the VL805 firmware loading patch series. > > The first comercially available board I've seen without the vl805 eeprom is the > new 8GB variant. There should be an unpopulated chip just below the audio Jack. > > > > > In any case, I did figure out one thing that was going on. I was using > > > > the rpi4 DTB as it came shipped with my board. I found that on the > > I strongly suggest you either use the Linux upstream device-tree or if not > possible, the latest device-tree maintained by the rpi guys. For example the > one available on their rpi-5.7.y branch. > > Lots has changed since they released the original device-tree and you're likely > to run into issues like this one all over the place, if combining it with > upstream code. Thanks! Stuart
diff --git a/drivers/pci/pcie_brcmstb.c b/drivers/pci/pcie_brcmstb.c index dade79e..ceae56a 100644 --- a/drivers/pci/pcie_brcmstb.c +++ b/drivers/pci/pcie_brcmstb.c @@ -608,6 +608,7 @@ static const struct dm_pci_ops brcm_pcie_ops = { }; static const struct udevice_id brcm_pcie_ids[] = { + { .compatible = "brcm,bcm7211-pcie" }, { .compatible = "brcm,bcm2711-pcie" }, { } };