> On Jan 31, 2020, at 01:31 , Christian Mauderer > <christian.maude...@embedded-brains.de> wrote: > > On 30/01/2020 22:12, dufa...@hda.com wrote: >> >> >>> On Jan 30, 2020, at 01:24 , Christian Mauderer >>> <christian.maude...@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.maude...@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. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
