Re: PR85 Question for Xiao Xiang
On Sun, Jan 12, 2020 at 2:20 AM Gregory Nutt wrote:
>
>
> > I fixed this section of code because it had ETIMEOUT instead of
> > ETIMEDOUT and so caused a compilation failure.
> >
> > Looking more carefully, net_timedwait() will return -ETIMEDOUT on the
> > timeout. So shouldn't the condition be (ret == -ETIMEDOUT && acked ==
> > state.snd_acked). I will change the code that way but I really need
> > your input.
> >
> > 701 for (; ; )
> > 702 {
> > 703 uint32_t acked = state.snd_acked;
> > 704
> > 705 ret = net_timedwait(&state.snd_sem,
> > 706 _SO_TIMEOUT(psock->s_sndtimeo));
> > 707 if (ret != -ETIMEDOUT || acked == state.snd_acked)
> > 708 {
> > 709 break; /* Timeout without any progress */
> > 710 }
> > 711 }
> >
> No, my suggested change is not right. But I don't understand the loop
> termination condition either. There is something wrong. Wouldn't ret
> always be -ETIMEDOUT if acked == state.snd_acked? The comment is wrong
> in any case.
>
The condition is good, but the comment just describe the one exit
criteria which make the confusion:
1.Exit if ret != -ETIMEDOUT which mean that the transfer is either
completed(OK) or interrupted(-EINTR)
2.Exit if ret == -ETIMEDOUT && acked == state.snd_acked which mean the
transfer stuck for a while
The only condition to continue the loop is:
ret == -ETIMEDOUT && acked != state.snd_acked
> We will merge PR85 with only the the change to the spelling of
> ETIMEDOUT, but could you please review the condition for exiting the
> loop (and whatever that should be, make it match the comments?).
>
> Greg
>
>
Nuttx and SPI when using a gate 74AHC1G125
Why is the CS not pulled low at the end? So it can receive the last 0xFF? When I bypass the gate it is working.. Using the gate it is not? Thanks Ben
Re: Nuttx and SPI when using a gate 74AHC1G125
Hi Ben, You need to describer better your issue and what you are trying to do. We cannot guess what is happening at your side. Normally the /CS should goes low before the SPI data transfer and should go high at end of the transfer. So if you are connecting it to 74AHC1G125 to /OE you should see the MOSI signal at the pin Y. Are you connecting the /CS at your other device that probably is connected to 74AHC1G125 ? BR, Alan On 1/12/20, disruptivesolution...@gmail.com wrote: > Why is the CS not pulled low at the end? So it can receive the last 0xFF? > > When I bypass the gate it is working.. Using the gate it is not? > > > > Thanks > > > > Ben > > > >
Re: Nuttx and SPI when using a gate 74AHC1G125
Hi Ben, I saw the circuit you sent privately to me. Actually you are using the 74AHC1G125 as buffer to MISO signal, not MOSI as I was thinking. I see no reason it is not working, did you try to change the SPI frequency? BR, Alan On 1/12/20, Alan Carvalho de Assis wrote: > Hi Ben, > > You need to describer better your issue and what you are trying to do. > We cannot guess what is happening at your side. > > Normally the /CS should goes low before the SPI data transfer and > should go high at end of the transfer. So if you are connecting it to > 74AHC1G125 to /OE you should see the MOSI signal at the pin Y. > > Are you connecting the /CS at your other device that probably is > connected to 74AHC1G125 ? > > BR, > > Alan > > On 1/12/20, disruptivesolution...@gmail.com > wrote: >> Why is the CS not pulled low at the end? So it can receive the last 0xFF? >> >> When I bypass the gate it is working.. Using the gate it is not? >> >> >> >> Thanks >> >> >> >> Ben >> >> >> >> >
Re: thttpd question (TCP close problem?)
It was a bug in thttpd – it wasn't accounting for the length of the headers properly. I'll make a PR for it once I get a few other issues worked out. The thttpd performance is a lot worse then uIP webserver– this shouldn't be the case. Maybe there is a resource bottleneck of some kind. I tried adjusting some of the config settings for sockets/file descriptors/etc. but haven't had any luck. I might have to profile the app. The first thing I would do would be to use Wireshark to see what exactly the timing on the network is.
Re: Nuttx and SPI when using a gate 74AHC1G125
Yes I did. It seems that every SPI board already has this functionality... its working when I bypass the gate. Verstuurd vanaf mijn iPhone > Op 12 jan. 2020 om 15:25 heeft Alan Carvalho de Assis het > volgende geschreven: > > Hi Ben, > > I saw the circuit you sent privately to me. Actually you are using the > 74AHC1G125 as buffer to MISO signal, not MOSI as I was thinking. > > I see no reason it is not working, did you try to change the SPI frequency? > > BR, > > Alan > >> On 1/12/20, Alan Carvalho de Assis wrote: >> Hi Ben, >> >> You need to describer better your issue and what you are trying to do. >> We cannot guess what is happening at your side. >> >> Normally the /CS should goes low before the SPI data transfer and >> should go high at end of the transfer. So if you are connecting it to >> 74AHC1G125 to /OE you should see the MOSI signal at the pin Y. >> >> Are you connecting the /CS at your other device that probably is >> connected to 74AHC1G125 ? >> >> BR, >> >> Alan >> >>> On 1/12/20, disruptivesolution...@gmail.com >>> wrote: >>> Why is the CS not pulled low at the end? So it can receive the last 0xFF? >>> >>> When I bypass the gate it is working.. Using the gate it is not? >>> >>> >>> >>> Thanks >>> >>> >>> >>> Ben >>> >>> >>> >>> >>
Re: thttpd question (TCP close problem?)
> The first thing I would do would be to use Wireshark to see what exactly > the timing on the network is. > Greg, Thanks- that sounds good. Would you be willing to say more about this? What exactly would you look for? I also plan to hook up a gigabit Ethernet from the board to my laptop to see if that has a higher speed, and also use the USB CDC ECM gadget with a Raspberry Pi Zero– I got the RPi's gadget driver working the other day while debugging the NuttX gadget driver. I want to see the differences in these setups. cheers adam -- Adam Feuer
Re: thttpd question (TCP close problem?)
The first thing I would do would be to use Wireshark to see what exactly the timing on the network is. Greg, Thanks- that sounds good. Would you be willing to say more about this? What exactly would you look for? You should see the connection, the HTTP requests and the HTTP responses, and the socket close sequence. More importantly, you will see the times between them and if there is anything weird going on like retransmissions.
Re: thttpd question (TCP close problem?)
Greg, Ok, thanks. I did do that yesterday with tcpdump while trying to find the closing-early problem with the header lengths. Now with the header length calculation things look good– at low speeds, the packet exchange matches what I am getting from a Linux web server. No retransmissions, resets, or missed ACKs. I will try a high-speed capture and examine it. I did try tcpblaster last night, and can only get about 100 KB/s maximum – about 800kbps, so much less than the 480Mbps that's possible. So that is probably part of the constraint. The SAMA5D36 has USB DMA.so it should be possible to get 100Mbps or higher... I will try with the Gigabit Ethernet and see if I can find the bottleneck. -adam On Sun, Jan 12, 2020 at 11:07 AM Gregory Nutt wrote: > > >> The first thing I would do would be to use Wireshark to see what exactly > >> the timing on the network is. > >> > > Greg, > > > > Thanks- that sounds good. Would you be willing to say more about this? > What > > exactly would you look for? > > You should see the connection, the HTTP requests and the HTTP responses, > and the socket close sequence. More importantly, you will see the times > between them and if there is anything weird going on like retransmissions. > > > -- Adam Feuer
Re: thttpd question (TCP close problem?)
Ok, thanks. I did do that yesterday with tcpdump while trying to find the closing-early problem with the header lengths. Now with the header length calculation things look good– at low speeds, the packet exchange matches what I am getting from a Linux web server. No retransmissions, resets, or missed ACKs. I will try a high-speed capture and examine it. I did try tcpblaster last night, and can only get about 100 KB/s maximum – about 800kbps, so much less than the 480Mbps that's possible. So that is probably part of the constraint. The SAMA5D36 has USB DMA.so it should be possible to get 100Mbps or higher... I will try with the Gigabit Ethernet and see if I can find the bottleneck. This might be useful to you: https://cwiki.apache.org/confluence/display/NUTTX/TCP+Network+Performance TCP blaster can be set up for sending to or receiving from the device. Which are you doing? I have verified NuttX TCP Tx performance with tcpblaster and found that it runs at about the maximum for the network I was using (I was using a slow, half duplex network). You are probably not being limited by the USB transfer rate, but by the network transfer rate. Well both should have and effect, but the (probably) network transfer rate at 100Mbit/sec is a lot lower than the USB transfer rate. 100KB/s is 800Kbit/sec which is considerably lower than the network transfer rate. Rx performance is more difficult to characterize.
Re: Nuttx and SPI when using a gate 74AHC1G125
On Sun, Jan 12, 2020 at 1:27 PM Disruptive Solutions wrote: > > Yes I did. It seems that every SPI board already has this functionality... > its working when I bypass the gate. > > Verstuurd vanaf mijn iPhone > > > Op 12 jan. 2020 om 15:25 heeft Alan Carvalho de Assis > > het volgende geschreven: > > > > Hi Ben, > > > > I saw the circuit you sent privately to me. Actually you are using the > > 74AHC1G125 as buffer to MISO signal, not MOSI as I was thinking. > > > > I see no reason it is not working, did you try to change the SPI frequency? > > > > BR, > > > > Alan > > > >> On 1/12/20, Alan Carvalho de Assis wrote: > >> Hi Ben, > >> > >> You need to describer better your issue and what you are trying to do. > >> We cannot guess what is happening at your side. > >> > >> Normally the /CS should goes low before the SPI data transfer and > >> should go high at end of the transfer. So if you are connecting it to > >> 74AHC1G125 to /OE you should see the MOSI signal at the pin Y. > >> > >> Are you connecting the /CS at your other device that probably is > >> connected to 74AHC1G125 ? > >> > >> BR, > >> > >> Alan > >> > >>> On 1/12/20, disruptivesolution...@gmail.com > >>> wrote: > >>> Why is the CS not pulled low at the end? So it can receive the last 0xFF? > >>> > >>> When I bypass the gate it is working.. Using the gate it is not? If you are switching the OE (Output Enable), it takes some non-zero amount of time for the device to switch from HighZ to driving the output and back. You might want to check if that is messing up the beginning or end (or both) of your communication. I've run into problems like this before and had to add some wait states to the firmware to work around it. If you have an oscilloscope available, you might want to try comparing the signals on the input and output pins of that HC125. Nathan
Re: thttpd question (TCP close problem?)
Thanks, that document is very helpful. I set up TCP Blaster as a client, not a server, just because it was easier for me to send data from Linux with netcat. I'll try it as a server, I just have to look up the right netcat params. I am glad to hear from you that's your experience was that NuttX is limited by the network. That's great! :) I do think high speed transfers should be possible using Ethernet over USB and I would love to get it working at close to the link speed of 480Mbps. That would really help for the application I'm building. Right now I'm trying to get the ethernet to work on the SAMA5D36-Xplained board. NuttX compiles, but the ethernet interfaces won't go up. I am using ETH0 with the GMAC and ETH1 with EMACA. I've set the PHYs as laid out in the README.txt. Not sure how to debug, but I am looking for how ifconfig tries to get the interface to come up... On Sun, Jan 12, 2020 at 11:28 AM Gregory Nutt wrote: > > > Ok, thanks. I did do that yesterday with tcpdump while trying to find the > > closing-early problem with the header lengths. Now with the header length > > calculation things look good– at low speeds, the packet exchange matches > > what I am getting from a Linux web server. No retransmissions, resets, or > > missed ACKs. I will try a high-speed capture and examine it. > > > > I did try tcpblaster last night, and can only get about 100 KB/s maximum > – > > about 800kbps, so much less than the 480Mbps that's possible. So that is > > probably part of the constraint. The SAMA5D36 has USB DMA.so it should be > > possible to get 100Mbps or higher... I will try with the Gigabit Ethernet > > and see if I can find the bottleneck. > > This might be useful to you: > https://cwiki.apache.org/confluence/display/NUTTX/TCP+Network+Performance > > TCP blaster can be set up for sending to or receiving from the device. > Which are you doing? > > I have verified NuttX TCP Tx performance with tcpblaster and found that > it runs at about the maximum for the network I was using (I was using a > slow, half duplex network). You are probably not being limited by the > USB transfer rate, but by the network transfer rate. Well both should > have and effect, but the (probably) network transfer rate at 100Mbit/sec > is a lot lower than the USB transfer rate. > > 100KB/s is 800Kbit/sec which is considerably lower than the network > transfer rate. > > Rx performance is more difficult to characterize. > > > > > -- Adam Feuer
Re: thttpd question (TCP close problem?)
Thanks, that document is very helpful. I set up TCP Blaster as a client, not a server, just because it was easier for me to send data from Linux with netcat. I'll try it as a server, I just have to look up the right netcat params. I am not sure if you should not use netcat. When you build apps/examples/tcpblaster it will build the matching host side of the test. Best to use the version generated by build/apps/examples/tcpblaster. It will leave the host program in the apps/examples/tcpblaster directory. The host program will be called either tcpclient or tcpserver, depending upon how you have the example configured. I am glad to hear from you that's your experience was that NuttX is limited by the network. That's great! :) I do think high speed transfers should be possible using Ethernet over USB and I would love to get it working at close to the link speed of 480Mbps. That would really help for the application I'm building. The is only on Tx. The Rx side is more complex and will depending more on you application configuration. 480Mbps is NOT the link speed. That is the USB speed. The link speed will be negotiated on the network and only 10Mbit/sec or 100Mib/sec are likely. Are you expecting this to work on a giga-bit network? I suppose that will depend on the what you have plugged into the USB port. I have never experiment with a giga-bit network accessed via USB. If that is the case, then USB will be the bottle neck. More people use RNDIS and CDC/ECM. Has anyone using either USB networks with a giga-bit network? How did it perform. I know that Masayuki Ishikwawa has used RNDIS a lot. Perhaps he can respond. You might also ask on the old Google forum too. There are still 300 or so people still using only the Google forum (or are inactive). Greg
Re: thttpd question (TCP close problem?)
Greg, Thanks, I will try to use the host client programs. I just need to see if I can get them compiled on Linux. Re: link speed, 100 Mbps using Ethernet over USB would work. Higher would be better. The network I want this to work on is just from the NuttX box to the host computer. The host is directly plugged into the NuttX via a USB cable. For my Gigibit Ethernet tests, I'm using a USB 3.0 USB to Ethernet adapter directly plugged in to the SAMA5D36 GMAC ethernet port. So I should not expect the USB link to be the bottleneck. It should have 5 Gbps total bandwidth. -adam On Sun, Jan 12, 2020 at 1:52 PM Gregory Nutt wrote: > > > Thanks, that document is very helpful. I set up TCP Blaster as a client, > > not a server, just because it was easier for me to send data from Linux > > with netcat. I'll try it as a server, I just have to look up the right > > netcat params. > > I am not sure if you should not use netcat. When you build > apps/examples/tcpblaster it will build the matching host side of the > test. Best to use the version generated by > build/apps/examples/tcpblaster. It will leave the host program in the > apps/examples/tcpblaster directory. The host program will be called > either tcpclient or tcpserver, depending upon how you have the example > configured. > > > I am glad to hear from you that's your experience was that NuttX is > limited > > by the network. That's great! :) I do think high speed transfers should > be > > possible using Ethernet over USB and I would love to get it working at > > close to the link speed of 480Mbps. That would really help for the > > application I'm building. > > The is only on Tx. The Rx side is more complex and will depending more > on you application configuration. > > 480Mbps is NOT the link speed. That is the USB speed. The link speed > will be negotiated on the network and only 10Mbit/sec or 100Mib/sec are > likely. Are you expecting this to work on a giga-bit network? I > suppose that will depend on the what you have plugged into the USB > port. I have never experiment with a giga-bit network accessed via > USB. If that is the case, then USB will be the bottle neck. > > More people use RNDIS and CDC/ECM. Has anyone using either USB > networks with a giga-bit network? How did it perform. > > I know that Masayuki Ishikwawa has used RNDIS a lot. Perhaps he can > respond. > > You might also ask on the old Google forum too. There are still 300 or > so people still using only the Google forum (or are inactive). > > Greg > > > -- Adam Feuer
SAMA5D36-Xplained Ethernet – interface won't come up
I have a SAMA5D36-Xplained. I have configured NuttX to use the GMAC gigabit ethernet as eth0, and EMACA 10/100 ethernet as eth1. NuttX compiles and runs. When I do ifconfig, I see both interfaces. But I plug an ethernet cable into either port and into my laptop's ethernet port, neither interface will come up: nsh> ifconfig > eth1 Link encap:Ethernet HWaddr 00:00:00:00:00:00 at DOWN > inet addr:107.127.109.40 DRaddr:107.127.109.1 Mask:255.255.255.0 > > eth0 Link encap:Ethernet HWaddr 00:e0:de:ad:be:ef at DOWN > inet addr:10.0.0.2 DRaddr:10.0.0.1 Mask:255.255.255.0 > Any ideas how to debug? Stepping through netdev_ifr_ioctl doesn't show any errors– the device just doesn't show UP afterwards... -adam -- Adam Feuer
Re: SAMA5D36-Xplained Ethernet – interface won't come up
NuttX compiles and runs. When I do ifconfig, I see both interfaces. But I plug an ethernet cable into either port and into my laptop's ethernet port, neither interface will come up: nsh> ifconfig eth1 Link encap:Ethernet HWaddr 00:00:00:00:00:00 at DOWN inet addr:107.127.109.40 DRaddr:107.127.109.1 Mask:255.255.255.0 eth0 Link encap:Ethernet HWaddr 00:e0:de:ad:be:ef at DOWN inet addr:10.0.0.2 DRaddr:10.0.0.1 Mask:255.255.255.0 Have you turned on network debug output? At least errors and warnings. eth1 has no MAC address. Are you using NSH? Do you have apps/netutils/netinit enabled? Have you tried: nsh>ifup eth0 The networks should come up if properly configured and there are cables plugged into a network. You might look at the other GMAC configurations to see if you are missing any settings.
Re: Side-effects of removing (void)
On Tue, Jan 7, 2020 at 5:09 PM Gregory Nutt wrote: > > The removal of (void) from all functions whose return value has been > ignored has introduced several new warnings into the build test output. > For example in lpc3_appinit(), I now see this: > > # define nsh_spifi_initialize() (OK) > > and > > nsh_spifi_initialize(); > > which now generates a new warning: "warning: statement with no effect > [-Wunused-value]" So I guess our choices are: 1. Reinstate (void) only where the warning occurs. 2. Reinstate (void) everywhere return values aren't checked. What a nightmare. 3. Change defines such as the above to static inline functions. Disadvantage: The inline keyword is not in the C89 standard. Nathan
Re: Side-effects of removing (void)
So I guess our choices are: 1. Reinstate (void) only where the warning occurs. 2. Reinstate (void) everywhere return values aren't checked. What a nightmare. 3. Change defines such as the above to static inline functions. Disadvantage: The inline keyword is not in the C89 standard. I have ran the build tests and do not know of any other cases like this. Certainly, a few more might show up but it is not an endemic problem at the moment. At its worst, it is only a warning. Greg
Re: Side-effects of removing (void)
So I guess our choices are: 1. Reinstate (void) only where the warning occurs. 2. Reinstate (void) everywhere return values aren't checked. What a nightmare. 3. Change defines such as the above to static inline functions. Disadvantage: The inline keyword is not in the C89 standard. I have ran the build tests and do not know of any other cases like this. Certainly, a few more might show up but it is not an endemic problem at the moment. At its worst, it is only a warning. The real problem here is not really that we may (or may not have) opened up a bunch of new warnings. The issue here is that our QA process sucks. We make enormous changes like this and commit it to master without so little as verifying that the code compiles and or that it builds without introducing new warnings. The code is just changed and "thrown over the fence." This is total unprofessional and must come to a stop. The way to bring this to a stop is to complete the workflow definition and the implementation of some nightly builld-everything step that has to happen before any PR is committed. The fix is to improve our QA processes so that this cannot happen. But we have, apparently, lost interest in the workflow. Apparently, Haitao Liu is working on something, but that is a black box. We have no visibility of what is happening, what is being done in detail, when it will be rolled out, or how it integrates with the unfinished workflow. Greg
Apache Code Relese (Was Re: Side-effects of removing (void))
I have ran the build tests and do not know of any other cases like this. ... That needs clarification. I have been starting the build tests everyday for the past weeks, but there has been no successful, complete run of the ARM builds in the past 3 weeks. The build has been broken every day for the past three weeks and the breakage appears to be getting worse, not better. This weekend was the due date for the 8.4 release of NuttX. That has now gone by. I will not be doing any further releases. That is now the responsibility of the PPMC. The next NuttX release will be the first Apache release. When should we do this first Apache release? How do we do this? Who is the release manager? (hint: not me) Since the breakage is coming on a daily basis, how/when can we get a stable enough system to even consider a release. I required two weeks of stable builds with no new bugs reported before a release. We are not ready to do a release right now. I don't think I have ever seen the OS so unstable as it is right now. It does not build correctly. There are more and more reports of old stable functionality that is now broken. I have no idea how to get there... at least not without some proper workflow definition and some qualification tools in place. Folks, we are destroying this OS. Greg
Re: SAMA5D36-Xplained Ethernet – interface won't come up
On Sun, Jan 12, 2020 at 3:08 PM Gregory Nutt wrote: > Have you turned on network debug output? At least errors and warnings. > Yes, I have the following set: CONFIG_DEBUG_INFO=y CONFIG_DEBUG_NET_INFO=y > eth1 has no MAC address. > H. How do I set this? Where is eth0's MAC set? > Are you using NSH? Do you have apps/netutils/netinit enabled? > Yes to NSH. Yes to apps/netutils/netinit. > Have you tried: nsh>ifup eth0 > No. Bravo! That got the interface up! I can ping the interface from NSH now. I think the routing table on my laptop needs work though– I can't ping it from NSH, and I can't ping the NuttX board from the laptop. The networks should come up if properly configured and there are cables > plugged into a network. > And so they do if I issue the "ifup" command. I guess I'm too used to doing that with ifconfig under linux. I didn't know about the ifup command! :) You might look at the other GMAC configurations to see if you are > missing any settings Looks like I'm closer now. Thank you! cheers adam -- Adam Feuer
Re: Apache Code Relese (Was Re: Side-effects of removing (void))
What needs to be done to move closer to release? On other projects I've been on, we froze the master branch except for bugfix commits (did not merge new features), and iterated until things stabilized. Can we do that here? As to having a release manager, what's involved in that? Is there a role description somewhere? cheer adam On Sun, Jan 12, 2020 at 4:44 PM Gregory Nutt wrote: > > > I have ran the build tests and do not know of any other cases like > > this. ... > > That needs clarification. I have been starting the build tests everyday > for the past weeks, but there has been no successful, complete run of > the ARM builds in the past 3 weeks. The build has been broken every day > for the past three weeks and the breakage appears to be getting worse, > not better. > > This weekend was the due date for the 8.4 release of NuttX. That has > now gone by. I will not be doing any further releases. That is now the > responsibility of the PPMC. The next NuttX release will be the first > Apache release. > > When should we do this first Apache release? How do we do this? Who is > the release manager? (hint: not me) Since the breakage is coming on a > daily basis, how/when can we get a stable enough system to even consider > a release. > > I required two weeks of stable builds with no new bugs reported before a > release. We are not ready to do a release right now. I don't think I > have ever seen the OS so unstable as it is right now. It does not build > correctly. There are more and more reports of old stable functionality > that is now broken. I have no idea how to get there... at least not > without some proper workflow definition and some qualification tools in > place. > > Folks, we are destroying this OS. > > Greg > > > -- Adam Feuer
Re: SAMA5D36-Xplained Ethernet – interface won't come up
eth1 has no MAC address. H. How do I set this? Where is eth0's MAC set? eth0 will be configured by apps/netutils/netinit. Bit it will initialize only one network. It will require custom logic to initialize two networks. Have you tried: nsh>ifup eth0 No. Bravo! That got the interface up! I can ping the interface from NSH now. I think the routing table on my laptop needs work though– I can't ping it from NSH, and I can't ping the NuttX board from the laptop. That means that you probably do not have apps/netutils/netinit configured correctly. It can be configured to bring up the network. And it can be configured to handle cases where the cable is not connected and initialized the network later when the cable is connected. It is common not to be able to ping from the target. That is usually because the host PC has disabled ping responses. You probably need to disable the firewall altogether on the 10.0.0.xx network. Greg
Re: SAMA5D36-Xplained Ethernet – interface won't come up
I fixed the routing table on my laptop and can ping the Nuttx board now; and the NuttX board can ping the laptop. Super! NuttX reports an ethernet address of ff:ff:ff:ff:ff:ff though. I'll look into how to add logic to set a better ethernet address. I'll do some bandwidth tests tomorrow with the EMAC and GMAC and report back. Thanks again for the help. cheers adam On Sun, Jan 12, 2020 at 6:41 PM Gregory Nutt wrote: > > >> eth1 has no MAC address. > > H. How do I set this? Where is eth0's MAC set? > eth0 will be configured by apps/netutils/netinit. Bit it will > initialize only one network. It will require custom logic to initialize > two networks. > > > >> Have you tried: nsh>ifup eth0 > > No. Bravo! That got the interface up! I can ping the interface from NSH > > now. I think the routing table on my laptop needs work though– I can't > ping > > it from NSH, and I can't ping the NuttX board from the laptop. > > That means that you probably do not have apps/netutils/netinit > configured correctly. It can be configured to bring up the network. > And it can be configured to handle cases where the cable is not > connected and initialized the network later when the cable is connected. > > It is common not to be able to ping from the target. That is usually > because the host PC has disabled ping responses. You probably need to > disable the firewall altogether on the 10.0.0.xx network. > > Greg > > > -- Adam Feuer
Re: SAMA5D36-Xplained Ethernet – interface won't come up
NuttX reports an ethernet address of ff:ff:ff:ff:ff:ff though. I'll look into how to add logic to set a better ethernet address. Not a problem. That is the broadcast address
Re: SAMA5D36-Xplained Ethernet – interface won't come up
The GMAC at eth0 also works! :) On Sun, Jan 12, 2020 at 6:57 PM Gregory Nutt wrote: > > NuttX reports an ethernet address of ff:ff:ff:ff:ff:ff though. I'll look > > into how to add logic to set a better ethernet address. > Not a problem. That is the broadcast address > -- Adam Feuer
Re: SAMA5D36-Xplained Ethernet – interface won't come up
The GMAC at eth0 also works! :) There is a good dual network test at apps/examples/bridge. There is a description in the Kconfig there. There are test configurations here: boards/arm/sama5/sama5d3-xplained/configs/bridge boards/arm/sama5/sama5d4-ek/configs/bridge That should, at lease, show you how to configure the dual networks (and should even run on your board).
