Hi
We have built a new image for IMX6 as following https://doc.qt.io/Boot2Qt/index.html .
But I found there is a wic file not a zip file of image.
We are using the old version 4.1.15 on the unit, and it doesn't seem to detect to SD card with wic.
Could you please tell us how to flash it to the unit with the old version?
Regards
Solved! Go to Solution.
since you use old bsp version 4.1.15, why do you get wic images? you should get xx.sdcard images after you build the bsp
I don't know how you build, if your bulit bsp version is 4.1.15, you should find all of built images under "deploy/images" folder
you can use uuu tool to download image to the board,
"https://github.com/NXPmicro/mfgtools/releases"
you also can use dd command to download image to the SD card, for detailed information, pls refer to the enclosed user guide
Also I found I could not create sdcard type for the image:
We couldn't create this type for imx6dlsabresd, is that rigth?
Hi again.
I tried to use the command as follow to burn the image to imx6dlsabresd but fail
uuu -b emmc_all u-boot-tagged.imx imx-image-full-imx6dlsabresd-20230131030147.rootfs.wic.bz2
it will be frozen:
What should I do for it?
Hi @Mihan
Make sure you local.conf has:
IMAGE_FSTYPES += " wic"
And try to get Yocto to build an uncompressed wic image. Some uses have found compressed wic's give problems with UUU.
Also, try:
uuu -b emmc_all imx-image-full-imx6dlsabresd-20230131030147.rootfs.wic (without the u-boot section and wic uncompressed)
Cheers.
Hi @Mihan,
Whether the wic starts off compressed or not, once UUU get's hold of it it will end up on the board extracted. As commented some users found UUU had issues extracting and flashing at the same time; hence to build and start testing without compression.
Can I suggest starting with a smaller image until the UUU issue has been resolved. Build a Yocto image with the bare basics i.e core-image-minimal (your image may be called something similar, but try this first), this image will boot up and give you lots of basic tools as well as all your device drivers. It's just quicker to build, flash and evaluate then once you've fixed your issue go back to the other build.
Next, copy the contents of the /deploy/image folder into a text file and post it here in case your not using a full image with uboot and everything in it...
Finally, lots if users have issues running on a VM; find a native Linux machine and try flashing your board.
EDIT: Just reread some of your posts and you're using Boot-2-Qt bsp; I'm not familiar with that but you could try looking around on this site and trying some of their pre-built images. You need to ascertain if it's your 'build' or the 'UUU download process' first I think then work on which one is the real issue.
https://www.embeddedartists.com/boot2qt-for-imx-developers-kits/
Cheers.
Hi @Mihan,
The link you posted ends with 'Bad Linux ARM zImage magic', is that what you are experiencing? This error is typically a result of the build i.e. loading the kernel with wrong bits (64bit loader and 32bit kernel / 32 bit kernel and 64 bit loader) OR the image is the wrong type for u-boot (uimage/zimage). Another case is the build image could be looking for an SD card not eMMC. However if you're using a standard Yocto build matched to your board and memory, all of that will be take care off.
Whose board are you using? NXP EVK, Digi, custom board?
Did you get the NXP image working? Was this built by yourself or a pre-built image?
Hi @Mihan,,
I think you may be at the point where you need to 'clear the desk' somewhat and confirm what works and what doesn't. It seems you have too many unknowns and that can make a situation like this very hard to diagnose especially if it's your first time around a new board or build.
iMXs have a manufacturing mode set by dip switches or links that must be used after the initial programming. By default - out of the factory - they are blank and automatically in manufacturing mode for ease of programming during production.
Set the switches to program the board after which set them to back to boot and run the board. In most cases, users will be setting them to program the eMMC and then to boot from eMMC.
uuu is the successor to MFGTool and is better, there's no messing around with that xml file! Like MFGTool you still have to flick those switches to program eMMC or nand. Also like MFGTool everything gets downloaded into your boards RAM to eventually program the board. To flash a board nothing must be ran from eMMC (or nand, sd card), therefore once connected uuu will download it's own version of u-boot and a kernel with a ramdisk, everything it needs to boot and run a basic Linux OS in RAM in that instance of use. Once uuu gets a basic OS running in RAM it will start to download and program the board's actual uboot, kernel, devicetree and FS. You can see why everything has to be off the silicon for a complete reflash..
So it looks like uuu is not getting one of the requirements above. Personally I haven't seen anyone passing uuu an old_image with the new_image, normally you'd wipe the board and program it with just the new image. I do appreciate there's probably times where something like this is required.
So, back to your board. Have a search on the ZLG website and forums to see if there is a downloadable wic image for your exact board and try that. Also search the site for uuu information specific to you board. Use those manufacturing switches.
You mentioned that you built a smaller Yocto image for you board, did Yocto have the exact machine type for your board or did you use a generic iMX6 build (PMIC, pheripherials, RAM, eMMC specs will differ)?
Are you actually trying to program eMMC or an SD card?
If an SD card, are you trying to program the SD card using uuu with the card installed into your board?
Cheers.
Hi @Mihan,
1# For simplicity don't try to program the SD card when inserted into your board it's just adds more unknowns. at this stage. If you want to use a SD card load it directly off your PC using 'dd' or whatever tool works.
If you want to program the eMMC on your board use uuu and set the dip switches accordingly.
2# This old image off the ZLG website you mentioned, is that the v4 kernel using MFGTool and that worked?