Attention is currently required from: Angel Pons, Arthur Heymans, Christian Walter, David Milosevic, Felix Singer, Julius Werner, Martin L Roth, Maximilian Brune, Nico Huber.
ron minnich has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/74798?usp=email )
Change subject: arch/arm64: Add EL1/EL2/EL3 support for arm64 ......................................................................
Patch Set 9: Code-Review+1
(1 comment)
Patchset:
PS9: The best is the enemy of the good, as the saying goes. We know what we want, we want 100% GPL firmware as it was in 2000, but I feel we should be careful not to close off a chance for a design win because it's not exactly that model.
TBH, I worry a lot more about our growing UEFI inclusion in the payload than this change.
I'm inclined to think this CL is a reasonable approach. Back in the linuxbios days, we did something very similar with a delivered intel HPC system, i.e. we gave over 64K of hardware startup to an intel blob and the rest was linuxbios. This would have been ca 2002, with company called Linux Labs. I can't find an article from that time.
Sometimes, you have to give a little up to make progress. This CL certainly seems no worse than what we've had to do on x86.
w.r.t the blob issue, there are proprietary DRAM controllers out there that make it impossible to release source code for early startup. None of us likes it, but that's the way it is. ARM, in theory open, is in practice very closed, esp in the server market. But many companies don't own core parts of the IP used in DRAM hardware, for example.
on the RISC-V, on oreboot, we now run the ramstage at a lower privilege level than the ROM code. I like that; it follows a principle of least privilege, and this change has a certain similarity: drop privilege, at every step, as much as possible. Hence he use of the term "EL2" -- think of EL3 as a sort of SMM mode in x86 terms, and EL2 as kind of Ring 0, and it might make more sense.
So, back to this CL; I think it shows how flexible coreboot can be, even as we necessarily accept a model we don't entirely like. But, as compared to what we have to accept in the x86 world? This does not seem as bad to me.
I'm going +1 b/c the code may need further change, and I respect the concerns expressed by Julius, Nico, Felix, and others; but I'd also like to ask you all to step back and consider whether the gain here might be worth it. Thanks.
-
ron minnich (Code Review)