After several months, it’s time to resume our series of blog posts about building a Linux system for the STM32MP1 platform. After showing how to build a minimal Linux system for the STM32MP157 platform, how to connect and use an I2C based pressure/temperature/humidity sensor and how to integrate Qt5 in our system, how to set up a development environment to write our own Qt5 application and how to develop a Qt5 application, we will now cover the topic of factory flashing.
List of articles in this series:
- Building a Linux system for the STM32MP1: basic system
- Building a Linux system for the STM32MP1: connecting an I2C sensor
- Building a Linux system for the STM32MP1: enabling Qt5 for graphical applications
- Building a Linux system for the STM32MP1: setting up a Qt5 application development environment
- Building a Linux system for the STM32MP1: developing a Qt5 graphical application
- Building a Linux system for the STM32MP1: implementing factory flashing
- Building a Linux system for the STM32MP1: remote firmware updates
What is factory flashing ?
So far, we have used a microSD card as storage for the Linux system running on the STM32MP1 platform. Since this media is removable, we can easily switch the microSD card back and forth between the STM32MP1 platform and our development workstation, which is nice during development and debugging.
However, an actual product will most likely use some form of non-removable persistent storage, typically an eMMC or a NAND flash. While not available on the STM32MP1-DK1 board probably for cost reasons, these storage devices are very common in most embedded systems. For example, the STM32MP157A-EV1 board provides three non-removable persistent storage devices: a 4 GB eMMC, a 1 GB NAND flash, and a 64 MB QSPI NOR flash.
When such storage devices are shipped by their manufacturer, they are typically empty. Therefore, as part of the manufacturing process of your embedded systems, you will have to load the relevant storage device with your Linux system, applications and data, so that the embedded system is fully operational: this is the process referred to as factory flashing in this blog post.
If you are doing a very high volume product, you can ask your eMMC or NAND flash vendor to pre-load a system image on the storage before it is shipped to you and assembled on your board. However, many companies do products with volumes that are not large enough to make such a strategy possible: in this case, you really receive an empty storage device, and have to flash it.
A first possibility to flash the non-removable storage is to use a removable storage device, boot a Linux system on the device, and use it to flash the non-removable storage. This can definitely be a possible option in some situations, but it is not always possible (if there’s no removable storage device interface at all) or not always practical.
However, most system-on-chips, including the STM32MP1 include some ROM code that the processor executes at boot time, even before it loads the first stage bootloader. This ROM code is primarly responsible for loading the first stage bootloader into memory, but it also very often offers a communication channel with the outside world, which can be used to gain control of a platform that has nothing at all on its storage. This communication channel is typically over USB or UART, and most often uses a custom, vendor-specific protocol, which is understood by vendor-specific tools. This protocol generally allows to send some code to the target and get it executed, which is sufficient to be able to reflash the target device.
Here are a few examples with system-on-chips from various vendors:
- The ROM code of the NXP i.MX processors implements a USB-based protocol, which can be interfaced either using the NXP-provided mfgtools, or using the community-developed imx_usb_loader. The latter was presented in one of our earlier blog posts about i.MX6 factory flashing.
- The ROM code of Microchip SAMA5 processors implements a USB-based protocol, which can be interfaced using a tool called SAM-BA
- The ROM code of Rockchip processors implements a USB-based protocol, which can be interfaced either using a Rockchip-specific tool called rkdeveloptool
- The ROM code of the ST STM32MP15 processors also implement a USB-based protocol, which can be interfaced using the STM32 Cube Programmer
Obviously, in this blog post, we are going to use the latter, STM32 Cube Programmer, to flash our STM32MP1 platform. Since the DK2 board only has a removable device, we will use the tool to flash the SD card, but the process and logic would be the same for any other (non-removable) storage device.
Getting and installing STM32 Cube Programmer
While ST generally has very good upstream and open-source support for its products, the STM32 Cube Programmer unfortunately doesn’t follow this strategy: you need to be registered on the ST web site to download it, and its source code is not available. Due to this registration process, we for example cannot create a Buildroot package that would automatically download and install this tool for you.
So, follow the process to create an account on the ST web site, and then go to the STM32 Cube Programmer page. At the time of this writing, the latest version is 2.2.1, but according this Wiki page, this version doesn’t work for the STM32MP1 platform. Instead, select to download the 2.2.0 version, which is known to work. You will then download a file called en.stm32cubeprog.zip (it doesn’t have the version in its name, which isn’t great) weighting 187 MB, and which has the SHA256 hash 91107b4d605d126f5c32977247d7419d42abb2655848d2d1a16d52f5f7633d2d.
Extract this ZIP file somewhere in your system, and then run the SetupSTM32CubeProgrammer-2.2.0.linux executable:
$ ./SetupSTM32CubeProgrammer-2.2.0.linux
Got through the installation steps. On our system, we customized the installation path to be just $HOME/stm32cube, and the remainder of this blog post will assume this is where you installed the STM32 Cube Programmer.
In this blog post, we are only going to use the command line interface (CLI) of STM32 Cube Programmer, so just make sure you can run the corresponding tool:
$ ~/stm32cube/bin/STM32_Programmer_CLI
-------------------------------------------------------------------
STM32CubeProgrammer v2.2.0
-------------------------------------------------------------------
Usage :
STM32_Programmer_CLI.exe [command_1] [Arguments_1][[command_2] [Arguments_2]...]
[...]
Testing the communication with the board
On the back of the board, there is a two-way DIP switch labeled SW1, which is used to configure the boot mode. When both are “ON”, the board boots from the SD card. When both are “OFF”, the board enters the “USB boot for flashing mode”, which is what we are going to use. So switch both switches to OFF, and reset the board.
Plug an additional USB-C cable from the board CN7 connector (which is located between the HDMI port and the 4 USB host ports).
Then, reset the board. If you run lsusb on your Linux workstation, you should see a new device:
Bus 003 Device 011: ID 0483:df11 STMicroelectronics STM Device in DFU Mode
Then, you can ask STM32_Programmer_CLI to list the devices it sees over USB. This needs root permissions (unless appropriate udev rules are created):
$ sudo ~/stm32cube/bin/STM32_Programmer_CLI -l usb
-------------------------------------------------------------------
STM32CubeProgrammer v2.2.0
-------------------------------------------------------------------
===== DFU Interface =====
Total number of available STM32 device in DFU mode: 1
Device Index : USB1
USB Bus Number : 003
USB Address Number : 003
Product ID : DFU in HS Mode @Device ID /0x500, @Revision ID /0x0000
Serial number : 004200343338510534383330
Firmware version : 0x0110
Device ID : 0x0500
Good, the STM32CubeProgrammer tool is seeing our board, and we see that the Device Index is USB1. Keep that in mind for the next steps.
Change the Linux system boot chain
STM32CubeProgrammer works by sending a U-Boot bootloader over USB, and then talking to this U-Boot to make it erase the MMC or NAND flash, and make it write some data to those storage devices. However, for some reason, STM32CubeProgrammer doesn’t work with the boot flow we have used so far, which uses the U-Boot SPL as the first-stage bootloader, and U-Boot itself as the second stage bootloader. It only works when the first stage bootloader is the Arm Trusted Firmware, also called TF-A. You can get more details about the different possible boot chains on STM32MP1 on this Wiki page.
Due to this constraint, we are going to switch our Buildroot configuration to use TF-A instead of U-Boot SPL as the first stage bootloader.
First of all, we need to backport two Buildroot commits, which did not exist in the Buildroot 2019.02 we are using, but have been integrated later. The first commit, 9dbc934217e170578d4cbfdf524bc1b3988d0b9e allows to build TF-A for ARM 32-bit platforms, while the second commit, e4d276c357fdf9f19f99f826cab63f373687f902 allows to provide a custom name for the TF-A image name.
In Buildroot, do:
$ git cherry-pick 9dbc934217e170578d4cbfdf524bc1b3988d0b9e $ git cherry-pick e4d276c357fdf9f19f99f826cab63f373687f902
The second one will cause some minor conflict in boot/arm-trusted-firmware/Config.in. Resolve the conflict by removing the BR2_TARGET_ARM_TRUSTED_FIRMWARE_DEBUG option from this file, remove the conflict markers, then run:
git add boot/arm-trusted-firmware/Config.in git commit
If you’re not sure about this, you can check our 2019.02/stm32mp157-dk-blog-6 branch on Github, which has these changes already integrated.
Once done, we can run make menuconfig and start modifying the Buildroot configuration. Here are the changes that we need:
- In the Bootloaders menu, enable ARM Trusted Firmware (ATF), and then:
- Set ATF Version to
Custom Git repository - Set URL of custom repository to
https://github.com/STMicroelectronics/arm-trusted-firmware.git - Set Custom repository version to
v2.0-stm32mp-r2 - Set ATF platform to
stm32mp1 - Set Additional ATF build variables to
DTB_FILE_NAME=stm32mp157c-dk2.dtb AARCH32_SP=sp_min. TheDTB_FILE_NAMEselects the correct Device Tree file for the DK2 board, while theAARCH32_SPindicates that we are using the “minimal” secure payload, and not a complete Trusted Execution Environment such as OP-TEE. - Set Binary boot images to
*.stm32. This makes sure the final image gets copied tooutput/images.
- Set ATF Version to
- Still in the Bootloaders menu, inside the U-Boot option, make the following changes:
- Change Board defconfig to
stm32mp15_trusted. This is the most important change, which makes U-Boot build only the second stage, and in a format that gets loaded by TF-A as the first stage. - In U-Boot binary format, disable
u-boot.img, and instead enableCustom (specify below)and indicateu-boot.stm32as the value for U-Boot binary format: custom names. - Disable the Install U-Boot SPL binary image option.
- Change Board defconfig to
Overall, the diff of the changes in the configuration looks like this:
@@ -30,16 +30,22 @@ BR2_TARGET_ROOTFS_EXT2=y BR2_TARGET_ROOTFS_EXT2_4=y BR2_TARGET_ROOTFS_EXT2_SIZE="120M" # BR2_TARGET_ROOTFS_TAR is not set +BR2_TARGET_ARM_TRUSTED_FIRMWARE=y +BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_GIT=y +BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_REPO_URL="https://github.com/STMicroelectronics/arm-trusted-firmware.git" +BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_REPO_VERSION="69cc28c5a1b877cf67def7f94dece087f3917b1c" +BR2_TARGET_ARM_TRUSTED_FIRMWARE_PLATFORM="stm32mp1" +BR2_TARGET_ARM_TRUSTED_FIRMWARE_ADDITIONAL_VARIABLES="DTB_FILE_NAME=stm32mp157c-dk2.dtb AARCH32_SP=sp_min" +BR2_TARGET_ARM_TRUSTED_FIRMWARE_IMAGES="*.stm32" BR2_TARGET_UBOOT=y BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y BR2_TARGET_UBOOT_CUSTOM_GIT=y BR2_TARGET_UBOOT_CUSTOM_REPO_URL="https://github.com/STMicroelectronics/u-boot.git" BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION="v2018.11-stm32mp-r2.1" -BR2_TARGET_UBOOT_BOARD_DEFCONFIG="stm32mp15_basic" +BR2_TARGET_UBOOT_BOARD_DEFCONFIG="stm32mp15_trusted" BR2_TARGET_UBOOT_CONFIG_FRAGMENT_FILES="board/stmicroelectronics/stm32mp157-dk/uboot-fragment.config" # BR2_TARGET_UBOOT_FORMAT_BIN is not set -BR2_TARGET_UBOOT_FORMAT_IMG=y -BR2_TARGET_UBOOT_SPL=y -BR2_TARGET_UBOOT_SPL_NAME="spl/u-boot-spl.stm32" +BR2_TARGET_UBOOT_FORMAT_CUSTOM=y +BR2_TARGET_UBOOT_FORMAT_CUSTOM_NAME="u-boot.stm32" BR2_TARGET_UBOOT_CUSTOM_MAKEOPTS="DEVICE_TREE=stm32mp157c-dk2" BR2_PACKAGE_HOST_GENIMAGE=y
Before we can restart the build, we need to adjust the genimage.cfg file that describes the layout of the SD card. Indeed, the file name of the first stage bootloader is now tf-a-stm32mp157c-dk2.stm32 instead of u-boot-spl.stm32 and the file name of the second stage bootloader is now u-boot.stm32 instead of u-boot.img. All in all, your genimage.cfg file in board/stmicroelectronics/stm32mp157-dk/genimage.cfg should now look like this:
image sdcard.img {
hdimage {
gpt = "true"
}
partition fsbl1 {
image = "tf-a-stm32mp157c-dk2.stm32"
}
partition fsbl2 {
image = "tf-a-stm32mp157c-dk2.stm32"
}
partition ssbl {
image = "u-boot.stm32"
}
partition rootfs {
image = "rootfs.ext4"
partition-type = 0x83
bootable = "yes"
size = 256M
}
}
With this in place, it’s time to restart the build. You can do a complete rebuild with make clean all, or you can just clean up U-Boot, and restart the build:
$ make uboot-dirclean $ make
You should now have in output/images the new TF-A image tf-a-stm32mp157c-dk2.stm32 and the new U-Boot image u-boot.stm32. Of course the sdcard.img file has been updated.
Rather than updating our SD card on our workstation, we’ll directly use the STM32CubeProgrammer tool to do that, in the next section.
Flashing the board
The STM32CubeProgrammer tool takes as input a flash layout file, which has a .tsv extension. The format of this file is extensively documented on this Wiki page. It is essentially a text file that says what should be flashed in each partition.
In our case, we are going to simply flash the entire sdcard.img instead of flashing partition by partition. To achieve this, we are going to use the RawImage image type, also described on the Wiki page.
Let’s create a file board/stmicroelectronics/stm32mp157-dk/flash.tsv, with the following contents:
#Opt Id Name Type IP Offset Binary - 0x01 fsbl1-boot Binary none 0x0 tf-a-stm32mp157c-dk2.stm32 - 0x03 ssbl-boot Binary none 0x0 u-boot.stm32 P 0x10 sdcard RawImage mmc0 0x0 sdcard.img
The first line is a comment, just to help remember what each field is about. The second and third lines tell STM32CubeProgrammer which bootloader images should be used as part of the flashing process. Finally, the last line says we want to flash sdcard.img as a raw image on the mmc0 device.
Then, go do output/images, and run STM32CubeProgrammer. We use the -c port=usb1 argument, because our board was detected as device USB1 when we enumerated all detected devices using the -l usb previously.
$ cd output/images/ $ sudo ~/stm32cube/bin/STM32_Programmer_CLI -c port=usb1 -w ../../board/stmicroelectronics/stm32mp157-dk/flash.tsv
The output will look like this:
-------------------------------------------------------------------
STM32CubeProgrammer v2.2.0
-------------------------------------------------------------------
USB speed : High Speed (480MBit/s)
Manuf. ID : STMicroelectronics
Product ID : DFU in HS Mode @Device ID /0x500, @Revision ID /0x0000
SN : 004200343338510534383330
FW version : 0x0110
Device ID : 0x0500
Device name : STM32MPxxx
Device type : MPU
Device CPU : Cortex-A7
Start Embedded Flashing service
Memory Programming ...
Opening and parsing file: tf-a-stm32mp157c-dk2.stm32
File : tf-a-stm32mp157c-dk2.stm32
Size : 237161 Bytes
Partition ID : 0x01
Download in Progress:
[==================================================] 100%
File download complete
Time elapsed during download operation: 00:00:00.444
RUNNING Program ...
PartID: :0x01
Start operation done successfully at partition 0x01
Flashlayout Programming ...
[==================================================] 100%
Running Flashlayout Partition ...
Flashlayout partition started successfully
Memory Programming ...
Opening and parsing file: u-boot.stm32
File : u-boot.stm32
Size : 748042 Bytes
Partition ID : 0x03
Download in Progress:
[==================================================] 100%
File download complete
Time elapsed during download operation: 00:00:00.791
RUNNING Program ...
PartID: :0x03
reconnecting the device ...
USB speed : High Speed (480MBit/s)
Manuf. ID : STMicroelectronics
Product ID : USB download gadget@Device ID /0x500, @Revision ID /0x0000
SN : 004200343338510534383330
FW version : 0x0110
Device ID : 0x0500
Start operation done successfully at partition 0x03
Memory Programming ...
Opening and parsing file: sdcard.img
File : sdcard.img
Size : 539002368 Bytes
Partition ID : 0x10
Download in Progress:
[==================================================] 100%
File download complete
Time elapsed during download operation: 00:04:31.583
RUNNING Program ...
PartID: :0x10
Start operation done successfully at partition 0x10
Flashing service completed successfully
Finally, we can toggle back the SW1 DIP switches to their ON position, to boot again from SD card, and hit the reset button. The board should boot, but this time with our new image, which uses TF-A instead of U-Boot SPL, so the first lines of the boot process should look like this:
NOTICE: CPU: STM32MP157CAC Rev.B NOTICE: Model: STMicroelectronics STM32MP157C-DK2 Discovery Board NOTICE: Board: MB1272 Var2 Rev.C-01 NOTICE: BL2: v2.0-r2.0(release): NOTICE: BL2: Built : 16:10:53, Jan 7 2020 NOTICE: BL2: Booting BL32 NOTICE: SP_MIN: v2.0-r2.0(release): NOTICE: SP_MIN: Built : 16:10:53, Jan 7 2020 U-Boot 2018.11-stm32mp-r2.1 (Jan 07 2020 - 16:13:55 +0100)
Conclusion
In this article, we have discussed the concept of factory flashing, understood better the different boot chains available for the STM32MP1, switched to a boot chain using TF-A, and presented how to use STM32CubeProgrammer to reflash the entire SD card.
As usual, we have a branch on Github with the Buildroot changes corresponding to this blog post, see the branch 2019.02/stm32mp157-dk-blog-6.
Stay tuned for the next article in this series of blog post, in which we will cover the topic of Over-The-Air firmware update.
You can also use the Graphical User Interface to do that. You just need a correct Java Setup to launch it (described in STM32CubeProgrammer user manual).
Somehow that doesn’t work, not on Linux, not on OSX. There is some error about JavaFX not installed, but some path cannot be found. This is still not fixed. Anyone a solution…
I have not used the Graphical User Interface, only the command line interface. Could you try the command line interface instead ?
Install Liberica Full JDK 8
https://bell-sw.com/pages/downloads/
Click on the dropdown to select the “Full JDK” package next to the download links.
Froms stackoverflow: https://stackoverflow.com/questions/61783369/install-openjdkopenjfx-8-on-ubuntu-20/62198111#62198111
The packages don’t include JavaFX
To fix this you can install Liberica Full JDK which does include this. On their website “bell-sw” you can get the deb package.
I like this blog series a lot! Can’t weet for the next covering OTA updates! Will you be covering Mender?
Thanks Dremsol for your comment. For the OTA, we have chosen to cover swupdate, but Mender.io is of course another very good solution for OTA updates.
Running into this error, both making my own changes following the blog and checking out the branch 2019.02/stm32mp157-dk-blog-6, any ideas?
—
Built stm32image successfully
package/pkg-generic.mk:238: recipe for target ‘/home/user/Desktop/bootlin/linux-system-STM32MP1/buildroot/output/build/arm-trusted-firmware-69cc28c5a1b877cf67def7f94dece087f3917b1c/.stamp_built’ failed
make[1]: *** [/home/user/Desktop/bootlin/linux-system-STM32MP1/buildroot/output/build/arm-trusted-firmware-69cc28c5a1b877cf67def7f94dece087f3917b1c/.stamp_built] Error 2
Makefile:84: recipe for target ‘_all’ failed
make: *** [_all] Error 2
—
Thanks Dan for your comment. Unfortunately, you are not giving enough build output for us to see what the error is. What you posted only shows that it happened during the build of the arm-trusted-firmware package. A possible issue though is that the Device Tree Compiler is missing on your system: I submitted a patch to upstream Buildroot to fix this (https://git.buildroot.org/buildroot/commit/boot?id=ddbb5dbd83170a71f92d3d54e5f8b288cb80871e). I need to have the same in 2019.02/stm32mp157-dk-blog-6 branch.
Hello again Dan. I have now fixed this in 2019.02/stm32mp157-dk-blog-6. Note that to keep a clean Git history that is easily readable, I have force-pushed the branch, so you will want to make sure to use the latest version of this branch. Let me know if that is fixing the problem for you.
Hey Thomas, yeah the updated repo seems to be working fine now, thanks for taking the time to investigate. Keep up the excellent work on the blog series, I’ve been following all the way from the beginning and have learnt so much, you can really tell a lot of thought and effort has gone into the series!
Thanks Dan, glad to hear the issue is resolved for you. And happy to read that this series of blog posts is useful!
Hello Thomas,
that’s working flawlessly on SDcard. What’s the procedure for direct flash on emmc (i use a EV1 board)? If I try to flash rawimage to mmc1 i doesn’t boot…
Hello sgufa, I don’t have an EV1 board readily available, so I cannot double check directly. However, according to https://wiki.st.com/stm32mpu/wiki/STM32MP15_ROM_code_overview#Boot_from_e-E2-80-A2MMC-E2-84-A2, for eMMC boot, the first stage bootloader should in the special eMMC boot regions, and not in normal GPT partitions named fsbl1/fsbl2. I encourage you to compare section 4.3 (for SD card boot) and 4.4 (for eMMC boot) of this wiki page at https://wiki.st.com/stm32mpu/wiki/STM32MP15_ROM_code_overview to understand the differences between eMMC boot and SD card boot.
Then look at https://wiki.st.com/stm32mpu/wiki/STM32CubeProgrammer_flashlayout#Field6-_Offset which documents what special “offset” values you need to use in the STM32 Cube Programmer TSV file to write to the two eMMC boot regions.
Do not hesitate to contact us if you need additional help with this topic.
Hello Thomas,
regarding fsbl1 and fsbl2 i managed to write correctly them modiying the tsv this way:
#Opt Id Name Type IP Offset Binary
– 0x01 fsbl1-boot Binary none 0x0 tf-a-stm32mp157c-ev1-trusted.stm32
– 0x03 ssbl-boot Binary none 0x0 u-boot-stm32mp157c-ev1-trusted.stm32
P 0x10 emmc RawImage mmc1 0x0 sdcard.img
P 0x04 fsbl1 Binary mmc1 boot1 tf-a-stm32mp157c-ev1-trusted.stm32
P 0x05 fsbl2 Binary mmc1 boot2 tf-a-stm32mp157c-ev1-trusted.stm32
u-boot boots correctly but then it stucks at “starting kernel”as below:
Kernel image @ 0xc2000000 [ 0x000000 – 0x9b5690 ]
## Flattened Device Tree blob at c4000000
Booting using the fdt blob at 0xc4000000
`Using Device Tree in place at c4000000, end c4012e2f
Starting kernel …
OK, glad to hear you’ve been able to flash the FSBL properly to the eMMC. Regarding the kernel not booting, you’re not giving enough details. Which kernel version/configuration are you using? Which Device Tree are you using? A boot failure such as the one you’re experiencing typically indicate an incorrect kernel configuration, or an incorrect Device Tree.
I’m using the same in your guide, but i selected EV1 instead of DK2. Anyway i don’t think it’s a configuration/devicetree problem just because if i boot from sd with the same image it works well. I think it’s a problem about offsets in TSV file or something similar
Boot device support for NAND and Flash programming via USB is not supported in Basic boot chain (U-Boot SPL)
Hello mrgabu. This is indeed correct and is already written in this blog, which I’m going to quote: However, for some reason, STM32CubeProgrammer doesn’t work with the boot flow we have used so far, which uses the U-Boot SPL as the first-stage bootloader, and U-Boot itself as the second stage bootloader. It only works when the first stage bootloader is the Arm Trusted Firmware, also called TF-A.
How do I use STM32CubeProgrammer to push boot image (TF-A + uboot) to DRAM
and run it ? Need to boot over USB without media.
Hello SJA. It is not really clear if STM32CubeProgrammer supports this use-case out of the box. Have you tried a TSV file with just the following lines:
See if it gives something useful. But it might be that STM32CubeProgrammer will immediately start the “stm32prog” command on U-Boot. You could probably contact ST for support on this particular question.
Hi, Thomas! Did you try to use factory flashing with the last versions of buildroot, atf, uboot and kernel?
I tryed, but i have an error at start.
Memory Programming …
Opening and parsing file: tf-a-stm32mp157a-dk1.stm32
File : tf-a-stm32mp157a-dk1.stm32
Size : 233784 Bytes
Partition ID : 0x01
Download in Progress:
[==================================================] 100%
File download complete
Time elapsed during download operation: 00:00:00.799
RUNNING Program …
PartID: :0x01
Error: Start operation failed at partition 0x01
Error: TSV flashing service failed
In minicom I see next:
NOTICE: CPU: STM32MP157AAC Rev.B
NOTICE: Model: STMicroelectronics STM32MP157A-DK1 Discovery Board
NOTICE: Board: MB1272 Var1.0 Rev.C-01
ERROR: Boot interface 6 not supported
PANIC at PC : 0x2ffd714f
Buildroot ver: 2020.05
ATF: stm32mp-2.2.r1
uboot: stm32mp-2020.01
kernel: 5.4.31
Hello Vlad. No, I did not recently tried factory flashing, so I can’t say if it is still working or not, I would have to test.
I have the same issue:
ERROR: Boot interface 6 not supported
You need to set this for Additional ATF build variables:
DTB_FILE_NAME=stm32mp157c-dk2.dtb AARCH32_SP=sp_min STM32MP_EMMC=1 STM32MP_USB_PROGRAMMER=1 STM32MP_SDMMC=1)
Hi, Artem! Did you get a working image with new versions of ATF, kernel and uboot? Because i changed ATF variables, but factory flashing still not working for me.
the path to the genimage is incorrect based on your blog-6 branch. It is missing the /common/ dir in the path.
You are not using my 2019.02/stm32mp157-dk-blog-6 as-is: there is no board/stmicroelectronics/common/ directory in my branch. This directory was added later in upstream Buildroot. I think you are mixing changes from my 2019.02/stm32mp157-dk-blog-6 branch with a newer upstream version. Obviously, if you do this, some adaptations may be necessary.
Using the blog-6 branch and all the changes I get the following error:
make[1]: Entering directory ‘/home/yme/Documents/git/buildroot-cloned/buildroot/output/build/uboot-2018.09’
HOSTCC scripts/basic/fixdep
YACC scripts/kconfig/zconf.tab.c
LEX scripts/kconfig/zconf.lex.c
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
***
*** Can’t find default configuration “arch/../configs/stm32mp15_trusted_defconfig”!
***
scripts/kconfig/Makefile:128: recipe for target ‘stm32mp15_trusted_defconfig’ failed
make[2]: *** [stm32mp15_trusted_defconfig] Error 1
Makefile:496: recipe for target ‘stm32mp15_trusted_defconfig’ failed
make[1]: *** [stm32mp15_trusted_defconfig] Error 2
make[1]: Leaving directory ‘/home/yme/Documents/git/buildroot-cloned/buildroot/output/build/uboot-2018.09’
boot/uboot/uboot.mk:469: recipe for target ‘/home/yme/Documents/git/buildroot-cloned/buildroot/output/build/uboot-2018.09/.config’ failed
make: *** [/home/yme/Documents/git/buildroot-cloned/buildroot/output/build/uboot-2018.09/.config] Error 2
Only the tf-a-stm32mp157c-dk2.stm32 is in the images folder now.
Here again, you are not using my 2019.02/stm32mp157-dk-blog-6 branch. Indeed your build log shows that you’re building U-Boot 2018.09 (i.e an upstream Buildroot version), while by 2019.02/stm32mp157-dk-blog-6 branch points to:
BR2_TARGET_UBOOT_CUSTOM_GIT=y
BR2_TARGET_UBOOT_CUSTOM_REPO_URL=”https://github.com/STMicroelectronics/u-boot.git”
BR2_TARGET_UBOOT_CUSTOM_REPO_VERSION=”v2018.11-stm32mp-r2.1″
Yes thanks my mistake. I figured this out immediately after and it did build in the end when I corrected it.
Hello! Thanks for an excellent series on the STM32MP1!
I have some trouble booting Linux following the example above. I am running 2020.05.x of Buildroot with the exact same defconfig as above. I remove partition-type from the genimage.cfg in order to get a protective MBR instead of hybrid. Hybrid did not allow Uboot to start. I write sdcard.img to an SD card because I want to validate the SD card (DFU works fine). The end result is “Starting kernel …” and then nothing observable. I tried with a known working zImage, but I get the same result leading me to believe that perhaps something more is required from Uboot to boot the kernel. Same result with e.g. 2018.11-stm32mp-r4.3 of Uboot. Any ideas?
I understand that I am running a later version of Buildroot, but it would be nice to understand what could be wrong.
Again thanks and best regards.
Below is the stdout from Uboot
U-Boot 2018.11-stm32mp-r2.1 (Sep 02 2020 – 20:41:19 +0200)
CPU: STM32MP157CAC Rev.B
Model: STMicroelectronics STM32MP157C-DK2 Discovery Board
Board: stm32mp1 in trusted mode (st,stm32mp157c-dk2)
Board: MB1272 Var2 Rev.C-01
DRAM: 512 MiB
Clocks:
– MPU : 650 MHz
– MCU : 208.878 MHz
– AXI : 266.500 MHz
– PER : 24 MHz
– DDR : 533 MHz
NAND: 0 MiB
MMC: STM32 SDMMC2: 0, STM32 SDMMC2: 1
In: serial
Out: serial
Err: serial
Net: eth0: ethernet@5800a000
Hit any key to stop autoboot: 0
Boot over mmc0!
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:4…
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
131 bytes read in 0 ms
1: stm32mp157c-dk2-buildroot
Retrieving file: /boot/zImage
4154896 bytes read in 181 ms (21.9 MiB/s)
append: root=/dev/mmcblk0p4 rootwait
Retrieving file: /boot/stm32mp157c-dk2.dtb
49532 bytes read in 3 ms (15.7 MiB/s)
Kernel image @ 0xc2000000 [ 0x000000 – 0x3f6610 ]
## Flattened Device Tree blob at c4000000
Booting using the fdt blob at 0xc4000000
Using Device Tree in place at c4000000, end c400f17b
Starting kernel …
It is difficult to say without reproducing the problem. But this could be an incorrect serial console being used, so you don’t see any messages from the kernel. Or the kernel configuration is incorrect. I cannot really help further, I would need to reproduce the situation + investigate.
Hi,
which kernel are you using?
Currently mainline kernels don’t work when using TFA because some of the clocks are only accessible from the secure world. The ST kernel has patches for this but they haven’t made it into mainline yet.
This manifests itself as a hang after booting kernel but if you enable debug_ll and early printk you can see this:
[ 0.000000] 8<— cut here —
[ 0.000000] Unhandled fault: imprecise external abort (0x1c06) at 0xd3eab612
[ 0.000000] pgd = (ptrval)
[ 0.000000] [d3eab612] *pgd=d3e1141e(bad)
[ 0.000000] Internal error: : 1c06 [#1] SMP ARM
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.77-pknbsp-svn5249-atag-v5.4.77-173-g65b76a04442b-dirty #1807
[ 0.000000] Hardware name: STM32 (Device Tree Support)
[ 0.000000] PC is at _raw_spin_unlock_irqrestore+0xc/0x24
[ 0.000000] LR is at clk_gate_enable+0xc/0x14
[ 0.000000] pc : [] lr : [] psr: a00000d3
[ 0.000000] sp : c1001e28 ip : 00000000 fp : 00000001
[ 0.000000] r10: d0019300 r9 : ffffffff r8 : 00000000
[ 0.000000] r7 : e0805010 r6 : d0018a80 r5 : 00000000 r4 : d00193c0
[ 0.000000] r3 : 00000000 r2 : 00000001 r1 : a00000d3 r0 : c10cde74
[ 0.000000] Flags: NzCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment none
[ 0.000000] Control: 10c5387d Table: c000406a DAC: 00000051
[ 0.000000] Process swapper/0 (pid: 0, stack limit = 0x(ptrval))
[ 0.000000] Stack: (0xc1001e28 to 0xc1002000)
…
[ 0.000000] [] (_raw_spin_unlock_irqrestore) from [] (clk_gate_enable+0xc/0x14)
[ 0.000000] [] (clk_gate_enable) from [] (clk_composite_enable+0x28/0x2c)
[ 0.000000] [] (clk_composite_enable) from [] (clk_core_enable+0x68/0xbc)
[ 0.000000] [] (clk_core_enable) from [] (__clk_register+0x4e0/0x760)
[ 0.000000] [] (__clk_register) from [] (clk_hw_register+0x24/0x40)
[ 0.000000] [] (clk_hw_register) from [] (clk_hw_register_composite+0x19c/0x284)
[ 0.000000] [] (clk_hw_register_composite) from [] (_clk_stm32_register_composite+0x1e8/0x2ac)
[ 0.000000] [] (_clk_stm32_register_composite) from [] (stm32mp1_rcc_of_clk_init_driver+0xd8/0x1d0)
[ 0.000000] [] (stm32mp1_rcc_of_clk_init_driver) from [] (of_clk_init+0x168/0x21c)
[ 0.000000] [] (of_clk_init) from [] (time_init+0x24/0x30)
[ 0.000000] [] (time_init) from [] (start_kernel+0x294/0x468)
[ 0.000000] [] (start_kernel) from [] (0x0)
[ 0.000000] Code: e12fff1e e3a03000 ee073fba e1d020b0 (e2822001)
[ 0.000000] —[ end trace 6e550abd212f869a ]—
[ 0.000000] Kernel panic – not syncing: Attempted to kill the idle task!
Adding some logs shows it’s failing trying to confiugre PLL2_R
Which is logical as (with the ST boot chain)
NOTICE: SP_MIN: Built : 13:13:37, Oct 2 2018
INFO: ARM GICv2 driver initialized
INFO: stm32mp HSI (18): Secure only
INFO: stm32mp HSE (20): Secure only
INFO: stm32mp PLL2 (27): Secure only
INFO: stm32mp PLL2_R (30): Secure only
INFO: SP_MIN: Initializing runtime services
INFO: SP_MIN: Preparing exit to normal world
I’m wondering if it would be possible to write a tool to remplace the STM32CubeProgrammer.
As it’s using DFU (or maybe ST’s DFUSE variant) that are documented and already have open source implementations that should be doable. I hope to try that soon.
A little more info on the “could we replace the STM32 Cube programmer”?
It is possible to load the FBSL into RAM and execute just using the “dfu-util” tool which is available in most Linux distributions.
I built u-boot from upstream (not the ST git that Thomas has been using in his articles) u-boot 2020.10 using the stm32mp15_basic defconfig and DEVICE_TREE=stm32mp157c-dk2
Then, removing the SD card, setting the boot switches for DFU mode the generated u-boot-spl.stm32 can be loaded into RAM and executed with
sudo /usr/bin/dfu-util -a 1 -D u-boot-2020/out/stm32mp15_basic/u-boot-spl.stm32
dfu-util 0.5
(C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc.
(C) 2010-2011 Tormod Volden (DfuSe support)
This program is Free Software and has ABSOLUTELY NO WARRANTY
dfu-util does currently only support DFU version 1.0
Opening DFU USB device… ID 0483:df11
Run-time device DFU version 0110
Found DFU: [0483:df11] devnum=0, cfg=1, intf=0, alt=1, name=”@FSBL /0x01/1*1Me”
Claiming USB DFU Interface…
Setting Alternate Setting #1 …
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 1024
No valid DFU suffix signature
Warning: File has no DFU suffix
bytes_per_hash=2416
Copying data from PC to DFU device
Starting download: [##################################################] finished!
state(7) = dfuMANIFEST, status(0) = No error condition is present
state(2) = dfuIDLE, status(0) = No error condition is present
Done!
On the serial console I see
U-Boot SPL 2020.10-dirty (Dec 14 2020 – 15:46:30 +0100)
Model: STMicroelectronics STM32MP157C-DK2 Discovery Board
RAM: DDR3-DDR3L 16bits 533000Khz
WDT: Not found!
SPL: Unsupported Boot Device!
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
So the SPL is being started.
The error is because the bootrom is requsting “boot from USB” which u-boot SPL does not currently support.
ST’s TFA has the code to handle this case and continue the DFU protocol for the SSBL which would have to be added to u-boot SPL to get a complete solution.
This document describes the process well: https://www.st.com/resource/en/application_note/dm00589815-usb-dfu-usart-protocols-used-in-stm32mp1-series-bootloaders-stmicroelectronics.pdf
Thanks Martin for the additional details. Would it be possible then to use dfu-util instead of the Cube Programmer with the TF-A based boot sequence ?
Hi Thomas,
yes I think I so.
I have now got it booting up to u-boot using just dfu-util instead of the cube programmer.
You have to use the v2.2-stm32mp-r2 tag of the ST TFA which has this commit
commit d6c7f1f23d4ed5bccb1b78134bc462460f347d30
Author: Nicolas Le Bayon
Date: Mon Nov 18 17:10:52 2019 +0100
plat/st: initialize dev_status with correct status
Solve issue when DFU get status is the first command requested:
provided the good state.
Without this patch, GetStatus return 0 = appIdle instead of 2 = dfuIdle,
and that cause issue with dfu-utils.
That, in turn requires using the v2020.01-stm32mp branch of ST’s u-boot
(The newer TFA and older u-boot don’t seem to be compatible, leading to errors like “stm32_smc: Failed to exec in secure mode (err = -3)” once u-boot starts
Then the .tsv file has to wrapped with the ST header:
mkimage -T stm32image -d flash.tsv flash.tsv.stm32
Finally the following script will boot as far as u-boot with dfu-util
#! /bin/sh -e
phase_file=$(mktemp -d)/phase
dfu-util -a 1 -D tf-a-stm32mp157c-dk2.stm32
dfu-util -a 5 -U $phase_file
rm $phase_file
dfu-util -a 0 -D flash.tsv.stm32
dfu-util -a 5 -U $phase_file
rm $phase_file
dfu-util -a 3 -D st-u-boot-2020-1.stm32
dfu-util -a 5 -e
The “upload” (transfer from board to host) of the “phase” file is necessary to advance the state machine but the contents isn’t actually needed (though the first byte contains the expected “phase_id” which could be used instead of the hard coded values above.
Console logs with this
NOTICE: CPU: STM32MP157CAC Rev.B
NOTICE: Model: STMicroelectronics STM32MP157C-DK2 Discovery Board
NOTICE: Board: MB1272 Var2.0 Rev.C-01
INFO: Reset reason (0x14):
INFO: Pad Reset from NRST
INFO: PMIC version = 0x10
INFO: Using USB
INFO: Instance 2
INFO: Boot used partition fsbl1
NOTICE: BL2: v2.2-r2.0(debug):v2.2-stm32mp-r2
NOTICE: BL2: Built : 18:22:11, Jan 4 2021
INFO: Using crypto library ‘stm32_crypto_lib’
INFO: BL2: Doing platform setup
INFO: RAM: DDR3-DDR3L 16bits 533000Khz
INFO: Memory size = 0x20000000 (512 MB)
INFO: BL2 runs SP_MIN setup
INFO: BL2: Loading image id 4
INFO: Loading image id=4 at address 0x2ffeb000
INFO: Image id=4 loaded: 0x2ffeb000 – 0x2ffff000
INFO: BL2: Loading image id 5
INFO: receive request 6
INFO: receive request 6
INFO: receive request 6
INFO: receive request 6
INFO: receive request 6
INFO: GETSTATUS :
INFO: DFU_STATE_IDLE
INFO: UPLOAD :
INFO: Phase ID : 0
INFO: address 0x2ffe46bc
INFO: receive request 6
INFO: receive request 6
INFO: receive request 6
INFO: receive request 6
INFO: Start Download partition 0 to address 0xc0000000 length 0
INFO: USB : DFU : end of download partition : 0
INFO: Loading image id=5 at address 0xc0100000
INFO: receive request 6
INFO: receive request 6
INFO: receive request 6
INFO: receive request 6
INFO: GETSTATUS :
INFO: DFU_STATE_IDLE
INFO: UPLOAD :
INFO: Phase ID : 3
INFO: address 0x2ffe46bc
INFO: receive request 6
INFO: receive request 6
INFO: receive request 6
INFO: receive request 6
INFO: receive request 6
INFO: usb_partition_size: partition size : 0xdcd44
INFO: Start Download partition 3 to address 0xc0100000 length 904516
INFO: USB : DFU : end of download partition : 3
INFO: receive request 6
INFO: receive request 6
INFO: receive request 6
INFO: receive request 6
INFO: GETSTATUS :
INFO: DFU_STATE_IDLE
INFO: Receive Detach
INFO: Image id=5 loaded: 0xc0100000 – 0xc01dcd44
WARNING: Skip signature check (header option)
NOTICE: ROTPK is not deployed on platform. Skipping ROTPK verification.
NOTICE: BL2: Booting BL32
INFO: Entry point address = 0x2ffeb000
INFO: SPSR = 0x1d3
NOTICE: SP_MIN: v2.2-r2.0(debug):v2.2-stm32mp-r2
NOTICE: SP_MIN: Built : 17:24:11, Jan 4 2021
INFO: ARM GICv2 driver initialized
INFO: Set calibration timer to 60 sec
INFO: stm32mp IWDG1 (12): Secure
INFO: SP_MIN: Initializing runtime services
INFO: SP_MIN: Preparing exit to normal world
U-Boot 2020.01-stm32mp-r2-00001-g8288f5f-dirty (Jan 04 2021 – 19:30:22 +0100)
CPU: STM32MP157CAC Rev.B
Model: STMicroelectronics STM32MP157C-DK2 Discovery Board
Board: stm32mp1 in trusted mode (st,stm32mp157c-dk2)
Board: MB1272 Var2.0 Rev.C-01
DRAM: 512 MiB
Clocks:
– MPU : 650 MHz
– MCU : 208.878 MHz
– AXI : 266.500 MHz
– PER : 24 MHz
– DDR : 533 MHz
WDT: Started with servicing (32s timeout)
NAND: 0 MiB
MMC: STM32 SD/MMC: 0, STM32 SD/MMC: 1
In: serial
Out: serial
Err: serial
****************************************************
* WARNING 500mA power supply detected *
* Current too low, use a 3A power supply! *
****************************************************
Net: eth0: ethernet@5800a000
Hit any key to stop autoboot: 0
Boot over usb0!
MMC: no card present
Error: mmc device 0 not found
DFU alt info setting: done
Next step to do DFU in u-boot to actually flash…
Flashing over DFU from u-boot is quite simple.
Just needs a dfu command per file to transfer with an alt setting based on the index.
For example if the .tsv file contains
#Opt Id Name Type IP Offset Binary
– 0x01 fsbl1-boot Binary none 0x0 st-tfa.stm32
– 0x03 ssbl-boot Binary none 0x0 st-u-boot.stm32
P 0x02 fsbl1 Binary mmc0 0x22000 u-boot-spl.stm32
P 0x04 fsbl2 Binary mmc0 0x222000 u-boot-spl.stm32
P 0x05 ssbl Binary mmc0 0x422000 u-boot.img
There a three files to be flashed (those with “P” in the option field)
And they are assigned alt settings starting from 0 in order of increasing ID.
So the dfu-util commands needed are
dfu-util -a 0 -D u-boot-spl.stm32
dfu-util -a 1 -D u-boot-spl.stm32
dfu-util -a 2 -D u-boot.img
Then to reset the board
dfu-util -a 3 -e -R
Note you have to wait a few seconds after uploading u-boot to RAM and running these (to give it time to reenumerate)
So it is quite possible to flash without needing the ST cube programmer 🙂
Hi,
we have downloaded stm32mp157A_dk2 source code from git clone. But we are using stm32mp157a_dk1 board.when we dump sdcard.img to board.it is booting up to kernel. After kernel we didn’t get build root login prompt.
I created stm32mp157A_dk1_def config and did some modifications in stm32mp157A_dk1_def config(i.e,BR2_arm=y
+BR2_cortex_a7=y
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_5_3=y
+BR2_ROOTFS_OVERLAY=”board/stmicroelectronics/stm32mp157a-dk1/overlay/”
+BR2_ROOTFS_POST_IMAGE_SCRIPT=”support/scripts/genimage.sh”
+BR2_ROOTFS_POST_SCRIPT_ARGS=”-c board/stmicroelectronics/stm32mp157a-dk1/genimage.cfg”
+BR2_LINUX_KERNEL=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION=y
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE=”5.3.7″
+BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
+BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE=”board/stmicroelectronics/stm32mp157a-dk1/linux.config”
+BR2_LINUX_KERNEL_DTS_SUPPORT=y
+BR2_LINUX_KERNEL_INTREE_DTS_NAME=”stm32mp157a-dk1″
+BR2_LINUX_KERNEL_INSTALL_TARGET=y
+BR2_TARGET_ROOTFS_EXT2=y
+BR2_TARGET_ROOTFS_EXT2_4=y
+BR2_TARGET_ROOTFS_EXT2_SIZE=”120M”
+BR2_TARGET_ROOTFS_EXT2_MKFS_OPTIONS=”-O ^64bit,^metadata_csum,^dir_index”
+# BR2_TARGET_ROOTFS_TAR is not set
+BR2_TARGET_UBOOT=y
+BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y
+BR2_TARGET_UBOOT_CUSTOM_VERSION=y
+BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE=”2019.10″
+BR2_TARGET_UBOOT_BOARD_DEFCONFIG=”stm32mp15_basic”
+BR2_TARGET_UBOOT_CONFIG_FRAGMENT_FILES=”board/stmicroelectronics/stm32mp157a-dk1/uboot-fragment.config”
+# BR2_TARGET_UBOOT_FORMAT_BIN is not set
+BR2_TARGET_UBOOT_FORMAT_IMG=y
+BR2_TARGET_UBOOT_SPL=y
+BR2_TARGET_UBOOT_SPL_NAME=”spl/u-boot-spl.stm32″
+BR2_TARGET_UBOOT_CUSTOM_MAKEOPTS=”DEVICE_TREE=stm32mp157a-dk1″
+BR2_PACKAGE_HOST_GENIMAGE=y
and we created genimage.cfg,linux.config,overlay/boot/extlinux/extlinux.conf,uboot-fragment.config)still we are unable to get build root login prompt.How can we get user login prompt.
Please help us in this Regards.
Hello. Thanks for your comment. Could you contact us at info@bootlin.com and provide the complete boot log of your STM32MP1 board, so we can have a look? Right now the information provided is not sufficient to give a specific answer or solution.
Hi Thomas,
I am building this from Docker container with WSL2 as backend and using Ubuntu 20.04. But I don’t have the /etc/udev/ directrory to setup STM32CubeProgrammer. Can you please let me know how should I proceed here? Is it safe to create this directory and access USB devices?
Thanks in advance!
Unfortunately, I’m afraid I have no experience at all with WSL2, so I can’t really help here. I suggest you to check the STM32CubeProgrammer documentation, or better use a native Linux installation 🙂
Hi,
We are using stm32mp157a processor in my custom board. I have download stm32mp157a-dk1 discovery kit code.The difference between discovery board and my custom board is Debug Serial port Configuration.
My uboot version is ubootv2018.11.
we are using buildroot.
In Discovery Board The debug uart pins are
PG11–>UART4_TX
PB2–>UART4_RX.
where as in my custom board the pins are different
PE0–> UART8_TX
PE1–>UART8_RX
So I have changed the pin muxing and nodes in dts files. And debug_uart_init() in Uboot source code. Up to Uboot It is working fine. I have done the same configuartion except debug_uart_init() in kernal source code.why because debug_uart_init() function is not there in linux source code. when can i get kernal log in my custom board. Please help me in this regards. You can see my log below.
U-Boot 2018.11-stm32mp-r2.1 (Aug 09 2022 – 18:00:59 +0530)
CPU: STM32MP157AAA Rev.?
Model: STMicroelectronics STM32MP157C-DK2 Discovery Board
Board: stm32mp1 in basic mode (st,stm32mp157c-dk2)
DRAM: 1 GiB
Clocks:
– MPU : 650 MHz
– MCU : 208.878 MHz
– AXI : 266.500 MHz
– PER : 24 MHz
– DDR : 533 MHz
Fastboot key pressed, STM32Programmer key pressed, entering download mode…
board_check_usb_power: Can’t get adc device(-19)
Board_Usb_init end
NAND: 0 MiB
MMC: STM32 SDMMC2: 0, STM32 SDMMC2: 1
In: serial
Out: serial
Err: serial
Net: eth0: ethernet@5800a000
Invalid bus 1 (err=-19)
Slave_Ret :0
waiting for chracter taking from serial port
1
Sigma
Hit any key to stop autoboot: 0
Boot over usb0!
DFU alt info setting: done
Can’t get vdd3v3-supply regulator
failed to found usb phy
### ERROR ### Please RESET the board ###
Hi,
I tried burning my STM32MP1 board with existing “FlashLayout_emmc_stm32mp157a-ev1-trusted.tsv” file but it throws following error –
Error: TSV files are only supported for STM32MP
I’m using onboard eMMC (From Kioxia) and STM32MP157AAD3 chip from ST. I have attached snapshot of log. and I’m extremely in need of support
user@user:~/STM32MPU-Ecosystem-v4.0.0/Starter-Package/stm32mp1-openstlinux-5.15-yocto-kirkstone-mp1-v22.06.15/images/stm32mp1$ STM32_Programmer_CLI -c port=usb1 -w flashlayout_st-image-weston/trusted/FlashLayout_emmc_stm32mp157a-ev1-trusted.tsv
——————————————————————-
STM32CubeProgrammer v2.11.0
——————————————————————-
USB speed : High Speed (480MBit/s)
Manuf. ID : STMicroelectronics
Product ID : DFU in HS Mode @Device ID /0x500, @Revision ID /0x0000
SN : 0019002C3431511733353431
DFU protocol: 1.1
Board : —
Device ID : 0x0500
Device name : STM32MP1
Device type : MPU
Revision ID : —
Device CPU : Cortex-A7
Start Embedded Flashing service
Memory Programming …
Opening and parsing file: tf-a-stm32mp157a-ev1-usb.stm32
File : tf-a-stm32mp157a-ev1-usb.stm32
Size : 220.82 KB
Partition ID : 0x01
Download in Progress:
[==================================================] 100%
File download complete
Time elapsed during download operation: 00:00:01.150
RUNNING Program …
PartID: :0x01
Error: Start operation failed at partition 0x01
Error: TSV flashing service failed
user@user:~/STM32MPU-Ecosystem-v4.0.0/Starter-Package/stm32mp1-openstlinux-5.15-yocto-kirkstone-mp1-v22.06.15/images/stm32mp1$ STM32_Programmer_CLI -c port=usb1 -w flashlayout_st-image-weston/trusted/FlashLayout_emmc_stm32mp157a-ev1-trusted.tsv
——————————————————————-
STM32CubeProgrammer v2.11.0
——————————————————————-
USB speed : High Speed (480MBit/s)
Manuf. ID :
Product ID :
SN :
DFU protocol: 1.1
Board : —
IAP
Error: TSV files are only supported for STM32MP
Can we use STM32MP157A-EV1 image for flashing our custom STM32MP1 based board ? Or do i need to build a custom image.
Please Help me out for loading the linux on my custom SOM board.
Thanks in Advance!!
Could you please have a look at https://github.com/bootlin/buildroot-external-st which provides a much more up-to-date solution, including the appropriate TSV files?
Great article comment:
I guess, that it is not best solution to solder down already programmed NAND flash. Despite fact, that in most cases NOR memory should be used, already programmed flash memory transistor content is strongly “weakened” during soldering heat treatment. The same is for IC’s configuration for example pre-programmed non-volatile content of programmable voltage regulator.
It is possible, but could enhance device failure ratio.