[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

[Neeraj Dantu]

Tomas,

You should see a new branch “kirstone” on meta-octavo-osd32mp1 here: https://github.com/octavosystems/meta-octavo-osd32mp1/tree/kirkstone. We are working on getting audio issues resolved. Apart from that, everything should be working.

Best,

Neeraj

[Neeraj Dantu]

Hey Ben,

As a quick check, can you make sure you have proper double quotation marks around the FIP_BL32_CONF variable? There could be a problem with the way the quotation marks are encoded. Can you check by deleting the quotation marks and re-entering them when you execute the command on the terminal?

Also, please make sure you have your FIP_DEPLOYDIR_ROOT assignment correctly as that is important. Please see https://octavosystems.com/app_notes/stm32mp1-cubemx-tutorial-for-osd32mp15x/ for more information on compiling using Developer Package.

Finally, please note that we stopped maintaining the BRK developer Package patches as we have moved to supporting Distribution Package: https://github.com/octavosystems/meta-octavo-osd32mp1. So, the latest sources in the BRK patches repo will only work for OpenSTLInux v2.x.

However, you can use the patches in meta-octavo and import them into the Developer Package. For example, uboot patches are available here: https://github.com/octavosystems/meta-octavo-osd32mp1/tree/dunfell/recipes-bsp/u-boot/files.

Best,

Neeraj

 

[Neeraj Dantu]

Hey Farid,

The kernel messages indicate an issue with voltage selection settings in the device tree. In the sdmmc3 node, an IO VCC supply may be needed. See example here: https://wiki.st.com/stm32mpu/wiki/SDMMC_device_tree_configuration. The property needed could be vqmmc-supply.

I am assuming you have VIO for the WiFi module set to 1.8V and the IOs of the MMC interface are pulled to 1.8V and not 3.3V.

If you have some time, please post some info about how you were able to resolve your earlier boot issue.

Thanks and Best,

Neeraj

[Neeraj Dantu]

Thanks Michal for a great reply.

Gil,

If you have an eMMC on board, you will need a way to program it. Michal described 2 ways to do it and both of them require different interfaces to be active:

1. You can program the eMMC by booting from a secondary source like an SD card interface(this would also require you to change boot mode). From the Linux image booted from the SD card, you can program the eMMC by using “dd”

2. You can also program the eMMC via USB device port(like in OSD32MP1-BRK or OSD32MP1-RED). You will need to use Cube Programmer to USB boot

There is a 3rd way to boot which also involves using Cube Programmer, but only requires a UART via Serial boot. You can send FSBL(TF-A) and SSBL(U-Boot) via serial using Cube Programmer while you set the boot mode to serial. Then you can program the eMMC via a communication interface enabled by the SSBL, generally this is Ethernet, because you do not have USB/SD card interfaces as described in #1 or #2.

Please take a look at https://www.st.com/resource/en/application_note/an5275-usb-dfuusart-protocols-used-in-stm32mp1-series-bootloaders-stmicroelectronics.pdf and https://wiki.stmicroelectronics.cn/stm32mpu/wiki/How_to_use_UART_as_serial_boot_device_with_STM32CubeProgrammer for more info.

Best,

Neeraj

[Author]

Posts