On Sat, Aug 23, 2025 at 08:59:13AM +0100, Julien Grall wrote: > > On 22/08/2025 21:09, Elliott Mitchell wrote: > > Since you're not pointing to anything definite, could it be everything > > has been resolved? > > Unfortunately, the situation has not changed since your last thread about > enabling CONFIG_ACPI=y a couple of years ago. The main feature we are > lacking is the parsing the IORT (used to discover SMMUs and MSI > controllers). Without this...
No one to sponsor this work? Disappointing with how far ACPI support had gotten. Surprising the funding ended here. > > We've got at least two people for whom ACPI on ARM > > works pretty well. > > ... Xen will only properly boot on "simple" case like the Raspberry PI. > Also, IIRC Xen would use ACPI rather than Device-Tree by default. What is the "improper" booting on non-simple cases like? panic()? Domain 0 boots, but the system isn't properly protected by the SMMU? Ideally it would be runtime configurable with the former being the default, but the panic message indicating how to override to produce the latter. Perhaps even accompanied by an invitation for sponsorship. Yet handling those simple cases would help many people. For a long time IO-MMUs were rare, yet the world did not end. > > There may be many more using it. Perhaps this > > should even be done on the 4.20 branch given how long this has been > > working? > > I am guessing you mean 4.21 which will be released in a couple of months > time, correct? As it is very simple to flip the default, I was thinking it might be worthwhile to change it on earlier versions too. After all it has actually been known to work for kind of a long time. > We have been discussing among the committers on whether we are ok to enable > ACPI despite the fact it is still not feature complete (see above). The > discussion is not fully finalized but if we were to enable CONFIG_ACPI=y by > default then I think we would need the following: > > * Select device-tree by default rather than ACPI > * Go through SUPPORT.MD and check what features we marked as SUPPORTED.md > but doesn't work on ACPI. > > Maybe you can help with that? I'm not sure this is a good role for me. I suppose I could do a first pass marking everything as non-ACPI. Problem is most recently I've been focussing on another aspect and I would mostly be guessing about things. > Out of interest, sorry if this was already mentioned before, is there any > reason ACPI is used on the Raspberry PI over Device-Tree? Is there any issue > with the latter on Xen? Issue is various Linux distributions have differing levels of support for various targets. Nearly everyone has some degree of support for Raspberry PI (even Tianocore!), but the quality does vary from distribution to distribution. My favored distribution is rather limited in what it does for !x86. Everything gets built for !x86, but things such as booting hasn't been heavily looked at. There is agreement using U-Boot/UEFI => GRUB would likely be a Good Thing, but there is a shortage of people with the right expertise to get that working. As a result booting Xen is troublesome. Whereas copying the Tianocore firmware into place and getting it booting is *extremely* simple. Further this has very few restrictions (GPT and a ~200MB FAT filesystem). Better yet once in place this is extremely robust. The only argument in favor of device-trees I've seen is that they're easy to deal with. Certainly they need little runtime processing. Yet they come with a major weakness that they're really part of the kernel. When the Linux kernel is replaced (even patch-level differences) you pretty well always need to replace the device-trees. Once you've done that it is quite difficult to go back to the earlier kernel. New device-trees often cause older kernels to panic or malfunction. If storage is on USB you can unplug and adjust on a nearby desktop, but this means you need to keep another system handy. Whereas due to being well isolated from the OS, the same set of ACPI tables works for many OSes and nearly all versions of Linux. The instances of ACPI tables which worked with Windows, but failed for other operating systems are quite famous. The instances where a given set of device-trees work with Linux, but then fail with other OSes (or even merely different version of Linux) are not notable. In fact instances where device-trees *don't* change drastically between kernel minor versions are newsworthy. > > The one remaining major issue was the state of EFI-FB support. There > > was a patch which had that working for Linux kernel 5.10, but that might > > need more work for a proper solution. > > Yes. And there was no interest from the other members to fix it properly. So > I gave up that on that work as I don't have a particular interest of using > FrameBuffer on the raspberry PI. Feel free to revive it and I would be happy > to review them. Uhm, I thought I had expressed a strong desire to have it operational. My knowledge of ACPI is rather limited, but I am well-setup for debugging ARM (unlike x86 which is intended for serious work). As mentioned by others it is kind of a popular platform. I dislike the thought of giving it special status merely due to that, but it is rather readily available. -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | ehem+sig...@m5p.com PGP 87145445 | ) / \_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
