On Wed, Oct 23, 2019 at 10:21 PM Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx> 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
