mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH 1/2] mvebu: make boards pass initial memory size
Date: Mon, 13 Feb 2017 09:06:05 +0100	[thread overview]
Message-ID: <20170213080605.4v3ldwhyk7xtiodq@pengutronix.de> (raw)
In-Reply-To: <20170210155100.16463-2-u.kleine-koenig@pengutronix.de>

Hi Uwe,

On Fri, Feb 10, 2017 at 04:50:59PM +0100, Uwe Kleine-König wrote:
> While assuming SZ_64M initially is save and fixed up later, the size of the
> malloc area is determined from this value. So it might make sense for some
> boards to pass the correct version from the start to have more RAM available
> for example to write big images into an FPGA.
> 
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
>  arch/arm/boards/globalscale-guruplug/lowlevel.c    |  2 +-
>  arch/arm/boards/globalscale-mirabox/lowlevel.c     |  2 +-
>  arch/arm/boards/lenovo-ix4-300d/lowlevel.c         |  2 +-
>  arch/arm/boards/marvell-armada-xp-gp/lowlevel.c    |  2 +-
>  arch/arm/boards/netgear-rn104/lowlevel.c           |  2 +-
>  arch/arm/boards/netgear-rn2120/lowlevel.c          |  2 +-
>  arch/arm/boards/plathome-openblocks-a6/lowlevel.c  |  2 +-
>  arch/arm/boards/plathome-openblocks-ax3/lowlevel.c |  2 +-
>  arch/arm/boards/solidrun-cubox/lowlevel.c          |  2 +-
>  arch/arm/boards/usi-topkick/lowlevel.c             |  2 +-
>  arch/arm/mach-mvebu/include/mach/lowlevel.h        |  2 +-
>  arch/arm/mach-mvebu/lowlevel.c                     | 15 +++++++--------
>  12 files changed, 18 insertions(+), 19 deletions(-)
> 
>  /*
>   * Determining the actual memory size is highly SoC dependent,
> - * but for all SoCs RAM starts at 0x00000000. Therefore, we start
> - * with a minimal memory setup of 64M and probe correct memory size
> - * later.
> + * but for all SoCs RAM starts at 0x00000000. If the available RAM isn't known
> + * at the call-site of mvebu_barebox_entry, using a value that is not too big is
> + * safe. The correct memory size will be probed later.
>   */
>  #define MVEBU_BOOTUP_MEMORY_BASE	0x00000000
> -#define MVEBU_BOOTUP_MEMORY_SIZE	SZ_64M
>  
> -void __naked __noreturn mvebu_barebox_entry(void *boarddata)
> +void __naked __noreturn mvebu_barebox_entry(void *boarddata,
> +					    unsigned long memsize)
>  {
>  	mvebu_remap_registers();
> -	barebox_arm_entry(MVEBU_BOOTUP_MEMORY_BASE,
> -			  MVEBU_BOOTUP_MEMORY_SIZE, boarddata);
> +	barebox_arm_entry(MVEBU_BOOTUP_MEMORY_BASE, memsize, boarddata);
>  }

I would prefer if you could split mvebu_barebox_entry into
armada_370_xp_barebox_entry, dove_barebox_entry and
kirkwood_barebox_entry. Then you could call the SoC specific SDRAM
detection functions and call barebox with the correct amount of SDRAM
from the start.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2017-02-13  8:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-10 15:50 [PATCH 0/2] mvebu: make more RAM available from malloc Uwe Kleine-König
2017-02-10 15:50 ` [PATCH 1/2] mvebu: make boards pass initial memory size Uwe Kleine-König
2017-02-13  8:06   ` Sascha Hauer [this message]
2017-02-10 15:51 ` [PATCH 2/2] netgear-rn2120: use complete memory from the start Uwe Kleine-König

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=20170213080605.4v3ldwhyk7xtiodq@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=u.kleine-koenig@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