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
View more

 

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