"atsamv" BSP legacy network driver status

[Christian Mauderer]

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.