[U-Boot-Board-Maintainers] Raspberry pi 4 - u-boot - genet / scb

[U-Boot-Board-Maintainers] Raspberry pi 4 - u-boot - genet / scb

[Andreas Färber]

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 at 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 at arm.com <mailto:andre.przywara@arm.com>
>     <mailto:andre.przywara at arm.com <mailto:andre.przywara@arm.com>>>:
>     >
>     >     On Wed, 20 Nov 2019 12:13:55 +0100
>     >     Matthias Brugger <mbrugger at suse.com <mailto:mbrugger@suse.com>
>     <mailto:mbrugger at 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 at gmail.com <mailto:sascha.dewald@gmail.com>
>     <mailto:sascha.dewald at 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 at 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)

[U-Boot-Board-Maintainers] Raspberry pi 4 - u-boot - genet / scb

[Sascha Dewald]

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 at 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 at arm.com <mailto:andre.przywara@arm.com>
> >     <mailto:andre.przywara at arm.com <mailto:andre.przywara@arm.com>>>:
> >     >
> >     >     On Wed, 20 Nov 2019 12:13:55 +0100
> >     >     Matthias Brugger <mbrugger at suse.com <mailto:mbrugger@suse.com>
> >     <mailto:mbrugger at 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 at gmail.com <mailto:sascha.dewald@gmail.com>
> >     <mailto:sascha.dewald at 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 at 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)

[U-Boot-Board-Maintainers] Raspberry pi 4 - u-boot - genet / scb

[Amit Tomer]

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

[U-Boot-Board-Maintainers] Raspberry pi 4 - u-boot - genet / scb

[Sascha Dewald]

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

[U-Boot-Board-Maintainers] Raspberry pi 4 - u-boot - genet / scb

[Matthias Brugger]

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

[U-Boot-Board-Maintainers] Raspberry pi 4 - u-boot - genet / scb

[Andre Przywara]

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  

[U-Boot-Board-Maintainers] Raspberry pi 4 - u-boot - genet / scb

[Matthias Brugger]

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  
> 

[U-Boot-Board-Maintainers] Raspberry pi 4 - u-boot - genet / scb

[Florian Fainelli]

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?
-- 
Florian

[U-Boot-Board-Maintainers] Raspberry pi 4 - u-boot - genet / scb

[Andre Przywara]

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.

[U-Boot-Board-Maintainers] Raspberry pi 4 - u-boot - genet / scb

[Florian Fainelli]

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