U-Boot initramfs check fails if cpio is newcx format

[BigAl]

We've been building our OS for an x86-64 based device but now I must make it also build for the zynqmp (zcu106).

When I'm attempting to bootm, U-Boot claims that my initramfs is invalid or corrupt.   We had modified the build process (Yocto based) to add the 'newcx' support to cpio (to set xattrs at build-time which are retained at run-time in our read-only fs) and I'm suspecting that U-Boot (u-boot-xlnx) includes a cpio parsing tool to check the integrity but doesn't known about the 'newcx' format.

I can't simply revert use of the 'newcx' format in the cpio.  I need other ideas.

For instance:

• Is there a way to disable the cpio integrity check being done by U-Boot?
  • At the U-Boot command-line?
  • At U-Boot build-time (does someone know where to start?)
• If I switched to UEFI bootloading support, in U-Boot, would the cpio integrity check still bite me?
• Other ideas?

[rfs613]

I don't think u-boot contains code to look inside a cpio archive... but maybe I'm behind the times.

Normally, u-boot expects all files to have a header, produced with mkimage command -- unlike on x86-64 where you can use initramfs.cpio.gz directly. The header includes image type, compression, checksum, and optionally cryptographic signatures. Uboot will verify this header, and will remove it (by advancing pointer) so the kernel then sees just the initramfs.

So I wonder if you are putting the header on your image? If not, then that would be the first thing to try.

If you do have the header... then I would suggest switching from 'newcx' to 'newc' temporarily. Does u-boot accept your image then? It doesn't have to boot all the way, just want to know if u-boot gets past the check that is currently failing for you.

[BigAl]

To get a working base case, I did switch back to the 'newc' format for cpio.  But I discovered that I was also fatload'ing the cpio into an address which was then partly overwritten with my kernel.  So, U-Boot did do a checksum validation on it which was failing.  But, you are correct that it wasn't actually looking into the validity of the cpio (that failure would have occurred at the end of Xilinx kernel init).