On 31/01/2020 13:39, dufa...@hda.com wrote: > > >> 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. >
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.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. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
