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 B3865C4332E for ; Fri, 5 Mar 2021 11:14:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8555465022 for ; Fri, 5 Mar 2021 11:14:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229711AbhCELO2 (ORCPT ); Fri, 5 Mar 2021 06:14:28 -0500 Received: from marcansoft.com ([212.63.210.85]:52272 "EHLO mail.marcansoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229576AbhCELOX (ORCPT ); Fri, 5 Mar 2021 06:14:23 -0500 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 714C03FA1B; Fri, 5 Mar 2021 11:14:12 +0000 (UTC) To: Krzysztof Kozlowski , linux-arm-kernel@lists.infradead.org Cc: Marc Zyngier , Rob Herring , Arnd Bergmann , Olof Johansson , Mark Kettenis , Tony Lindgren , Mohamed Mediouni , Stan Skowronek , Alexander Graf , Will Deacon , Linus Walleij , Mark Rutland , Andy Shevchenko , Greg Kroah-Hartman , Jonathan Corbet , Catalin Marinas , Christoph Hellwig , "David S. Miller" , devicetree@vger.kernel.org, linux-serial@vger.kernel.org, linux-doc@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org References: <20210304213902.83903-1-marcan@marcan.st> <20210304213902.83903-28-marcan@marcan.st> From: Hector Martin Subject: Re: [RFT PATCH v3 27/27] arm64: apple: Add initial Apple Mac mini (M1, 2020) devicetree Message-ID: <2a4c461a-51d1-60b7-b698-edb3c0bfb243@marcan.st> Date: Fri, 5 Mar 2021 20:14:10 +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 05/03/2021 20.03, Krzysztof Kozlowski wrote: >> + memory@800000000 { >> + device_type = "memory"; >> + reg = <0x8 0 0x2 0>; /* To be filled by loader */ > > Shouldn't this be 0x800000000 with ~0x80000000 length (or whatever is > more common)? Or did I miss some ranges? The base model has 8GB of RAM, and RAM always starts at 0x800000000, hence that reg property. It's not actually useful to try to boot Linux like this, because it'll step all over device carveouts on both ends and break, but since those are potentially dynamic it doesn't really make sense to use a more specific example for the dts. E.g. on my system, with my current firmware version, this ends up getting patched to: reg = <0x8 0x0134c000 0x1 0xda294000> Thanks, -- Hector Martin (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.3 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 A11D0C433E0 for ; Fri, 5 Mar 2021 11:16:11 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 1396F64E6B for ; Fri, 5 Mar 2021 11:16:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1396F64E6B Authentication-Results: mail.kernel.org; dmarc=fail (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=desiato.20200630; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:Subject: From:References:Cc:To:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=LUOo4TbmPnTDllWeVmNS5hmAJDxS3lOiX45ote2Ro1M=; b=XUgUyknNnnuWn8xkcPS6GcMlZ kQbzbqufpOEX0SKw9PsigRx6wPu2JeX4tCA9cmhnkimDdnq5B66q5f5V6zsJ9zEGcnvFjrZSHLVNl zO8CiHoP+qLeDmr9PkaFRdoENKQhaIb90j4M4yR311ibcm2V8oL5jCES0JNUe/Dhal7astdeXBCSp IYAaiJnW4oCainjFPQWuXVS1UNR/oSnZhGWn5lrQGL6gQBOMsbLcoHfnrWlKH9DwjS+GQjgr93A39 R2QbENQfu/GZLvJyk75XFc+7aa4/S0M8HroqIlKHK2KDBH2WYRsFFbf1cM74papuIda5vGJkAnBvY SZjeV4W6A==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lI8Pb-00EiVU-Ri; Fri, 05 Mar 2021 11:14:27 +0000 Received: from marcansoft.com ([212.63.210.85] helo=mail.marcansoft.com) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lI8PT-00EiUE-O3 for linux-arm-kernel@lists.infradead.org; Fri, 05 Mar 2021 11:14:22 +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 714C03FA1B; Fri, 5 Mar 2021 11:14:12 +0000 (UTC) To: Krzysztof Kozlowski , linux-arm-kernel@lists.infradead.org Cc: Marc Zyngier , Rob Herring , Arnd Bergmann , Olof Johansson , Mark Kettenis , Tony Lindgren , Mohamed Mediouni , Stan Skowronek , Alexander Graf , Will Deacon , Linus Walleij , Mark Rutland , Andy Shevchenko , Greg Kroah-Hartman , Jonathan Corbet , Catalin Marinas , Christoph Hellwig , "David S. Miller" , devicetree@vger.kernel.org, linux-serial@vger.kernel.org, linux-doc@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org References: <20210304213902.83903-1-marcan@marcan.st> <20210304213902.83903-28-marcan@marcan.st> From: Hector Martin Subject: Re: [RFT PATCH v3 27/27] arm64: apple: Add initial Apple Mac mini (M1, 2020) devicetree Message-ID: <2a4c461a-51d1-60b7-b698-edb3c0bfb243@marcan.st> Date: Fri, 5 Mar 2021 20:14:10 +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-20210305_111420_986974_EFEBF763 X-CRM114-Status: GOOD ( 12.54 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 05/03/2021 20.03, Krzysztof Kozlowski wrote: >> + memory@800000000 { >> + device_type = "memory"; >> + reg = <0x8 0 0x2 0>; /* To be filled by loader */ > > Shouldn't this be 0x800000000 with ~0x80000000 length (or whatever is > more common)? Or did I miss some ranges? The base model has 8GB of RAM, and RAM always starts at 0x800000000, hence that reg property. It's not actually useful to try to boot Linux like this, because it'll step all over device carveouts on both ends and break, but since those are potentially dynamic it doesn't really make sense to use a more specific example for the dts. E.g. on my system, with my current firmware version, this ends up getting patched to: reg = <0x8 0x0134c000 0x1 0xda294000> Thanks, -- Hector Martin (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