[Erik Welsh]

Khan,

Unfortunately, the backlight LED booster functionality of the PMIC is not available on the OSD335x Family of devices.

We would recommend using an an external Backlight LED driver:

http://www.ti.com/power-management/led-drivers/backlight-led-drivers/products.html

This provide you with more flexibility and better dimming ability since you will be able to control the brightness using a PWM from the OSD335x.

Thanks,

Erik

[Erik Welsh]

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

 

[Erik Welsh]

Andy,

There could be some trace length issues.  You might want to look at the RX bus on the oscilloscope.  Focus on the RX_CLK and one of the data lines to see if there are issues with the clock and data not lining up.  100Mbps requires a 25MHz clock while 1Gbps requires a 125MHz clock, hence the timing requirements are much stricter.  Additionally the RGMII requires data to be clocked on both the rising and falling edges.

Thanks,

Erik

 

[Erik Welsh]

Andy,

We took a quick look at the layout and pcap files and didn’t see anything that jumped out at us.  From your description, it feels more like a network issue at your office.  One thing you could check is to take your office adapter and try it on your home network.  There could be some small noise issues on your office network which is causing the GbE adapaters to not perform as well as the 10/100 adapters.  I don’t think it is anything inherent with GbE but could be a bad cable since GbE requires more twisted pairs in the cable than 10/100 Ethernet.

Let us know how the testing goes.

Thanks,

Erik

 

 

[Erik Welsh]

Andy,

U-Boot in the BeagleBoard.org images expects the Ethernet PHY to be at address 0.  As long as you don’t need to use Ethernet during U-Boot (i.e. no TFTP or network boot) then you can just ignore that error message.  If you do need Ethernet during U-Boot, then you will have to modify U-Boot to use the different PHY address.  I believe that you would need to modify the “phy_interface” value in the “cpsw_pdata” structure (approx line 915) in board.c (http://git.denx.de/?p=u-boot.git;a=blob;f=board/ti/am335x/board.c).

Looking at the performance problem, it looks like this might be related to the Ethernet driver and malformed packets.  Looking around, I found a couple of links that could help debug the problem:

https://forums.xilinx.com/t5/Embedded-Linux/Ethernet-Lite-Linux-Driver-Bug-quot-skbuff-skb-over-panic-quot/td-p/587295

https://e2e.ti.com/support/processors/f/791/t/530328

My suggestion would be to first use WireShark (https://www.wireshark.org/) to look at the network traffic on the switch to understand what packets are being sent to the OSD335x.  Then, you can take a look in the Ethernet driver and see if it might have a similar issue to the Xilinx driver.  Given that everything works fine when you are routing things through your computer, it would indicate this is more of a software issue than a hardware issue.

Additionally, what kernel version / image are you using?

Thanks,

Erik

[Erik Welsh]

You can find the source for all the overlays in the repository:

https://github.com/beagleboard/bb.org-overlays

If you look at the source for BB-SPIDEV1-00A0:

https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-SPIDEV1-00A0.dts

you can see that it has not been updated to be compatible with the OSD3358-SM-RED:

compatible = "ti,beaglebone", "ti,beaglebone-black", "ti,beaglebone-green";

1	compatible = "ti,beaglebone", "ti,beaglebone-black", "ti,beaglebone-green";

You will need to modify the DTS to be compatible with “oct,osd335x”:

compatible = "ti,beaglebone", "ti,beaglebone-black", "ti,beaglebone-green", "oct,osd335x";

1	compatible = "ti,beaglebone", "ti,beaglebone-black", "ti,beaglebone-green", "oct,osd335x";

and then recompile.  This will create a new DTBO file that you can use to replace the one in /lib/firmware   We will look at getting the repository updated to add in the OSD3358-SM-RED compatibility to the applicable device tree overlays.

Then you should change which address you are using for the overlay to “addr4”:

uboot_overlay_addr4=/lib/firmware/BB-SPIDEV1-00A0.dtbo

1	uboot_overlay_addr4=/lib/firmware/BB-SPIDEV1-00A0.dtbo

This should resolve the issue and allow you to use /dev/spidev1.0

[Erik Welsh]

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

[Erik Welsh]

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:

[ 13.095361] libphy: PHY 4a101000.mdio:04 not found [ 13.151944] net eth0: phy "4a101000.mdio:04" not found on slave 0, err -19

1 2	[   13.095361] libphy: PHY 4a101000.mdio:04 not found [   13.151944] net eth0: phy "4a101000.mdio:04" not found on slave 0, err -19

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.

 

[Erik Welsh]

For the PRUs, here are a couple of tutorial links that should help:

1. Basic Introduction to PRUs:  http://beagleboard.org/pru
2. TI PRU Training Lab:  http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs
3. remoteproc and UIO:
   • http://ianrrees.github.io/2016/11/20/getting-started-with-beaglebone-pru-programming-the-new-way.html
   • https://jumpnowtek.com/beaglebone/Working-with-the-BeagleBone-PRUs.html

 

For the RT linux, you should be able to build an image using the instructions found:

https://www.digikey.com/eewiki/display/linuxonarm/BeagleBone+Black

See section “For am33x-rt-v4.14 (Longterm 4.14.x + Real-Time Linux)”.  We have used these build instructions on an Ubuntu 16.04 VM.

Please let us know if you have any additional questions.

[Erik Welsh]

Based on the information provided, it looks like you have all of the drivers installed and working properly. The other thing to check is that Windows has configured the network settings correctly.

• Under “Settings” –> “Network & Internet” –> “Change adapter options”
  • You should have a “Network Connections” window pop up that will have an “EthernetXX” entry that is an “Remote NDIS Compatible” device
• Right click on this device and select “Properties”. This will pop up another window
• Select “Internet Protocol Version 4 (TCP/IPv4)” and Click “Properties”
• Make sure that: “Use the following IP address:” is selected and that the following information is in the network box:
  • IP address: 192.168.7.1
  • Subnet Mask: 255.255.255.252

We are not sure exactly why Windows will not set up the network connections correctly when the board if first attached, but it is always good to check these network settings to make sure that they are correct. Additionally, if you try to share your computer’s Ethernet or WiFi connection with the OSD3358-SM-RED or a Beagleboard development board, Windows will automatically change the IP settings for the RNDIS connection and you will need to follow the above procedure to correct them.

[Erik Welsh]

Dan,

We have done some preliminary characterization of the OSD335x C-SiP’s support for RTC-only mode and the results are encouraging.  Unfortunately, it will take us a little while longer to finish up the work needed to publish the application note on using RTC-only mode with the C-SiP.  In the meantime, I would encourage you to fill out the contact form (https://octavosystems.com/contact/) so that we can directly discuss the preliminary characterization results and what would need to be done connection-wise to enable the RTC-only support since I do not want to discuss preliminary findings on the forum.  If not, I will make sure to update this thread with a link to the application note once it is published.

Thanks,

Erik

[Erik Welsh]

Marcin,

Unfortunately, we do not have a reference design that uses the LAN8720.

Looking through your connection proposal, you will need to make a few minor adjustments.  If you look in the LAN8720 datasheet (http://ww1.microchip.com/downloads/en/devicedoc/00002165b.pdf), there are two connection schemes listed.  Figure 3.7 shows the connections when using an external 50MHz clock source.  In this case, nINT/REFCLKO is an interrupt and should go to a GPIO pin on the OSD335x device.  Additionally, you need to be careful in layout to make sure that the clock is balanced between the PHY and the OSD335x.  Figure 3.8 shows the connections when using a 25MHz crystal.  In this case, nINT/REFCLKO is used as a reference clock that should be sent to the OSD335x.

Figure 3.8 is what is shown in the first picture you attached from the reference design.  If you would like to use the 50 MHz oscillator, then you will need to remove R11 in your diagram and connect the nINT/REFCLKO to a different GPIO pin that you will specify as the Ethernet interrupt in your device tree.  Alternatively, you can change the 50MHz oscillator to a 25MHz crystal and use the connections from the reference design.

Regardless, you will need to add the appropriate pull up resistors (i.e. the 10K resistors in the reference design picture) in order to set all the strap pins.  Additionally, you will need to add the 1.5k pull up resistor the the MDIO connection per the Ethernet specification.  Also, it is a good idea to add the 33Ohm termination resistors to help with signal integrity on the interface.

Please let us know if you have any additional questions on this.

 

 

 

[Erik Welsh]

First, be aware that the AR8035 is a 10/100/1000 Ethernet PHY, while the LAN8720 is a 10/100 Ethernet PHY.  The reason you find more information about the LAN8710 interfacing to the AM335x or OSD335x is due to the open hardware reference designs from BeagleBoard.org that use that device.  However, the LAN8720 should work as well.  It appears that the LAN8720 uses the same Linux driver as the LAN8710, but within Octavo, we do not have experience with the LAN8720 and the OSD335x family of devices.  The main thing to be aware of is that the LAN8720 uses RMII, so you need to make sure that the layout comprehends the clocking and timing requirements of RMII so that you don’t run into any issues.

[Erik Welsh]

The additional current consumption comes from the fact that the OSD335x and OSD335x-SM use TPS65217C PMIC.  If you look in the application note from TI (http://www.ti.com/lit/ug/slvu551i/slvu551i.pdf), you can see that in the case of the TPS65217C, both VDDS and VDDS_RTC are connected to the LDO1 output of the PMIC.  The additional current consumption that you see is a result of the VDDS power input being connected to the LDO1.

Unfortunately, the connection between VDDS and LDO1 is internal within the SiP and cannot be modified on the OSD335x and OSD335x-SM.  However, we are in the process of characterizing the OSD335x C-SiP to see if it can support the power use case where VDDS is not connected to LDO1.  We should have that characterization finalized in early January.

Additionally, the TL5209 is enabled with an internal pull up within the OSD335x family of devices.  In the OSD335x and OSD335x-SM, this connection cannot be modified.  However, in the OSD335x C-SiP, there is a pin, SYS_VDD1_CTL, that will allow a user to disable the TL5209.

 

[Erik Welsh]

Unfortunately, this is probably a software issue related to the boot process. The hardware differences between the OSD335x on the BeagleBone Blue and the OSD335x-SM on the PocketBeagle are small (the OSD335x-SM integrates the EEPROM on I2C0 and reduces the size of the devices). The differences in hardware would not account for the 4x difference in boot times you are seeing.

Our speculation is that there is an issue in the boot procedure whereby the board ID value for the PocketBeagle is not enumerated properly in a some case statement. This in turn causes some kind of time out, or alternate execution path which takes much longer than the execution path for the BeagleBone Blue, which is properly enumerated. Our suggestion would be to understand the startup entire Linux boot procedure for the PocketBeagle vs the BeagleBone Blue. If you start with the BeagleBone Blue, it should be straight forward to understand when the PocketBeagle does something different on boot.

As a test, you can re-write the EEPROM on the PocketBeagle with the value from the BeagleBone Blue, but still use the PocketBeagle device tree. If you ground the “WP” test point on the back of the PocketBeagle, you can update the value of the EEPROM. See our app note (https://octavosystems.com/app_notes/osd335x-eeprom-during-boot/) for more information about how to program the EEPROM.

[Author]

Posts