Boot UBIFS from dataflash (nor0)

[ATringali]

Hi Everybody,

I would like to completely boot kernel 5.10-dunfell (last year) from a 64MB dataflash (nor0). No mmc0 or nand0.

Compiled the correct DTS with TF-A, U-Boot and kernel, I would like to use the following TSV for STM32CubeProgrammer:

#Opt Id Name Type IP Offset Binary
- 0x01 fsbl1-boot Binary none 0x0 tf-a-stm32mp151a-***-mx-usb.stm32
- 0x03 fip-boot Binary none 0x0 fip-stm32mp151a-***-mx-trusted.bin
P 0x04 fsbl1 Binary nor0 0x00000000 tf-a-stm32mp151a-***-mx-nor.stm32
P 0x05 fsbl2 Binary nor0 0x00040000 tf-a-stm32mp151a-***-mx-nor.stm32
P 0x06 fip Binary nor0 0x00080000 fip-stm32mp151a-***-mx-trusted.bin
PDE 0x07 u-boot-env Binary nor0 0x00480000 none
P 0x10 UBI Binary nor0 0x00500000 rootfs.bin

where *** is my project code (obfuscated).

Once started, U-Boot fails to proceed to load rootfs.bin, which contains the kernel, modules and filesystem as a UBI partition. This was produced by Buildroot and it is valid; I checked loop-mounting it with mtdram. The type for UBI is Binary since, as I read somewhere, for big NORs System times out (and it does).

It is read by U-Boot:

STM32MP> mtdparts
SF: Detected mx66l51235l with page size 256 Bytes, erase size 64 KiB, total 64 MiB
 
device nor0 <nor0>, # parts = 5
 #: name		size		offset		mask_flags
 0: fsbl1 0x00040000	0x00000000	0
 1: fsbl2 0x00040000	0x00040000	0
 2: fip 0x00400000	0x00080000	0
 3: u-boot-env 0x00080000	0x00480000	0
 4: UBI 0x03b00000	0x00500000	0
 
active partition: nor0,0 - (fsbl1) 0x00040000 @ 0x00000000
 
defaults:
mtdids : nor0=nor0
mtdparts: mtdparts=nor0:256k(fsbl1),256k(fsbl2),4m(fip),512k(u-boot-env),-(UBI)
STM32MP> ubi part UBI
<...hangs for a lot of time while it expands the image...>
STM32MP> ubi info
UBI: MTD device name: "UBI"
UBI: MTD device size: 59 MiB
UBI: physical eraseblock size: 65536 bytes (64 KiB)
UBI: logical eraseblock size: 65408 bytes
UBI: number of good PEBs: 944
UBI: number of bad PEBs: 0
UBI: smallest flash I/O unit: 1
UBI: VID header offset: 64 (aligned 64)
UBI: data offset: 128
UBI: max. allowed volumes: 128
UBI: wear-leveling threshold: 4096
UBI: number of internal volumes: 1
UBI: number of user volumes: 1
UBI: available PEBs: 0
UBI: total number of reserved PEBs: 944
UBI: number of PEBs reserved for bad PEB handling: 0
UBI: max/mean erase counter: 1/0
STM32MP> ubifsmount ubi:rootfs
STM32MP> ubifsls /
<DIR>	 5024 Mon Nov 21 13:18:30 2022 bin
<DIR>	 608 Wed Oct 05 12:24:08 2022 dev
<DIR>	 1432 Mon Nov 21 13:18:30 2022 etc
<DIR>	 1472 Mon Nov 21 13:18:30 2022 lib
<DIR>	 160 Wed Oct 05 12:24:08 2022 mnt
<DIR>	 232 Wed Oct 19 13:01:42 2022 opt
<DIR>	 160 Mon Nov 21 13:18:31 2022 run
<DIR>	 160 Wed Oct 05 12:24:08 2022 tmp
<DIR>	 160 Wed Oct 05 12:24:08 2022 sys
<DIR>	 672 Mon Nov 21 13:18:31 2022 var
<DIR>	 480 Mon Nov 21 13:18:31 2022 usr
<DIR>	 504 Wed Oct 05 12:24:08 2022 boot
<DIR>	 160 Wed Oct 05 12:24:08 2022 proc
<DIR>	 3736 Wed Oct 05 16:02:52 2022 sbin
<DIR>	 160 Wed Oct 05 12:24:08 2022 root
<LNK>	 11 Wed Oct 05 16:02:52 2022 linuxrc
<LNK>	 3 Wed Oct 05 16:01:28 2022 lib32
<DIR>	 160 Wed Oct 05 12:24:08 2022 media

A suspect issue is that to insert UBI in mtdparts, since saveenv is not working, I had to modify the U-Boot source code. Otherwise it would default to nor_user in board/st/common/stm32mp_mtdparts.c.

Instead of proceeding with UBI it tries to load kernel from SD-Card. In the U-Boot .config file I put the following setup:

CONFIG_MTDPARTS_NOR0_BOOT="256k(fsbl1),256k(fsbl2),4m(fip),512k(u-boot-env),-(UBI)"

the whole U-Boot configuration file is attached. The configuration above should match the TSV.

In no example I have seen in the ST Wiki there is support for completely booting Linux from dataflash.

Is a complete boot from nor0 supported? 

Thanks for your help,

Antonio

[ATringali]

Hello again,

I managed to solve the problem above by myself. So I am writing here the short "how I did it" in case it may be useful for somebody else. Maybe there is a smarter way, but I did not find it and it should be transformed into some patches for U-Boot. It is all too easy to produce a U-Boot which simply hangs.

The solution I found is to compile two U-Boots: one to use via USB loading that is responsible for flashing and the other one which automatically starts Linux from the UBI partition. The latter is obtained modifying:

1. include/configs/stm32mp1.h: bootcmd must be "run ubifs_boot"
2. include/config_distro_bootcmd.h: bootubivol set to "rootfs" instead of boot. The former is the UBI partition name generated by BuildRoot, which contains the kernel, modules and root filesystem (I do not want a separated boot partition).
3. board/st/common/stm32mp_mtdparts.c: change the append for "-(nor_user)" with "-(UBI)", which is the U-Boot partition name you can check with command "ubi part UBI", or some other name you may like; then modify bootubivol as a consequence.

When the dataflash is in pristine condition all partitions can be flashed straight away. The dataflash I used is 64MB in size, so about 59MB are available for the UBI partition.

If the UBI partition must be reflashed you must erase it (PED in the first column), then reprogrammed, because UBI expands to all blocks and simply reprogramming with Binary will not work. When erasing it takes forever (about 2 minutes). STM32CubeProgrammer times out in 30 seconds and spits error message boxes, but U-Boot proceedes on its own way. This is a part which could be better on both sides, but no time to contribute.

On success U-Boot will show:

...
Erasing UBI on nor0: Erasing 0x00500000 ... 0x03ffffff (944 eraseblock(s))
done
Phase=END
DFU alt info setting: using id 'nor0,0'
using id 'nor0,1'
using id 'nor0,2'
using id 'nor0,3'
using id 'nor0,4'
done

At this point the UBI partition may be reprogrammed with P in the first column of the TSV.

On first boot the UBI partition is automatically expanded to fit the whole remaining size. In my hardware it takes about 110s, then Linux is started. For next reboots this does not happen, unless you reflash.

The solution is temporary and it should be streamlined. The environment is not saved in NOR yet, but it does not roadblock at the moment.

Antonio

[Kevin HUBER]

Hello @ATringali​ ,

The problem was being handled internally in a ticket #139482 and we were waiting to see your "env print" to help you more, but good to know that you made it works!

For me, your solution is the good one, you only modified in the source code, what was necessary to update correctly the U-Boot environment and the MTD configuration.

Thanks for the detailed explanation that will surely help other people.

On my side, I will look at why the STM32CubeProgrammer times out and if it is possible to modify this timeout value.

Best Regards,

Kevin

[ATringali]

Hello @Kevin HUBER​ 

I think that in U-Boot the erase cycle should be developed to be similar to the flash phase, so STM32CubeProgrammer can be attached at the output (the '#' ticks or whatever).

Probably the programmer fails because there is no output during flash erase. This should be negligible for NAND, but NOR delete for 64MB is slower and 30s for the programmer is not enough.

Thank you,

Antonio

[PatrickD]

Hi,

For information, the STM32CubeProgrammer timeout can be increased with "-tm" option.

https://www.st.com/resource/en/user_manual/dm00403500-stm32cubeprogrammer-software-description-stmicroelectronics.pdf

5.1.4 Flashing service (page 129)

Note: While programming the Flashlayout.tsv file, U-boot can spend a long time to start correctly,

for this reason configure the timeout value by using the timeout command (-tm <timeout>).

Regards

Patrick

[ATringali]

Hello @Community member​ 

my bad, of course. My answer was focused about changing U-Boot, not STM32CubeProgrammer.

Sorry I wasn't clear.

Have a nice day,

Antonio