"atsamv" BSP legacy network driver status

Fri Jan 31 12:39:08 UTC 2020

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

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

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.