512-861-3400Log inCreate Account

andyolivares

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 28 total)
1 2
  • Author
    Posts
  • May 21, 2019 at 6:36 pm in reply to: Poor Ethernet performance (AR8035) #8200
    Andres Olivaresandyolivares
    Participant

      Will try to perform the test with the oscilloscope as soon as possible. Thank you for all the help so far.

      Andy

      May 20, 2019 at 3:49 pm in reply to: Poor Ethernet performance (AR8035) #8188
      Andres Olivaresandyolivares
      Participant

        Erik:

        I did the test of connecting my GbE USB-to-Ethernet adapter directly to my base test board (through the USB host connector). It was recognized as a 1000Mbps (GbE) full-duplex link and loaded as “eth1”. I connected to my office network switch/router and it worked like a charm (unlike my Ethernet daugther board based on AR8035 chipset).

        Just for completeness, also did the test of connecting my Ethernet daugther board to my office network but downgrading the link to 100Mbps full-duplex and it also worked just fine.

        So it is confirmed that for some reason, my Ethernet daugther board does not work properly at GbE speeds. Could be the trace lengths, routing problems, noise issues due to the board-to-board connector, you name it 🙂

        But it seems like using the USB adapter at GbE speeds is more forgiving and works just fine. I assume that’s because the way it is constructed, how the USB driver works and other variables.

        Regards,

        Andy

        May 19, 2019 at 10:33 pm in reply to: Poor Ethernet performance (AR8035) #8178
        Andres Olivaresandyolivares
        Participant

          One more thing to consider: when in GbE mode, I’m getting a lot of Rx CRC Errors:

          When in 100Mbps mode, that number does not increase.

          I read some forums about the trace length from my PHY to the microprocessor could be too long for the GbE speeds. Due to the fact that I’m connecting the PHY through a header connector to my base board, and then to the microprocessor, they indeed could be too long.

          Do you think that may be the cause?

          Andy

          May 19, 2019 at 9:52 pm in reply to: Poor Ethernet performance (AR8035) #8177
          Andres Olivaresandyolivares
          Participant

            Hi Erik:

            I did the test with my GbE adapter on my home network and same results as the office: poor performance, very slow, almost unusable.

            Further testing with “ethtool”, I forced the connection to 100Mbps as follows (still with the GbE adapter):

            Did a few tests, and it worked great just like if I had connected the board to a 100Mbps adapter.

            I really think this has something to do with GbE but not sure how. Maybe, as you suggested, my cable has an important role. I’m testing with a cable almost identical to this one: https://www.ebay.com/itm/AWM-E212689-STYLE-2854-32-AWG-30V-2-FEET-CAT-5E-B0816F281J-CABLE-BRAND-NEW-/202639361149 (except mine is black, but has same markings on the cable: AWM E212689 STYLE 2854 80°C 30V CABLE).

            Anyway, cabling at office allows 1000Mbps speeds with my USB GbE adapter, at least with my laptop PC, with no problems. Connecting that same cable to my test board produces poor results with some kernel panics from time to time, as stated before.

            Maybe USB GbE is more forgiving to link issues than the AR8035 chipset/driver. I don’t really know. Do you think my board’s Ethernet connector choice may have something to do with it (Molex 93626-3508)? As you said… there are not apparent routing problems or board design issues.

            Next test will be to connect the GbE USB-to-Ethernet directly to the USB host on my test board and see if the network connection works at full 1000Mbps speed directly connected to my office network.

            Will keep you posted. Thank you!

            Andy

            May 16, 2019 at 2:00 pm in reply to: Poor Ethernet performance (AR8035) #8170
            Andres Olivaresandyolivares
            Participant

              Hi Erik:

              For my tests, I’m using a USB-to-Ethernet adapter that came with my laptop PC. In fact, I have two of these adapters: one that came with my personal laptop, and one that came with my office laptop (both ASUS brand).

              And so far, I’ve performed the following tests:

              1. Used my personal laptop’s USB-to-Ethernet adapter to share laptop’s Wi-Fi connection (to my home network): it works very good with no problems at all (at least no noticeable issues). I can download things at max speed, upgrade things with apt, perform network speed tests, communicate with external servers, ping, etc.

              2. Used my office laptop’s USB-to-Ethernet adapter to share laptop’s Wi-Fi connection (to my office network): it has very poor performance, quite unusable, only a few Kb/s with many errors and timeouts.

              3. Board directly connected to a GbE port on my office network switch: same as 2 but with some Kernel panics from time to time.

              I noticed that my personal laptop’s USB-to-Ethernet adapter is based on AX88772B chipset (10/100 Mbps), and that my office laptop one is based on a Realtek GbE chipset.

              So the next obvious thing to do was to test my AX88772B USB-to-Ethernet adapter on my office network to share the Wi-Fi throught my office laptop, and guess what: it worked just fine just like in case 1.

              In both cases where a GbE port is used (2 & 3) the network performance is very poor and unusable (with kernel panics in the case of 3). So it seems like there’s something to do to with the Ethernet speed (or adapter chipset) rather than the network itself (I’m guessing here).

              Also, due to the fact that my (small) office router is very basic and doesn’t have traffic capture capabilities, I’ve been unable to find the packet that is causing the kernel to panic seen on 3.

              To that end, I enabled tcpdump on the target board to see if I could find some more information of the offending packet, but the trace looks pretty normal to me. Almost all packets are 1400 bytes in length (max) which relates to my MTU I guess.
              I’m attaching the file in case you want to take a look. Board’s IP address was 192.168.0.175.
              After the last packet (1373) in **capture.cap** file I got a kernel panic, but unfortunately, that offending packet did not get captured, at least not entirely as Wireshark complains about an incomplete packet on the capture file.
              Used a tool to repair the capture file and a new last packet appeared (1374, incomplete) but its headers look normal to me too. I doesn’t seem like an overly large packet.

              I’m very puzzled to be honest. Do you think GbE has something to do with this? I don’t really think the USB-to-Ethernet adapter’s chipsets has anything to do here, as there may be many chipsets in routers/switches out there. It’s hard for me to believe that the board will fail depending on the router/switch chipset.

              I have a RED board laying around and haven’t done the test with it yet. Will try to do that ASAP. Maybe there are HW problems with my custom made Ethernet board and/or its routing. I’m attaching the Eagle BRD file just in case you want to take a look.

              Thanks for any help.

              Andy

              Edit: I was unable to upload the files. Please download them from here https://www.dropbox.com/s/rorc9lsafqae4mv/eth.zip?dl=1

              • This reply was modified 5 years, 6 months ago by Andres Olivaresandyolivares. Reason: attached new file
              • This reply was modified 5 years, 6 months ago by Andres Olivaresandyolivares.
              • This reply was modified 5 years, 6 months ago by Andres Olivaresandyolivares. Reason: added url to dropbox file
              May 13, 2019 at 8:33 pm in reply to: Poor Ethernet performance (AR8035) #8158
              Andres Olivaresandyolivares
              Participant

                Thank you Erik for the valuable information & suggestions. Indeed, it appears to be a software issue. I’ve been performing some test on other networks and it works very good with no performance issues and/or kernel panics. I even performed some speed tests and I got maximum speed for my current ISP service.

                Will perform more tests with Wireshark capturing packet information on the network with issues and try to narrow down which packet is causing the problem (or type of packets). The network that causes issues is my company network. I would guess that there are some kind of jumbo packets and/or VLANs or some other “company specific” packet that may cause the problem. My home network works like a charm.

                I’m using latest IoT image available from Beagleboard.org:
                Linux beaglebone 4.14.71-ti-r80 #1 SMP PREEMPT Fri Oct 5 23:50:11 UTC 2018 armv7l GNU/Linux

                Will keep you all posted on my findings.

                Regards,

                Andy

                April 8, 2019 at 7:27 am in reply to: OSD32MP1 Reference Board and/or Schematics #7904
                Andres Olivaresandyolivares
                Participant

                  Thank you Greg! Hope to see that reference board soon 🙂

                  April 5, 2019 at 8:28 pm in reply to: OSD32MP1 Reference Board and/or Schematics #7896
                  Andres Olivaresandyolivares
                  Participant

                    Hey Greg, thank you the reply.

                    10/100 Mbps Ethernet connectivity should be a must with a PHY IC easily accesible through common distributors like Mouser and Digikey… a Microchip PHY maybe… they’re quite common and good supported on Linux.

                    Also I’m currently developing some audio applications so it would be great to see some (multichannel?) audio subsystem on the reference board if possible. I might be asking too much, but you asked 🙂

                    On the other hand, do you have a suggested price point for the SiP @ 100 units? I assume it should be cheaper than current OSD335X offerings.

                    Thank you, and I can’t wait to start prototyping with this new promising SiP.

                    Andy

                    February 25, 2019 at 1:11 pm in reply to: Ethernet compatible PHYs #7601
                    Andres Olivaresandyolivares
                    Participant

                      Hey Erik! That makes perfect sense 🙂

                      Just for completeness… where is that documented?

                      Thank you so much,

                      Andy

                      February 21, 2019 at 11:48 am in reply to: Ethernet compatible PHYs #7497
                      Andres Olivaresandyolivares
                      Participant

                        Thank you Greg!

                        I’m trying to figure out what are BBB device tree “defaults” regarding to MAC0 and see if that looks OK for my LAN8710 chipset in MII mode. I can see that the pin mux defaults to MII mode (in file am335x-bone-common.dtsi):

                        Indeed, that pinmux looks just fine for MAC0 in MII mode. Also the MAC section is configured as:

                        Which also looks just fine, except that I noticed that the RED board device tree has the following “phy_id”:

                        I can’t find any documentation regarding what that “<0>” or “<4>” actually mean? I looked for any reference to that number in the Kernel’s device tree bindings documentation but found none. Why are they different and what that number references to?

                        Thank you!

                        • This reply was modified 5 years, 9 months ago by Andres Olivaresandyolivares.
                        February 21, 2019 at 7:50 am in reply to: Ethernet compatible PHYs #7492
                        Andres Olivaresandyolivares
                        Participant

                          Hi Eshtaartha:

                          Going back to the LAN7810… I designed a test board using that Ethernet chipset, based mostly on the Ethernet part of the “SBC Reference Design” (https://octavosystems.com/docs/osd3358-bas-sbc-reference-design-schematic).

                          My board is custom design so I have my own device tree and I’m wondering where can I find the “SBC Reference Design” device tree source (like the GitHub repo with RED board’s device tree) to take a look at what should I put on mine. It looks difficult to figure that out by myself specially if it may be already up there.

                          Thank you!

                          January 3, 2019 at 8:47 pm in reply to: Kernel panic on shutdown #6935
                          Andres Olivaresandyolivares
                          Participant

                            Hi Neeraj:

                            I reworked my RTC circuit replacing the crystal and supporting capacitors and now it oscillates with a good 32 kHz sine wave (as can be seen on my oscilloscope). I really don’t know what could have caused the old crystal to stop working at some point.

                            With the RTC up and running with the external oscillator, I did a quick test again with “sudo hwclock -f /dev/rtc0 –debug” and it got a tick as expected, so running the “sudo poweroff” command turned my board off just fine with no kernel panics (finally!).

                            So, I think we can close this topic now and hope all my process will help someone else facing the same problem.

                            Thank’s again for all the help and support.

                            Best regards,

                            Andy

                            January 1, 2019 at 9:33 pm in reply to: Kernel panic on shutdown #6934
                            Andres Olivaresandyolivares
                            Participant

                              I’m not sure what I did different this time, but I modified RTC_OSC_REG with value 0x40 again to set internal oscillator.
                              I did a quick test with “sudo hwclock -f /dev/rtc0 –debug” and I got a clock tick (this command failed with external oscillator), so the RTC is working with the internal oscillator with no problems.

                              After that check I did a “sudo poweroff” and now the board was powered off just fine with no kernel panics. I can see my board’s power indication LED being turned off.

                              So it is confirmed, it is a hardware issue with my RTC oscillator circuit. Will try to fix that and see what happens.

                              January 1, 2019 at 8:58 pm in reply to: Kernel panic on shutdown #6931
                              Andres Olivaresandyolivares
                              Participant

                                Neeraj:

                                I tested “devmem2” tool as suggested and it indeed says that value of register RTC_OSC_REG (address 0x44E3E054) is 0x48 which means that RTC source should be external and it should be enabled. The DC voltage level on OSC1_IN pin is about 0.9V at power up.
                                If I write this register with value 0x10 (disable the oscillator and apply high impedance to the output) the voltage level on OSC1_PIN jumps up to a DC level of about 1.8V.

                                FYI, I booted with EEPROM programed as a RED board with no special DTB file. Just latest IoT BB image as-is in order to discard DTB issues. So, to summarize, after power up, registers of interest have the following values:

                                RTC_OSC_REG = 0x48
                                RTC_CTRL_REG = 0x01
                                RTC_STATUS_REG = 0x02
                                RTC_SYSCONFIG = 0x03
                                RTC_PMIC = 0x10011

                                I also tried changing RTC_OSC_REG value to 0x40 (internal oscillator selected and enabled) and a read back confirmed the value change (as I wrote both KICK registers with unlock values), but still got the same kernel panic message. Maybe the kernel needs more than just an on-the-fly register change.

                                I noticed that, according to AM335x TRM, default reset value of RTC_OSC_REG is 0x10 (RTC disabled and high impedance), so there is one place where this register is being changed to 0x48… just for completeness: can you point me to the exact place where this happens? I would say that it is the rtc32k_enable() function on u-boot’s “board/ti/am335x/board.c” or is it the “omap_rtc” Linux driver.

                                Bottom line, it seems like I do have a hardware issue at hand. Will try removing RTC circuit components and put new ones to see if that solves the problem. I’ll keep you posted with my findings.

                                Thank you and happy new year BTW!

                                • This reply was modified 5 years, 10 months ago by Andres Olivaresandyolivares. Reason: typo
                                • This reply was modified 5 years, 10 months ago by Andres Olivaresandyolivares.
                                December 31, 2018 at 5:23 pm in reply to: Kernel panic on shutdown #6929
                                Andres Olivaresandyolivares
                                Participant

                                  Neeraj:

                                  I really appreciate all the help.

                                  I did more testing and to my surprise, the oscillator is not oscillating at all. I’m 100% sure I measured it in the past with a good 32kHz oscillation but now it does not oscillate. I can only see a DC voltage of about 1.5V on OSC1_IN pin.

                                  The BB image I’m now testing (latest IoT image) is different from the one I tested when I saw the oscillator working. The problem is that I don’t remember which one I had on my SD card at that time. When I tested back on those days, the EEPROM was blank and my u-boot had some patches to ignore EEPROM checks. Now, the EEPROM has been programmed with the same values to be recognized as a RED board (as specified here: https://octavosystems.com/app_notes/osd335x-eeprom-during-boot/#_Toc382081431) and I’m testing the BB image “as is” (except that I’m putting my board’s DTB file on uEnv.txt).

                                  So, I have a couple of questions:

                                  1) Is the 32 kHz oscillator supposed to start oscillating at board power-on?
                                  2) If not, who’s responsible to initialize and turn it on? u-boot? the Linux kernel somewhere?

                                  I inspected one of RCN patches and I noticed he modified some RTC suff. In particular, when my u-boot runs, I can see the “RTC 32KCLK Source: External” (as in https://rcn-ee.com/repos/git/u-boot-patches/v2018.03/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch @ line 267). But to be honest, that doesn’t say if the clock is enabled (turned on) or not.

                                  Also, I put debug strings on the function “rtc32k_enable()” (line 219 of the same patch) to see if the RTC was being initialized or not, but I never saw those lines during u-boot start, so I assume the function didn’t get called.
                                  It seems that the function is only called if macro CONFIG_SPL_AM33XX_ENABLE_RTC32K_OSC is defined. I compiled u-boot with “make ARCH=arm CROSS_COMPILE=${CC} am335x_evm_defconfig” which does not define that macro. Although, the generated .config file contains a line “CONFIG_SPL_AM33XX_ENABLE_RTC32K_OSC=y”, so I’m not sure if my u-boot is being compiled with that macro turned on or not.

                                  Anyway, I don’t understand why the RED board doesn’t need any of that and the RTC works just fine by default (that’s why I asked for the DTB file to check that there is no difference with mine on that regard). What really puzzles me is that the oscillator once worked but now it doesn’t at all.

                                  So if you could give some answers to the two questions above, would give me more light on to where to look next. Will check the documentation you provided too, and also see if I can compile the rtc_omap driver and debug that part.

                                  Once again, thank’s for all the help.

                                • Author
                                  Posts
                                Viewing 15 posts - 1 through 15 (of 28 total)
                                1 2

                                Octavo Systems LLC all rights reserved
                                OCTAVO is registered in the U.S. Patent and Trademark Office. OSD, C-SiP, and the Octavo Logo are trademarks of Octavo Systems LLC.