public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: Chris Morgan <macromorgan@hotmail.com>
Cc: Eugen Hristev <eugen.hristev@collabora.com>,
	Kever Yang <kever.yang@rock-chips.com>,
	Chris Morgan <macroalpha82@gmail.com>,
	u-boot@lists.denx.de, xypron.glpk@gmx.de, cym@rock-chips.com,
	philipp.tomsich@vrull.eu, sjg@chromium.org, jonas@kwiboo.se
Subject: Re: [PATCH 1/2] rockchip: rk3588: Add support for ATAG parsing
Date: Thu, 28 Mar 2024 16:02:09 -0400	[thread overview]
Message-ID: <20240328200209.GE3442575@bill-the-cat> (raw)
In-Reply-To: <DM4PR05MB92298DB9B7803B3E0ABC0137A5342@DM4PR05MB9229.namprd05.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 3613 bytes --]

On Wed, Mar 27, 2024 at 10:03:11AM -0500, Chris Morgan wrote:
> On Wed, Mar 27, 2024 at 04:21:49PM +0200, Eugen Hristev wrote:
> > On 3/27/24 15:32, Chris Morgan wrote:
> > > On Wed, Mar 27, 2024 at 06:32:06PM +0800, Kever Yang wrote:
> > >> Hi Chris,
> > >>
> > >>     The ATAGS is used for passing parameter from bootloader to kernel at
> > >> first, which has been replaced by DTB now for ARM platform.
> > >>
> > >>     And Rockchip using ATAGs for passing parameter like dram memory
> > >> size/board uart in different boot process like DRAM init binary/ TPL/SPL to
> > >> U-Boot since 2018.
> > >>
> > >>     And almost at the same time, Simon add bloblist for mainline U-Boot
> > >> which for similar purpose.
> > >>
> > >>     So I'm not sure if this ATAGS should be accept in mainline U-Boot or
> > >> not, even for rockchip platform only seems some kind of regression for this
> > >> feature support.
> > >>
> > >>
> > >> Hi Simon and Tom,
> > >>
> > >>      Could you help to give some suggestion for this?
> > >>
> > > 
> > > I really meant to do this as an "RFC", so I apologize in advance for
> > > possibly causing more work in treating this as a full-fledged patch.
> > > 
> > > The problem I'm trying to solve is that I've got 2 boards, a Rock 5B
> > > as well as an Indiedroid Nova both with 16GB of RAM. I noticed that
> > > without the memory holes the Rock 5B defined in my Indiedroid it would
> > > also fail to boot. I've got 2 other boards as well with less than 16GB
> > > of RAM which seem to work fine without any holes (a 4GB Indiedroid Nova
> > > prototype and a GameForce Ace with 12GB of RAM).
> > 
> > Hi,
> > 
> > When I initially added these holes in the memory, I tried to ask Rockchip what are
> > the holes for. I didn't get any answer, however the patches to reserve the holes
> > were accepted.
> > If we could get more information about why the holes are there, if that area is
> > specific to something, or that it's fixed in a per-SoC basis, we could reserve it
> > by hardcoding in the Linux DT, without the need for ATAGs.
> > Without real information, we cannot be sure that for other variants of the SoC or
> > some other bootrom configuration, the holes will not change/move.
> > 
> > Eugen
> 
> It's not *just* about the holes, but also making sure we use the full
> extent of the RAM. For example on my 4GB Indiedroid Nova the existing
> logic ignores about 256MB of RAM that's otherwise present. When we
> use the existing code the RAM map reported by Linux is as follows:
> 
> [    0.000000] Early memory node ranges
> [    0.000000]   node   0: [mem 0x0000000000200000-0x00000000efffffff]
> 
> Whereas when we do ATAGS parsing to set the banks we get the following:
> 
> [    0.000000] Early memory node ranges
> [    0.000000]   node   0: [mem 0x0000000000200000-0x00000000efffffff]
> [    0.000000]   node   0: [mem 0x00000001f0000000-0x00000001ffffffff]
> 
> So basically the issue is two-fold... one we need to create the memory
> holes when necessary, and two the current method of defining memory
> banks leaves some RAM unallocated. Parsing the ATAGS does both of these,
> I'm just curious if it's the RIGHT way or there's something else I'm
> missing...

It's unfortunate that all of this is in the wild, from the Rockchip
side. The best answer is that the platform should be passing all of this
along via bloblist. I would hope that future platforms will do that. For
now yes, I guess we need to constrain this ATAG parsing to rockchip as
much as we can and use it.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

  reply	other threads:[~2024-03-28 20:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-26 20:49 [PATCH 0/2] Use ATAGs for RK3588 For RAM Info Chris Morgan
2024-03-26 20:49 ` [PATCH 1/2] rockchip: rk3588: Add support for ATAG parsing Chris Morgan
2024-03-27  9:45   ` Quentin Schulz
2024-03-27 10:32   ` Kever Yang
2024-03-27 12:12     ` Tom Rini
2024-03-27 13:32     ` Chris Morgan
2024-03-27 14:21       ` Eugen Hristev
2024-03-27 15:03         ` Chris Morgan
2024-03-28 20:02           ` Tom Rini [this message]
2024-03-28 21:58             ` Chris Morgan
2024-03-28 22:13               ` Tom Rini
2024-03-26 20:49 ` [PATCH 2/2] rockchip: rk3588: Add Support for RAM Defines from ATAGs Chris Morgan
2024-03-27 10:51   ` Quentin Schulz
2024-03-27 13:10     ` Jonas Karlman

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=20240328200209.GE3442575@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=cym@rock-chips.com \
    --cc=eugen.hristev@collabora.com \
    --cc=jonas@kwiboo.se \
    --cc=kever.yang@rock-chips.com \
    --cc=macroalpha82@gmail.com \
    --cc=macromorgan@hotmail.com \
    --cc=philipp.tomsich@vrull.eu \
    --cc=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    --cc=xypron.glpk@gmx.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