512-861-3400Log inCreate Account

Ethernet compatible PHYs

Forums › Devices › OSD335x-SM › Ethernet compatible PHYs

Tagged: 

Viewing 15 reply threads
  • Author
    Posts
    • October 11, 2018 at 3:45 pm #6605
      Andres Olivaresandyolivares
      Participant

        I see that you used Qualcomm’s AR8035-AL1A in your OSD335x-SM-RED platform but it seems like it has some sourcing problems (at least on Mouser and/or Digikey) with lead times upto 14 weeks.

        Have you ever tried any other Gigabit PHYs compatible with OSD335x-SM SiP? And if so, do you have any particular recommendation with good support on Linux?

        I’m looking at TI’s DP83867 which seems like a good alternative, but I would like to hear your feedback before starting to layout a test board with that particular PHY.

        Thank you in advance!

      • October 12, 2018 at 12:42 pm #6606
        Neeraj Kumar Reddy DantuNeeraj Dantu
        Moderator

          Andy,

          While we have not used it ourselves, the DP83867 is a good candidate for a Gigabit Ethernet PHY. You can find a reference design that integrates the DP83867 and AM335x here:http://www.ti.com/tool/TIDA-00204#technicaldocuments. Documentation: http://www.ti.com/lit/ug/tidu832b/tidu832b.pdf

          The schematics are also available: http://www.ti.com/lit/df/tidrdr0a/tidrdr0a.pdf

          Note that AM335x supports MII, RMII and RGMII interfaces. There are other devices from Microchip(https://www.microchip.com/ParamChartSearch/chart.aspx?branchID=1635) that have good Linux support.

          Best regards,

          Neeraj

           

           

        • October 12, 2018 at 1:16 pm #6607
          Andres Olivaresandyolivares
          Participant

            Thanks for the valuable info again. I was indeed designing a board with KSZ8081 from Microchip/Micrel in RMII mode but read on other sites and TI forums that they had some problems with that chip. I don’t know if they ever solved those problems but I thought I better go with a proven design for now.

          • December 20, 2018 at 2:29 am #6898
            Jaroslaw DoboszJarekD
            Participant

              I need to use AR8035-AL1B for industrial temperature range which is even more difficult to obtain.
              Is that possible to use any other part which is more common so that I can use linux image \ device tree provided with OSD3358-SM-RED?

              I don’t need gigabit ethernet in my application, 100Mb would be enough. I know that OSD3358 SBC uses LAN8710 but it also uses bigger SIP.

              Is there any design that integrates OSD3358-512M-ISM with ETH10/100 chip which is available on Mouser/Farnell and has device tree ready to download so that it would not require any low-level programming effort?

              I may also use USB to Ethernet bridge solution. Is there any bridge that would not require any drivers for Linux?

              Thank you in advance,
              Jaroslaw

              • This reply was modified 5 years, 10 months ago by Jaroslaw DoboszJarekD.
              • This reply was modified 5 years, 10 months ago by Jaroslaw DoboszJarekD.
            • December 20, 2018 at 10:31 am #6901
              Eshtaartha BasuEshtaartha Basu
              Moderator

                Hello JarekD,

                The major internal components of OSD3358-512M-ISM (smaller 21mm x 21mm SiP) are same as that of OSD3358-512M-BAS (bigger 27mm x 27mm) chip except for the fact that the BSM/ISM SiP has an additional internal EEPROM integrated into it. Therefore, you can use the SBC Design as a reference for your OSD335x-ISM ethernet PHY design. You can find the pin mapping between AM335x, OSD335x-BAS/IND and OSD335x-BSM/ISM at https://octavosystems.com/app_notes/am335x-signal-to-osd335x-pins/.

                Any of the latest Beagleboard.org Debian images (https://beagleboard.org/latest-images) should work for the SBC Reference Design with OSD335x-ISM since BeagleBone Black design also uses LAN8710 on MII1 interface of AM335x. No device tree modifications will be necessary as long as the hardware on your board exactly matches that of SBC Reference Design or one of the Beagleboards. If you decide make any hardware changes, then those changes will have to be reflected in your device tree to achieve proper operation. In that case, our app note on Linux Device Trees (https://octavosystems.com/app_notes/osd335x-design-tutorial/osd335x-lesson-2-minimal-linux-boot/linux-device-tree/) should help you get started with Device Tree modifications.

                Drivers are required for any of the USB to Eth Bridges. Debian Linux should automatically load the required USB drivers as long as it supports the USB to Eth Bridge solution. We recommend prototyping your USB to Eth Bridge by hooking it up to the USB port of a a lost cost Linux Development Board before committing to it.

              • December 21, 2018 at 2:27 am #6902
                Jaroslaw DoboszJarekD
                Participant

                  Thanks for your response. Now I have some off-topic questions.
                  Do I have to remember about anything other than mapping the pins when using OSD3358-512M-ISM instead of OSD3358-512M-BAS?

                  For example, I can see that OSD-3358-SM-RED uses reset supervisor which is not used in OSD3358 SBC design. Is that for increased reliability only or the hardware inside the SiPs is somehow different so that one of them requires a supervisor an the other doesn’t?

                  The other question is that if I can omit some hardware used in OSD3358 SBC which I don’t need (e.g. HDMI framer)? Is it possible that omitting some hardware will cause device-tree related problems with the remaining hardware? I assumme that the device tree will not be modified.

                • December 23, 2018 at 3:56 pm #6916
                  Eshtaartha BasuEshtaartha Basu
                  Moderator

                    The reset supervisor circuit was added to OSD3358-SM-RED design to improve reliability.

                    You can find the latest recommendations for OSD335x-SM from the following resources:

                    1. OSD3358-SM-RED design files:

                    OSD3358-SM-RED Eagle Files

                    2. OSD33x-SM Design Tutorial (This app note talks about step by step design process and also about differences between OSD335x and OSD335x-SM):

                    OSD335x-SM Design Tutorial

                    3. OSD335x-SM Schematic Checklist:
                    https://octavosystems.com/app_notes/osd335x-schematic-checklist/

                    4. OSD335x-SM Layout Guide:

                    OSD335x-SM Layout Guide

                    You can find many more useful app notes under OSD335x-SM section of our App Notes page (https://octavosystems.com/app_notes/).

                    Omission of HDMI framer may lead to device tree issues. Suitable device tree modifications will be necessary. Since you’re designing an embedded system, modifying/debugging the Device Tree will be definitely necessary at some point in the design/debug process.

                    A device tree is a tree data structure that describes the hardware configuration of the system to the Linux operating system. During boot, the Linux kernel will use the information in the device tree to recognize, load appropriate drivers and manage the hardware devices in the system.

                    The device tree may look overwhelming in the beginning but it is actually easy to modify and debug since you will be modifying only few necessary nodes while the rest of the device tree remains mostly the same. Please go through our Device Tree app note (https://octavosystems.com/app_notes/osd335x-design-tutorial/osd335x-lesson-2-minimal-linux-boot/linux-device-tree/) to get a better idea. In this app note, we show you how to modify a device tree in simple and easy steps.

                  • January 10, 2019 at 4:21 am #6980
                    Jaroslaw DoboszJarekD
                    Participant

                      Thank you for yor reply.

                      Now I have doubt how should I connect boot configuration resistors. I understand that I should follow SBC design if I want to run BeagleBone Black software on OSD3358-512M-ISM. I have checked that the configuration of these pull-ups and pull-downs in RED and SBC designs are the same apart from LCD_DATA5 pin which is low state in RED design and high state in SBC. Surprisingly the comments in both designs suggest that this pin should be low state:
                      CLKOUT1 disabled (SYSBOOT[5] = 0b)

                      Also the comments:
                      SYSBOOT[15:0] = 0x401C (default)
                      – Boot Order: MMC1, MMC0, UART0, USB0
                      SYSBOOT[15:0] = 0x4018 (SD boot)
                      – Boot Order: SPI0, MMC0, USB0, UART0

                      are consistent with RED design but suggests a mistake in SBC design (R56 should be DNI-marked instead of R81).

                      I want to use only half of the resistors to save space.

                      Is it really a mistake in SBC design? Or does it not influence the system very much?

                    • January 11, 2019 at 11:42 am #6983
                      Eshtaartha BasuEshtaartha Basu
                      Moderator

                        Hello JarekD,

                        Thank you for catching the error in comments. Looks like this is a copy/paste error while updating the comments. We will fix it soon.

                        On the SBC Reference Design, SYSBOOT[5] should be pulled high (enabled) because CLKOUT1 is being used to supply clock signal to HDMI framer through a clock divider. However, on the RED design, SYSBOOT[5] should be pulled low (disabled) because an external MEMS oscillator is used to provide clock for the HDMI framer and CLKOUT1 is no longer used.

                        Even though some of the SYSBOOT[15:0] pins are “don’t care” for the ROM code, it is recommended to pull them up/down because all SYSBOOT values are latched into the CONTROL_STATUS register and may be used by software after ROM execution has completed. You can find a discussion on the same at TI forum:

                        https://e2e.ti.com/support/processors/f/791/t/343891?AM335x-SYSBOOT-pins-which-are-not-cared-for-ROM-code

                        The same information is also available under Table 26-7 (SYSBOOT Configuration Pins Notes) of AM335x TRM (SPRUH73P).

                      • February 21, 2019 at 7:50 am #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!

                          • February 21, 2019 at 8:19 am #7493
                            Greg SheridanGreg Sheridan
                            Keymaster

                              Hi Andy,

                              The original SBC Reference Design was developed to be an exact duplicate of the Beagle Bone Black.  We just used the standard BeagleBone images and device trees.  We never created one specifically for that reference design.

                              Thanks,

                              Greg

                          • February 21, 2019 at 11:48 am #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, 8 months ago by Andres Olivaresandyolivares.
                            • February 22, 2019 at 10:30 am #7513
                              Erik WelshErik Welsh
                              Keymaster

                                The “<0>” or “<4>” is the Ethernet PHY address on the MDIO bus.  If you look at the datasheet for the PHY, you will see that you can set the three bits of the Ethernet PHY address using pull-ups or pull-downs.  If you look at Sheet 8 of the OSD3358-SM-RED schematics, you can see that PHY_ADDR[2:0] = 0b100 (or 4).  If you do not have that set correctly, then you will see an error message in your boot logs like:

                                Each Ethernet PHY that you put on an MDIO bus should have a unique PHY address.  If you ever want to do a dual Ethernet design, then you will need to make sure the PHY addresses are different.

                                 

                              • February 25, 2019 at 1:11 pm #7601
                                Andres Olivaresandyolivares
                                Participant

                                  Hey Erik! That makes perfect sense 🙂

                                  Just for completeness… where is that documented?

                                  Thank you so much,

                                  Andy

                                • March 4, 2019 at 3:45 pm #7618
                                  Erik WelshErik Welsh
                                  Keymaster

                                    Andy,

                                    I apologize for the delayed response.  You can find the documentation on the TI Ethernet controller device tree bindings at:

                                    https://www.kernel.org/doc/Documentation/devicetree/bindings/net/cpsw.txt

                                    Thanks,

                                    Erik

                                  • July 17, 2019 at 3:31 pm #8686
                                    William Thompsonwgthompson
                                    Participant

                                      Hello,

                                      I notice in your ethernet app note you use microchip’s KSZ9031.

                                      When will the design files be made available for this (preferably eagle)?

                                      Thanks,
                                      Will

                                    • July 19, 2019 at 9:57 am #8716
                                      Erik WelshErik Welsh
                                      Keymaster

                                        Will,

                                        Thanks for the interest.  We are still in the process of validating the rest of dual Ethernet design and will be publishing the Eagle design files later this quarter.  If you have a project that you are working on, I would encourage you to reach out to our sales department and we can help you through the design process.

                                        Thanks,

                                        Erik

                                         

                                    • Author
                                      Posts
                                    Viewing 15 reply threads
                                    • You must be logged in to reply to this topic.

                                    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.