mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Alexander Shiyan <eagle.alexander923@gmail.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Michael Tretter <m.tretter@pengutronix.de>, barebox@lists.infradead.org
Subject: Re: [PATCH] ARM: rockchip: dmc: fix DRAM for sizes 16+ GiB on rk3588
Date: Mon, 14 Apr 2025 08:15:50 +0300	[thread overview]
Message-ID: <CAP1tNvTVK-Ukt0Y4_iTEOM_gdxnU6rfJ9C08m+ZArPdZOro=5Q@mail.gmail.com> (raw)
In-Reply-To: <Z_lBnMOJQNNN4T6l@pengutronix.de>

Hello.

This is probably exactly the case I encountered at the time. [1]
For myself, I solved this problem through the device tree. [2]
Let's see which solution to the problem will be better.

[1] https://lore.pengutronix.de/barebox/CAP1tNvS_BwD_gXcDwMH61DY9Vtg1GSY7gsy8Wr9vaE+KsqabAg@mail.gmail.com/T/
[2] https://github.com/MacroGroup/barebox/blob/macro/arch/arm/dts/rk3588-diasom-btb.dtsi#L234

Thanks!

пт, 11 апр. 2025 г. в 19:22, Sascha Hauer <s.hauer@pengutronix.de>:
>
> On Fri, Apr 11, 2025 at 05:20:20PM +0200, Michael Tretter wrote:
> > RK3588 has two known memory gaps when using 16+ GiB DRAM,
> > [0x3fc000000, 0x3fc500000) and [0x3fff00000, 0x400000000).
> >
> > Skip both gaps when initializing the DRAM on rk3588 to avoid running
> > into an exception when running memtest on an rk3588 board with 16+ GiB
> > DRAM.
> >
> > The information about the gaps is taken from a patch by Jonas Karlman to
> > the U-Boot mailing list [0].
> >
> > [0] https://lore.kernel.org/all/20250405153832.1427549-5-jonas@kwiboo.se/
> >
> > Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
> > ---
> > The start and end addresses of the gaps probably should be put into of
> > rockchip_dmc_drvdata and only set for the rk3588. Any suggestion how to
> > implement this more nicely would be very welcome.
>
> Looks like the rk3588 currently is the only SoC that can have that much
> memory that it hits the gaps. You could add a comment that the gaps are
> only verified on rk3588 and need another look once the next SoC is
> added.
>
> Once we are there we can add a function pointer into struct rockchip_dmc_drvdata
> doing the right thing, but I think for now it's fine the way you did it.
>
> Sascha
>
> > ---
> >  arch/arm/mach-rockchip/dmc.c | 20 ++++++++++++++++++--
> >  1 file changed, 18 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/mach-rockchip/dmc.c b/arch/arm/mach-rockchip/dmc.c
> > index 86e61f311661..cf63fdb5a8bb 100644
> > --- a/arch/arm/mach-rockchip/dmc.c
> > +++ b/arch/arm/mach-rockchip/dmc.c
> > @@ -27,6 +27,12 @@
> >  #define RK3568_INT_REG_START         RK3399_INT_REG_START
> >  #define RK3588_INT_REG_START         RK3399_INT_REG_START
> >
> > +/* RK3588 has two known memory gaps when using 16+ GiB DRAM */
> > +#define DRAM_GAP1_START         0x3fc000000
> > +#define DRAM_GAP1_END           0x3fc500000
> > +#define DRAM_GAP2_START         0x3fff00000
> > +#define DRAM_GAP2_END           0x400000000
> > +
> >  struct rockchip_dmc_drvdata {
> >       unsigned int os_reg2;
> >       unsigned int os_reg3;
> > @@ -220,9 +226,19 @@ static int rockchip_dmc_probe(struct device *dev)
> >       arm_add_mem_device("ram0", membase,
> >               min_t(resource_size_t, drvdata->internal_registers_start, memsize) - membase);
> >
> > -     /* ram1, remaining RAM beyond 32bit space */
> > +     /* ram1, RAM beyond 32bit space up to first gap */
> >       if (memsize > SZ_4G)
> > -             arm_add_mem_device("ram1", SZ_4G, memsize - SZ_4G);
> > +             arm_add_mem_device("ram1", SZ_4G,
> > +                     min_t(resource_size_t, DRAM_GAP1_START, memsize) - SZ_4G);
> > +
> > +     /* ram2, RAM between first and second gap */
> > +     if (memsize > DRAM_GAP1_END)
> > +             arm_add_mem_device("ram2", DRAM_GAP1_END,
> > +                     min_t(resource_size_t, DRAM_GAP2_START, memsize) - DRAM_GAP1_END);
> > +
> > +     /* ram3, remaining RAM after second gap */
> > +     if (memsize > DRAM_GAP2_END)
> > +             arm_add_mem_device("ram3", DRAM_GAP2_END, memsize - DRAM_GAP2_END);
> >
> >       return 0;
> >  }
> > --
> > 2.39.5
> >
> >
> >
>
> --
> Pengutronix e.K.                           |                             |
> Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
>



      reply	other threads:[~2025-04-14  5:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-11 15:20 Michael Tretter
2025-04-11 16:21 ` Sascha Hauer
2025-04-14  5:15   ` Alexander Shiyan [this message]

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='CAP1tNvTVK-Ukt0Y4_iTEOM_gdxnU6rfJ9C08m+ZArPdZOro=5Q@mail.gmail.com' \
    --to=eagle.alexander923@gmail.com \
    --cc=barebox@lists.infradead.org \
    --cc=m.tretter@pengutronix.de \
    --cc=s.hauer@pengutronix.de \
    /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