Why local.conf UBOOT_CONFIG updates are not visible in /tmp/deploy/images?

[djregan]

Hello,  1st supporting background, then a question...

Supporting background information...

- We are using the mx6ull evk reference design.

- We are following NXP iMX6ULL supporting documentation revision level 'fsl-yocto-L4.1.15_2.0.0-ga'.

- We have followed document 'i.MX_Yocto_Project_User's_Guide.pdf' procedures and have successfully built for the SD card targeted U-boot images, and QSPI1 NOR flash images.

- While following 'i.MX_Yocto_Project_User's_Guide.pdf' subsection 5.5, and while changing preferences for U-boot image targets from 'qspi1' to 'spinor', we notice that /fsl-release-bsp/build-fb/tmp/deploy/images/imx6ull14x14evk are not updated with the U-Boot SPI-NOR preferences (for ECSPI Serial ROM boot option).

- I can confirm the last line within the 'conf/local.conf' file is UBOOT_CONFIG = "spinor"

- However executing statement $MACHINE=imx6ull14x14evk bitbake -c deploy u-boot-imx after updating the 'local.conf' file does not produce new files supporting the 'spinor' option.

My question is...

Why aren't new 'spinor' images showing up in /fsl-release-bsp/build-fb/tmp/deploy/images/imx6ull14x14evk/  ...image deployment folder?

I do see links to the u-boot binary images are updated / refreshed. But... actual u-boot binary images are not. See attached screenshot.

[Yuri]

Hello,

  Have You applied bitbake cleanall option before U-boot configuration
modification and rebuild ?

Have a great day,
Yuri

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[djregan]

Hi Yuri, Thanks for the quick reply sir!

Unfortunately -> we can repeatedly run 'bitbake -c cleanall' ...and observe there is no change in outcome with the effort to run console $MACHINE=imx6ull14x14evk bitbake -c deploy u-boot-imx

Some additional information I can offer...

I just now (today) deleted my old '/fsl-release-bsp' folder and re-executed all necessary steps to recreate a new ''/fsl-release-bsp' folder and expected contents within this folder. I re-ran $MACHINE=imx6ull14x14evk bitbake -c deploy u-boot-imx ...and before changing the last line of file /conf/local.conf to support "spinor", I observe only a sd supporting u-boot imx image is produced (as expected),

After adding UBOOT_CONFIG = "spinor", and re-running $MACHINE=imx6ull14x14evk bitbake -c deploy u-boot-imx ...and, the resulting console output states: 'Tasks Summary: Attempted 234 tasks of which 234 didn't neet to be re-run and all succeeded." Meanwhile no new images are produced in the deployment folder.

Subsequently, after successfully building the default sd image, and unsuccessfully building the 'spinor' image, I revised /conf/local.conf to use the 'qspi1' targeted image, and reran $MACHINE=imx6ull14x14evk bitbake -c deploy u-boot-imx. This time - i see qspi supporting images show up in the deployment folder.

So... 

- Default sd U-boot image generation capabilities work well.

- Target 'qspi1' image generation capabilities also work well.

- Target 'spinor' image generation efforts are broken. Bitbake thinks there are 234 tasks, and all 234 were complete even before /conf/local.conf is revised to be configured for 'spinor' for the 1st time.

Thoughts?

Thanks Yuri!

--DJ

[djregan]

Sorry for re-replying to my reply from a few minutes ago... but... there's some new information that I just realized...

Revising UBOOT_CONFIG to be 'spinor' and running console command MACHINE=imx6ull14x14evk bitbake -c deploy u-boot-imx ...results in only a sd supporting image within the /tmp/deploy/images folder.

However, revising UBOOT_CONFIG to be 'qspi1' and running console command MACHINE=imx6ull14x14evk bitbake -c deploy u-boot-imx ...results in both a sd and qspi supporting u-boot image within the /tmp/deploy/images folder.

So... that's interesting? ...right? Ideas for 'where?' to look next?

Thanks much in advance,

--DJ Regan

[djregan]

NXP Support,

Any ideas for things to try next?

Thanks in advance!

--DJ Regan