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 · Accepted solution]

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