It hasn't really started yet, other than some discussions on IRC, but the TL;DR is on every other ARM64 system those features are handled by either a hypervisor or a supervisor, via special PSCI calls. These machines don't have the option for a supervisor (and no nested virtualization, so an under-OS hypervisor would preclude VMs). Rather than introducing a special snowflake driver for these machines, the current thinking is we can introduce some kind of third PSCI mechanism to make these calls into code set up by the bootloader (a la EFI runtime services), without switching to a higher privilege level. That means we need to define how all that would work first.
Implementing a PSCI mechanism in m1n1 sounds like a nice workaround (I could almost consider it an actual fix, even if it's not totally standard), but I'm a bit surprised:
- Doesn't ARMv8 architecture require supervisor mode? You should be able to just pop a good old Arm Trusted Framework sample, implement PSCI in there just like other standard ARMv8?
- Linux kernel already supports various PSCI-less architectures (rpi4 notably for armv8 if I'm not mistaken), so I don't think upstream would mind about that at all?
I guess your proposed approach makes sense when the target is more than just Linux though, do you have hopes that m1n1 could be eventually suitable to boot Windows?
ARMv8 does not require EL3 (nor EL2, for that matter). They are architecturally optional, and there's a whole bunch of the spec dedicated to how things interact with their presence or absence. There is definitely no EL3 on these machines.
Does rPi4 really have these features without PSCI? The internet suggests it does not support sleep states at all, and I wouldn't be surprised if it doesn't do any fancy CPU idle states either. Hence, they're at the same point we're at without PSCI.
The rpi4 has some power management via the mailbox interface to the videocore, but it's just hacked on to the side and is more of an example of how not do things IMO. Particularly how it's exposed to user space is real gross (basically raw mailbox calls). It's closer to the primitives that psci or acpi would be papering over.
It's honestly a bit amusing how many people have been doubting how good Asahi can get without official support, but then you look at "officially supported" platforms like Raspberry Pi and so much stuff is barely held together with string and kernel forks...
Honestly, those Broadcom chips are crazier to support than th M1s, and the rPi foundation don't exactly have much of an upstream-first reputation... so I'm quite confident we can do a lot better.
yeah I was really excited about the first generation of RPi and then ran headlong into big problems where the kernel would drop USB packets when running at sustained high loads at USB 2.0 speeds. And nobody else could fix it because it was relying on CPU documentation that Broadcom hadn't released yet. It took basically 2 years to get USB working properly, and the RPi architecture basically uses USB as a system bus so potentially more or less everything was affected...
A huge number of the use-cases that people were excited about ended up being "low-power device to connect X usb device to network" (whether that's storage devices, cameras, whatever) and it kinda killed a lot of the utility for a long time.
And yeah I know the "official" purpose was as a low-power system for schools, but the first gen also had reliability problems due to the full-size SD cards being unsupported in their slow and tending to warp a little bit with sustained warm-ish temperatures and questionable power adapters people were using, so they weren't even something I'd really want to administer, the reliability wasn't there.
I know a lot of these have been fixed over time in various fashions (the microSD card doesn't cantilever out into open air, so it doesn't tend to warp as much, and people have figured out better adapters, etc) but the early experience was rough and the software issues were exacerbated by Broadcom's high level of secrecy with their documentation. And unlike Asahi, there wasn't the drive to "figure it out" and write your own implementation/documentation - just as an outsider it seems like the existence of documentation (even if nobody outside the foundation could see it) killed the drive to reverse-engineer it. Why go to the effort ifthe documentation exists, type thing.
Yup, rpi being the the "most acclaimed" SBC Linux platform shows that even in our midst marketing is everything, while other SBC have actual full opensource full mainline for every components (both for first boot stages, and EL3) support from SoC vendor.
I don't think ARMv8 requires EL3 but even if it did there is no EL3 on the M1.
Booting Windows natively would require Microsoft's support since some rather invasive changes to the kernel would be required (FIQ support, DART instead of SMMU) on top of implementing drivers for everything.
