marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
klaus has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
amw has quit [Ping timeout: 265 seconds]
marshmallow has quit [Ping timeout: 272 seconds]
marshmallow has joined #asahi
phiologe has quit [Ping timeout: 260 seconds]
phiologe has joined #asahi
Tokamak has quit [Ping timeout: 246 seconds]
Tokamak has joined #asahi
marvin24 has quit [Ping timeout: 240 seconds]
marvin24 has joined #asahi
Tokamak has quit [Ping timeout: 240 seconds]
Tokamak has joined #asahi
Tokamak has quit [Remote host closed the connection]
Tokamak has joined #asahi
VinDuv has joined #asahi
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
klaus has joined #asahi
maor26 has joined #asahi
thestr4ng3r has joined #asahi
thestr4ng3r_ has quit [Ping timeout: 256 seconds]
<arnd>
never_released: indeed, most of the setup code looks like it should just go into the bootloader, there is no reason for Linux to care about that. For a lot of SoCs, we end up with that stuff in the driver so we can support devices that ship with an unknown bootloader, but if we can just modify the loader here there is no need for that
Bublik has quit [Ping timeout: 272 seconds]
<Fanfwe>
So, according to Tom's hardware's article from 3 days ago about the Apple M1, "Apple’s I2C has a custom firmware that uses an exclusive protocol, which thwarted using the USB Type-A ports." lol
jkao[m] has quit [Quit: Idle for 30+ days]
fl35[m] has quit [Quit: Idle for 30+ days]
hotsndot[m] has quit [Quit: Idle for 30+ days]
Tokamak has joined #asahi
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<marcan>
lolwut
<marcan>
arnd: I want to bring up as much PHY stuff as I can in m1n1, to avoid pushing those hideous register poke blobs downstream into the linux fdt
<marcan>
but yeah that depends on how deep a sleep we go into and how much state is lost in that case
<marcan>
this is m1n1's entire reason to exist, to take care of as many apple-isms as it can before handing off to linux, u-boot, or whatever
<marcan>
given how macos lasts for ages on battery... if it isn't ever going into deep enough sleep to need those PHY reinits, then I say we don't need to either
<marcan>
I think part of apple's motivation for pushing all that crap into macos is simply to keep iBoot small and simple, because it's a higher security boundary - not because it *has* to be macos doing these things
<marcan>
but we should be able to introduce this at a later stage anyway; no deep sleep for now, if it turns out we need phy blobs to resume from deep sleep states we want to use, we make m1n1 pass those through, and until then this keeps the drivers and DT bindings simpler and more reviewable for the initial versions
bostjan has joined #asahi
bgb has joined #asahi
bgb has quit [Ping timeout: 256 seconds]
acelogic has quit [Remote host closed the connection]
KindOne has quit [Ping timeout: 272 seconds]
KindOne has joined #asahi
klaus has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
klaus has joined #asahi
bostjan has quit [Quit: Leaving]
<kettenis>
marcan: that might work as long as m1n1 will continue to do this even if you pass on the blobs
<kettenis>
but it means you'll have to deal with clock (un)gating in m1n1
<never_released>
kettenis: the PCIe controller on M1 Macs provides an ECAM
<never_released>
so you might even be able to get away without a driver
<kettenis>
never_released: yes
<kettenis>
the AIC would ave to handle MSIs though like arnd suggested
<modwizcode>
Question about SMP startup, from M1N1's code it seems that there's some sort of power management control interface and there's a register you can write to set the reset vectors for each core, and another two registers for poking the cores to start, and a third that maybe ungates the IRQs is that accurate?
<modwizcode>
I emulated a (slightly wrong) but functional copy of something doing that but I still had to hack up the code in M1N1 a bit, but I get SMP startup. Linux breaks though I think I need to connect all of the cores timer's to their FIQ inputs not just one of the cores.
<never_released>
the reset address is locked by iBoot
<marcan>
never_released: only for the boot core
<marcan>
which is already running
<marcan>
which makes it irrelevant
<never_released>
you can turn off the boot core
<never_released>
it's not irrelevant
<modwizcode>
Turning off CPUs is what I was going to ask about
<modwizcode>
does clearing the bits in the turn on register turn them off
<marcan>
can you? why would you ever do that?
<marcan>
these cores support retention wfi
<marcan>
which power gates the core but when it comes back it keeps pc/sp
<never_released>
marcan: retention WFI is when you turn off a core individually
<never_released>
but you can turn off a whole complex
<never_released>
(which preserves 0 state)
<modwizcode>
Does retention WFI only keep PC/SP and no other registers?
<marcan>
modwizcode: yes
<marcan>
never_released: does macos ever actually do that for the e-complex?
<modwizcode>
yes on clearing the bit or yes about the registers
<marcan>
modwizcode: the registers
<never_released>
note
<marcan>
but you can configure it to only clock gate, and then it keeps state
<never_released>
that it's not always
choozy has joined #asahi
<never_released>
it's an heuristic somewhere, not guaranteed that the registers are wiped
<marcan>
there are three settings
<marcan>
always power down, never power down, let the heuristic decide
<modwizcode>
Interesting
<marcan>
m1n1 sets it to never power down, so linux doesn't need any weirdo wfi hook like corellium did
<marcan>
and then a cpuidle driver can set it to always or heuristic, and deal with it there
<modwizcode>
That's kind of strange though, how would you handle that inconsitency with the heuristic? Wouldn't you have to assume it lost state in case it did?
<marcan>
it checks
<modwizcode>
Oh it can check
<marcan>
if lr == 0, it knows it was deep
<modwizcode>
Ohhhh
<marcan>
otherwise it can just return
<modwizcode>
that's simple of courase
<modwizcode>
Do we know anything besides what the dev tree tells us about memory map?
<modwizcode>
Like is ROM mapped at 0 or is that kind of thing pulled out of the address space after startup
<modwizcode>
(if it was ever mapped in)
<never_released>
modwizcode: you don't have access to ROM
<never_released>
unmapped
<never_released>
permanently so
<modwizcode>
Well that's probably ideal for my needs then
<modwizcode>
I've been meaning to look into how suspend-to-ram is implemented.
<clover[m]>
is it S3? (ACPI)
<jn__>
there's no ACPI in apple firmware/software on the M1
<clover[m]>
Trusted Firmware-A can implement suspend-to-ram via PSCI (ARM power state coordination interface)
<j`ey>
no PSCI either
zopieux has quit [Quit: zopieux]
<modwizcode>
What was the deal with alternate SMP startup methods on linux?
<j`ey>
psci vs spin-table?
<modwizcode>
yeah
<modwizcode>
There was a mention of it on the mailing list
<modwizcode>
but the M1 doesn't have PSCI...
<modwizcode>
But I saw a patch to linux about emulating it or something weird. Didn't fully parse the code out to figure it out
<clover[m]>
could m1 be ported to use TF-A?
<j`ey>
there was some mention of some EFI related stuff, that Ard wrote a patch for, but I didn't look at it either
<modwizcode>
It doesn't have EL3
<modwizcode>
Yeah the UEFI mention seemed a little annoying tbh
<modwizcode>
not sure why it would matter with a platform like this that doesn't need UEFI in the pipeline
Bublik has quit [Ping timeout: 272 seconds]
<clover[m]>
do we understand how macOS pulls off deep sleep?
<kettenis>
I don't see why psci-as-a-firmware-call should be tied to UEFI
<kettenis>
a device tree binding that provides the entry point that lives in memory reserved by the bootloader (m1n1) would work just as well
<kettenis>
but I don't see a benefit over using spin-table unless m1n1 would want to implement other psci functionality
<clover[m]>
does psci-as-a-firmware call necessarily need to be tied to TF-A?
<clover[m]>
a device tree binding that provides the entry point that lives in memory reserved by the bootloader (levinboot) might work just as well
<kettenis>
psci was never tied to TF-A
<never_released>
PSCI can't be in the same exception level as the OS
<kettenis>
U-Boot provides an implementation for some boards
<never_released>
that's the catch
<never_released>
on 🍎M1, PSCI would mean running the OS at EL1 instead of EL2
<never_released>
(because no EL3 in HW)
<never_released>
that's possible? Yes. Is that sane? No.
<kettenis>
indeed you either need smc which implies EL3 or hvc which implies EL2
<never_released>
because you lose virt
<modwizcode>
This is basically what I thought
<never_released>
maybe arm64 needs some kind of PALcode
<never_released>
but too late for that now I'd bet
<modwizcode>
PALcode?
<never_released>
modwizcode: > PALcode (Privileged Architecture Library code) is the name used by DEC for a set of functions in the SRM or AlphaBIOS firmware, providing a hardware abstraction layer for system software, covering features such as cache management, translation lookaside buffer (TLB) miss handling, interrupt handling and exception handling
Tokamak has joined #asahi
<never_released>
so that it's abstracted away in an SW layer
ys0seri0us has joined #asahi
Tokamak_ has joined #asahi
Tokamak has quit [Ping timeout: 246 seconds]
zopieux has joined #asahi
<marcan>
modwizcode: there was some talk on #armlinux about implementing PSCI over UEFI
<marcan>
I might look into trying that out if the scaffolding required isn't too much trouble
<never_released>
marcan: it's not too much trouble imo
<never_released>
looked at implementing it
<never_released>
I'd just like it to be a standard instead of a thing cooked for Apple Si
<marcan>
it's intended to be standard (on linux at least), AIUI
<never_released>
as other SoC makers will look at it and want to use such an interface afterwards
<marcan>
well for SoCs with EL3 they already have it anyway
<never_released>
I meant for a new PSCI conduit over UEFI
<never_released>
should be standardised somewhere
<never_released>
wait, will talk about it with arm folks
<marcan>
I'd be happy to have something standard-ish like that that m1n1 can provide, because then we can hide even more nonsense away from linux, like proper full suspend and dealing with initialization functions on resume
<never_released>
marcan: there's also a new upcoming ECAM over PSCI interface for PCIe
<marcan>
doing all confing accesses over PSCI?
<marcan>
-n
<never_released>
more geared towards ECAM accesses
<never_released>
used to workaround hardware erratas
<marcan>
kettenis: u-boot provides UEFI, right? can it enhance an existing UEFI implementation, i.e. add services?
<marcan>
(how much of UEFI does it do?)
<never_released>
marcan: it is the UEFI implementation
<never_released>
a pretty basic one without acpi
<never_released>
but runs Grub fine
ys0seri0us has quit [Ping timeout: 240 seconds]
<marcan>
I'm wondering if I can e.g. provide all the hardware-related init stuff in m1n1, then let u-boot provide the boot sequence and disk/FS services
<never_released>
I mean
<never_released>
why not have it as a U-Boot SPL
<marcan>
sure, but m1n1 already exists
<marcan>
I mean if you want to throw all the code into SPL, that works too
<marcan>
but it's not like 3-bootloader chains are rare on arm
<marcan>
and it gives us some flexibility while avoiding duplication of responsibilities
<never_released>
at the end, m1n1 should never launch a kernel directly
<marcan>
for most users, probably not
<never_released>
but be just a stub for u-boot/tianocore/whatever
<bylaws>
<never_released "used to workaround hardware erra"> Stuff like that bug on t194?
<modwizcode>
Initially it seemed you were opposed to uboot in some ways?
<marcan>
but it should be *capable* of doing that :)
<never_released>
bylaws: Yes. t194 was one of the reasons for it being created.
<marcan>
modwizcode: me?
<modwizcode>
yeah
<marcan>
not at all
<marcan>
I said I don't want to have u-boot as a hard dependency in order to boot linux *at all* because being tied to piles of bootloader code makes it harder to do back to basics tests and I do like being able to throw kernels at m1n1 and play around in a small codebase
<marcan>
but I very much expect the production version of Asahi Linux to end up looking like m1n1 -> u-boot -> grub -> kernel, for end user installs
<marcan>
or something along those lines
<modwizcode>
I guess the problem with long bootloader chains is more points of failure, and more complexity
<marcan>
well, kind of, but the thing is it also makes it more modular
<marcan>
which makes it easier to debug the next stage by loading at the previous one
<never_released>
and you'll need a bunch of complexity anyway
<never_released>
for NVMe, FS access
<never_released>
and such
<marcan>
e.g. m1n1 makes an excellent "boot and throw things at it via serial" loader, for almost literally anything because of the python rpc interface
<modwizcode>
Does NVMe offer no simplified storage access protocol?
<never_released>
in practice, almost no one has serial, marcan
<marcan>
never_released: I'll be fixing that next week
<marcan>
also plenty of people have two M1s
<modwizcode>
Serial is helpful for qemu work c;
<marcan>
I actually want to try writing a minimal NVMe driver, I don't expect it to be that hard?
<marcan>
most "complex" devices are only complex to implement all features of
<kettenis>
marcan: U-Boot already does too much UEFI ;)
vilhalmer has quit [Read error: Connection reset by peer]
<never_released>
kettenis: it does too little UEFI :P
<modwizcode>
I guess the complexity for NVMe I'm assuming is that I assumed you have to get PCIe working
<never_released>
to the extent that ACPI is part of UEFI
<never_released>
modwizcode: NVMe isn't over PCIe of those
<never_released>
*on
<marcan>
modwizcode: it's not PCIe
<modwizcode>
it's not related at all then?
<marcan>
not at all
<modwizcode>
Okay I've been misled
<winocm>
oh man, ghettohci
<marcan>
unless you're running a corellium kernel, then it's PCIe because they faked a PCIe bus for it
<winocm>
that’s nostalgic
<marcan>
which is completely insane
<modwizcode>
what the heck is this file
<modwizcode>
lmao
<modwizcode>
I don't think I've ever seen this
<marcan>
:D
<winocm>
wii
<winocm>
u
<modwizcode>
Yeah but is this even
<modwizcode>
ohhh
<winocm>
I think
vilhalmer has joined #asahi
<modwizcode>
It's not in the orig wii repo I don't think
<marcan>
we used that on the Wii U to get mini (yes the same python RPC protocol and codebase as m1n1) working
<modwizcode>
(I've only ever paid much attention to that because I never had a Wii u
<marcan>
because there was no good debug port
<marcan>
no serial
<modwizcode>
interesting
<modwizcode>
That's annoying having to do a USB stack to get anything
<marcan>
so the first version was output only
<marcan>
it bitbanged RS-232 over the sensor bar
<marcan>
as in turning it on and off
<modwizcode>
LOL I remember reading about that I think
<marcan>
then I debugged that ghettohci thing using that
<marcan>
;-)
<modwizcode>
When I read about the Wii stuff the thing I'm most amazed about is finding the test points for the gpios and mapping them back to a register :p
<modwizcode>
Anyway that's offtopic, but NVMe isn't PCIe based good to know
vilhalmer has quit [Read error: Connection reset by peer]
<marcan>
I'll be adding a platform/DT binding for the NVMe driver once I get to that, shouldn't be hard
<marcan>
then we can instantiate it properly
<marcan>
same as every other driver that has both versions, e.g. xHCI
<modwizcode>
Do you expect it to be fairly similar to other NVMe stuff? Or completely different?
<marcan>
it's the standard apple nvme
<marcan>
which linux already has quirk workarounds for
<marcan>
just not over PCI
<marcan>
not sure if there are any other quirks, if there are they should be trivial to work around
<modwizcode>
I'm thinking about if I'll be able to reuse the NVMe code in qemu :p
<modwizcode>
storage code is like a different area with concerns I've not paid attention to yet
vilhalmer has joined #asahi
vilhalmer has quit [Read error: Connection reset by peer]
<marcan>
would need to implement the same quirks
<marcan>
it shouldn't be hard
<modwizcode>
cool
<marcan>
mostly just the queue entry size is doubled IIRC
<marcan>
the other quirks probably don't affect an emulator
vilhalmer has joined #asahi
<modwizcode>
For most quirk stuff I just need to stub stuff out so code doesn't complain (i.e. all the HID registers are mostly stubbed to zero, but I expect I'll have to emulate a writable reg for things that readback the value (m1n1 doesn't))
<modwizcode>
Incidentally where did you pull the reg definitions for spinning up cores from?
<marcan>
the reg addresses come from the adt
<modwizcode>
Yeah but the offsets
<marcan>
the what reg does what is, well, corellium code, which I treated as vendor code
<modwizcode>
got it
<marcan>
i.e. I broke it down and figured out what i needed and what I didn't
<modwizcode>
Are you planning to write docs for it anywhere? (at least defining the offsets?)
<marcan>
yeah
<marcan>
I want to write docs for everything, and anyone is welcome to poke me to write docs about any specific thing they need because that'll encourage me to do so
<modwizcode>
I have enough hacked together to boot linux with a version of m1n1 that doesn't pull the addresses from the ADT but it's not modeled after hardware at all
vilhalmer has quit [Read error: Connection reset by peer]
<marcan>
just need to allocate time to it
<marcan>
eventually ideally we should have fairly comprehensive SoC docs
<modwizcode>
I'd appreciate NVMe and the SMP bringup docs.
<modwizcode>
I'm hoping the QEMU code will generally be well documented enough to have full docs embedded
<modwizcode>
most of QEMU doesn't do that and it sucks
<marcan>
what I know about SMP is trivial so far, let me infodump on wiki real quick
<marcan>
also feel free to rewrite/reformat whatever
<kettenis>
marcan: I don't think it makes sense for m1n1 to do UEFI stuff itself
<kettenis>
if it would implement a PSCI interface it should just advertise it in the device tree
<kettenis>
and have U-Boot or tianocore expose it in a UEFI table
<never_released>
kettenis: should be part of the UEFI itself
<never_released>
as a set of runtime services functions
<never_released>
don't think that m1n1 is the right place for it, would end with oddball hacks
<never_released>
whereas the UEFI runtime services region is already mapped
<Glanzmann>
marcan: I read in the backlog that NVMe is not over PCIe on M1. What I/O bus do they use? Do you know anything about the Sound card used in the M1 models?
<Glanzmann>
Does someone know if palm detection is done in the kernel or in userland on Linux for the touchpad?
raster has joined #asahi
<Glanzmann>
marcan: I'm also using thinkpad usb keyboards. Luckily none failed so far. I also have a bluetooth one.
<modwizcode>
Glanzwmann: Last I knew I think palm detection was done in the kernel in the hid stuff but that's changed a lot since the last time I messed with it so it might be raw hid with a userspace driver
<modwizcode>
also I would assume the NVMe controller is just directly accessible off the memory as MMIO rather than being tunneled through pcie
<modwizcode>
marcan: thanks
<modwizcode>
Wonder what WLAN debug is
<marcan>
probably literally what it says on the tin...
<marcan>
debug output from the broadcom firmware I presume
<modwizcode>
Ah I forget that WLAN chipsets actually like run a whole freaking OS
<modwizcode>
I'm not sure how I feel about that :/
<marcan>
it's fullmac, and also custom stuff (it'll have proprietary stuff for AirDrop I bet...)
<modwizcode>
You think AirDrop is something proprietary in the WLAN? I bet it's just normal Wifi Direct/P2P with a special broadcast format that's generic
<opticron>
yeah, there was an airdrop on linux implementation floating around, iirc
<modwizcode>
that's pretty neat, might be interesting to poke at. No idea why Google can't get this right Wifi direct is pretty easy
<opticron>
one special thing that's necessary is apparently active monitor mode
<opticron>
only some wifi cards support it
<marcan>
modwizcode: it's proprietary
<marcan>
(AWDL)
<marcan>
I mean of course it's over the WiFi physical layer
<davidrysk[m]>
yeah someone recently RE'd it (which is what opticron linked)
<davidrysk[m]>
but indeed it is proprietary, built on standards, apparently the standards aren't good enough to be reliable
<modwizcode>
I bet the issue is the polling/discovery time for existing stuff. A lot of stuff on android uses bluetooth based discovery with Wifi data transfer which is the worst possible option
<modwizcode>
I just was assuming it's a featureset supported by generic controllers but I guess not, what's AWDL?
zopieux has quit [Ping timeout: 265 seconds]
zopieux has joined #asahi
<marcan>
just some protocol Apple cooked up (Apple Wireless Direct Link?)
<arnd>
The approach that ardb came up with for psci over the uefi runtime interface would definitely be intended to run in u-boot, and not rely on having tianocore or something along those lines. As far as I understand it could actually be implemented in m1n1 as well, without doing any other parts of UEFI
<arnd>
it's a bit of a hack, but probably enough to get things running until everyone has moved to u-boot for their boot flow
<arnd>
my first suggestion was to do something more like RTAS in powerpc open firmware, which has a different way of calling into firmware code based on DT properties, but I do prefer ardb's solution since it uses a callback interface that is already established on arm firmware, just not yet for psci
<arnd>
I also thought about what it would take to route PCI config space through that for the NVMe drive. It would probably work, but I'd rather have a simple platform driver in the kernel for this one than to hack up a PCI host in firmware for the sake of making an unmodified Linux driver work
<arnd>
I remember doing PCI config space over RTAS on powerpc, and I always wondered why the arm server folks that use ACPI haven't done it yet, but as the M1 only has one device behind it, there is really point
<never_released>
arnd: depends
<never_released>
minimal kernel work required could be a goal
<arnd>
For other OSs certainly: if you want to run Windows, that would be helpful. For Linux I prefer doing it right
<never_released>
arnd: I'd prefer all the OSes to share the same stack there
<never_released>
not this FW for Linux, this other FW for X and this other one for Y
<arnd>
not going to happen anyway: windows and RHEL rely on ACPI, and for normal Linux we want a sane abstraction
<never_released>
PSCI has already an upcoming PCIe config space conduit
<never_released>
what it'd look like basically is it being a PSCI conduit in addition to hvc and smc ones
<arnd>
What I could see though would be an EL2 wrapper that runs tianocore and provides a SBSA/SBBR style environment for booting unmodified operating systems, with an emulated GIC, pl011, PCI mmconfig, and (if you want to go wild) virtio-net and shadow page tables for 64kb pages
<never_released>
arnd: or even more insane
<never_released>
exploiting guarded execution
<never_released>
remember that we have GL2 in parallel of EL2
<arnd>
I don't remember what that does
<never_released>
security feature, a set of rings in parallel used for PPL notably
<never_released>
(Page Protection Layer)
<never_released>
GL1 for guest OSes (at EL1) and GL2 for host OS (at EL2)
<never_released>
has its own exception vectors of course
<arnd>
ah, so they do have a higher privilege level than EL2 but just didn't want to be compatible with Trustzone/EL3? I can't say I blame them ;-)
<never_released>
arnd: they had EL3 on the Apple A7 to Apple A9
<never_released>
then dropped that to only have EL1 and EL0
<never_released>
A13 added guarded exec
<never_released>
and then A14/M1 added... EL2 and 4KB page support (which was there in Apple A7 and A8, dropped in A9)
<never_released>
they also dropped big endian in user-mode on A10... A7-A9 had big endian at EL0 only
vilhalmer has joined #asahi
<kettenis>
well, IMNSHO Red Hat choosing not to support device trees in RHEL is their problem
vilhalmer has quit [Read error: Connection reset by peer]
vilhalmer has joined #asahi
<modwizcode>
I thought it extremely strange that ARM (and previously open firmware stuff) successfully met their needs via device tree seemingly just fine, and then later ACPI was reintroduced for... some unclear reason. (I'm sure there's a real reason but I've not seen it explained anywhere)
<never_released>
modwizcode: same FW everywhere
<never_released>
it's an absolute requirement for Windows
<never_released>
and DT was underspecified a lot
<never_released>
and is still not _that_ stable
<modwizcode>
I think I asked about this before, but is there any documentation of what the heck GL1/2 actually do? (and why they're special?). I've read all the docs I can find about PPL and APRR (which I think is mostly unrelated) but guarded execution seems to be a totally undocumented thing so far?
<modwizcode>
never_released: I mean I don't see why windows can't learn to deal with DT
<never_released>
modwizcode: technical reasons
<never_released>
Windows is tightly bound to ACPI
<never_released>
since ages now
<modwizcode>
:/
vilhalmer has quit [Read error: Connection reset by peer]
vilhalmer has joined #asahi
vilhalmer has quit [Read error: Connection reset by peer]
vilhalmer has joined #asahi
<arnd>
25 years since Windows NT for PowerPC used an Open Firmware device tree ;-)
raster has quit [Quit: Gettin' stinky!]
<krbtgt>
NT on PPC used ARC, not OF
<krbtgt>
the tl;dr on windows' dependence on EFI/ACPI is that NT actually mandates ARC from the beginning
<krbtgt>
NTLDR.COM? that's actually an ARC emulator for BIOS
<krbtgt>
there's a shim bootloader for ARC on OF on PPC
<krbtgt>
and NT had a bunch of HALs but that's not relevant
<krbtgt>
anyways 2000 made it use ACPI optionally in HALs
<davidrysk[m]>
mjg59 has written at length regarding ACPI and Windows and how vendor assumptions make things difficult
<krbtgt>
vista mandates ACPI on all platforms, then some stuff happens in 8.x for the ARM platform superfund site (it mandates ACPI/EFI on ARM, just IIRC there's some "HAL extensions" that paper over interrupt controlleer differences, ask never_released)
<davidrysk[m]>
it's at the point where Linux has to claim to be Windows for the hardware to behave correctly (on most x86 systems)
<krbtgt>
i can't blame MS for that
<krbtgt>
but dumb OEMs
<never_released>
krbtgt: on Windows 8.0, you technically only needed an halext for the timer on arm
<never_released>
on 8.1, GTDT ACPI table for the timer
<never_released>
and no halexts needed
<davidrysk[m]>
never_released: why couldn't MS build out devicetree support for ARM64? The desire to placate OEMs?
<never_released>
for HW with arm arch timer + GIC
<never_released>
davidrysk[m]: it's a Linux only broken thing
<never_released>
sorry
<never_released>
it's not a standard
<never_released>
it's whatever Linux folks cooked on their side
<davidrysk[m]>
meanwhile ACPI is practically a Windows-only broken thing, and doesn't follow the standard in practice
<never_released>
davidrysk[m]: what?
<never_released>
Windows on Arm was booting with ACPI in 2007
<never_released>
choice was already set in stone by then
<never_released>
device tree came way too late for arm