From: Rob Herring <robh@kernel.org>
To: "Hector Martin 'marcan'" <marcan@marcan.st>
Cc: Mark Rutland <mark.rutland@arm.com>,
Arnd Bergmann <arnd@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Linus Walleij <linus.walleij@linaro.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Marc Zyngier <maz@kernel.org>,
Mohamed Mediouni <mohamed.mediouni@caramail.com>,
Will Deacon <will@kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Stan Skowronek <stan@corellium.com>
Subject: Re: [RFC PATCH 4/7] irqchip/apple-aic: Add support for Apple AIC
Date: Thu, 21 Jan 2021 11:09:08 -0600 [thread overview]
Message-ID: <CAL_JsqKNcEd=WGYKcecwTSu=L_KY9HYiqJnsmRMFfo3geXLQbQ@mail.gmail.com> (raw)
In-Reply-To: <d0eedc9e-2412-048a-9c7c-1e4a79aadb3b@marcan.st>
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-01-21 17:11 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-20 13:27 [RFC PATCH 0/7] Linux on Apple Silicon Mohamed Mediouni
2021-01-20 13:27 ` [RFC PATCH 1/7] arm64: kernel: FIQ support Mohamed Mediouni
2021-01-20 13:27 ` [RFC PATCH 2/7] arm64: kernel: Add a WFI hook Mohamed Mediouni
2021-01-20 16:46 ` Alexander Graf
[not found] ` <94C20F55-D3B8-4349-B26F-9EA8AAEBF639@caramail.com>
2021-01-21 12:33 ` Hector Martin 'marcan'
2021-01-21 10:52 ` Arnd Bergmann
2021-01-21 11:01 ` Mohamed Mediouni
2021-01-21 11:36 ` Arnd Bergmann
2021-01-20 13:27 ` [RFC PATCH 3/7] arm64: mm: use nGnRnE instead of nGnRE on Apple processors Mohamed Mediouni
2021-01-20 16:47 ` Alexander Graf
2021-01-20 18:06 ` Mohamed Mediouni
2021-01-20 18:10 ` Alexander Graf
2021-01-21 11:27 ` Will Deacon
2021-01-21 11:38 ` Arnd Bergmann
2021-01-21 11:44 ` Marc Zyngier
2021-01-21 12:47 ` Will Deacon
2021-01-21 15:12 ` Mohamed Mediouni
2021-01-21 16:25 ` Marc Zyngier
2021-01-21 17:55 ` Will Deacon
2021-01-21 18:15 ` Marc Zyngier
2021-01-21 18:22 ` Mohamed Mediouni
2021-01-21 18:22 ` Will Deacon
2021-01-20 13:27 ` [RFC PATCH 4/7] irqchip/apple-aic: Add support for Apple AIC Mohamed Mediouni
2021-01-20 17:11 ` Alexander Graf
2021-01-20 18:04 ` Mohamed Mediouni
2021-01-20 20:16 ` Andrew Lunn
2021-01-20 21:18 ` Stan Skowronek
2021-01-21 9:48 ` Linus Walleij
2021-01-21 10:37 ` Arnd Bergmann
2021-01-21 15:29 ` Hector Martin 'marcan'
2021-01-21 17:09 ` Rob Herring [this message]
2021-01-21 17:45 ` Rob Herring
2021-01-21 16:44 ` Rob Herring
2021-01-21 16:53 ` Hector Martin 'marcan'
2021-01-20 13:27 ` [RFC PATCH 5/7] arm64/Kconfig: Add Apple Silicon SoC platform Mohamed Mediouni
2021-01-20 13:27 ` [RFC PATCH 6/7] arm64: kernel: Apple CPU start driver Mohamed Mediouni
2021-01-21 11:14 ` Arnd Bergmann
2021-01-20 13:27 ` [RFC PATCH 7/7] irqchip/apple-aic: add SMP support to the Apple AIC driver Mohamed Mediouni
2021-01-21 12:44 ` Arnd Bergmann
2021-01-21 12:50 ` Mohamed Mediouni
2021-01-21 13:00 ` Arnd Bergmann
2021-01-21 13:01 ` Hector Martin 'marcan'
2021-01-21 13:22 ` Marc Zyngier
2021-01-21 13:32 ` Mark Rutland
2021-01-21 14:05 ` Marc Zyngier
2021-01-21 13:34 ` Mohamed Mediouni
2021-01-21 14:10 ` Marc Zyngier
2021-01-21 15:09 ` Arnd Bergmann
2021-01-21 15:18 ` Mohamed Mediouni
2021-01-21 16:40 ` Rob Herring
2021-01-21 16:43 ` Mohamed Mediouni
2021-01-21 17:37 ` Rob Herring
2021-01-21 18:08 ` Mohamed Mediouni
2021-01-21 18:57 ` Rob Herring
2021-02-02 19:15 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAL_JsqKNcEd=WGYKcecwTSu=L_KY9HYiqJnsmRMFfo3geXLQbQ@mail.gmail.com' \
--to=robh@kernel.org \
--cc=arnd@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcan@marcan.st \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=mohamed.mediouni@caramail.com \
--cc=stan@corellium.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).