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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 90EC6C433EF for ; Wed, 18 May 2022 15:18:29 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 0FE738426A; Wed, 18 May 2022 17:18:27 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (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="pv6TQSVE"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id BBD4F82125; Wed, 18 May 2022 17:18:25 +0200 (CEST) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 8516C80FC8 for ; Wed, 18 May 2022 17:18:22 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qt1-x831.google.com with SMTP id p4so1817741qtq.12 for ; Wed, 18 May 2022 08:18:22 -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; bh=26P3e4hu1ZHCtn/ld0VsuG2ScJs+mcdgHXLIP1w0hYQ=; b=pv6TQSVEd69rD8E2q2NTkf1Bz5bNHk1XlIEnICqT/bTKDp8IYgWpR5NyXN6DdYmipF ad1usbX2psjpRiIvGfP1l39FOhgCxfR0L6K45JUQ+VNFkZOYyvOE9qNkzZ0UhtzCgX8e G2pmrAKffTcwbnA55WDip9FpDtoF7t0qMCQt4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=26P3e4hu1ZHCtn/ld0VsuG2ScJs+mcdgHXLIP1w0hYQ=; b=Bho+XBmKowEmo+O+hn6jk658IPg2v5sxhZgR9WBNmCTwrF0qrHTF72QdXrwQ/9Jh6s Ap4QGhBkQVy6pFVVvI76b3ZrgAGkZ+ZLUD1gMKej/5YF/0p38+b8PU02unkr2uoxNxvM i7gNHF2yoCYD/UzxYyKM2hcqexCTkzRsf6zciJxdZ7l4Lb41/NcE5aISZCN+8db09u0u V8HTOy/8HQs7up6QReeolHcsVAdXcP/M1HXwc8OtVBevfi4lDz2gB+avmbBGKv8srSp3 GWS7YEj/ze+cn6Vvl5bfmkefnkuWAAWJ8urliWSlrKm347OYe/SZGPuj+Pup2eEBMvfB UTnA== X-Gm-Message-State: AOAM532qJlpzejQo4j/F1eYUYZdAPR+SAh3VhjJKzVsM3qgzoBxehVUi McRPeI+qDZpj5lBInEbMjTvH6Q== X-Google-Smtp-Source: ABdhPJyJ1cRGbr2Hmwa/GqleIPWMtnkLlhHKFQAIcsObGtGuXqyH/2wM5Fr3fpUlIoWzJtQajT9MIA== X-Received: by 2002:a05:622a:30f:b0:2f3:eb61:db6b with SMTP id q15-20020a05622a030f00b002f3eb61db6bmr237739qtw.222.1652887101156; Wed, 18 May 2022 08:18:21 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-4500-d95c-f120-8640-d523.res6.spectrum.com. [2603:6081:7b01:4500:d95c:f120:8640:d523]) by smtp.gmail.com with ESMTPSA id l6-20020ac848c6000000b002f39b99f68csm1352267qtr.38.2022.05.18.08.18.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 May 2022 08:18:20 -0700 (PDT) Date: Wed, 18 May 2022 11:18:18 -0400 From: Tom Rini To: Pali =?iso-8859-1?Q?Roh=E1r?= Cc: Simon Glass , u-boot@lists.denx.de Subject: Re: Broken support for 4GB DDR on 32-bit platforms Message-ID: <20220518151818.GA3901321@bill-the-cat> References: <20220516123143.GI3901321@bill-the-cat> <20220516215651.g4joz4p6atpv57h2@pali> <20220517155214.GS3901321@bill-the-cat> <20220517160016.ji4g3ly3rylhmfrp@pali> <20220517163843.GT3901321@bill-the-cat> <20220518105838.qzxtg7hi44dakxrl@pali> <20220518121655.GU3901321@bill-the-cat> <20220518121739.akw25qs67ochhian@pali> <20220518121936.GW3901321@bill-the-cat> <20220518131919.yzc66ieh6bn4gv4h@pali> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PvO6gVpe2R1m8PYV" Content-Disposition: inline In-Reply-To: <20220518131919.yzc66ieh6bn4gv4h@pali> X-Clacks-Overhead: GNU Terry Pratchett X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 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.5 at phobos.denx.de X-Virus-Status: Clean --PvO6gVpe2R1m8PYV Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 18, 2022 at 03:19:19PM +0200, Pali Roh=E1r wrote: > On Wednesday 18 May 2022 08:19:36 Tom Rini wrote: > > On Wed, May 18, 2022 at 02:17:39PM +0200, Pali Roh=E1r wrote: > > > On Wednesday 18 May 2022 08:16:55 Tom Rini wrote: > > > > On Wed, May 18, 2022 at 12:58:38PM +0200, Pali Roh=E1r wrote: > > > > > On Tuesday 17 May 2022 12:38:43 Tom Rini wrote: > > > > > > On Tue, May 17, 2022 at 06:00:16PM +0200, Pali Roh=E1r wrote: > > > > > > > On Tuesday 17 May 2022 11:52:14 Tom Rini wrote: > > > > > > > > On Mon, May 16, 2022 at 11:56:51PM +0200, Pali Roh=E1r wrot= e: > > > > > > > > > On Monday 16 May 2022 08:31:43 Tom Rini wrote: > > > > > > > > > > On Sat, May 14, 2022 at 01:00:06AM +0200, Pali Roh=E1r = wrote: > > > > > > > > > >=20 > > > > > > > > > > > Hello! I tried to enable support for 2GB+ of DDR memo= ry (with 4GB DDR3) > > > > > > > > > > > on powerpc P2020 board in 32-bit addressing mode and = U-Boot crashed > > > > > > > > > > > during startup. > > > > > > > > > > >=20 > > > > > > > > > > > I figured out that issue is not powerpc specific, but= rather generic to > > > > > > > > > > > all 32-bit platforms. U-Boot stores memory size into = phys_size_t type > > > > > > > > > > > (gd->ram_size) and last mapped memory address increas= ed by one byte into > > > > > > > > > > > phys_addr_t type (gd->ram_top). > > > > > > > > > > >=20 > > > > > > > > > > > Despite size 4GB fits into 32-bit addressing mode, it= does not fit into > > > > > > > > > > > above two variables, and it overflows to zero. U-Boot= then see zero RAM > > > > > > > > > > > size and crashes. > > > > > > > > > > >=20 > > > > > > > > > > > I tried to workaround this issue by changing both phy= s_size_t and > > > > > > > > > > > phys_addr_t types to 64-bit. But it did not helped be= cause U-Boot on > > > > > > > > > > > many places cast gd->ram_size or gd->ram_top to ulong= type, which is > > > > > > > > > > > 32-bit on 32-bit platforms. > > > > > > > > > > >=20 > > > > > > > > > > > Next I changed ulong parameters of board_get_usable_r= am_top() function > > > > > > > > > > > to u64. > > > > > > > > > > >=20 > > > > > > > > > > > This still was not enough because config value CONFIG= _MAX_MEM_MAPPED is > > > > > > > > > > > ignored on one important place -- in function get_eff= ective_memsize(). > > > > > > > > > > > This config value takes effect only when also CONFIG_= VERY_BIG_RAM is > > > > > > > > > > > set. > > > > > > > > > > >=20 > > > > > > > > > > > Finally With this change I was able to start U-Boot w= ith more than 2GB > > > > > > > > > > > of DDR memory inserted in SODIMM slot on P2020. > > > > > > > > > > >=20 > > > > > > > > > > > How to fix issues with gd->ram_size and gd->ram_top? = That +1 byte is > > > > > > > > > > > really stupid limitation. Changing phys_size_t and ph= ys_addr_t types > > > > > > > > > > > unconditionally to 64-bit? Or something else? > > > > > > > > > > >=20 > > > > > > > > > > > And what is the purpose of CONFIG_VERY_BIG_RAM config= option? Why is > > > > > > > > > > > CONFIG_MAX_MEM_MAPPED check skipped in get_effective_= memsize() function, > > > > > > > > > > > but is not skipped on many more places? > > > > > > > > > >=20 > > > > > > > > > > So, there's two parts to this, as I recall it all. Fir= st, even on 64bit > > > > > > > > > > platforms we contain ourselves to 32bit address space a= nd even then > > > > > > > > > > something within the "old" 2GB window. We then set a C= ONFIG option to > > > > > > > > > > not mess with the memory node in DT which has the real = value. Second, > > > > > > > > > > for 32bit platforms which can support 4GB memory, or mo= re, some further > > > > > > > > > > games need to be played, typically I believe around ini= tializing the > > > > > > > > > > memory controller (I'm more confident of that for dra7x= x_evm, which I > > > > > > > > > > don't have the big memory version of, just a small memo= ry one) so that > > > > > > > > > > Linux can do whatever needs doing to enable "36bit" typ= ically address > > > > > > > > > > support. Looking at the other P*36BIT* configs might g= ive you some more > > > > > > > > > > clues about what to do on your platform, or at least wh= o might still be > > > > > > > > > > able to explain and test things on the PowerPC side. > > > > > > > > >=20 > > > > > > > > > I know about 36-bit addressing on e500v2 but I'm not goin= g to enable it > > > > > > > > > due to performance reasons (see Freescale AN4064 [1]). So= I want to > > > > > > > > > stick with 32-bit addressing for 2GB+ memory usage (aroun= d 3GB; it is > > > > > > > > > 4GB minus memory used by peripherals; which is still more= than 2GB). > > > > > > > > >=20 > > > > > > > > > And due to 32-bit type for phys_size_t, phys_addr_t and c= asting these > > > > > > > > > types to ulong is an issue. Plus issue with CONFIG_VERY_B= IG_RAM and > > > > > > > > > CONFIG_MAX_MEM_MAPPED as I already wrote. > > > > > > > >=20 > > > > > > > > I'm not seeing the problem, sorry. You run U-Boot in the n= ormal 2GB > > > > > > >=20 > > > > > > > Ok, I will try to explain it again. > > > > > > >=20 > > > > > > > I want to run U-Boot in normal 2GB area. U-Boot normally stor= e detected > > > > > > > RAM size into the gd->ram_size structure. And here is the iss= ue. > > > > > > >=20 > > > > > > > 32-bit unsigned C type cannot represent maximal 32-bit addres= sable size. > > > > > > > U-Boot tries to store 4GB value =3D 0x100000000 into gd->ram_= size which > > > > > > > overflows to 0x00000000. And U-Boot then crashes because it e= xpects that > > > > > > > can store some data at address "gd->ram_size - few_kb" as it = expects > > > > > > > that RAM is in the area [0, gd->ram_size). > > > > > > >=20 > > > > > > > It is more clear what is the problem? > > > > > > >=20 > > > > > > > If I theoretically find 3.9GB RAM module (but such probably d= oes not > > > > > > > exist) then U-Boot should work in normal 2GB area as number 3= =2E9GB can be > > > > > > > stored into 32-bit unsigned type. > > > > > >=20 > > > > > > Yes, you need to disable CONFIG_ARCH_FIXUP_FDT_MEMORY > > > > >=20 > > > > > CONFIG_ARCH_FIXUP_FDT_MEMORY affects booting OS. > > > > >=20 > > > > > The issue is that **u-boot** is crashing during its initializatio= n. > > > >=20 > > > > When configuring the controller for 4GB, but limiting U-Boot to 2GB? > > >=20 > > > Yes! > >=20 > > Interesting. Maybe you just have to do the 36BIT games on that SoC, to > > support what you're trying to do. If anyone at NXP knows something > > perhaps they'll chime in. >=20 > Why? It is issue in U-Boot and affects all 32-bit platforms not only powe= rpc/NXP. I disagree. It's working as intended with other 32bit platforms, unless it's stopped working on dra7xx_evm with >2GB memory (which I don't have, unfortunately). If you can't configure the memory controller to know that 4GB exists, but limit yourself to running within 2GB, that's a SoC-specific problem. If you want to make the big changes so that we can have a larger than 2GB memory space for U-Boot, period, that's a big general change with challenges as you've already seen. --=20 Tom --PvO6gVpe2R1m8PYV Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmKFDjcACgkQFHw5/5Y0 tyyuhgv/V/6urvth3uMcSSVCUR5a8d3D8YR1tvwCrokjgRNX+qbehrJeXFedw6ow iPRp64ajR2HKa1Ycw6sNjmz0ON2ShoBOlUqbQ7n2oTAP9iRG/kRrDfKoiJ5mgtL+ JGSsIz4ZDVTaShoYX2UE8Ty0GL1fJ2IbPAak7QXwpcUyOxnnIqWhDj6pJhaM9ocq WnXnm+2jh5Acu3MoI/7jAkOy3ajc8ZRmfnaSv6ZL20AH/XOsJuqN+FWIFQsi1pYT fcx9Ir6FcESzGthSztXy3ezYYybIb5NKPzwfbZ7RbSDRfAGJEgqva5VLOMCIO4Dq jN9Ext2o1EjadlPr+J9YcJGPiiw1R34/2sxj6vSMPxKnXdR6k7SmQAS3/wrekfoo ycf2hBR1fNU94NAF4Lby9D+AJn0lMtoiOm4Cq+6hXOgqxtz3yZgdyYe01aYwrE6i BnfQMbbq0VCa1Nq/rjacwSSR1mfJ5StMBwpaRbRls2FNVDTEZZu7yu2w059rT6py mn9JQW9x =2HXy -----END PGP SIGNATURE----- --PvO6gVpe2R1m8PYV--