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=-7.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,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 0E6D4C4338F for ; Fri, 6 Aug 2021 18:47:10 +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 D7E6F60EE8 for ; Fri, 6 Aug 2021 18:47:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D7E6F60EE8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.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 A97F38314A; Fri, 6 Aug 2021 20:47:06 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.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=konsulko.com header.i=@konsulko.com header.b="E3SiR4Nu"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id B432383175; Fri, 6 Aug 2021 20:47:04 +0200 (CEST) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id DA079821F0 for ; Fri, 6 Aug 2021 20:47:00 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qk1-x730.google.com with SMTP id az7so10927899qkb.5 for ; Fri, 06 Aug 2021 11:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=v52v5XzC97uMibVmBbcjG8ZbBXDsro/y1cqq0HMph7Y=; b=E3SiR4NugJjcstSK17o0QV1YILEF5uszlBKtb9rpGXuWKrV47X1Q/6vTrVSrXWguk4 hQ+3JTNkVUaSY5GUstM6+oqQdMOGiqa7FHjMwIVg7x69LUljfDuQogfoE0YNt34v+Z5g Ywg0SDxuJ2rbWOuszU734amX8AMvKBeTIT68A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=v52v5XzC97uMibVmBbcjG8ZbBXDsro/y1cqq0HMph7Y=; b=aWo4V9KsvPFFiBotVuYI+Xs+ugGjiJr21e56sxCfEub5piLH+RSOak+be6D7rOn9C0 IwuWEcCRqHS2En2XYDiClrJKwz+eQ/4iZErRBAcKoNglHCRm7+JpRAiZqvPWDz9oyQSD Eth/U7JQJWMcn+PVdyIzhRcafijTx/eJOHVPtohLbdLJ+XQvhVTqwyeYpRi8sXbRmBzD nV07Q7YHxBLPNalszS8xtX+HGry0VojRMSYiVhUzfSe+r2zWqpq4Fd8isiOgF0XKYxzS ScG/LInYKGk50KHpAhfYPw35GRoXkzkY4japgQonSjTpQxEyEd5/c/IybUcCPn/pFBw/ nlOg== X-Gm-Message-State: AOAM530Ny3N2VsVaRmDh0WTsByUIL51nHdtgv9yp/NwB5RPv9WdrKfnw BherFjMLs6691FYKYguDvbxQpA== X-Google-Smtp-Source: ABdhPJzkoBwS0QuKs4UaoVxmhd4PR9hkUJVvxDdcsfrDF/L6Zbu1uVsV1AwD+BpoGNtPQuqE60qyVw== X-Received: by 2002:a05:620a:19a9:: with SMTP id bm41mr11554885qkb.399.1628275619617; Fri, 06 Aug 2021 11:46:59 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-412a-6045-b0a6-0c94.res6.spectrum.com. [2603:6081:7b01:cbda:412a:6045:b0a6:c94]) by smtp.gmail.com with ESMTPSA id r3sm5106550qkm.118.2021.08.06.11.46.58 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Fri, 06 Aug 2021 11:46:58 -0700 (PDT) Date: Fri, 6 Aug 2021 14:46:56 -0400 From: Tom Rini To: Michal Simek Cc: u-boot@lists.denx.de, git@xilinx.com, Alexandre GRIVEAUX , Ashok Reddy Soma , Aswath Govindraju , Ilias Apalodimas , Lukasz Majewski , Michal Simek , Simon Glass , T Karthik Reddy Subject: Re: [PATCH] xilinx: Disable ARCH_FIXUP_FDT_MEMORY Message-ID: <20210806184656.GD858@bill-the-cat> References: <1f2589b334942bc5adeedd5df58e6af32ec31ce2.1628252571.git.michal.simek@xilinx.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Lg8eXa+brxrbjAbR" Content-Disposition: inline In-Reply-To: <1f2589b334942bc5adeedd5df58e6af32ec31ce2.1628252571.git.michal.simek@xilinx.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.9.4 (2018-02-28) 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 --Lg8eXa+brxrbjAbR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > Here is what it is happening. > Origin DT. > memory@0 { > device_type =3D "memory"; > reg =3D <0x0 0x0 0x0 0x80000000>; > }; >=20 > memory@800000000 { > device_type =3D "memory"; > reg =3D <0x8 0x00000000 0x0 0x80000000>; > }; >=20 > After fdt_fixup_memory_banks() >=20 > memory@0 { > device_type =3D "memory"; > reg =3D <0x0 0x0 0x0 0x80000000>, <0x8 0x00000000 0x0 0x80000000>; > }; >=20 > memory@800000000 { > device_type =3D "memory"; > reg =3D <0x8 0x00000000 0x0 0x80000000>; > }; >=20 > As is visible memory@0 node got second range but there is still > memory@800000000 node present and 2G range is listed twice. >=20 > 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. --=20 Tom --Lg8eXa+brxrbjAbR Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmENg50ACgkQFHw5/5Y0 tyxxqQv9G1yDRyUTb40uEf1mYFsUsoLn7UzVHSq3V8OWLFP6XabdmoArrRed7xww BrXNqIbelYm9oHPpWgHGGla1t63m3V7+YGE5RFfHBMM8Uo/Bk9dYn0ZT2OCks9Qr ttX+eLR3jpnCREmMe5NwFgOiUuuCEXAFCKzsGxeYVnPFNuoBqWlRAcxa+ckqDWMM KXeF+E9Fo00Ud/DVQCit9VmKauNBmg7vNQLR2GwWx5XmdFcPSisZ3HSR4mzgMBWn z1HamSi8IyrxxoKATwDvhwhvt3jLDjsrvtWc1d2fWKcKUnk79vjmfalD3afMhAPq eABwVzD/0zn3v8qXLcGFeLOiAi2QOoOCvhvKcZB46ninjb9kG7AkqWkih4fL5X8t VAMcTgOWsht0GKhKhe+s8n5aBojTdDjSbJVH7LmIzyUtSIzKx6pQakUoMAo0ckwq YA5Ht5YyVVpXkvrfsOdvYPRQCviGxpJSisGJAmhGbSpszgP8kscjhYFvZgdlTOva 7p2opdji =QWxE -----END PGP SIGNATURE----- --Lg8eXa+brxrbjAbR--