richlowe
qemu: use u-boot here, too
There's a couple of reasons to do this, but I think they end up basically the same.
- It means all the boards boot the same way (a reasonable thing to expect to continue on systems that aren't UEFI).
- Most actual hardware requires some level of firmware initialization, without firmware on qemu, that initialization never happens and the OS has to take care of it. It would be nice if that were possible, but it's a lot of work that's not really ARM-specific
This doesn't use arm-trusted-firmware as well since that is for the moment less relevant and being an "insecure" CPU world is perhaps an interesting quirk to preserve.
@rmustacc this seems like a cop out, but it's probably an expedient cop out, right?
I've also booted this under qemu in an emu-branded OmniOS zone - also successful once I removed the secure=on that we were putting in there.
@rmustacc this seems like a cop out, but it's probably an expedient cop out, right?
I don't know the cost of using u-boot, but seems like a reasonably starting point for now to me.
I've also booted this under qemu in an emu-branded OmniOS zone - also successful once I removed the
secure=onthat we were putting in there.
I would have expected secure=on to imply we came up in EL3 and would really prefer to have the trusted firmware in there. I'm surprised things worked if we come up in EL3 without the firmware. hm.
@r1mikey I left this dangling because it isn't actually necessary to me until the rest of PCI support works properly.
That said, I think your plan long-term includes us using u-boot too (and possibly, its UEFI, but I don't think that is important right now). If so, would me merging this now make sense?
One thing I've noticed is that, with this, virtio_mmio nodes self-identify, so we can make use of that globally if we're willing to say "We're going to use u-boot on all non-SBSA systems"?
I'm working on top of this change for getting loader up.
No further changes were needed for UEFI to work, so it'd be great to get this in.
