On Wed, 9 Nov 2022 at 13:35, Leif Lindholm <quic_llind...@quicinc.com> wrote: > > From: Leif Lindholm <Leif Lindholm quic_llind...@quicinc.com> > > We have mainly (well, as will become clear, in fact "exclusively") been using > sbsa-ref with the "max" CPU. But sbsa-ref was created with a default CPU of > Cortex-A57, which we have not updated along the way.
So, I don't have a strong opinion on what sbsa-ref's CPU type should be: if 'max' works better for the use case we should change to it. > However, the "max" cpu has seen a bug where Linux boot fails around UEFI > ExitBootServices. Marcin Juszkiewicz has found the cause for that, but that > requires a patch to TF-A. (Has that been submitted upstream?) > > Turns out that due to a change in upstream TF-A last year, all supported cpus > other than "max" fail to even boot UEFI fully, due to the top-level (TF-A) > Makefile defaulting to enabling the maximum ARM architectural version > (currently 8.6), in combination with not verifying all features at runtime > using the ID registers. This seems to me straightforwardly to be a problem that should be fixed in TF-A. "Default to the newest possible architecture version and don't check ID registers" is a recipe for "can't boot on anything". Many *hardware* CPUs aren't that new yet! Part of the purpose of sbsa-ref is to find problems with the software stack -- so we should expect that sometimes the answer is "fix the software stack", not "change the model's behaviour". > Since the *point* of sbsa-ref is to serve as a continuously evolving platform > tracking (with some obvious lag) the evolution of the ARM architecture and the > SystemReady specifications, I don't really want to restrict the enabled > feature set in TF-A to the Cortex-A57 one. > > My preferred course of action would be to change the default cpu to max - > maybe even dropping support for other cpus. I would then step the version > field that was added to the DT. *But* this would break existing boots with > old TF-A that can currently boot Linux. An intermediate option would be to move forward to for instance the neoverse-n1 CPU type. If you want to use 'max' for sbsa-ref then you probably also want to look at making sure that TF-A is doing the same thing Linux does where it checks ID registers for feature presence before enabling feature use, because 'max' is a moving target and relies on the guest code doing the right thing with feature checks. In particular it does not honour the nominal architectural requirements about v8.x/v9.x levels, but may implement features from further in the "future" than is strictly permitted given the absence of some other older features. thanks -- PMM
