[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 at 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 at 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