Mnagibulla,
We apologize for the delayed response. Can you please check when the 24HMz clock signal comes up in relation to the power rails? We suspect a delay in the clock signal could be holding up the processor from booting.
Another thing to check is the boot mode configuration(See Table 26-7 of the AM335x Technical Reference Manual:Â https://www.ti.com/lit/ug/spruh73p/spruh73p.pdf) The device may be getting ‘stuck’ in a boot source that has precedence over UART/MMC. If you can, please verify the SYSBOOT configuration and post here.
Please let us know how the debug is going and if you have additional questions.
Best,
Neeraj.
Hey Memaher,
A couple of changes are suggested for the device tree attached:Â emanip-arm-ctrl.txt.
1. pinctrl-names ‘default’ and ‘sleep’ are defined but ‘sleep’ pin mux definitions are not linked in the @mac node.
2. The pin mux definitions in ‘mii_pins_default‘ set the pins for GMII and RGMII modes instead of the MII mode that they need to be set to
3. This is more of a clean up action, but please get rid of the pinmux nodes that are not being used for clarity.
These changes might fix the issues you are having. In case they do not, please attach a complete log output of dmesg(failed upload in your last post) so that we can examine how the processor is probing the PHYs and initializing the interfaces
In addition, note that only 1 1.5K pull-up is enough on MDIO_DATA and 2 pull-ups in parallel could be stronger than necessary,
Hope this helps. Please let us know how your debug goes.
Neeraj
Thanks for the update!
Neeraj
Aliberal,
You are right, the current version of the cube-MX does not generate a GPIO specific pinctlr node. Instead, the generated device tree files include the https://github.com/STMicroelectronics/linux/blob/v4.19-stm32mp/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi. So, you will have to edit this file to set the pin multiplexing for GPIO.
ST has iterated the tool a couple of times since the release of the MP1 and we noticed that they are adding additional features. We assume the MX tool is still getting worked on to make the generation of the device trees more specific. We will forward this feedback to the ST team.
Best,
Neeraj
Eric,
Thanks for the update. If you want to use the Uniflash tool, please make sure to configure it at described in section 6.2.1 of the application note
Best,
Neeraj
srebers,
From the logs(last lines), it looks like the board is trying to use CPSW(ethernet PHY) as the communication interface. The RED board uses a different PHY than the Beaglebone Black. Can you verify that the USB RNDIS is being used by using “printenv ethact”?
Addition info in this thread:Â https://stackoverflow.com/questions/32747239/can-u-boot-support-more-than-one-ethernet-port
Also note that we demonstrated TFTP boot over USB interface on the RED board in this app note:Â https://octavosystems.com/app_notes/programming-emmc-with-usb/
Please follow up here.
Best,
Neeraj
Memaher,
Please take a look at baremetal code attached to the EEPROM application note: https://octavosystems.com/app_notes/osd335x-eeprom-during-boot/#_Toc382081438
Best,
Neeraj
Hey Randy,
Thank you for the input. Currently, you can generate a Solidworks model with Altium 3D model export support:Â https://www.altium.com/documentation/15.1/display/ADES/NFS_15_1((Enhanced+3D+Model+and+Export+Support))_AD
We will add the 3D model on our website as well in the future.
Best,
Neeraj
Anthony,
See https://octavosystems.com/forums/topic/osd335x-c-sip-bootloader-issues/ for relevant discussion. Aleix was kind enough to put together a guide: https://docs.google.com/document/d/1mLe8aKckKvg9QwjWJkdTg8gPltMKCRK__lkcNBFa6k0/edit
Best,
Neeraj
Kartik,
I am assuming the flow control pins for UART0(C12/C13) are accessible on your custom board. Hardware flow control is supported in omap uart driver.
You should be able to test hardware flow control for UART. First, you will have to set pin multiplexing for these pins in your device tree. You should add pin mux details of C12 and C13 her:Â https://github.com/RobertCNelson/dtb-rebuilder/blob/4.14-ti/src/arm/am335x-bone-common.dtsi#L92
Please see application notes regarding device tree for help:
Pin multiplexing for OSD335x: https://octavosystems.com/app_notes/osd335x_pinmux/
Device tree tutorial:Â https://octavosystems.com/app_notes/osd335x-design-tutorial/osd335x-lesson-2-minimal-linux-boot/linux-device-tree/
For testing, please take a look at:Â http://processors.wiki.ti.com/index.php/Linux_Core_UART_User%27s_Guide. You can also create a test environment by setting up your board as transmitter and pull down the CTS pin to GND to see if the processor stops communication.
Best,
Neeraj
Eric,
I am able to verify that the RNDIS ethernet adapter does show up in Windows 10 when you hold down the boot button with no SD card present.
Did you check whether you have the RNDIS driver installed? The board should send out BOOTP requests on the USB interface before it jumps to UART boot mode on UART0. If you are seeing characters on the UART console, it means that the board has cycled through the other boot modes in the list.
I would advise to try a different host Windows machine.
Another suggestion is for you to install the Uniflash tool from TI and try to boot from USB:http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components_Tools.html#sitara-uniflash
We demonstrate how to use Uniflash to program EEPROM for the OSD335x family here: https://octavosystems.com/app_notes/osd335x-eeprom-during-boot/#_Toc382081434
Please let us know if you make progress or if you have additional questions.
Best,
Neeraj
Eric,
You should be able to see a USB RNDIS adapter on your computer. Please make sure you have the RNDIS driver(https://developer.toradex.com/knowledge-base/how-to-install-microsoft-rndis-driver-for-windows-7). The board should show up under “Network Adapters” in Device Manager.
Also, make sure the RED board is functional and boots through eMMC and SD card.
Best,
Neeraj
Anthony,
Thanks for the update! Glad you are able to get it to work.
I am not sure why you were unable to boot with the BLANK image. Do you have an RTC oscillator on OSC1 on the board? If you do not, my guess is that u-boot is trying to exercise RTC and running into a fault(See https://octavosystems.com/forums/topic/osd335x-c-sip-bootloader-issues/)
Let us know if you have any other questions.
Best,
Neeraj
Anthony,
Yes, you should be able to boot the board with the PocketBeagle device tree
Best,
Neeraj
Anthony,
The model you enter does make a difference for start-up services. I would suggest try the Beaglebone Black model name to try and boot the board and communicate via the RNDIS ethernet adapter since that is your first goal.
You will not need a separate device tree to boot the board if you are booting from the SD card interface using the same pins as PocketBeagle and if you are using the same USB0 configuration as on the PocketBeagle.
Now, in order for the board to be fully functional however, you would need to build a custom device tree that includes the wifi module and other devices on your board.
Hope that helps.
Best,
Neeraj
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.
"*" indicates required fields
"*" indicates required fields
"*" indicates required fields
"*" indicates required fields