cancel
Showing results for 
Search instead for 
Did you mean: 

Missing bootfs Partition in Yocto TSV Image Layout

Piratkin
Associate II

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.

1 ACCEPTED SOLUTION

Accepted Solutions

Hello @Piratkin ,
I just take back the files that are generated on OpenSTLinux v5, thanks to yocto, and just to compare with what you can see on your side : 

The st-image-weston-openstlinux-weston-stm32mp1_nand_4_256_multivolume.ubi generated and present in the TSV file is the analog of your test-image-stm32mp135d_nand_4_256_multivolume.ubi.

When I check the content of this file :

 

PC $> ubireader_extract_images ./st-image-weston-openstlinux-weston-stm32mp1_nand_4_256_multivolume.ubi
PC $> cd ubifs-root/
PC $> cd st-image-weston-openstlinux-weston-stm32mp1_nand_4_256_multivolume.ubi/
PC $> ubireader_extract_files img-697060950_vol-boot.ubifs
PC $> cd ubifs-root/
PC $> ls

Output :

boot.scr.uimg                   stm32mp135f-dk.dtb               stm32mp157c-ev1.dtb              stm32mp157f-dk2-m4-examples.dtb
mmc0_extlinux                   stm32mp157a-dk1.dtb              stm32mp157c-ev1-m4-examples.dtb  stm32mp157f-ed1.dtb
mmc1_extlinux                   stm32mp157a-ev1.dtb              stm32mp157d-dk1-a7-examples.dtb  stm32mp157f-ev1-a7-examples.dtb
nand0_extlinux                  stm32mp157c-dk2-a7-examples.dtb  stm32mp157d-dk1.dtb              stm32mp157f-ev1.dtb
splash_landscape.bmp            stm32mp157c-dk2.dtb              stm32mp157d-dk1-m4-examples.dtb  stm32mp157f-ev1-m4-examples.dtb
splash_portrait.bmp             stm32mp157c-dk2-m4-examples.dtb  stm32mp157d-ev1.dtb              uImage
st-image-resize-initrd          stm32mp157c-ed1.dtb              stm32mp157f-dk2-a7-examples.dtb
stm32mp135f-dk-a7-examples.dtb  stm32mp157c-ev1-a7-examples.dtb  stm32mp157f-dk2.dtb

 

So it seems that all the information are well placed. I will check which part of Yocto do it so you can clearly compare with the normal situation.

Kind regards,
Erwan.

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.

View solution in original post

17 REPLIES 17
Erwan SZYMANSKI
ST Employee

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.

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.

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"

 

@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.

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.

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.

@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.

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.

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

 

@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.

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.

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.

@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.

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.