Linux-Rockchip Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Marty E. Plummer" <hanetzer@startmail.com>
To: Kever Yang <kever.yang@rock-chips.com>
Cc: vagrant@debian.org, u-boot@lists.denx.de,
	linux-rockchip@lists.infradead.org
Subject: Re: [PATCH 3/3] rockchip: fix incorrect detection of ram size
Date: Sun, 6 May 2018 21:34:14 -0500	[thread overview]
Message-ID: <20180507023413.mil4wj7xtjy6gnuw@proprietary-killer> (raw)
In-Reply-To: <6a0116f8-fd8a-dd53-2759-0014c7ab2700@rock-chips.com>

On Mon, May 07, 2018 at 10:20:55AM +0800, Kever Yang wrote:
> Hi Marty,
> 
> 
> On 05/06/2018 10:25 PM, Marty E. Plummer wrote:
> > Taken from coreboot's src/soc/rockchip/rk3288/sdram.c
> >
> > Without this change, my u-boot build for the asus c201 chromebook (4GiB)
> > is incorrectly detected as 0 Bytes of ram.
> 
> I know the root cause for this issue, and I have a local patch for it.
> The rk3288 is 32bit, and 4GB size is just out of range, so we need to before
> the max size before return with '<<20'. Sorry for forgot to send it out.
> 
> >
> > Signed-off-by: Marty E. Plummer <hanetzer@startmail.com>
> > ---
> >  arch/arm/mach-rockchip/sdram_common.c | 62 ++++++++++++++++-----------
> >  1 file changed, 37 insertions(+), 25 deletions(-)
> >
> > diff --git a/arch/arm/mach-rockchip/sdram_common.c b/arch/arm/mach-rockchip/sdram_common.c
> > index 76dbdc8715..a9c9f970a4 100644
> > --- a/arch/arm/mach-rockchip/sdram_common.c
> > +++ b/arch/arm/mach-rockchip/sdram_common.c
> > @@ -10,6 +10,8 @@
> >  #include <asm/io.h>
> >  #include <asm/arch/sdram_common.h>
> >  #include <dm/uclass-internal.h>
> > +#include <linux/kernel.h>
> > +#include <linux/sizes.h>
> >  
> >  DECLARE_GLOBAL_DATA_PTR;
> >  size_t rockchip_sdram_size(phys_addr_t reg)
> > @@ -19,34 +21,44 @@ size_t rockchip_sdram_size(phys_addr_t reg)
> >  	size_t size_mb = 0;
> >  	u32 ch;
> >  
> > -	u32 sys_reg = readl(reg);
> > -	u32 ch_num = 1 + ((sys_reg >> SYS_REG_NUM_CH_SHIFT)
> > -		       & SYS_REG_NUM_CH_MASK);
> > +	if (!size_mb) {
> 
> I don't understand this and follow up changes, we don't really need it,
> isn't it?
> I think don't need the changes before here.
Yeah, that was just another level of indentation for the if (!size_mb)
guard, but I've reworked the patch to not do that as it was pointed out
that since size_mb is initialized to 0 prior.
> > +		/*
> > +		 * we use the 0x00000000~0xfeffffff space
> > +		 * since 0xff000000~0xffffffff is soc register space
> > +		 * so we reserve it
> > +		 */
> > +		size_mb = min(size_mb, 0xff000000/SZ_1M);
> 
> This is what we really need, as Klaus point out, we need to use
> SDRAM_MAX_SIZE
> instead of hard code.
Yeah, I've got a rework on that which uses SDRAM_MAX_SIZE as instructed,
build and boot tested on my hardware.
> 
> Thanks,
> - Kever
> >  	}
> >  
> >  	return (size_t)size_mb << 20;
> 
> 
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

  reply	other threads:[~2018-05-07  2:34 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-06 14:25 [PATCH 0/3] add support for the asus C201 chromebook (4GiB) Marty E. Plummer
     [not found] ` <20180506142513.19911-1-hanetzer-zVALfsKDk1AS+FvcfC7Uqw@public.gmane.org>
2018-05-06 14:25   ` [PATCH 1/3] sf: Add GigaDevice gd25q32b entry Marty E. Plummer
2018-05-09  8:57     ` [U-Boot,1/3] " Philipp Tomsich
2018-05-06 14:25   ` [PATCH 2/3] rockchip: add support for veyron-speedy (ASUS Chromebook C201) Marty E. Plummer
2018-05-06 14:25   ` [PATCH 3/3] rockchip: fix incorrect detection of ram size Marty E. Plummer
2018-05-06 22:19     ` Dr. Philipp Tomsich
2018-05-07  0:25       ` Marty E. Plummer
2018-05-07  2:20     ` Kever Yang
2018-05-07  2:34       ` Marty E. Plummer [this message]
2018-05-07  9:16         ` Dr. Philipp Tomsich
     [not found]           ` <791299C0-EEC0-4DB1-97C4-A8DAD3B1A481-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org>
2018-05-08  0:52             ` [U-Boot] " Marty E. Plummer
2018-05-08 10:21               ` Dr. Philipp Tomsich
2018-05-08 10:23                 ` Dr. Philipp Tomsich
2018-05-08 19:21                 ` Marty E. Plummer
2018-05-08 21:08                   ` Dr. Philipp Tomsich
     [not found]                     ` <C5B7DFAE-C5CA-4D9E-B6CB-C44E9AD974E9-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org>
2018-05-09  5:29                       ` [U-Boot] " Marty E. Plummer
2018-05-09  7:24                         ` Dr. Philipp Tomsich
2018-05-14 15:56                           ` Dr. Philipp Tomsich
2018-07-10 14:41                 ` Simon Glass
2018-07-10 18:55                   ` Dr. Philipp Tomsich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180507023413.mil4wj7xtjy6gnuw@proprietary-killer \
    --to=hanetzer@startmail.com \
    --cc=kever.yang@rock-chips.com \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=u-boot@lists.denx.de \
    --cc=vagrant@debian.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox