From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 59E1BC433E9 for ; Thu, 21 Jan 2021 15:31:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0F85B23A1C for ; Thu, 21 Jan 2021 15:31:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733027AbhAUPbr (ORCPT ); Thu, 21 Jan 2021 10:31:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37590 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732158AbhAUPaq (ORCPT ); Thu, 21 Jan 2021 10:30:46 -0500 Received: from mail.marcansoft.com (marcansoft.com [IPv6:2a01:298:fe:f::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2732FC06174A for ; Thu, 21 Jan 2021 07:30:05 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: marcan@marcan.st) by mail.marcansoft.com (Postfix) with ESMTPSA id 3E7D4419AD; Thu, 21 Jan 2021 15:30:01 +0000 (UTC) To: Arnd Bergmann , Linus Walleij Cc: Mohamed Mediouni , Mark Rutland , Catalin Marinas , "linux-kernel@vger.kernel.org" , Marc Zyngier , Will Deacon , Linux ARM , Stan Skowronek References: <20210120132717.395873-1-mohamed.mediouni@caramail.com> <20210120132717.395873-5-mohamed.mediouni@caramail.com> From: Hector Martin 'marcan' Subject: Re: [RFC PATCH 4/7] irqchip/apple-aic: Add support for Apple AIC Message-ID: Date: Fri, 22 Jan 2021 00:29:58 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: es-ES Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 21/01/2021 19.37, Arnd Bergmann wrote: > On Thu, Jan 21, 2021 at 10:48 AM Linus Walleij 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 82C09C433E6 for ; Thu, 21 Jan 2021 15:31:51 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2B79523A1E for ; Thu, 21 Jan 2021 15:31:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2B79523A1E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=marcan.st Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:Subject: From:References:To:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=jmUKDMwiWrwWQaWBhOvxk4KsbDbpRLXFT4Yrvgkgfd8=; b=Bac5fUyeE4BnNjQhk86QCM6xP UcgTZ8TW6rcijM+gki3hRZER2fTS+eq13GO4Xzd73kCEQ/UfuBuOLQVl7G4ZLc44NcPkZfQtHZyb/ HAET1Jwbdd0QophTDv/kfITNKkMy731O5f4+1OHTbQajvmAmXJN+tb7E9Evzq1qH37ChIvsrR1+3c HPE5Oyo0FLWbBdbkcwbza4slIPNarw+wYG/rsPogeHzLk09MlaG1IjHMoC2mLGS8b+Js602xptKou apCaU05W7GA1lXkug49nLia0U8FkBjZdvUIuDUHWFT5ksvuEKPgPUKvKZpD7frVBKAH/gq7n/8UFC obbRpr0Aw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l2buV-0006Wu-Fd; Thu, 21 Jan 2021 15:30:11 +0000 Received: from marcansoft.com ([212.63.210.85] helo=mail.marcansoft.com) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l2buS-0006Vc-Vv for linux-arm-kernel@lists.infradead.org; Thu, 21 Jan 2021 15:30:10 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: marcan@marcan.st) by mail.marcansoft.com (Postfix) with ESMTPSA id 3E7D4419AD; Thu, 21 Jan 2021 15:30:01 +0000 (UTC) To: Arnd Bergmann , Linus Walleij References: <20210120132717.395873-1-mohamed.mediouni@caramail.com> <20210120132717.395873-5-mohamed.mediouni@caramail.com> From: Hector Martin 'marcan' Subject: Re: [RFC PATCH 4/7] irqchip/apple-aic: Add support for Apple AIC Message-ID: Date: Fri, 22 Jan 2021 00:29:58 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Language: es-ES X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210121_103009_152755_C3DD917A X-CRM114-Status: GOOD ( 21.44 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Marc Zyngier , "linux-kernel@vger.kernel.org" , Catalin Marinas , Mohamed Mediouni , Will Deacon , Linux ARM , Stan Skowronek Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 21/01/2021 19.37, Arnd Bergmann wrote: > On Thu, Jan 21, 2021 at 10:48 AM Linus Walleij 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel