"atsamv" BSP legacy network driver status

Christian Mauderer christian.mauderer at embedded-brains.de
Fri Jan 31 12:45:24 UTC 2020 

On 31/01/2020 13:39, dufault at hda.com wrote:
> 
> 
>> On Jan 31, 2020, at 01:31 , Christian Mauderer <christian.mauderer at embedded-brains.de> wrote:
>>
>> On 30/01/2020 22:12, dufault at hda.com wrote:
>>>
>>>
>>>> On Jan 30, 2020, at 01:24 , Christian Mauderer <christian.mauderer at embedded-brains.de> wrote:
>>>>
>>>> The SDRAM initialization is done in bsp_start_hook_0. Most
>>>> initialization is done in bsp_start_hook_1. You should be able to put
>>>> the following into SDRAM without problems:
>>>>
>>>> - REGION_WORK
>>>> - REGION_BSS
>>>> - REGION_DATA
>>>> - REGION_STACK
>>>>
>>>> If that's not enough, I would have to take a more detailed look.
>>>>
>>>> Best regards
>>>>
>>>> Christian
>>>
>>> Is it possible that the latest "SAMV71 "Xplained" Ultra" board doesn't work? Details:
>>>
>>> Putting those sections into SDRAM worked perfectly, perfectly enough to duplicate the problem I had with the legacy stack using the "libbsd" stack.  The symptoms are the same:
>>>
>>> - The network stack is initialized.
>>> - The network stack is receiving incoming packets.
>>> - No transmit packets are sent out.  The software is trying to send out packets but they never go out.
>>>
>>> I'm looking at two of many possibilities as most likely.
>>> 1. Do I have the media setup mis-configured so it can't transmit?
>>> -- Unlikely if that's the case since it's receiving.
>>> -- In the case of using the "libbsd" stack I'm using "ifconfig if-atsam0 (ip-address) netmask (netmask) media 100TX up", and it starts receiving packets but not sending.
>>
>> Just an idea: With Ethernet I have already seen hardware bugs that lead
>> to the effect that a device wouldn't work on one switch but worked
>> completely fine on another. Such stuff can also have an influence on the
>> direction. Did you test stuff like connecting to another switch, maybe
>> using another speed (10MBit), connecting to a PC directly, ...
>>
>>> 2. The second possibility.  I'm looking at this now, and I'm sending the email so that you can tell me to stop wasting my time.
>>>
>>> Is it possible this is related to not initializing transmit FIFOS?  My google searches have turned up really similar situations associated with not initializing registers for queues that I don't think exist.
>>>
>>> I haven't sorted this out yet but look at:
>>> https://www.avrfreaks.net/comment/2648206#comment-2648206
>>> "I found the problem, at least in the ASF4 code base for Revision B chips
>>> The Revision B chips have 6 priority transmit fifos (there is an errata regarding this for the Rev A chips)
>>> Each of these fifos have to be initialized before sending can occur, Atmel tried to do this at the end ..."
>>> I went to ... because it doesn't apply after this point.
>>
>> If that is a problem with newer chips, that is a quite possible reason.
>> From a quick look into the driver it seems that we only initialize three
>> queues. I also had a quick look at one of the customer boards we have
>> and it seems to be a revision A chip.
>>
>> Revision A chips seem to have only three queues even if the data sheet
>> describes 6. So that could match too.
>>
>> It seems that our driver sets up the queues with the same buffer. Have
>> you tried just adding the remaining 3 buffers below the lines
>>
>>    	GMAC_SetRxQueue(pHw, (uint32_t)buffer_desc, 1);
>> 	GMAC_SetRxQueue(pHw, (uint32_t)buffer_desc, 2);
>>
>> and
>>
>> 	GMAC_SetTxQueue(pHw, (uint32_t)buffer_desc, 1);
>> 	GMAC_SetTxQueue(pHw, (uint32_t)buffer_desc, 2);
>>
>> There is a CHIPID_CIDR.VERSION register that gives the chip revision. So
>> if that works, it maybe would be good to do that only for chips with
>> this field set to revision B and newer (value >= 0x1).
>>
>>>
>>> The newest Microchip / Atmel support package, the one that the "atsamv" BSP is *not* based on (and that is totally, totally reorganized and will be difficult to rebase on) includes "dummy buffers for unconfigured queues".
>>
>> Yes, I know. It's really annoying that the new library isn't compatible.
>> I think that discussion popped up two or three times on the list. It
>> would be great if someone would have the time for an upgrade.
>>
>>>
>>>    for (i = 0; i < GMAC_QUEUE_COUNT; i++) {
>>>        gmacd_setup_queue(gmacd, i,
>>>                DUMMY_BUFFERS, dummy_buffer, dummy_rx_desc,
>>>                DUMMY_BUFFERS, dummy_buffer, dummy_tx_desc,
>>>                NULL);
>>>    }
>>>
>>> So, as I said:
>>>
>>> Is it possible that the latest "SAMV71 "Xplained" Ultra" board doesn't work? 
>>
>> I would say that it is possible.
>>
>> Best regards
>>
>> Christian
>>
>>>
>>> Peter
>>> -----------------
>>> Peter Dufault
>>> HD Associates, Inc.      Software and System Engineering
>>>
>>> This email is delivered through the public internet using protocols subject to interception and tampering.
>>>
>>
>> -- 
>> --------------------------------------------
>> embedded brains GmbH
>> Herr Christian Mauderer
>> Dornierstr. 4
>> D-82178 Puchheim
>> Germany
>> email: christian.mauderer at embedded-brains.de
>> Phone: +49-89-18 94 741 - 18
>> Fax:   +49-89-18 94 741 - 08
>> PGP: Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> 
> SHGL [/] # ping 192.168.240.4
> PING 192.168.240.4 (192.168.240.4): 56 data bytes
> 64 bytes from 192.168.240.4: icmp_seq=0 ttl=64 time=0.994 ms
> 64 bytes from 192.168.240.4: icmp_seq=1 ttl=64 time=0.729 ms
> 64 bytes from 192.168.240.4: icmp_seq=2 ttl=64 time=0.732 ms
> 
> --- 192.168.240.4 ping statistics ---
> 3 packets transmitted, 3 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev = 0.729/0.818/0.994/0.124 ms
> SHGL [/] # 
> 
> Well, that was an adventure.  I've been doing this in my spare time since my customer is now planning to use either the NXP i.MX RT1050 or 1060, but I did want to see this work.  I'll verify this will now also work with the legacy driver since the footprint is so much smaller.
> 
> I'll look at putting together a patch that:
> - Adds another linkscript that uses the SDRAM.  That has the advantage of working out-of-the-box with "libbsd" on the SAMV71 "Xplained" Ultra.  Note that you will get overflows, though, when building some of the tests in "libbsd".
> - Initializes the additional queues for non rev A chips.
> - Fixes the situation in the legacy driver where the hardware address isn't specified in the configuration.
> - Any other minor item I've forgotten about.
>

Sounds great. Thanks for the work.

> I'll get to it as time permits.  I have to start looking at creating an i.MX RT10x0 BSP.

Take your time. I currently don't know of other reports regarding this
so I don't think that there is any need to hurry.

Best regards

Christian

>
> Peter
> -----------------
> Peter Dufault
> HD Associates, Inc.      Software and System Engineering
> 
> This email is delivered through the public internet using protocols subject to interception and tampering.
> 

-- 
--------------------------------------------
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

More information about the devel mailing list