Re: [U-Boot-Board-Maintainers] Raspberry pi 4 - u-boot - genet / scb
Sascha,
Am 07.12.19 um 07:23 schrieb Sascha Dewald:
Hello,
is there any progress yet ?
There is absolutely no reason to annoy all the board maintainers on this mailing list with nagging about an unimplemented driver for one board! Especially not with HTML mail and top-posting!!! Please take this discussion to the u-boot mailing list (Reply-to set).
Regards, Andreas
Am Fr., 22. Nov. 2019 um 00:27 Uhr schrieb André Przywara <andre.przywara@arm.com mailto:andre.przywara@arm.com>:
On 21/11/2019 21:46, Sascha Dewald wrote: Hi, > could someone give me a summary which is missing in u-boot and what > needs to be ported ? The PHY is pretty much standard and already supported, as far as I can see, the MAC is not. > I found other broadcom drivers, which are already in u-boot. The RPi4 uses a Broadcom GENETv5 IP (with a slight tweak). The Linux driver is quite sophisticated: it supports older revisions (v1..v4), makes clever use of multiple priority queues and is of course fully interrupt driven, including napi shortcuts, also enjoys all the glory of the full Linux driver framework galore. For U-Boot we can get away with a MUCH simpler driver. Amit and I spent a while understanding the hardware based on the Linux driver, and Amit saw the first ARP packet from U-Boot on his laptop yesterday. He is currently working on the recv() function. > How difficult is it, to strip the drivers down, from the linux kernel to > work with u-boot? As mentioned, stripping the driver down (as in copying and editing) is not a good idea, but the basic driver is already somewhat working (probing, instantiation, sending packets), so we are not far away. If I could ask for just for a few more days of patience, then I am looking forward for your help with review and testing! Cheers, Andre > Am Mi., 20. Nov. 2019 um 12:21 Uhr schrieb Andre Przywara > <andre.przywara@arm.com <mailto:andre.przywara@arm.com> <mailto:andre.przywara@arm.com <mailto:andre.przywara@arm.com>>>: > > On Wed, 20 Nov 2019 12:13:55 +0100 > Matthias Brugger <mbrugger@suse.com <mailto:mbrugger@suse.com> <mailto:mbrugger@suse.com <mailto:mbrugger@suse.com>>> wrote: > > Hi, > > > Adding Andre as he helps in the effort to port the driver. More > comments inline. > > > > On 19/11/2019 22:46, Heinrich Schuchardt wrote: > > > On 11/19/19 9:48 PM, Simon Glass wrote: > > >> Hi Sascha, > > >> > > >> On Tue, 19 Nov 2019 at 10:10, Sascha Dewald > <sascha.dewald@gmail.com <mailto:sascha.dewald@gmail.com> <mailto:sascha.dewald@gmail.com <mailto:sascha.dewald@gmail.com>>> wrote: > > >>> > > >>> Hi Simon, > > >>> > > >>> it uses bcmgenet. > > >>> > > >>> Below some information from "hwinfo" and "dmesg" > > >>> > > >> > > >> OK, well I think this is in linux as > drivers/net/ethernet/broadcom/genet > > >> > > >> I'm not sure about the PHY but it looks like there is no driver for > > >> genet in U-Boot. I suggest poriting it over. > > Amit (CC:ed) is working on that. That is still quite rough and not > really working yet, but as of yesterday he saw the first (empty) > packets on the line at least. > I would assume we get something working still this year. > > > > In linux-next/next-20191119 > > > arch/arm64/boot/dts/broadcom/bcm2711-rpi-4-b.dtb > > > there is no network device. > > > > > Florian send a new pull request, I think yesterday which adds the > genet driver > > to RPi4. > > I found the burst length quirk together with the new compatible > string in David's net-next/master two days ago. > > > > On Raspbian you can find for RPi4: > > > > > > compatible = "brcm,genet-v5" > > > relating to Linux drivers/net/ethernet/broadcom/genet/bcmgenet.c > > > CONFIG_BCMGENET "Broadcom GENET internal MAC support" > > > > > > > RPi4 is a special case as DMA burst size is different from plain > genet-v5 > > driver. But that might be of no relevance for U-Boot. > > Yeah, since there is no other user, we could just go ahead and fix > the smaller burst length of 8 in U-Boot. I guess we don't care about > the performance impact that has. > > Cheers, > Andre. > > > > > > compatible = "ethernet-phy-ieee802.3-c22"; > > > relating to Linux drivers/of/of_mdio.c. > > > CONFIG_OF_MDIO OpenFirmware MDIO bus (Ethernet PHY) accessors > > > > > > compatible = "brcm,genet-mdio-v5"; > > > relating to Linux drivers/net/phy/mdio-bcm-unimac.c > > > CONFIG_MDIO_BCM_UNIMAC "Broadcom UniMAC MDIO bus controller" > > > > > > So wouldn't we need all three drivers? > > > > > > Maybe Joe can tell us. > > > > > > Best regards > > > > > > Heinrich > > > > > > > > >> > > >> Regards, > > >> Simon > > >> _______________________________________________ > > >> U-Boot-Board-Maintainers mailing list > > >> U-Boot-Board-Maintainers@lists.denx.de <mailto:U-Boot-Board-Maintainers@lists.denx.de> > <mailto:U-Boot-Board-Maintainers@lists.denx.de <mailto:U-Boot-Board-Maintainers@lists.denx.de>> > > >> https://lists.denx.de/listinfo/u-boot-board-maintainers > > >> > > > >
Hmm, looks like the google webmail doesn't send multi-mime messages. I didn't know that yet.
And if there is no progress, then i would look for another solution. No problem :-)
Am Sa., 7. Dez. 2019 um 10:27 Uhr schrieb Andreas Färber afaerber@suse.de:
Sascha,
Am 07.12.19 um 07:23 schrieb Sascha Dewald:
Hello,
is there any progress yet ?
There is absolutely no reason to annoy all the board maintainers on this mailing list with nagging about an unimplemented driver for one board! Especially not with HTML mail and top-posting!!! Please take this discussion to the u-boot mailing list (Reply-to set).
Regards, Andreas
Am Fr., 22. Nov. 2019 um 00:27 Uhr schrieb André Przywara <andre.przywara@arm.com mailto:andre.przywara@arm.com>:
On 21/11/2019 21:46, Sascha Dewald wrote: Hi, > could someone give me a summary which is missing in u-boot and what > needs to be ported ? The PHY is pretty much standard and already supported, as far as I can see, the MAC is not. > I found other broadcom drivers, which are already in u-boot. The RPi4 uses a Broadcom GENETv5 IP (with a slight tweak). The Linux driver is quite sophisticated: it supports older revisions (v1..v4), makes clever use of multiple priority queues and is of course fully interrupt driven, including napi shortcuts, also enjoys all the glory of the full Linux driver framework galore. For U-Boot we can get away with a MUCH simpler driver. Amit and I spent a while understanding the hardware based on the Linux driver, and Amit saw the first ARP packet from U-Boot on his laptop yesterday. He is currently working on the recv() function. > How difficult is it, to strip the drivers down, from the linux kernel to > work with u-boot? As mentioned, stripping the driver down (as in copying and editing) is not a good idea, but the basic driver is already somewhat working (probing, instantiation, sending packets), so we are not far away. If I could ask for just for a few more days of patience, then I am looking forward for your help with review and testing! Cheers, Andre > Am Mi., 20. Nov. 2019 um 12:21 Uhr schrieb Andre Przywara > <andre.przywara@arm.com <mailto:andre.przywara@arm.com> <mailto:andre.przywara@arm.com <mailto:andre.przywara@arm.com>>>: > > On Wed, 20 Nov 2019 12:13:55 +0100 > Matthias Brugger <mbrugger@suse.com <mailto:mbrugger@suse.com> <mailto:mbrugger@suse.com <mailto:mbrugger@suse.com>>> wrote: > > Hi, > > > Adding Andre as he helps in the effort to port the driver. More > comments inline. > > > > On 19/11/2019 22:46, Heinrich Schuchardt wrote: > > > On 11/19/19 9:48 PM, Simon Glass wrote: > > >> Hi Sascha, > > >> > > >> On Tue, 19 Nov 2019 at 10:10, Sascha Dewald > <sascha.dewald@gmail.com <mailto:sascha.dewald@gmail.com> <mailto:sascha.dewald@gmail.com <mailto:sascha.dewald@gmail.com>>> wrote: > > >>> > > >>> Hi Simon, > > >>> > > >>> it uses bcmgenet. > > >>> > > >>> Below some information from "hwinfo" and "dmesg" > > >>> > > >> > > >> OK, well I think this is in linux as > drivers/net/ethernet/broadcom/genet > > >> > > >> I'm not sure about the PHY but it looks like there is no driver for > > >> genet in U-Boot. I suggest poriting it over. > > Amit (CC:ed) is working on that. That is still quite rough and not > really working yet, but as of yesterday he saw the first (empty) > packets on the line at least. > I would assume we get something working still this year. > > > > In linux-next/next-20191119 > > > arch/arm64/boot/dts/broadcom/bcm2711-rpi-4-b.dtb > > > there is no network device. > > > > > Florian send a new pull request, I think yesterday which adds the > genet driver > > to RPi4. > > I found the burst length quirk together with the new compatible > string in David's net-next/master two days ago. > > > > On Raspbian you can find for RPi4: > > > > > > compatible = "brcm,genet-v5" > > > relating to Linux drivers/net/ethernet/broadcom/genet/bcmgenet.c > > > CONFIG_BCMGENET "Broadcom GENET internal MAC support" > > > > > > > RPi4 is a special case as DMA burst size is different from plain > genet-v5 > > driver. But that might be of no relevance for U-Boot. > > Yeah, since there is no other user, we could just go ahead and fix > the smaller burst length of 8 in U-Boot. I guess we don't care about > the performance impact that has. > > Cheers, > Andre. > > > > > > compatible = "ethernet-phy-ieee802.3-c22"; > > > relating to Linux drivers/of/of_mdio.c. > > > CONFIG_OF_MDIO OpenFirmware MDIO bus (Ethernet PHY) accessors > > > > > > compatible = "brcm,genet-mdio-v5"; > > > relating to Linux drivers/net/phy/mdio-bcm-unimac.c > > > CONFIG_MDIO_BCM_UNIMAC "Broadcom UniMAC MDIO bus controller" > > > > > > So wouldn't we need all three drivers? > > > > > > Maybe Joe can tell us. > > > > > > Best regards > > > > > > Heinrich > > > > > > > > >> > > >> Regards, > > >> Simon > > >> _______________________________________________ > > >> U-Boot-Board-Maintainers mailing list > > >> U-Boot-Board-Maintainers@lists.denx.de <mailto:U-Boot-Board-Maintainers@lists.denx.de> > <mailto:U-Boot-Board-Maintainers@lists.denx.de <mailto:U-Boot-Board-Maintainers@lists.denx.de>> > > >> https://lists.denx.de/listinfo/u-boot-board-maintainers > > >> > > > >-- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
Hello Sascha,
Am 07.12.19 um 07:23 schrieb Sascha Dewald:
Hello,
is there any progress yet ?
Sorry for being late on this.
We have made some progress, ping from RPI to host is working now. Also, managed to received short files(< 63KB) via TFTP. but haven't managed to get proper handshaking going(that would enable us to receive bigger files too).
Working on it and keep you posted about the progress.
Thanks -Amit
Hello Amit,
no problem.
Is there some git feature branch, to have a look ?
Thank you Sascha
Am Mo., 9. Dez. 2019 um 12:12 Uhr schrieb Amit Tomer amittomer25@gmail.com:
Hello Sascha,
Am 07.12.19 um 07:23 schrieb Sascha Dewald:
Hello,
is there any progress yet ?
Sorry for being late on this.
We have made some progress, ping from RPI to host is working now. Also, managed to received short files(< 63KB) via TFTP. but haven't managed to get proper handshaking going(that would enable us to receive bigger files too).
Working on it and keep you posted about the progress.
Thanks -Amit
Hi all,
On 09/12/2019 14:33, Sascha Dewald wrote:
Hello Amit,
no problem.
Is there some git feature branch, to have a look ?
Yes I'd love to have a look as well :)
Regards, Matthias
Thank you Sascha
Am Mo., 9. Dez. 2019 um 12:12 Uhr schrieb Amit Tomer amittomer25@gmail.com:
Hello Sascha,
Am 07.12.19 um 07:23 schrieb Sascha Dewald:
Hello,
is there any progress yet ?
Sorry for being late on this.
We have made some progress, ping from RPI to host is working now. Also, managed to received short files(< 63KB) via TFTP. but haven't managed to get proper handshaking going(that would enable us to receive bigger files too).
Working on it and keep you posted about the progress.
Thanks -Amit
On Wed, 11 Dec 2019 10:23:16 +0100 Matthias Brugger matthias.bgg@gmail.com wrote:
Hi,
On 09/12/2019 14:33, Sascha Dewald wrote:
Hello Amit,
no problem.
Is there some git feature branch, to have a look ?
Yes I'd love to have a look as well :)
We will send an RFC later this week, Amit is doing some cleanup now. At the moment transfers work up to 256 packets (375KB when using TFTP), at this point it breaks, because recycling DMA descriptors is not working for some reason. I haven't found any documentation for the MAC, so I am reverse engineering the Linux driver and doing printf and tcpdump debugging right now. Looking forward to people joining us in this effort ;-)
Cheers, Andre
Am Mo., 9. Dez. 2019 um 12:12 Uhr schrieb Amit Tomer amittomer25@gmail.com:
Hello Sascha,
Am 07.12.19 um 07:23 schrieb Sascha Dewald:
Hello,
is there any progress yet ?
Sorry for being late on this.
We have made some progress, ping from RPI to host is working now. Also, managed to received short files(< 63KB) via TFTP. but haven't managed to get proper handshaking going(that would enable us to receive bigger files too).
Working on it and keep you posted about the progress.
Thanks -Amit
On 12/12/2019 11:41, Andre Przywara wrote:
On Wed, 11 Dec 2019 10:23:16 +0100 Matthias Brugger matthias.bgg@gmail.com wrote:
Hi,
On 09/12/2019 14:33, Sascha Dewald wrote:
Hello Amit,
no problem.
Is there some git feature branch, to have a look ?
Yes I'd love to have a look as well :)
We will send an RFC later this week, Amit is doing some cleanup now. At the moment transfers work up to 256 packets (375KB when using TFTP), at this point it breaks, because recycling DMA descriptors is not working for some reason. I haven't found any documentation for the MAC, so I am reverse engineering the Linux driver and doing printf and tcpdump debugging right now. Looking forward to people joining us in this effort ;-)
Thanks for the update. I CC'ed Florian who I think is the SW expert on that chip. Maybe he can help you.
Regards, Matthias
Cheers, Andre
Am Mo., 9. Dez. 2019 um 12:12 Uhr schrieb Amit Tomer amittomer25@gmail.com:
Hello Sascha,
Am 07.12.19 um 07:23 schrieb Sascha Dewald: > Hello, > > is there any progress yet ?
Sorry for being late on this.
We have made some progress, ping from RPI to host is working now. Also, managed to received short files(< 63KB) via TFTP. but haven't managed to get proper handshaking going(that would enable us to receive bigger files too).
Working on it and keep you posted about the progress.
Thanks -Amit
On 12/12/19 3:59 AM, Matthias Brugger wrote:
On 12/12/2019 11:41, Andre Przywara wrote:
On Wed, 11 Dec 2019 10:23:16 +0100 Matthias Brugger matthias.bgg@gmail.com wrote:
Hi,
On 09/12/2019 14:33, Sascha Dewald wrote:
Hello Amit,
no problem.
Is there some git feature branch, to have a look ?
Yes I'd love to have a look as well :)
We will send an RFC later this week, Amit is doing some cleanup now. At the moment transfers work up to 256 packets (375KB when using TFTP), at this point it breaks, because recycling DMA descriptors is not working for some reason. I haven't found any documentation for the MAC, so I am reverse engineering the Linux driver and doing printf and tcpdump debugging right now. Looking forward to people joining us in this effort ;-)
Thanks for the update. I CC'ed Florian who I think is the SW expert on that chip. Maybe he can help you.
Transfers work for up to 256 packets in which direction? Are you properly consuming descriptors that were produced by the RDMA (on receive), conversely, polling the TDMA consumer index on transmit? Can you share your code somewhere so I could see if there are obvious problems?
On Thu, 12 Dec 2019 10:13:27 -0800 Florian Fainelli f.fainelli@gmail.com wrote:
Hi Florian,
thanks for chiming in!
On 12/12/19 3:59 AM, Matthias Brugger wrote:
On 12/12/2019 11:41, Andre Przywara wrote:
On Wed, 11 Dec 2019 10:23:16 +0100 Matthias Brugger matthias.bgg@gmail.com wrote:
Hi,
On 09/12/2019 14:33, Sascha Dewald wrote:
Hello Amit,
no problem.
Is there some git feature branch, to have a look ?
Yes I'd love to have a look as well :)
We will send an RFC later this week, Amit is doing some cleanup now. At the moment transfers work up to 256 packets (375KB when using TFTP), at this point it breaks, because recycling DMA descriptors is not working for some reason. I haven't found any documentation for the MAC, so I am reverse engineering the Linux driver and doing printf and tcpdump debugging right now. Looking forward to people joining us in this effort ;-)
Thanks for the update. I CC'ed Florian who I think is the SW expert on that chip. Maybe he can help you.
Transfers work for up to 256 packets in which direction? Are you properly consuming descriptors that were produced by the RDMA (on receive),
Yes, not sure we do it properly, but we do.
The problem I see is that the TDMA_CONS_INDEX does not increase after it reaches 256, although RDMA_PROD_INDEX does. Is there any cleanup in the actual descriptors needed? Did I get this right that those indices are just linear "progress counters", and not actual descriptor indices? I see the Linux code masks them with 0xffff, not with the number of descriptors.
Will try to dig a bit deeper on this.
conversely, polling the TDMA consumer index on transmit?
Yes, I switched over to that (from polling for the DMA_OWN bit).
Can you share your code somewhere so I could see if there are obvious problems?
Of course, we just need to clean it up a bit, and it's getting late for Amit today. We will CC: you on the post tomorrow.
Thanks for you help!
Cheers, Andre.
On 12/12/19 10:38 AM, Andre Przywara wrote:
On Thu, 12 Dec 2019 10:13:27 -0800 Florian Fainelli f.fainelli@gmail.com wrote:
Hi Florian,
thanks for chiming in!
On 12/12/19 3:59 AM, Matthias Brugger wrote:
On 12/12/2019 11:41, Andre Przywara wrote:
On Wed, 11 Dec 2019 10:23:16 +0100 Matthias Brugger matthias.bgg@gmail.com wrote:
Hi,
On 09/12/2019 14:33, Sascha Dewald wrote:
Hello Amit,
no problem.
Is there some git feature branch, to have a look ?
Yes I'd love to have a look as well :)
We will send an RFC later this week, Amit is doing some cleanup now. At the moment transfers work up to 256 packets (375KB when using TFTP), at this point it breaks, because recycling DMA descriptors is not working for some reason. I haven't found any documentation for the MAC, so I am reverse engineering the Linux driver and doing printf and tcpdump debugging right now. Looking forward to people joining us in this effort ;-)
Thanks for the update. I CC'ed Florian who I think is the SW expert on that chip. Maybe he can help you.
Transfers work for up to 256 packets in which direction? Are you properly consuming descriptors that were produced by the RDMA (on receive),
Yes, not sure we do it properly, but we do.
The problem I see is that the TDMA_CONS_INDEX does not increase after it reaches 256, although RDMA_PROD_INDEX does. Is there any cleanup in the actual descriptors needed?
There is no explicit mention or description that the CPU should be polling the TDMA_CONS_INDEX and that this is being used by the HW as an indication to release the buffers, they should continue to increase linearly and wrap around. There must be something else that prevents the TDMA from making further progress.
How did you configure the TDMA start address/read/write pointers/size and do you use the same mode as the Linux driver which is on-chip descriptor ring (1 << 16 in TDMA_RING_CFG).
Can you start with as many as 2 buffers, copy whatever you get from the u-boot network stack (if you can't do zero copy TX) and see if wrapping around/recycling works properly?
Another possibility would be if you don't properly set the EOF/SOF on every packet you send, and it is waiting for that "last packet with the EOF flag set" could hold up TX for a while.
Did I get this right that those indices are just linear "progress counters", and not actual descriptor indices? I see the Linux code masks them with 0xffff, not with the number of descriptors.
They are linear progress counters of how many buffers the CPU produced, and how many buffers the GENET hardware consumed (and vice versa for RDMA).
Will try to dig a bit deeper on this.
conversely, polling the TDMA consumer index on transmit?
Yes, I switched over to that (from polling for the DMA_OWN bit).
Yes that is not going to work, there may have been older versions of GENET that did write back the descriptor flags back into memory, but the version in the Pi4 certainly does not do that to the best of my knowledge.
The hardware would not also tell you whether there were errors during transmit on per-packet basis but you may be able to extract the transmit vector bits out of the GENET_TBUF register space. That would give you access to the raw transmit status vector between the TDMA and UniMAC (the part that does the framing) but it would be just for the last packet basically.
Hope this helps...
participants (6)
-
Amit Tomer -
Andre Przywara -
Andreas Färber -
Florian Fainelli -
Matthias Brugger -
Sascha Dewald