Ethernet compatible PHYs

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

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 JarekD.
• This reply was modified 5 years, 10 months ago by JarekD.

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.

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.

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.

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?

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).

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.

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

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

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