Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
- STMicroelectronics Community
- STM32 MPUs
- STM32 MPUs Embedded software
- STM32CubeProgrammer Fails to Program NAND on QSPI ...
Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
STM32CubeProgrammer Fails to Program NAND on QSPI due to unexpected MTD Size
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2020-12-21 01:04 PM
Hello! I am trying to get CubeProgrammer to flash a NAND on a custom board.
UBOOT detects the NAND chip and mtdparts lists the following:
STM32MP> sf probe
STM32MP> mtdparts
device spi-nand0 <spi-nand0>, # parts = 4
#: name size offset mask_flags
0: fsbl 0x00200000 0x00000000 0
1: ssbl1 0x00200000 0x00200000 0
2: ssbl2 0x00200000 0x00400000 0
3: UBI 0x1fa00000 0x00600000 0
active partition: spi-nand0,0 - (fsbl) 0x00200000 @ 0x00000000
defaults:
mtdids : spi-nand0=spi-nand0
mtdparts: mtdparts=spi-nand0:2m(fsbl),2m(ssbl1),2m(ssbl2),-(UBI)It looks as though the FSBL partition size is 0x00200000 and it located at 0x0; however, when I attempt to use cube programmer with this TSV:
#Opt Id Name Type IP Offset Binary
- 0x01 fsbl1-boot Binary none 0x0 arm-trusted-firmware/tf-a-stm32mp157c-viper-serialboot.stm32
- 0x03 ssbl-boot Binary none 0x0 bootloader/u-boot-stm32mp157c-viper-trusted.stm32
P 0x04 fsbl1 Binary spi-nand0 0x00000000 arm-trusted-firmware/tf-a-stm32mp157c-viper-trusted.stm32
P 0x05 fsbl2 Binary spi-nand0 0x00040000 arm-trusted-firmware/tf-a-stm32mp157c-viper-trusted.stm32
P 0x06 ssbl Binary spi-nand0 0x00080000 bootloader/u-boot-stm32mp157c-viper-trusted.stm32I get the following output. Note i have enabled some debug messages while I was trying to figure out what was going on so there maybe extra output than you would expect to see normally.
U-Boot 2021.01-rc3 (Dec 21 2020 - 20:40:01 +0000)
CPU: STM32MP157CAD Rev.B
Model: Toxic Performance Viper MK1
Board: stm32mp1 in trusted mode (toxicperformance;stm32mp157-viper-mk1)
stm32_smc: Failed to exec svc=82001003 op=1 in secure mode (err = -3)
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
In: serial
Out: serial
Err: serial
invalid MAC address in OTP 00:00:00:00:00:00
stm32_smc: Failed to exec svc=82001003 op=1 in secure mode (err = -3)
Net: No ethernet found.
Hit any key to stop autoboot: 0
Boot over usb0!
flash layout =
- 0x01 fsbl1-boot Binary none 0x0
- 0x03 ssbl-boot Binary none 0x0
P 0x04 fsbl1 Binary spi-nand0 0x00000000
P 0x05 fsbl2 Binary spi-nand0 0x00040000
P 0x06 ssbl Binary spi-nand0 0x00080000
spi-nand0
MTD device spi-nand0: size=536870912 erasesize=262144
available address = 0x0..0x20000000
erase size = 0x40000
full_update = 1
id : Opt Phase Name target.n dev.n addr size part_off part_size
01 : 1 04 fsbl1 00.1 04.00 00000000 00040000 00000000 00200000
Error: fsbl1 (0x4): Bad size for partition 1 (fsbl) at 0x0 = 0x40000 <> 0x200000 expected
DFU alt info setting: dfu_alt_add(ram, NULL,@FlashLayout/0x00/1*256Ke) result 0
dfu_alt_add(virt,241,@virtual/0xf1/1*512Be) result 0
dfu_alt_add(virt,242,@OTP/0xf2/1*512Be) result 0
dfu_alt_add(virt,244,@PMIC/0xf4/1*8Be) result 0
doneLine 39 has the error message that the size was incorrect. Been fighting this for a couple days now and really would appreciate a hint here!
The end goal is to load this flash with the entire image and boot linux from it but right now I am just trying to get the bootloaders to work.
One final note, I am using the 2021.01 version of u-boot because the 2020 version of u-boot does not have support for the Toshiba NAND part and the 2021 version does.
here is the output of MTD list to show the detected SPI NAND part
STM32MP> mtd list
List of MTD devices:
* spi-nand0
- device: tc58cyg2s0hraig@0
- parent: spi@58003000
- driver: spi_nand
- type: NAND flash
- block size: 0x40000 bytes
- min I/O: 0x1000 bytes
- OOB size: 256 bytes
- OOB available: 126 bytes
- 0x000000000000-0x000020000000 : "spi-nand0"
- 0x000000000000-0x000000200000 : "fsbl"
- 0x000000200000-0x000000400000 : "ssbl1"
- 0x000000400000-0x000000600000 : "ssbl2"
- 0x000000600000-0x000020000000 : "UBI"Thanks!
Solved! Go to Solution.
Labels:
- Labels:
-
OpenSTLinux
-
STM32MP15 Lines
1 ACCEPTED SOLUTION
Accepted Solutions
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2021-01-18 06:58 AM
I figured out the SMC error. There was a mistake in the BSEC node in the TF-A device tree. The error is gone now.
You can close this question. I think I have a path forward on the QSPI NAND issue and if I run into issues I will ask specific questions at that point in time.
Thanks!!
3 REPLIES 3
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2021-01-11 01:26 AM
Hi @ADeck ,
Sorry to see this post so late.
Are you still facing issues ? Can you update your status ?
I read "I am using the 2021.01 version of u-boot"
This is a version ST does not yet support ...
Can you elaborate further about Toshiba NAND support ?
I also read message like "stm32_smc: Failed to exec svc=82001003 op=1 in secure mode (err = -3) "
Which highlight something is wrong already on TF-A side.
Olivier
Olivier GALLIEN
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2021-01-18 06:30 AM
No worries. We are just getting back from a holiday break anyway!
The NAND chip we are using is a tc58cyg2s0hraig. The driver for this chip is not present in the 2020 version of u-boot but the 2021 version of u-boot on the ST GitHub has it.
https://github.com/STMicroelectronics/u-boot/tree/v2021.01
Here is the specific driver I am talking about:
https://github.com/STMicroelectronics/u-boot/blob/v2021.01/drivers/mtd/nand/spi/toshiba.c
We did make some progress and got our custom hardware to boot off an SD card to Linux.
I did notice the SMC error and was just starting to dig into it.
It looks like SVC 82001003 is SMC_BSEC and OP 1 is STM32_SMC_READ_SHADOW. The error -3 seems to be STM32_SMC_INVALID_PARAMS but I have no idea what the error is point me to. Do you have any pointers here?
I would guess something in the TF-A Device tree, specifically with the EZPC node?
Our design is very similar to the DK-2 except
- We are using the "stm32mp15xd" package
- PMIC is on I2C6
- SD Card is on SDMMC2
My plan to solve the original issue I asked about was to boot Linux from SD card and then use the Linux flash utilities to flash the QSPI NAND chip and see if we can boot from QSPI NAND.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2021-01-18 06:58 AM
I figured out the SMC error. There was a mistake in the BSEC node in the TF-A device tree. The error is gone now.
You can close this question. I think I have a path forward on the QSPI NAND issue and if I run into issues I will ask specific questions at that point in time.
Thanks!!
Related Content
- STM32CubeProgrammer v2.16.0 released in STM32CubeProgrammer (MPUs)
- Can't flash my eMMC on STM32MP157 in STM32 MPUs Boards and hardware tools
- STM32MP153C SSP workflow in STM32 MPUs products
- STM32MP135F-DK SD and SNOR external loader for Baremetal in STM32 MPUs products
- STM32CubeProgrammer on STM32MP153CAB3 in STM32CubeProgrammer (MPUs)