On Wed, Oct 23, 2019 at 10:21 PM Segher Boessenkool segher@kernel.crashing.org wrote:
On Wed, Oct 23, 2019 at 12:36:35PM +1100, Oliver O'Halloran wrote:
When booting under OF the zImage expects the initrd address and size to be passed to it using registers r3 and r4. SLOF (guest firmware used by QEMU) currently doesn't do this so the zImage is not aware of the initrd location. This can result in initrd corruption either though the zImage extracting the vmlinux over the initrd, or by the vmlinux overwriting the initrd when relocating itself.
QEMU does put the linux,initrd-start and linux,initrd-end properties into the devicetree to vmlinux to find the initrd. We can work around the SLOF bug by also looking those properties in the zImage.
This is not a bug. What boot protocol requires passing the initrd start and size in GPR3, GPR4?
The CHRP binding (what SLOF implements) requires passing two zeroes here. And ePAPR requires passing the address of a device tree and a zero, plus something in GPR6 to allow distinguishing what it does.
This is what is assumed by the zImage.pseries. I have no idea where that assumption comes from,A B
As Alexey says, initramfs works just fine, so please use that? initrd was deprecated when this code was written already.
That's not what Alexey said and the distinction between an initrd and an initramfs is completely arbitrary.
Segher