Messages in this thread | | | From | Rob Herring <> | Date | Thu, 21 Jan 2021 11:09:08 -0600 | Subject | Re: [RFC PATCH 4/7] irqchip/apple-aic: Add support for Apple AIC |
| |
On Thu, Jan 21, 2021 at 9:31 AM Hector Martin 'marcan' <marcan@marcan.st> wrote: > > On 21/01/2021 19.37, Arnd Bergmann wrote: > > On Thu, Jan 21, 2021 at 10:48 AM Linus Walleij <linus.walleij@linaro.org> wrote: > >> > >> However weird it may seem, Apple is not in the file > >> Documentation/devicetree/bindings/vendor-prefixes.yaml > > > > Since Apple are already using both the "AAPL" and the "apple" > > prefix themselves, I have a bad feeling about reusing either of > > them for defining the devicetree.org bindings that we add to > > linux/Documentation/devicetree/bindings. The question is: if > > not "apple", what else should we use here? > > This ties into the larger question of how we should handle devicetrees > in general on these platforms. > > The two extremes are: > > 1) Have the bootloader outright convert ADT to FDT and make Linux > support the entirety of Apple's devicetree structure, or > > 2) Maintain our own devicetrees and ignore Apple's entirely > > My feeling is that 1) is a non-starter, because Linux ARM device trees > and Apple ARM device trees have seen independent evolution from the > PowerPC era, and many details are completely different. Plus conversion > is non-trivial, because the endianness is different and the format is > too ambiguous to do programmatically without complex logic.
You are right it's a non-starter. Apple's DT even from PowerPC days were weird and the hardware was much simpler then. Given we're still maintaining that code I don't care to add what they've evolved on their own over the last 15 years and support it for the next 20+ years (given folks notice when we break 1998 era Macs).
> On the other hand, cranking out devicetrees by hand for every device > variant that Apple puts out is a waste of time. > > Obviously at the bare minimum the bootloader will need to move some > dynamic information from the ADT to the FDT, but that can be a very > specific set of properties (memory layout, MAC addresses, etc). > > My current thinking is that we should write offline, automated tooling > to parse, diff, and automatically convert portions of Apple devicetrees > into Linux ones. Then we can more easily maintain our own, but still > ultimately have humans decide what goes into the Linux device trees.
Seems reasonable.
> It's worth noting that AIUI Apple does not consider their devicetree > layout to be stable, and it may change any time.
Yeah, also not something we want to support.
> On M1 devices, the > devicetree is provided as part of the iBoot2 firmware bundle, which > means it changes from one macOS version to the next (this is paired with > the Darwin kernel itself, and they are upgraded as a unit). It includes > placeholder values that iBoot2 then replaces with data from NOR before > handing control over to the kernel. My goal for our long-term project > [1] is to keep up with iBoot2 updates so that we do not have to instruct > users to dig up old macOS versions. > > Quick TL;DR on how these things boot: > - Boot ROM boots > - iBoot1 (system firmware) in NOR flash which looks for a bootable OS in > internal storage (only!) in the form of an APFS container+volume and > then boots > - iBoot2 (OS loader) which loads a bunch of firmware blobs and the > devicetree off of storage, customizes it with system data from NOR, and > then loads a wrapped mach-o file containing > - A Darwin kernel, or in our case a Linux bootloader which then boots > - A standard arm64 Linux blob > > The boot ROM is ROM. iBoot1 only ever rolls forward (downgrades > impossible). iBoot2 downgrades are possible but Apple already proved > they can break this willingly or not, at least in betas (macOS 11.2 > Beta2 iBoot1 cannot boot Beta1 iBoot2). The secureboot chain goes all > the way up to the mach-o kernel load, that is the first point where we > can change boot policy to load anything we want (with user consent). > > [1] https://asahilinux.org/ > > -- > Hector Martin "marcan" (marcan@marcan.st) > Public Key: https://mrcn.st/pub > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
| |