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 EA1A1C433F5 for ; Wed, 18 May 2022 12:19:47 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id E447884286; Wed, 18 May 2022 14:19:45 +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="G+lQ6Asv"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 0986884288; Wed, 18 May 2022 14:19:44 +0200 (CEST) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 40D6583D52 for ; Wed, 18 May 2022 14:19:40 +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-x829.google.com with SMTP id p4so1378741qtq.12 for ; Wed, 18 May 2022 05:19:40 -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=9HVXkT4s7UbsWc8iFzAUdbz1XIcAk43KpQqpazwhyzA=; b=G+lQ6Asvdv4ueEAs3wgwxtkceZfUbcFwZ1E0j9CfVqt2rbJZK7Ux2bNHOcjDjQl2m3 VRpgq9/2yEFI/gfjctQZr1WEfeIn72+/UWmKPMKIASOHqm03pg1RFgusqfssS5xts2+5 JwCBSBcyKEOoMEPI/Z1UzY6lXb88ZUrSitFKk= 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=9HVXkT4s7UbsWc8iFzAUdbz1XIcAk43KpQqpazwhyzA=; b=XFVXHHN7fpu6htGg6iqt759lRWAjmQVemumcDy2Ad2jYorzFPFlpH1Nvb3IAe/pkaT cKs/oKr7GFjmd1Af1Ceulaty8AXbPVLmgwsp3KWYKO4sIV+Drk9Vj4vS+tS58vQxsWlN QcpCqd+CVC1CG+XmXZkd9dftvbV/3Q9FIAW4HgnAXn4trQuYpyzs6ogBsi3rXrOnBYbC PhwvnLVRuL8c6QEf/Bzj4TB3bLtBXxqhKJlAmsbI14U5CgAC+1pvnk5u8ekhj9Ok6rr8 dS9y4EdLgXTaPNpJFJZ9Q9HTLrzkHx2JBETrkX+wZD1YgVGR7I8VoR0pckxUun607/YY U4Sw== X-Gm-Message-State: AOAM533XQPEx24rfItNUMxCC1qcgXZQKE6YyfJqORfzfRkX1bN7Xxp1v LHO7974o1XdcI1TKvyIXj4gNYQ== X-Google-Smtp-Source: ABdhPJzZ7s/IpTQKinzsvSCBkieamyn7lfltZCxIyXRmXfxDhGnE+BXlYSDGC0at0kAIZejJYgPHsA== X-Received: by 2002:ac8:7d86:0:b0:2f3:c523:19a2 with SMTP id c6-20020ac87d86000000b002f3c52319a2mr23439445qtd.566.1652876379027; Wed, 18 May 2022 05:19:39 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-4500-3558-7670-e34f-c790.res6.spectrum.com. [2603:6081:7b01:4500:3558:7670:e34f:c790]) by smtp.gmail.com with ESMTPSA id e4-20020ac84904000000b002f39b99f6b8sm1079421qtq.82.2022.05.18.05.19.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 May 2022 05:19:38 -0700 (PDT) Date: Wed, 18 May 2022 08:19:36 -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: <20220518121936.GW3901321@bill-the-cat> References: <20220513230006.ep5qdhuu6k5ado2l@pali> <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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UoQnh8DjDgfWLrgi" Content-Disposition: inline In-Reply-To: <20220518121739.akw25qs67ochhian@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 --UoQnh8DjDgfWLrgi Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 wrote: > > > > > > > On Monday 16 May 2022 08:31:43 Tom Rini wrote: > > > > > > > > On Sat, May 14, 2022 at 01:00:06AM +0200, Pali Roh=E1r wrot= e: > > > > > > > >=20 > > > > > > > > > Hello! I tried to enable support for 2GB+ of DDR memory (= with 4GB DDR3) > > > > > > > > > on powerpc P2020 board in 32-bit addressing mode and U-Bo= ot crashed > > > > > > > > > during startup. > > > > > > > > >=20 > > > > > > > > > I figured out that issue is not powerpc specific, but rat= her generic to > > > > > > > > > all 32-bit platforms. U-Boot stores memory size into phys= _size_t type > > > > > > > > > (gd->ram_size) and last mapped memory address increased b= y one byte into > > > > > > > > > phys_addr_t type (gd->ram_top). > > > > > > > > >=20 > > > > > > > > > Despite size 4GB fits into 32-bit addressing mode, it doe= s not fit into > > > > > > > > > above two variables, and it overflows to zero. U-Boot the= n see zero RAM > > > > > > > > > size and crashes. > > > > > > > > >=20 > > > > > > > > > I tried to workaround this issue by changing both phys_si= ze_t and > > > > > > > > > phys_addr_t types to 64-bit. But it did not helped becaus= e U-Boot on > > > > > > > > > many places cast gd->ram_size or gd->ram_top to ulong typ= e, which is > > > > > > > > > 32-bit on 32-bit platforms. > > > > > > > > >=20 > > > > > > > > > Next I changed ulong parameters of board_get_usable_ram_t= op() 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_effecti= ve_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 with = 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 phys_a= ddr_t types > > > > > > > > > unconditionally to 64-bit? Or something else? > > > > > > > > >=20 > > > > > > > > > And what is the purpose of CONFIG_VERY_BIG_RAM config opt= ion? Why is > > > > > > > > > CONFIG_MAX_MEM_MAPPED check skipped in get_effective_mems= ize() function, > > > > > > > > > but is not skipped on many more places? > > > > > > > >=20 > > > > > > > > So, there's two parts to this, as I recall it all. First, = even on 64bit > > > > > > > > platforms we contain ourselves to 32bit address space and e= ven then > > > > > > > > something within the "old" 2GB window. We then set a CONFI= G option to > > > > > > > > not mess with the memory node in DT which has the real valu= e. Second, > > > > > > > > for 32bit platforms which can support 4GB memory, or more, = some further > > > > > > > > games need to be played, typically I believe around initial= izing the > > > > > > > > memory controller (I'm more confident of that for dra7xx_ev= m, which I > > > > > > > > don't have the big memory version of, just a small memory o= ne) so that > > > > > > > > Linux can do whatever needs doing to enable "36bit" typical= ly address > > > > > > > > support. Looking at the other P*36BIT* configs might give = you some more > > > > > > > > clues about what to do on your platform, or at least who mi= ght 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 going to= enable it > > > > > > > due to performance reasons (see Freescale AN4064 [1]). So I w= ant to > > > > > > > stick with 32-bit addressing for 2GB+ memory usage (around 3G= B; it is > > > > > > > 4GB minus memory used by peripherals; which is still more tha= n 2GB). > > > > > > >=20 > > > > > > > And due to 32-bit type for phys_size_t, phys_addr_t and casti= ng these > > > > > > > types to ulong is an issue. Plus issue with CONFIG_VERY_BIG_R= AM and > > > > > > > CONFIG_MAX_MEM_MAPPED as I already wrote. > > > > > >=20 > > > > > > I'm not seeing the problem, sorry. You run U-Boot in the norma= l 2GB > > > > >=20 > > > > > Ok, I will try to explain it again. > > > > >=20 > > > > > I want to run U-Boot in normal 2GB area. U-Boot normally store de= tected > > > > > RAM size into the gd->ram_size structure. And here is the issue. > > > > >=20 > > > > > 32-bit unsigned C type cannot represent maximal 32-bit addressabl= e 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 expec= ts that > > > > > can store some data at address "gd->ram_size - few_kb" as it expe= cts > > > > > 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 does = not > > > > > exist) then U-Boot should work in normal 2GB area as number 3.9GB= 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 initialization. > >=20 > > When configuring the controller for 4GB, but limiting U-Boot to 2GB? >=20 > Yes! 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 Tom --UoQnh8DjDgfWLrgi Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmKE5FgACgkQFHw5/5Y0 tyzpFgwAjGsxH4vTM5JX0QM+Fwe8iqfuIoMCSI9RfDeOag4rr/8kgt4L4OwzRteA UNck2Qa9UyOmFEoD6wO3XZwIXDDkiqy12GyoaA232F3ajPMxNk9qYwxbTBec4fIs tuK+fsEw5EUdw6JX25k89X3n03d6eN7HMpqwehLROR3i2nmR6aQul79qvtwWMYC5 d0jIvpnjm3phV2xRPSs9WkK0x+XtuN9NA/f77gEK87SndxyIKY/cKDEQa0G4Fv/Y g4cL8ayaDzAtu9klwh6Y7D5y/3mTZMe4X8WbQWYita4osBZ1NKlRxoUt3t5j6k2o 67fd87texxtwu2zcfa+qkZ3VjxCKG+5wQQC5EDJnCxJiEUBu84pKMpTM/I1YIoKJ EZ8NYbeV/x8LbnkhptHU7KgSrVhuZnEcnQzoPj+czkpDCgEDJkTSwYCL6CpjOPnK YH2lyFdDYjnaGNwI+cIUSUlkP/mUG2OCvrCU2mTpLd/Hhncrpf4fGInTl/naE4Ir onhP9uMC =p0HF -----END PGP SIGNATURE----- --UoQnh8DjDgfWLrgi--