Hi all,
Is anyone else suffering from files like this no longer being available in their builds?
https://www.nxp.com/lgfiles/NMG/MAD/YOCTO//imx-gpu-viv-6.4.3.p4.6-aarch64.bin;fsl-eula=true
Started last monday I believe and I’m still struggling today.
Any help/confirmation that this is happening for other people would be greatly appreciated.
Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello,
When encountering 404 errors during Yocto builds due to missing files from upstream sources like NXP, it’s often a result of the file being moved, renamed, or removed from the server. This can disrupt builds, especially for components with specific licensing or distribution restrictions.
To address this issue, you can take the following steps:
Check the NXP website or source for an updated URL: Sometimes, the files are simply relocated. If you can find the new location, you can modify your Yocto recipes to point to the new URL.
Look for a mirror: Occasionally, mirrors of the required files exist. While this is less common for proprietary files subject to EULA agreements, it’s worth checking.
Update your Yocto layers: If you’re using a BSP layer provided by a vendor (e.g., Toradex), ensure it’s up to date. Vendors often release updates to address such issues when upstream sources change.
Check with the community: See if others are experiencing the same issue and if any workarounds have been identified. While direct community support recommendations are beyond my scope, engaging with forums where developers discuss Yocto and embedded Linux can be helpful.
Local source cache: If you previously downloaded the file for another build, you might have it in your local sources cache (DL_DIR in Yocto). You can manually place the file in the expected directory to bypass the fetch step.
Contact the provider: While direct contact recommendations are beyond my scope, reaching out to NXP for access to the file or information on its status could be a last resort.
Remember, when modifying Yocto recipes or layers, document your changes well for future reference and to assist others in your team.
Best regards,
Toradex AI Assistant
Please, also check if these links can help you solve your problem:
Hello @alan01252,
Could you provide more details about your build? Is it a yocto build based on BSP 6? Could you point to the actual error that’s being reported?
I just checked two things:
Rafael
That’s really interesting
That same link for me here gives
So I wonder if it’s region specific, UK London.
There’s not much to see in the logs really other than fetch failing because of 404s 
Did you try without the ;fsl-eula=true part? My guess it that this is not part of the official URL and should be stripped out somehow.
The full URL you showed fails for me too, but without that last part it works.
No I did not, yes that does work for me too thank you…
And I bet that is being stripped by yocto too, okay I’ll try my build again and see if I can see what’s actually being triggered.
Thanks again!
@rafael.tx here we go, I had a good run of builds yesterday but today I’m getting similar errors as before
ERROR: Logfile of failure stored in: /builds/networks/onvp/ifu/yocto/plc-ionopi/build/tmp/work/armv8a-mx8mp-poky-linux/imx-codec/4.7.2-r0/temp/log.do_fetch.87507
ERROR: Task (/builds/networks/onvp/ifu/yocto/plc-ionopi/build/../sources/meta-freescale/recipes-multimedia/imx-codec/imx-codec_4.7.2.bb:do_fetch) failed with exit code '1'
ERROR: imx-gpu-viv-1_6.4.3.p4.6-aarch64-r0 do_fetch: Fetcher failure: Fetch command export PSEUDO_DISABLED=1; export PATH="/builds/networks/onvp/ifu/yocto/plc-ionopi/build/tmp/sysroots-uninative/x86_64-linux/usr/bin:/builds/networks/onvp/ifu/yocto/plc-ionopi/sources/poky/scripts:/builds/networks/onvp/ifu/yocto/plc-ionopi/build/tmp/work/armv8a-mx8mp-poky-linux/imx-gpu-viv/1_6.4.3.p4.6-aarch64-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux:/builds/networks/onvp/ifu/yocto/plc-ionopi/build/tmp/work/armv8a-mx8mp-poky-linux/imx-gpu-viv/1_6.4.3.p4.6-aarch64-r0/recipe-sysroot/usr/bin/crossscripts:/builds/networks/onvp/ifu/yocto/plc-ionopi/build/tmp/work/armv8a-mx8mp-poky-linux/imx-gpu-viv/1_6.4.3.p4.6-aarch64-r0/recipe-sysroot-native/usr/sbin:/builds/networks/onvp/ifu/yocto/plc-ionopi/build/tmp/work/armv8a-mx8mp-poky-linux/imx-gpu-viv/1_6.4.3.p4.6-aarch64-r0/recipe-sysroot-native/usr/bin:/builds/networks/onvp/ifu/yocto/plc-ionopi/build/tmp/work/armv8a-mx8mp-poky-linux/imx-gpu-viv/1_6.4.3.p4.6-aarch64-r0/recipe-sysroot-native/sbin:/builds/networks/onvp/ifu/yocto/plc-ionopi/build/tmp/work/armv8a-mx8mp-poky-linux/imx-gpu-viv/1_6.4.3.p4.6-aarch64-r0/recipe-sysroot-native/bin:/builds/networks/onvp/ifu/yocto/plc-ionopi/sources/poky/bitbake/bin:/builds/networks/onvp/ifu/yocto/plc-ionopi/build/tmp/hosttools"; export HOME="/tmp/tmpi0nx9jcs"; /usr/bin/env wget -t 2 -T 30 --passive-ftp -P /builds/networks/onvp/ifu/yocto/plc-ionopi/build/../downloads 'https://www.nxp.com/lgfiles/NMG/MAD/YOCTO//imx-gpu-viv-6.4.3.p4.6-aarch64.bin' --progress=dot -v failed with exit code 8, no output
ERROR: imx-gpu-viv-1_6.4.3.p4.6-aarch64-r0 do_fetch: Bitbake Fetcher Error: FetchError('Unable to fetch URL from any source.', 'https://www.nxp.com/lgfiles/NMG/MAD/YOCTO//imx-gpu-viv-6.4.3.p4.6-aarch64.bin;fsl-eula=true')
ERROR: Logfile of failure stored in: /builds/networks/onvp/ifu/yocto/plc-ionopi/build/tmp/work/armv8a-mx8mp-poky-linux/imx-gpu-viv/1_6.4.3.p4.6-aarch64-r0/temp/log.do_fetch.87700
The NXP website gets slow occasionally or even goes down. You’re probably hitting these instances.
I wonder why are these files being downloaded on every build? Usually, the downloads are cached in a specific directory, so the files don’t need to be re-downloaded all the time (saving bandwidth and speeding up the build in the process).
Did you specifically turn off the download cache? Are you deleting everything inside the build directory at every build?
We usually rely on the sstate cache in our CI/CD pipelines ( I’ve now got a ticket to cache the downloads directory too but haven’t prioritized it yet ) to make sure we don’t run into these problems in future.
We’re building a new board and there’s lots of tweaks I keep making which means the sstate cache gets invalidated 
We’re getting there, slowly but surely 
The downloads directory and the sstate cache are handled independently of each other. You can keep the downloads outside your build directory and always use that.
I think it’s safer to keep a copy of the downloads directory somewhere, to make sure you’ll always be able to build the same version in the future, independently of the state of external sources.
Even if in the future you update to our latest BSP release, it will keep working because any new file will be downloaded correctly.
If you want to keep the size of the downloads folder under control, you can delete it once in a while and force a complete download (or even move it and make sure the fresh build can download everything before deleting it).
I usually set my downloads directory like this in local.conf:
DL_DIR ?= "${TOPDIR}/../../downloads"
nod locally I use kas and just mount the downloads directory into the container so it’s there everytime.
I think i’m just going to tar up my local Downloads directory, spit it up to s3 and then have our pipeline pull it down as part of the ticket.
Thanks for confirming that nxp sometimes has issues though! Means this is a necessary step, and really I should have been caching the downloads before now!