Hi, I am attempting to bring up a custom board that has the i.MX8QXP onboard, and I did a Yocto build of an image for the i.MX8QXPMEK development board. My question is on this custom board which is very similar to the dev board (MCIMX8QXP-CPU) I want to take the .sdcard file that is generated form my Yocto build and put it into an off-board QSPI with the use of an external tool that directly writes into the QSPI flash device. So if I take the .sdcard file and write it pound-for-pound to offset 0x8000, I should be able to boot up the Linux kernel?
I extracted the file that was built:
...and it appears to be a simple binary file as is. So that is why my thoughts are to simply flash this as-is starting at the 0x8000 offset.
If this is not how to do things, let me know. All hardware problems aside, this is what someone should do to get their image into the QSPI? If I am mistaken how to do this, what ways would I want to work on getting the data correctly placed into a QSPI flash device? And FWIF, I got this offset information from NXP's IMX Linux User's Guide. Either way, hoping to learn something here and appreciate the feedback I receive. Anything that I can clear up, please let me know. Thank you in advance, looking forward to hearing back.
suggest to create new thread for questions for yocto build,
for building image one can look at yocto guidelines on web:
for Q3. one refer to Reference Manual:
Ok let’s start from the beginning here. I have a yocto project that builds fine. It is configured by default to build an image for the SD card and I can even use that same image to flash the onboard eMMC via UUU and the USB interface on the dev board. So... how can I build an image for the QSPI interface? Isn’t there some simple configuration to change as suggested in the Yocto UG?
I was looking into the Yocto User's Guide and read section 5.5 (U-Boot configuration).
1) The local.conf file they are referring to is located at:
2) The manual also mentions to "echo" in UBOOT_CONFIG = ... to this file. Currently this line doesn't exist. It is implied ot simply append it by "echoing" it?
3) Another thing is we are using a QSPI flash device to store our kernel and boot, etc. Why were you talking about FSPI, or is this the same? Why wouldn't I pick QSPI1 or QSPI2 that are also mentioned in the Yocto UG?
4) If I add this "UBOOT_CONFIG" piece in this local.conf file, when I bitbake, I get an image for whatever the UBOOT_CONFIG is set for? i.e. it just "knows" how to make it say a QSPI image?
imx-image-core-imx8qxpmek.sdcard.bz2 is not intended for writing to
QSPI flash device. Reason is that FSPI requires special configuration block
used by imx-mkimage tool in
So shortly procedure could be:
Uboot: make imx8qxp_mek_fspi_defconfig
make imx_mkimage: cp ../../uboot-imx/u-boot.bin ./iMX8QX/
make SOC=iMX8QX flash_flexspi
UUU: sudo ./uuu -v -b qspi ../../imx-mkimage/iMX8QX/flash.bin
So I am not building u-boot manually - it just happens when I bitbake.
Referring to the NXP Yocto User's Guide, per section 5.5: U-Boot Configuration, I modified the local.conf file as stated to do so:
$echo "UBOOT_CONFIG = \"fspi\"" >> conf/local.conf
...when I run this at the terminal being currently situated in the root build directory.
I then clean the "imx-image-core" via:
bitbake -c clean imx-image-core
...and then run a bitbake to build the image again.
What do I look at to verify that I am getting an FSPI image that I can simply flash pound for pound into the QSPI via some external means. And by external means, it is a QSPI device on its own board flashed with a proprietary interface, hence why I want to load EVERYTHING - boot and kernel - into this QSPI that once it interfaces with the i.MX8, I can boot the thing up.
Section 5.5 means something, right? Why can't this work for me?
EDIT: I looked in the *.wic file that was generated in my bitbake build directory where all the images are placed, and there's nothing at address 0x400 when I look at it with a binary editor... This stuff is such a mess and difficult to figure out! Everything I try to do is such a struggle and you never know if you're posting info in the right place to ask the right questions, looking at info online if it's what you need... Sorry for complaining, but this is something that is taking me days and no results that are encouraging.
Forgive me, total beginner here. A lot to do here for me then and the steps you outlined to me are not very clear - probably because I'm inexperienced as you can tell by what I asked. I simply type in bitbake and I get my image. That's the extent of my knowledge.
First step, no idea what to do with this. Like I said, I do a bitbake, and I get some stuff... Flash the SD card with the 'dd' command and it works. Not a UUU expert and don't know all about it. Need some hand holding here...
make imx_mkimage: cp ../../uboot-imx/u-boot.bin ./iMX8QX/
I don't know how to clone the imx-mkimage stuff. I tried using 'repo' and all that explained in the NXP Yocto User's Guide, and no luck... And is this 2 separate operations - i.e. make and cp? So I make first, then copy something next???
Third step, already lost, so can't go this far...
Fourth step, not planning on using UUU to flash an off-board QSPI. We are going to flash the QSPI chip with other 3rd part utility, then connect it to the i.MX.
Overall, sorry your reply was of little help to me with what very little I know. I need someone to hold my hand so to speak on this because it is all new to me and would be nice if there was some sort of documentation on how to do what I'm attempting to do. I get it that it probably won't be in one place, but who else will I learn this when I know absolutely nothing??? Please help!!! I don't care if we work on clearly outlining a single step you explained one at a time need be, just want to understand what's going on here. I try to follow the NXP documents and they are above my head. Maybe this task is above my paygrade... IDK... Just want some good support for this task somehow, someway. Yeah, I'm kicking and crying here, haha!
for building image one can look at
OK, I'm looking into the first link. The Toradex stuff seems more generic and RidgeRun is the expensive solution to "hand-holding" as I called it since they are contracted out. Either way, I'll just see what I can do. Apparently, this QSPI image generation is a can of worms that one needs to know a few more things about this i.MX8 business.