Missing bootfs Partition in Yocto TSV Image Layout

[Piratkin]

Hi, I am trying to create an image for writing to NAND memory.

The problem is that when generating a TSV file using Yocto, I get a layout without a bootfs partition.
In this case, it is unclear how to load the Linux kernel and the DeviceTree.
Can someone explain to me why the bootfs is excluded from the image layout file (TSV) and how to handle this situation?

I can try to add this file to the image, but I am confused because this partition is missing even in the examples.
Maybe there's a reason for this that I'm not aware of.

I would greatly appreciate any help.

[Erwan SZYMANSKI]

Hello @Piratkin ,
Can you precise us on which version of OpenSTLinux you are working on ? And also can you share us the TSV file that is generated on your side ? 

Kind regards,
Erwan.

[Piratkin]

branch: mickledore

layer: meta-openembedded
commit: 75cf318cef3b4ee81fad2782cf063ecd69ba8842

layer: meta-st-stm32mp
commit 931b3f5be2c00f55d114c8f9122082a9d229b776

layer: poky
commit 2a553c39a03d88b7e24ea4d275c52d032c91159a

Poky had to be downgraded a bit because there were some problems.

I'm building an image on Ubuntu Linux:

$ uname -a
Linux 525396228a30 6.8.8-arch1-1 #1 SMP PREEMPT_DYNAMIC Sun, 28 Apr 2024 15:59:47 +0000 x86_64 x86_64 x86_64 GNU/Linux

 
TSV file:

#Opt    Id      Name    Type    IP      Offset  Binary
-       0x01    fsbl-boot       Binary  none    0x0     arm-trusted-firmware/tf-a-stm32mp135d-pcmd-usb.stm32
-       0x03    fip-boot        FIP     none    0x0     fip/fip-stm32mp135d-pcmd-optee.bin
P       0x04    fsbl1   Binary  nand0   0x00000000      arm-trusted-firmware/tf-a-stm32mp135d-pcmd-nand.stm32
P       0x05    fsbl2   Binary  nand0   0x00080000      arm-trusted-firmware/tf-a-stm32mp135d-pcmd-nand.stm32
P       0x06    metadata1       FWU_MDATA       nand0   0x00100000      arm-trusted-firmware/metadata.bin
P       0x07    metadata2       FWU_MDATA       nand0   0x00180000      arm-trusted-firmware/metadata.bin
P       0x08    fip-a1  FIP     nand0   0x00200000      fip/fip-stm32mp135d-pcmd-optee.bin
P       0x09    fip-a2  FIP     nand0   0x00600000      fip/fip-stm32mp135d-pcmd-optee.bin
PED     0x0A    fip-b1  FIP     nand0   0x00A00000      none
PED     0x0B    fip-b2  FIP     nand0   0x00E00000      none
P       0x10    ubifs   System  nand0   0x01200000      test-image-stm32mp135d_nand_4_256_multivolume.ubi

Probably everything I need should be in the /boot directory, but unfortunately it is empty.

ST_OSTL_COMPATIBILITY_VERSION_stm-st-stm32mp = "5.0"

[Erwan SZYMANSKI]

@Piratkin ,
I do not see anything strange in your TSV. When you compare with the reference TSV for Nand Flash memory we give on the Wiki, it looks coherent : https://wiki.st.com/stm32mpu/wiki/STM32CubeProgrammer_flashlayout#NAND_flash_memory

Kind regards,
Erwan.

[Piratkin]

I understand, but the issue is that the Linux Kernel and DeviceTree are missing in the final image for booting the system because the /boot directory is empty.

Perhaps I accidentally excluded a Bitbake recipe.

How does the copying of boot files to UBIFS actually happen?

Of course, it's possible to do all of this manually, but it shouldn't be that way, in my opinion.

[Erwan SZYMANSKI]

@Piratkin ,
OK sorry for misunderstanding.

Can you see all these files (Kernel Image / stm32xxxxx.dtb) in Yocto <build>/tmp-glibc/deploy/images/stm32mpX/ subfolders ? Or even in this subfolders, there is no trace of the files you are looking for ? (or maybe you can show me the folder tree directly)

During Yocto compilation, you have no error reported in any recipe task ? 

Kind regards,
Erwan.

[Piratkin]

There are no errors.
Here is the directory structure:

[stm32mp135d]$ ls -R1 .
.:
arm-trusted-firmware
fip
flashlayout_test-image

test-image-stm32mp135d-20240522072918_nand_4_256_multivolume.rootfs.ubi
test-image-stm32mp135d-20240522072918_nand_4_256.rootfs.ubi
test-image-stm32mp135d-20240522072918_nand_4_256.rootfs.ubifs
test-image-stm32mp135d-20240522072918.rootfs.ext4
test-image-stm32mp135d-20240522072918.rootfs.manifest
test-image-stm32mp135d-20240522072918.rootfs.tar.xz
test-image-stm32mp135d-20240522072918.testdata.json
test-image-stm32mp135d.ext4
test-image-stm32mp135d.manifest
test-image-stm32mp135d_nand_4_256_multivolume.ubi
test-image-stm32mp135d_nand_4_256.ubi
test-image-stm32mp135d_nand_4_256.ubifs
test-image-stm32mp135d.tar.xz
test-image-stm32mp135d.testdata.json
kernel
optee
scripts
st-image-bootfs-test-stm32mp135d-20240522072918.bootfs.ext4
st-image-bootfs-test-stm32mp135d-20240522072918.bootfs.manifest
st-image-bootfs-test-stm32mp135d-20240522072918.bootfs.tar.xz
st-image-bootfs-test-stm32mp135d-20240522072918_nand_4_256.bootfs.ubi
st-image-bootfs-test-stm32mp135d-20240522072918_nand_4_256.bootfs.ubifs
st-image-bootfs-test-stm32mp135d-20240522072918.testdata.json
st-image-bootfs-test-stm32mp135d.ext4
st-image-bootfs-test-stm32mp135d.manifest
st-image-bootfs-test-stm32mp135d_nand_4_256.ubi
st-image-bootfs-test-stm32mp135d_nand_4_256.ubifs
st-image-bootfs-test-stm32mp135d.tar.xz
st-image-bootfs-test-stm32mp135d.testdata.json
st-image-userfs-test-stm32mp135d-20240522072918_nand_4_256.userfs.ubi
st-image-userfs-test-stm32mp135d-20240522072918_nand_4_256.userfs.ubifs
st-image-userfs-test-stm32mp135d-20240522072918.testdata.json
st-image-userfs-test-stm32mp135d-20240522072918.userfs.ext4
st-image-userfs-test-stm32mp135d-20240522072918.userfs.manifest
st-image-userfs-test-stm32mp135d-20240522072918.userfs.tar.xz
st-image-userfs-test-stm32mp135d.ext4
st-image-userfs-test-stm32mp135d.manifest
st-image-userfs-test-stm32mp135d_nand_4_256.ubi
st-image-userfs-test-stm32mp135d_nand_4_256.ubifs
st-image-userfs-test-stm32mp135d.tar.xz
st-image-userfs-test-stm32mp135d.testdata.json
st-image-vendorfs-test-stm32mp135d-20240522072918_nand_4_256.vendorfs.ubi
st-image-vendorfs-test-stm32mp135d-20240522072918_nand_4_256.vendorfs.ubifs
st-image-vendorfs-test-stm32mp135d-20240522072918.testdata.json
st-image-vendorfs-test-stm32mp135d-20240522072918.vendorfs.ext4
st-image-vendorfs-test-stm32mp135d-20240522072918.vendorfs.manifest
st-image-vendorfs-test-stm32mp135d-20240522072918.vendorfs.tar.xz
st-image-vendorfs-test-stm32mp135d.ext4
st-image-vendorfs-test-stm32mp135d.manifest
st-image-vendorfs-test-stm32mp135d_nand_4_256.ubi
st-image-vendorfs-test-stm32mp135d_nand_4_256.ubifs
st-image-vendorfs-test-stm32mp135d.tar.xz
st-image-vendorfs-test-stm32mp135d.testdata.json
ubinize_nand_4_256-test-image-stm32mp135d-20240522072918.cfg
ubinize_nand_4_256-test-image-stm32mp135d.cfg
ubinize_nand_4_256_multivolume-test-image-stm32mp135d-20240522072918.cfg
ubinize_nand_4_256_multivolume-test-image-stm32mp135d.cfg
ubinize_nand_4_256-st-image-bootfs-test-stm32mp135d-20240522072918.cfg
ubinize_nand_4_256-st-image-bootfs-test-stm32mp135d.cfg
ubinize_nand_4_256-st-image-userfs-test-stm32mp135d-20240522072918.cfg
ubinize_nand_4_256-st-image-userfs-test-stm32mp135d.cfg
ubinize_nand_4_256-st-image-vendorfs-test-stm32mp135d-20240522072918.cfg
ubinize_nand_4_256-st-image-vendorfs-test-stm32mp135d.cfg
u-boot

./arm-trusted-firmware:
debug
fwconfig
metadata.bin
tf-a-stm32mp135d-test-nand.stm32
tf-a-stm32mp135d-test-sdcard.stm32
tf-a-stm32mp135d-test-uart.stm32
tf-a-stm32mp135d-test-usb.stm32

./arm-trusted-firmware/debug:
debug-tf-a-stm32mp135d-test-nand.stm32
debug-tf-a-stm32mp135d-test-sdcard.stm32
debug-tf-a-stm32mp135d-test-uart.stm32
debug-tf-a-stm32mp135d-test-usb.stm32
tf-a-bl2-stm32mp13-nand.elf
tf-a-bl2-stm32mp13-sdcard.elf
tf-a-bl2-stm32mp13-uart.elf
tf-a-bl2-stm32mp13-usb.elf

./arm-trusted-firmware/fwconfig:
stm32mp135d-test-fw-config-optee.dtb

./fip:
fip-stm32mp135d-test-optee.bin

./flashlayout_test-image:
deleteall
extensible
optee

./flashlayout_test-image/deleteall:
FlashLayout_board_stm32mp135d-test-deleteall.tsv

./flashlayout_test-image/extensible:
FlashLayout_sdcard_stm32mp135d-test-extensible.tsv

./flashlayout_test-image/optee:
FlashLayout_nand-2-64_stm32mp135d-test-optee.tsv
FlashLayout_nand-4-256_stm32mp135d-test-optee.tsv
FlashLayout_sdcard_stm32mp135d-test-optee.tsv

./kernel:
config-6.1.28
Image
Image--6.1.28-stm32mp-r1-r0-stm32mp135d-20240522072918.bin
Image-stm32mp135d.bin
modules--6.1.28-stm32mp-r1-r0-stm32mp135d-20240522072918.tgz
modules-stm32mp135d.tgz
modules-stripped--6.1.28-stm32mp-r1-r0-stm32mp135d-20240522072918.tgz
modules-stripped-stm32mp135d.tgz
stm32mp135d-test--6.1.28-stm32mp-r1-r0-stm32mp135d-20240522072918.dtb
stm32mp135d-test.dtb
stm32mp135d-test-stm32mp135d.dtb
uImage
uImage--6.1.28-stm32mp-r1-r0-stm32mp135d-20240522072918.bin
uImage-stm32mp135d.bin
vmlinux
vmlinux--6.1.28-stm32mp-r1-r0-stm32mp135d-20240522072918.bin
vmlinux-stm32mp135d.bin
zImage
zImage--6.1.28-stm32mp-r1-r0-stm32mp135d-20240522072918.bin
zImage-stm32mp135d.bin

./optee:
debug
tee-header_v2-stm32mp135d-test.bin
tee-pageable_v2-stm32mp135d-test.bin
tee-pager_v2-stm32mp135d-test.bin

./optee/debug:
tee-stm32mp135d-test.elf

./scripts:
create_sdcard_from_flashlayout.sh

./u-boot:
debug
u-boot-nodtb-stm32mp13.bin
u-boot-stm32mp135d-test.dtb

./u-boot/debug:
u-boot-stm32mp13.elf

[Erwan SZYMANSKI]

@Piratkin ,
OK, it looks all good from this point of view..

What happens when you try to generate the SD card version of your image ? Is /boot folder also empty ?  

(To do it you can do : 
PC $> cd script
PC $> ./create_sdcard_from_flashlayout.sh ../flashlayout_test-image/optee/xxxx.tsv
)

Then can you check on the SD card generated if boot partition is also empty. I need to understand if your issue is specific to NAND case.

Kind regards,
Erwan.

[Piratkin]

I can create an image based on the tsv file, I can write it to the NAND memory area.

There is no problem with that.

I can boot from it up to U-Boot, but then I can't go further because the Linux Kernel and DeviceTree aren't in the UBIFS.

I can add them manually and boot from there, but I don't understand why they're not included in the image itself.

It's really inconvenient to manually transfer the boot files every time.

This takes too much time.

Sure, I could write a script to save these boot files in the /boot directory, but that seems like a weird solution.

I just want to understand what's happening.

Is this a bug or is it meant to be?

Or am I missing something?

I just don't want to implement a hack if there's a proper way to solve this problem.

[Erwan SZYMANSKI]

@Piratkin ,
I fully understand your point, and I understand the consequences. The test I ask you with the script that is already present in your subfolders, is just to see on an SD card if the /boot folder is well created or not. It will help me to understand if this is a NAND specific issue in Yocto or if it is common to all the flash boot memory method. 

With the 2 commands I give you above, it will just create a raw SD card image, that you can flash on any SD card (we will not boot anything with it). But once installed, I would like to check if you have something inside /boot folder with this method. In theory, you should see the kernel, device tree and so on, but if this is the same issue as for your NAND, we will see nothing inside.

Kind regards,
Erwan.