lkml.org 
[lkml]   [2021]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC PATCH 4/7] irqchip/apple-aic: Add support for Apple AIC
Date
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.

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.

It's worth noting that AIUI Apple does not consider their devicetree
layout to be stable, and it may change any time. 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

\
 
 \ /
  Last update: 2021-01-21 16:32    [W:0.088 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site