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,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 9BFBCC4338F for ; Tue, 10 Aug 2021 11:44:49 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D6740604D7 for ; Tue, 10 Aug 2021 11:44:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D6740604D7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=xilinx.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 33A4F80405; Tue, 10 Aug 2021 13:44:46 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=xilinx.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=xilinx.onmicrosoft.com header.i=@xilinx.onmicrosoft.com header.b="dzy7wAEd"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 9025E80405; Tue, 10 Aug 2021 13:44:44 +0200 (CEST) Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam07on20622.outbound.protection.outlook.com [IPv6:2a01:111:f400:7eb2::622]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id E0BA781280 for ; Tue, 10 Aug 2021 13:44:36 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=xilinx.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=michals@xilinx.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ipCB40/JkaPOpw2yBtWfSq+lPoR8LA9XDt3V9O1/250YqBTh3GpxPNZ1tAvjbmCwW/WwwfXKZXMZN/lQIgihG4DdGDq/RwQBltwVdD3e2qxpjV8dxLv1R5OvOVAOjABAUUY7EiamlDvXHpvQ+WMkgYM1DTqFspYSPTpiWNblJsQ+dUlK7hox7TI7nq6ktR+uv+3gtnGuzUGuSPLn+VRxJlo8CNyGi7m6QCiKUJsN3G7E3dGBMYISdam8xAeD0UD4xW4XWsL1Av4gOxg3dZQmeihuz042OJZRXlBkymfcH8QRsR2NdPGdimypaTI1MJlafckQu4sY6FrcUJfvRUU0Zg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=koCfnrLa5WR699UpzZ+mLFmweUc2joAlqv8ttahqvbU=; b=BDbC5hE6VpuHL4DoOQLUspt3DNgLkYhMIPHR7ZAkdUPNgyYJ1Yq1dyTzAFeA2NlEapDkpLSIR8AP7UU5AE0I0XFNNg4GBmdl3lZTDFt1pxJm9Jimfr60iKurlGMx/HNsAiuO0LH09DG3wolIXqlZStnQpETy6edLYxpvqbpaz1gg0kD/M2jp8lUYcwl1EXs/BZyHiziP8wVpWvmv18nsWVnQ1P52nzzdx4h5Axs2ofzOiYUyCbTqO0m9tYQh0KRWZwzvoOumCpHYE0ECSE9mm3QZscRlo3qn+iHuv9haBPxBNtEPmtawwcBi+SNh0hkuKtWu3CFZ4lBzXPBFL/AV4Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 149.199.62.198) smtp.rcpttodomain=chromium.org smtp.mailfrom=xilinx.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=xilinx.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xilinx.onmicrosoft.com; s=selector2-xilinx-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=koCfnrLa5WR699UpzZ+mLFmweUc2joAlqv8ttahqvbU=; b=dzy7wAEd9NWU174mj2NN64SKIUYFhcLdHwObimAx3oT+ZNq3MCm1551wka6+dJ1zQ5FlzboJFoCw9SoHo3I2zPYmgWnuVFQA9VIOA/rawSUt/39KL/Vz9ePTpCaAtVs1V7Zqv5hmORDAA81AKEQPcOTaPRLh4GvT939D1sJLL/o= Received: from DM5PR2001CA0022.namprd20.prod.outlook.com (2603:10b6:4:16::32) by MWHPR02MB2718.namprd02.prod.outlook.com (2603:10b6:300:108::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.16; Tue, 10 Aug 2021 11:44:21 +0000 Received: from DM3NAM02FT063.eop-nam02.prod.protection.outlook.com (2603:10b6:4:16:cafe::25) by DM5PR2001CA0022.outlook.office365.com (2603:10b6:4:16::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.16 via Frontend Transport; Tue, 10 Aug 2021 11:44:21 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 149.199.62.198) smtp.mailfrom=xilinx.com; chromium.org; dkim=none (message not signed) header.d=none;chromium.org; dmarc=pass action=none header.from=xilinx.com; Received-SPF: Pass (protection.outlook.com: domain of xilinx.com designates 149.199.62.198 as permitted sender) receiver=protection.outlook.com; client-ip=149.199.62.198; helo=xsj-pvapexch02.xlnx.xilinx.com; Received: from xsj-pvapexch02.xlnx.xilinx.com (149.199.62.198) by DM3NAM02FT063.mail.protection.outlook.com (10.13.5.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.4394.16 via Frontend Transport; Tue, 10 Aug 2021 11:44:21 +0000 Received: from xsj-pvapexch02.xlnx.xilinx.com (172.19.86.41) by xsj-pvapexch02.xlnx.xilinx.com (172.19.86.41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Tue, 10 Aug 2021 04:44:20 -0700 Received: from smtp.xilinx.com (172.19.127.95) by xsj-pvapexch02.xlnx.xilinx.com (172.19.86.41) with Microsoft SMTP Server id 15.1.2176.2 via Frontend Transport; Tue, 10 Aug 2021 04:44:20 -0700 Envelope-to: git@xilinx.com, sjg@chromium.org, monstr@monstr.eu, lukma@denx.de, ilias.apalodimas@linaro.org, a-govindraju@ti.com, agriveaux@deutnet.info, u-boot@lists.denx.de, trini@konsulko.com Received: from [172.30.17.109] (port=48296) by smtp.xilinx.com with esmtp (Exim 4.90) (envelope-from ) id 1mDQB9-0002KM-0e; Tue, 10 Aug 2021 04:44:19 -0700 Subject: Re: [PATCH] xilinx: Disable ARCH_FIXUP_FDT_MEMORY To: Tom Rini , Michal Simek CC: , , Alexandre GRIVEAUX , Ashok Reddy Soma , Aswath Govindraju , Ilias Apalodimas , Lukasz Majewski , Michal Simek , Simon Glass , T Karthik Reddy References: <1f2589b334942bc5adeedd5df58e6af32ec31ce2.1628252571.git.michal.simek@xilinx.com> <20210806184656.GD858@bill-the-cat> <5637d26e-aaf8-fc4f-b681-dd10b16a9359@xilinx.com> <20210809163110.GZ858@bill-the-cat> From: Michal Simek Message-ID: Date: Tue, 10 Aug 2021 13:44:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <20210809163110.GZ858@bill-the-cat> Content-Type: text/plain; charset="windows-1252" Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 82de59bb-bb59-4768-43af-08d95bf431c6 X-MS-TrafficTypeDiagnostic: MWHPR02MB2718: X-Microsoft-Antispam-PRVS: X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: puGoXL0Ao2vWPENRX5rbYIpa0IAjOBYEXGiY6FfSWIxLwe45+tVFzrnmAKtdH9oNLM8CaCpSSxczgenBvVRWeL9amTdEMzErz7nEW7k2wjrkdBMkRXJiJg46FM2vMl06otfRnuslGfy6R4ZaPuvw1NCwjJ/X7n9//g2gxri6VUNZs3GT7eFyRwXA2ACnlWtBF6uHuMpCF8NcNnPOuG1wwK3HLHQo0EdCGKX/hRC8j0SzdMTkQMpiT2XNGK0jHL7z1yhvp0ibt2H4Ww22TOY6nYvSKqNG6MZxldZdlRe3Cr8rs65YOYjQs70WXzN73LhEGeI7Sb3mcfiGxXhqjowC4n6/voL6GBjfftkazUcX92bHphZZ3bumUYEeYtO7+4Jo4iAiKy6k3mJiHRMWkFgg/e+5iKeejYjwlLH1Z3lqL5XN+OiPYNTwpWwkch/OX4Kb7UEg3TGbsLbELHw+xFMFQWVRGJi8Y9jynToAzBDGOUqwPJLf0x17p2C20EMK2446X4bEC1CJbsLfEKnIbuVDYRtYRDy+wZz6RKJBtVqDvKn3pHnRhErs8GljYHAUs+cl2cDE7FTpKJGo76XTRzLJkaSLWE6kj2eCFhH8Z5DaIGFpTotM2uWwrw4C2L/t/v0WysdIg5yCuSM9Tur5/Q5RNpjSjWPf3IQ6cExN2eVQFy3xrRxF/ylAHBmlSWKFTve639f0Umc2wm354Vsv+A/95Q/U4CHb4IaEt5PZ/KaaDQcx2pWn5kOzQmZQ++CbJu3hZBhJ5pO64EgX0PYlQL6v2qBpJRFMkNGG0mavmPiwX9dyc6fuAJgEyqYUIw6KhPUuw3TjqsyAyZVxPClxHqsBwg== X-Forefront-Antispam-Report: CIP:149.199.62.198; CTRY:US; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:xsj-pvapexch02.xlnx.xilinx.com; PTR:unknown-62-198.xilinx.com; CAT:NONE; SFS:(4636009)(346002)(376002)(396003)(39860400002)(136003)(36840700001)(46966006)(5660300002)(70206006)(31686004)(53546011)(70586007)(4326008)(44832011)(54906003)(9786002)(107886003)(47076005)(2616005)(110136005)(426003)(6666004)(8676002)(2906002)(8936002)(7636003)(82310400003)(31696002)(356005)(36756003)(83380400001)(26005)(36860700001)(82740400003)(316002)(36906005)(186003)(478600001)(966005)(336012)(50156003)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: xilinx.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Aug 2021 11:44:21.3951 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 82de59bb-bb59-4768-43af-08d95bf431c6 X-MS-Exchange-CrossTenant-Id: 657af505-d5df-48d0-8300-c31994686c5c X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=657af505-d5df-48d0-8300-c31994686c5c; Ip=[149.199.62.198]; Helo=[xsj-pvapexch02.xlnx.xilinx.com] X-MS-Exchange-CrossTenant-AuthSource: DM3NAM02FT063.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR02MB2718 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean On 8/9/21 6:31 PM, Tom Rini wrote: > On Mon, Aug 09, 2021 at 08:24:48AM +0200, Michal Simek wrote: >> >> >> On 8/6/21 8:46 PM, Tom Rini wrote: >>> On Fri, Aug 06, 2021 at 02:22:56PM +0200, Michal Simek wrote: >>> >>>> Based on DT spec you can have one memory node which multiple ranges or >>>> multiple nodes. >>>> fdt_fixup_memory_banks() is not implemented in a correct way when multiple >>>> memory nodes are present because all ranges are put it to the first memory >>>> node found. And next memory nodes are kept in DT which ends up in the same >>>> range specification in the same DT. >>>> >>>> Here is what it is happening. >>>> Origin DT. >>>> memory@0 { >>>> device_type = "memory"; >>>> reg = <0x0 0x0 0x0 0x80000000>; >>>> }; >>>> >>>> memory@800000000 { >>>> device_type = "memory"; >>>> reg = <0x8 0x00000000 0x0 0x80000000>; >>>> }; >>>> >>>> After fdt_fixup_memory_banks() >>>> >>>> memory@0 { >>>> device_type = "memory"; >>>> reg = <0x0 0x0 0x0 0x80000000>, <0x8 0x00000000 0x0 0x80000000>; >>>> }; >>>> >>>> memory@800000000 { >>>> device_type = "memory"; >>>> reg = <0x8 0x00000000 0x0 0x80000000>; >>>> }; >>>> >>>> As is visible memory@0 node got second range but there is still >>>> memory@800000000 node present and 2G range is listed twice. >>>> >>>> The solution can't be that second node is removed because it can be >>>> referenced already that's why it is better for us to disable this option >>>> for now. >>> >>> I don't object to the patch at all. The main use of >>> fdt_fixup_memory_banks() is for the (at least used to be most common) >>> case of device trees that didn't fill in memory size, so that it could >>> be done at run-time, depending on the amount found. I do wonder if >>> CONFIG_ARCH_FIXUP_FDT_MEMORY being default makes the most sense these >>> days. Or maybe we just need some comments on fdt_fixup_memory_banks >>> making it clear which way we implement the spec as it does allow for as >>> you note, either way. >> >> The multi memory node configuration is not that common and the most of >> SOC are using one node with multiple ranges. It means I would say a lot >> of SOCs are not affected. > > OK. > >> Not sure how many SOCs are really using this feature that at run time >> you detect amount of memory. I remember freescale powerquicks with >> reading SPD eeprom on DIMMs and then one custom board with xilinx soc >> which was produced with two memory sizes where detection was performed. > > I think there's still a large number of platforms that don't describe > the amount of memory in the device tree and let it be figured out at > "run time", even if there's not nearly the level of SPD EEPROM related > smarts as there are in some environments. U-Boot's get_ram_size() is > usually good enough for those cases. But it's been a long time since I > checked a wide variety of dts files, and that it gets the more than 4GB > case wrong too is why there are a number of platforms that opt-out. > >> But anyway if you want me to add comment to that function to describe >> what it is implemented now I can do it. >> And of course the best would be to update this function handle both ways >> but for us is it better to disable this for now till we have real need >> to use it. >> We have also done internally one implementation but I don't think it >> works in generic way. > > A comment for now would be a great start, thanks! > Just for a record. Here it is send. https://lists.denx.de/pipermail/u-boot/2021-August/457629.html Thanks, Michal