[Neeraj Dantu]

Hey MC,

There are a couple of ways to approach the issue. First, from what we understand, you have a BBB with a working Linux image that loads the correct drivers. In order to reproduce the exact same system on the custom board, please make sure of the following.

1. Switch the EEPROM ID from what is currently programmed to the BBB EEPROM ID which is currently programmed in the BBB so that same initialization is done on both boards. See https://octavosystems.com/app_notes/osd335x-eeprom-during-boot/ for ways to program the EEPROM

2. Make sure the u-boot version and the boot source are the same on the custom board and the BBB. This may require you to extract the image in the BBB to an SD card and boot with the SD card on both the boards and compare the boot logs(including u-boot logs)

Secondly, from http://processors.wiki.ti.com/index.php/Sitara_Linux_UART_-_Switching_to_8250_Driver, it seems that the 2 changes that need to happen to use the 8250 driver instead of the omap serial are the change from ‘ttyO0’ to ‘ttyS0’ in u-boot and changing the kernel configuration to disable ‘omap serial port support’ and enable the internal 8250 drivers.

If the custom board you are booting is not booting from the same u-boot as BBB, that might be causing the incorrect loading of the driver. On the kernel level, make sure that you have the ‘omap serial port support’ disabled in your kernel configuration as it looks like these drivers are being loaded in the boot log attached.

Note that from boot log, the 8250 driver is being loaded: “[    0.498287] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled”, but the omap driver is taking precedence? (not sure) Disabling the omap driver could resolve this as discussed.

Best,

Neeraj

[Neeraj Dantu]

Hey Mr.Current,

Two files, refdesign.dts and OCTAVO_OUTPUT can’t be accessed because “This file type is not permitted for security reasons”. Can you please re-upload with a different name or ZIP them?

As for the issue, note that because of the EEPROM ID check in u-boot, different boards can go through different initializations that includes pin-multiplexing. Please make sure you have UART1 pin multiplexing in your device tree in the ‘am33xx_pinmux’ node. Also, please post the output of ‘cat /proc/device-tree/ocp/serial@58022000/status shows’

Best,

Neeraj

[Neeraj Dantu]

olmoDalco,

Not connecting to an existing network with a verified Linux image indicates an issue with either the design or layout.

Since you mentioned that the Etehrnet interface design is the same as the OSD3358-SM-RED, we are assuming:

1. The same interface pins of OSD335x-SM were used in your design

2. The same configurations are set on the PHY

One thing to look at is the Ethernet connector. If you are not using the same ethernet connector as OSD3358-SM-RED, please verify the magnetics configuration is the same as on the OSD3358-SM-RED.

If you still cannot resolve the issue, we will have to take a closer look at your design. Please contact our sales and business development (martin.burgos(at)octavosystems.com) for further offline discussions.

[Neeraj Dantu]

Hi olmoDalco,

Thanks for the additional info. The ethernet kernel logs look fine. First suspicion is that the method used to assign static IP is not functioning and as a result, the port is unable to communicate. Before assigning a static IP, can you first verify that the ethernet port is capable of communication?

For this, you should reverse the changes you made to assign eth0 a static IP address and use an ethernet cable to connect to a local network(must have a DHCP server). An unmodified RED board image(link provided in my previous reply) will send DHCP requests and obtain an IP address if the board is connected to a local network with a DHCP server.

If the board correctly obtains an IP address, then the method you are using to set a static IP address might not be working.

Please try the following commands to bring eth0 interface up and down:

– sudo ifconfig eth0 down

– sudo ifconfig eth0 up

Wireshark(https://www.wireshark.org/) can be a good tool to debug these issues as well. You can use this tool to monitor and validate ethernet communications

Also make sure that your local network is not blocking ethernet traffic.

Removing the HDMI should not cause an issue with Ethernet. So, please try to connect the board to a local network that has a DHCP and try to verify that the PHY is capable of communication.

Let us know if that helps.

Neeraj

[Neeraj Dantu]

olmoDalco,

The first thing to verify is whether the Ethernet interface is working. From the boot logs with the osd3358-bsm-refdesign.dtb, the AR8035 PHY is being detected by the kernel. Are you able to connect to the internet via eth0 interface?

Note that you will not be able to use am335x-boneblack.dtb device tree even if the ethernet PHY is detected during kernel boot. This is because the Ethernet interface pins and Ethernet mode are not the same on the Beaglebone Black(MII) and OSD3358-SM-RED(RGMII).

If your design is identical to OSD3358-SM-RED, a verified working Linux image is available at: https://octavosystems.com/files/osd3358-sm-red-linux-image/. Connection to internet and ssh have been verified on this image on the OSD3358-SM-RED. Using this image, you should be able to verify whether hardware/design is the cause of the issue.

Additionally, if your design has deviations from OSD3358-SM-RED, you will have to make changes in device tree(https://github.com/octavosystems/OSD335x-Device-Tree).

Additional resources:

Pinmux app note for OSD335x: https://octavosystems.com/app_notes/osd335x_pinmux/

Device Tree tutorial for OSD335x: https://octavosystems.com/app_notes/osd335x-design-tutorial/osd335x-lesson-2-minimal-linux-boot/linux-device-tree/

Hope that helps,

Best,

Neeraj

[Neeraj Dantu]

Hi boscoe,

Please check for shorts on IO signals of the board. Also measure the total current consumption and compare it to the expected current consumption of an equivalent design such as a Beaglebone. Monitor the thermal behavior of the board as well as that would indicate an abnormal power draw as well. A high power draw on one of the power rails could be causing the board to reset periodically. Also make sure that PMIC_PB_IN pin of OSD335x is not grounded as that causes the PMIC to power cycle(every 8 sec).

Apart from shorting/current draw there might be a specific component at fault. The processor has already booted at ~15 seconds, are there other components that are being powered up/initialized at ~15 seconds?

Plotting the main power rails including the power input, the PMIC/processor interface and power rails of various subsystems of the processor with an oscilloscope might be useful to pin point which power rail is at fault if that is the case.

Hope that helps. Please let us know how it goes.

Neeraj

[Neeraj Dantu]

Hi Calvin,

OSD335x C-SIP integrates the 24MHz main oscillator clock on OSC0. An external oscillator is required to generate the 32KHz real time clock for the RTC subsystem.

Please see the updated datasheet for available RTC power modes. Although we have separated the VDDS and VDDS_RTC rails that allow for them to be powered independently in an RTC only mode, there could be power up sequencing issues that might not allow for an RTC only mode operation when using just the TPS65217C PMIC in the SiP (See https://e2e.ti.com/support/processors/f/791/t/497615 for more explanation and alternate implementation). We are testing several other alternate implementations of the RTC only mode and we will create an App note with respect to implementation. For now, using an external RTC module is your best bet.

The battery controller you linked should work. Note that V_CTRL needs to be always high to enable 1.8V LDO to power the RTC. VDDS would required a separate LDO that would come up in the correct sequence. Please see: http://www.ti.com/lit/ug/slvu551i/slvu551i.pdf for the power up sequencing.

Best,

Neeraj

 

[Neeraj Dantu]

Hi Marcin,

We have followed up on this issue offline. Please look out for a schematic review providing input on the issue from our sales team.

Best,

Neeraj

[Neeraj Dantu]

Hi Hirogens,

The configuration described should work as MII1 and GPMC interfaces have no pins in common and pins shown in the figure can be used for SDIO interface.

Some resources that can help with pin multiplexing:

1. TI pinmux tool: https://dev.ti.com/pinmux/

2. Pin mapping between AM335x and OSD335x family: https://octavosystems.com/app_notes/osd335x-family-pin-assignments/

3. Device tree examples and building: https://github.com/RobertCNelson/dtb-rebuilder

Best,

Neeraj

[Neeraj Dantu]

The issue is probably related to EEPROM ID as you suspected. U-boot determines the flavor of the boards based on the EEPROM ID and selects the appropriate device tree for boot. It would be a good idea to check whether the device tree being selected is present at the right place in the root file system. Also, parse through the debug messages on UART0 to determine the exact point of failure. Here is a good resource on buildroot for build process and boot: https://bootlin.com/training/buildroot/

Please note that the forums at Beagleboard.org(https://beagleboard.org/discuss) are more appropriate for discussion and help on Beagle products.

Best,

Neeraj

[Neeraj Dantu]

Hi Alladin,,

Just to make sure, you have verified 24MHz oscillating crystal on the main OSC0 clock input?

As the issue is persisting, please send us your schematic and layout files for us for further debug. You can send them to our Business Development Manager at martin.burgos(at)octavosystems.com. You have communicated with him before.

Best,

Neeraj

[Neeraj Dantu]

Hi Alladin,

Can you check whether both your crystal oscillator(24MHz) as per this post: https://e2e.ti.com/support/processors/f/791/p/404843/1439658. Also regardless of internal pull-up, can you populate R4 and see if that fixes the issue?

Do you have more than 1 board that is exhibiting this behavior?

Best,

Neeraj

[Neeraj Dantu]

Hi Alladin,

If PMIC_PGOOD and PWRONRSTN are both at 1.8V, it means that the PMIC has successfully brought up all the power rails(See Figure 6 in http://www.ti.com/lit/ug/slvu551i/slvu551i.pdf). The output of the buffer IC C1(RESET#) should be 3.3V(pull up). If you are seeing a 0V on this signal, it could mean that the buffer IC C1 is at fault. If C1 is faulty, replacing it should fix the problem. Another possible reason would be a short on the RESET# signal to GND (caused by layout).

Also, if R4 is not populated, it needs to be populated as the output of the buffer is open drain and WARMRSTN pin has a weak pull-up.

Let us know if that helps and if you have more questions.

Best,

Neeraj

[Neeraj Dantu]

Memaher,

USB OTG functionality can be enabled by exposing the USB_ID pin to the USB connector(instead of floating or pulling to GND).

In addition to USB_ID, special configuration is required to manage the power supply to and from the USB port in different configurations. If the port is functioning as a client port, power must be supplied to USB_VBUS+VIN_USB. If the port is functioning as a host, on board power switches should be enabled to supply power to the USB slave(done via USBx_DRVVBUS). The switching between the power in/out can be done using USB_ID(USB_ID controls USBx_DRVVBUS which can be used as enable signal to power out) and presence of VIN_USB as control signals.  If you are using a powered hub when using the port as a USB host, then no additional power configuration is necessary.

EDIT: Updating this to add info about USBx_DRVVBUS

Hope this helps,

Best,

Neeraj

 

• This reply was modified 6 years, 4 months ago by Neeraj Dantu. Reason: Add info about USBx_DRVVBUS

[Neeraj Dantu]

Andy,

Glad you could find the cause of the issue. Thanks for the documentation and closing the loop.

Best,

Neeraj

[Author]

Posts