i.MX8MM QSPI booting and partition

[vignesh-baskaran]

Hi,

We having Custom board based on iMX8MM-EVk,

We replaced Qspi memory chip mt25qu02g. No issues in detecting in u-boot and linux.

We were trying to do porting Images and booting from QSPI, Please refer below images.

[Dhruvit]

Hi @vignesh-baskaran,

I hope you are doing well.

Errors in the attached image suggest that the device tree is not loaded correctly. Please make sure that you have used the correct offset and size.

Instead of using dd , one can flash Image and fdt using the sf write command in u-boot.

Please provide me with an output of the printenv command.

Please share the output of  the below-mentioned commands after loading device tree (using sf read )

=>  fdt addr ${fdt_addr_r} 

=>  fdt print 

Thanks & Regards,
Dhruvit Vasavada

[vignesh-baskaran]

Hi @Dhruvit,

1) Please refer the attachment for printenv .

2)

u-boot=>  fdt addr ${fdt_addr_r} 
libfdt fdt_check_header(): FDT_ERR_BADMAGIC

u-boot=> fdt print               
No FDT memory address configured. Please configure
the FDT address via "fdt addr <address>" command.
Aborting!

3)

Instead of using dd , one can flash Image and fdt using the sf write command in u-boot.

You suggested Sf write for writing to qspi,

Let assume i have images from SD card and want to copy to  QSPi, How can i do that?

Please let us know how to do it. it will be helpful. 

Thanks

[Dhruvit · Accepted solution]

Hi @vignesh-baskaran,

I hope you are doing well.

One can follow below-mentioned steps to load images in QSPI Flash in u-boot.

1. Load Image and dtb in RAM using fatload command.

#fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}

#fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr_r} ${fdtfile}

2. Flash the Image and dtb in flash using sf write.

#sf write ${loadaddr} <offset> <len>
# sf write ${fdt_addr_r} <offset> <len>

 - Please make sure to use correct offset and length while writing Image and dtb to flash & make sure that they don't overwrite each other.

  One can find the correct length (size) using the below command

# fatls mmc ${mmcdev}:${mmcpart}

 Please share the output of the above command.

Please try after erasing flash memory.

Thanks & Regards,
Dhruvit Vasavada

[Sunil_13]

Hi @Dhruvit ,

We are working with the i.MX8M Plus EVK, which has 32 MB QSPI flash.
Our goal is to boot U-Boot, Linux kernel, device tree, and initramfs (rootfs.img ) entirely from QSPI flash.

We are able to successfully boot:

U-Boot (from flash.bin)

Linux kernel (Image.gz)

Device Tree (imx8mp-evk.dtb)

However, we are facing issues when loading and using the initramfs/rootfs image from QSPI flash. The kernel starts successfully, but the kernel hangs at Waiting for removable media.... see the below log attached.

-----Flash Layout and Image Sizes----------------

QSPI flash size: 32 MB

flash.bin (U-Boot + SPL) ~2.3 MB
Image.gz (Kernel) ~13.5 MB
imx8mp-evk.dtb ~86 KB
rootfs.img ~12.6 MB

----QSPI Offset Layout----------
flash.bin @ 0x00000000
Image.gz @ 0x00240000
imx8mp-evk.dtb @ 0x01000000
rootfs.img @ 0x01080000

------Programming files into QSPI (from SD card)---------
sf probe 0
sf erase 0x0 0x2000000

fatload mmc 1 ${loadaddr} flash.bin
sf write ${loadaddr} 0x0 ${filesize}

fatload mmc 1 ${loadaddr} Image.gz
sf write ${loadaddr} 0x240000 ${filesize}

fatload mmc 1 ${loadaddr} imx8mp-evk.dtb
sf write ${loadaddr} 0x1000000 ${filesize}

fatload mmc 1 ${loadaddr} rootfs.img # initramfs (cpio.gz)
sf write ${loadaddr} 0x1080000 ${filesize}

------After flashing,power-cycle the board--------------

After boot from u-boot,setting the env variables for Linux kernel (Image.gz),Device Tree (imx8mp-evk.dtb),rootfs.img.

sf probe 0
setenv loadaddr 0x40480000 // kernel
setenv fdt_addr 0x43000000 //dtb
setenv initrd_addr 0x43800000 //rootfs
setenv kernel_comp_addr_r 0x50000000
setenv kernel_comp_size 0x04000000

sf read ${loadaddr} 0x240000 0xCD3CE2

sf read ${fdt_addr} 0x1000000 0x14360

sf read ${initrd_addr} 0x1080000 0xC04DB0

setenv bootargs "console=ttymxc1,115200 root=/dev/ram0 rw"

setenv bootcmd 'sf probe 0; sf read ${loadaddr} 0x240000 0xCD3CE2; sf read ${fdt_addr} 0x1000000 0x14360; sf read ${initrd_addr} 0x1080000 0xC04DB0; booti ${loadaddr} ${initrd_addr} ${fdt_addr}'

saveenv

-----------------------Question 1------------------------------------
1.With SD card Wic file working fine with partitions (Boot/Root).
2.We genarated Two yocto images
==> 1.bitbake core-image-minimal-initramfs (generated initramfs.cpio.gz) this cpio.gx converted into rootfs.img by using this cmd mkimage -A arm -O linux -T ramdisk -d <gzipped_rootfs> <Ramdisk_name> (from linux user guide)
==>2.Also generated tiny rootfs from yocto generated using bitbake core-image-tiny. core-image-tiny-imx8mp-evk.tar.zst this tar extracted into EXT4 partition in SD card succussfully loading tiny rootfs .
3.But as said in 2nd point rootfs.img also put into EXT4 root partition in SD card but not loading the rootfs.

-----------------------Question 2------------------------------------
1.Is this the correct approach to boot an initramfs (rootfs.img) directly from QSPI on i.MX8M Plus EVK?

-----------------------Question 3------------------------------------
3.Is there any recommended NXP reference image for booting kernel and initramfs entirely from QSPI on i.MX8MP(Linux kernel (Image.gz),Device Tree (imx8mp-evk.dtb),rootfs.img) ?

Thank You

[vignesh-baskaran]

Hi @Dhruvit ,

Thanks for the input. its working for us.

if Anyone facing same issue. This is because of the SPI mode selecting during Sf probe.

Thanks.

[vignesh-baskaran]

Hi @Dhruvit 

Thanks for the support.

[Dhruvit]

Hi @vignesh-baskaran,

I hope you are doing well.

Glad to know that issue is resolved.

Can I mark this case as close?

Thanks & Regards,
Dhruvit Vasavada

[vignesh-baskaran]

Hi @Dhruvit,

We believe somehow sf read and sf write is not working as we expected. 

We load the image from SD to RAM and check 

=> fdt addr ${fdt_addr}
=> fdt print ${fdt_addr}.

it is working perfectly.

But when We try to load from QSPI to RAM 

We getting error.

libfdt fdt_check_header(): FDT_ERR_BADMAGIC

We thought this could be issue with size we loading. We cross verified it, its not the issue. 

Note: We tried erase operation before the sf write. 

Can you please let us know about the issue?

[vignesh-baskaran]

Hi,

Can anyone please look into this?