[Neeraj Dantu]

Gil,

1. The hardware connections sound ok. One thing to check is the CC pin configuration. Are you using a USB-C controller chip like STUSB1600 to manage dual role function?

The CubeMX setup looks okay as well. I would check the device tree generated against a DK2/RED/BRK. Since the board connects to Cube Programmer initially, this feels like there is a configuration issue at TF-A. If you are using the same USB port and non-volatile memory interface(eMMC) as OSD32MP1-RED, you can use the same setup with a RED board to eliminate issues with the custom board as the cause for this issue.

2. Note that you can change pinmux settings in TF-A here: https://github.com/octavosystems/OSD32MP1-RED-Device-tree/blob/main/tf-a-v2.4-r0/stm32mp157c-osd32mp1-red.dts#L547

3. I am not quite sure what the setup is with the RED/BRK and which board firmware version you are using. I would start with https://github.com/octavosystems/meta-octavo-osd32mp1 since it is a known verified OpenST image. The UART settings should be 115200, 8N1. Gibberish on the terminal might also mean the host computer is not properly interpreting the data on the terminal. It might need a different terminal window or a reboot. See if you still see gibberish if you are entering data on that terminal via keyboard.

Best,

Neeraj

 

[Neeraj Dantu]

Banjamin,

In order to get an SSH connection over to the peripheral BRK, you will need to know the IP address of that BRK. You can bring up a console on the peripheral BRK by connecting to UART4 via a USB-UART cable, and then look at the output of ifconfig there. If you do not have an IP address, you can assign a static IP on that board and then you will need to use that IP address to SSH into that board from the host BRk board.

Best,

Neeraj

[Neeraj Dantu]

Gil,

It does seem that the board is able to boot via USB with the TF-A loaded. However, note that the USB configuration is from the internal ROM code. The TF-A also needs to be able to exercise the USB port correctly in order to load the next stage(U-Boot).

#include “stm32mp15-fw-config.dtsi” should already be part of the OpenSTLinux package you are using. This file is in ST’s sources: https://github.com/STMicroelectronics/arm-trusted-firmware/blob/v2.6-stm32mp/fdts/stm32mp15-fw-config.dtsi

You mentioned that you cannot access the logs from the board because the UART4 interface is not accessible. You can change the console output in TF-A here: https://github.com/STMicroelectronics/arm-trusted-firmware/blob/v2.6-stm32mp/fdts/stm32mp157c-dk2.dts#L28. Once you redirect the console output to a serial interface you can access, you can determine the error in boot more specifically.

Best,

Neeraj

[Neeraj Dantu]

Gil,

You should be able to do TF-A debug with CubeIDE, but there is currently no tutorial to show how it is done. However, you can use gdb as shown here: https://wiki.st.com/stm32mpu/wiki/How_to_debug_TF-A_BL2

Best,

Neeraj

EDIT: Found this: https://wiki.st.com/stm32mpu/wiki/How_to_manage_OpenSTLinux_projects_in_STM32CubeIDE. You can use CubeIDE to load OpenSTLinux projects.

• This reply was modified 1 year, 10 months ago by Neeraj Dantu.

[Neeraj Dantu]

Gil,

Please take a look at https://www.st.com/resource/en/application_note/an5275-usb-dfuusart-protocols-used-in-stm32mp1-series-bootloaders-stmicroelectronics.pdf for detailed information on the DFU protocol. The TF-A being sent over needs to initiate a DFU download of the next stage bootloader(u-boot), which is what is likely failing to do on your board. Please review your TF-A device tree: https://wiki.st.com/stm32mpu/wiki/USBPHYC_device_tree_configuration.

Best,

Neeraj

[Neeraj Dantu]

Peter,

The part for the eMMC used in C-SiP is subject to change. It does adhere to JEDEC standard v4.3 or later(supported by AM335x). JEDEC defines the standard for the eMMC(https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc). The standard allows to use different part numbers as long as they adhere to the JEDEC standards we adhere to. An example datasheet for an eMMC part that can be in the C-SiP can be found here: https://datasheet.lcsc.com/szlcsc/2006081033_Kingston-Technology-EMMC04G-M627-A01_C577446.pdf

Best,

Neeraj

[Neeraj Dantu]

bm,

The kernel boot options can be set in an extlinux file in /boot folder of the SD card. Please see https://github.com/octavosystems/osd32mp1-build-tools/blob/master/stm32mp157c-osd32mp1-red-extlinux.sh#L26 for example. From the boot log, it looks like the kernel is looking for a partition that has a UUID of e91c4e10-16e6-4c0e-bd0e-77becf4a3582. This does not exist on your SD card. The kernel is getting this from /boot/extlinux/extlinux.conf. This is where you can change the root= from the UUID to the root partition ID of your SD card or the UUID of your root partition. You can find the UUID of the partitions of the SD card you are using by inserting it into a Linux computer and running “blkid”. The output of the command is the UUIDs of all devices and filesystem UUIDs.

Best,

Neeraj

[Neeraj Dantu]

Gil,

I have verified STLink V3 with OSD32MP1-RED(with CubeIDE). I suggest installing CubeIDE, which may give you more detail on the error. Please double check the settings, I used the tag-connect header on OSD32MP1R-RED with Engineering mode(you will need to use 0b100 boot mode for this, make sure you have this boot mode), ST-LINK OpenOCD, Connection setup in CubeIDE is SWD interface, 8MHz frequency.

Best,

Neeraj

[Neeraj Dantu]

Gil,

Can you post the output on your Cube Programmer command line as well as the output on the console for the board? The output on the console of the board should reveal the error that has occurred during the download.

Have you gone through the check items here: https://community.st.com/s/article/FAQ-STM32MP1-STM32CubeProgrammer-USB-reconnect-error-at-STM32MP1-boot-device-flashing?

Please also update the Cube Programmer on your machine as we have seen issues when using an incompatible version between Cube Programmer and OpenSTLinux.

Best,

Neeraj

 

[Neeraj Dantu]

Gil,

As communicated offline, please see below:

1. Make sure all the jumpers required for the STLink V3 are populated according to the user guide: https://www.st.com/resource/en/user_manual/um2448-stlinkv3set-debuggerprogrammer-for-stm8-and-stm32-stmicroelectronics.pdf

2. Make sure you can connect to the debugger. You may need to upgrade CubeIDE to get latest drivers.

3. Make sure the debugger configuration for the CubeIDE project is correct and that STLink probe is detected and selected in the debug configuration window for the project.

We have verified connecting OSD32MP1-RED with STLink-V2 and STLink-V3 should not be any different. If you have an ST EV1 board, can you can connect the signals the exact same way as you are connecting to OSD32MP1-RED and verify the behavior is different.

Please let us know how it goes.

Best,

Neeraj

[Neeraj Dantu]

Gil,

If you do not intend to use the pin in conflict for wake up functionality, this should be fine.

Best,

Neeraj

[Neeraj Dantu]

Gil,

If you are not using the TAMP function for the assigned pin and are only intending to use the SPI function, there should not be a problem.

Since you are assigning the peripheral to Linux, it is possible to manage the chip select(NSS) in the Linux device tree. You can use any GPIO as a chip select. See https://wiki.st.com/stm32mpu/wiki/SPI_device_tree_configuration

Best,

Neeraj

[Neeraj Dantu]

Ian,

Few inputs regarding the issue:

1. Please check whether you need TX/RX delays in your MAC-PHY interface. This is set by phy-mode property in the device tree

2. Please check the pinmux settings of the RGMII interface you are using and whether all the pinmux needed is defined in your device tree.

3. Defining reset-gpios should not give you an error in your device tree overlay compilation. You may have to check your formatting

4. You can use the Ethernet Loop Back test we provided in the Ethernet Application Note(https://octavosystems.com/app_notes/ethernet-am335x-system-in-package/#_Toc382081438) to see if you can exercise the MAC-PHY interface

5. Please review how are you bringing the PHY out of reset during initialization, specifically how the reset of the PHY is being released. You should hold the PHY in reset for a little while after all the power sequencing is done for the PHY to initialize properly. Holding the PHY in reset a little bit using a jumper after power sequencing should allow you to see if there is a PHY reset timing issue.

6. You can scope the MAC-PHY interface signals to see activity and check timings of the signals.

Please let us know how it goes.

Best,

Neeraj

[Neeraj Dantu]

Ben,

The CubeMX tutorial you linked should work on both BRK and RED boards. The only caveat is that the image that you will generate will be a minimal image without all the features activated on the board.

 

For the patches for Developer Package, you can access them here: https://github.com/octavosystems/meta-octavo-osd32mp1/tree/dunfell/recipes-bsp/u-boot/files. We no longer update the patches repo since they are included in our Distribution Package support and we can avoid duplication.

best,

Neeraj

[Neeraj Dantu]

Carlos,

For now, our plan is to support the major versions of OSTL releases once a year(x.0). Please let us know any specific issues you have for this release. We can be flexible on doing another release if the issues are big.

Best,

Neeraj

[Author]

Posts