"atsamv" BSP legacy network driver status

[dufault at hda.com]

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

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

    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? 

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.