search

litex-hub / linux-on-litex-vexriscv

Linux on LiteX-VexRiscv
BSD 2-Clause "Simplified" License
553 stars 174 forks source link

Initramfs unpacking failed on Arty A7 & ULX3S #248

Open troibe opened 2 years ago

troibe commented 2 years ago

So I was trying to run some benchmarks to compare BlackParrot/VexRiscv/Rocket.

Unfortunately I'm running into this issue: Initramfs unpacking failed: invalid magic at start of compressed archive

Therefore I'm unable to execute the benchmarks.

essele commented 2 years ago

I've just been looking at this as I was having the same problem on the icestick_pro. The issue is actually that the initrd start and size are "hardcoded" into the devicetree and not adjusted or passed in by the bootloader (bios in this case.)

The fixed settings assume an 8M file and the actual rootfs.cpio file is inevitably different to this. The linux code to unpack the rootfs archive doesn't detect the end, it uses the provided length and therefore it runs off the end of the file and starts trying to process junk.

You can workaround the problem by putting the correct value for "linux,initrd-end" in the "chosen" section of the devicetree, although you'd have to update this any time the rootfs changed size.

A better answer would be for the bios to update things accordingly (and pass in the "chosen" section), but that seems to be non-trivial and possibly against the intent of the very lightweight bios approach.

It is worth saying that the error doesn't actually cause any problems ... the code (in init/initramfs.c) just seems to ignore the error message, so it should still work fine.

mithro commented 2 years ago

I think this continues to demonstrate why we need to be actively generating the device tree as part of the build process...

troibe commented 2 years ago

@essele It's quite some time ago since I have worked on this. If I remember correctly though when using BBL or OpenSBI in FW_PAYLOAD mode I didn't have to worry about the sizes of the specific memory segments. So is this an issue that is caused by using OpenSBI in FW_JUMP where we have to specify the size of memory segments? As you said of course updating the device tree would be solution this since we already generate it anyways.

Also when you are saying it does not cause any issues which commands did you try running? I didn't run into issues with builtin busybox commands of course but when trying to run other binaries inside the initramfs.

essele commented 2 years ago

@developandplay -- turns out there isn't really anything on the default image, so I've just built a new rootfs.cpio with "Lua" added, and that works fine, even with the error (... as I'd expect as it should still process every file, the error is just about going past the end.)

This is on a icesugar_pro ... I haven't tried any other devices yet, although an OrangeCrab and a ULX3S has finally just arrived, so I'll get to them shortly.

troibe commented 2 years ago

Ok great! I'll check out this issue again then. Maybe I ran into some other issue that I just mistakenly blamed on the initramfs error.

gsomlo commented 1 year ago

speaking of automatically generating the DT[S] -- anyone know of the precise way to calculate linux,initrd-end? Or, rather, given that initrd-end = initrd-start + initrd-size, how to calculate initrd-size?

I have created an initrd.cpio archive, which happens to be 1156096 (0x11A400) bytes in size. If I compress that with gzip, I get a resulting initrd.cpio.gz file that's 751462 (0xB7766) bytes in size.

However, if I set initrd-size to precisely 0xB7766, the booting kernel fails to unpack it with an error message that reads "Initramfs unpacking failed: read error".

Setting initrd-size to the full uncompressed size of initrd.cpio (0x11A400) allows the kernel to boot fine, but an error message (a slightly different one, btw) is printed: "Initramfs unpacking failed: invalid magic at start of compressed archive". That error comes from here: https://github.com/litex-hub/linux/blob/litex-rebase/init/initramfs.c#L537 and essentially means that incomprehensible junk was encountered during one of the (multiple) iterations of decompressing the archive (the bit about "start of compressed archive" is actively misleading, it's the start of the current iteration's buffer worth of data!!!).

With some added printouts I managed to narrow down exactly what my intrd-size should be to silence that error, and it turns out to be 0xBA974 (the size of my initrd.cpio.gz file plus 12814 bytes!!!).

I haven't the foggiest idea where the 12814 byte difference came from, whether it'd be the same difference if I rebuilt my initrd.cpio.gz archive and ended up with a file of a new size (different from my current 751462 bytes), and how actual bootloaders (u-boot, grub, etc.) deal with this issue...

Any further ideas much appreciated!

Dolu1990 commented 1 year ago

Realy no idea. The "Initramfs unpacking failed: invalid magic at start of compressed archive" was always a mistery for me.