[U-Boot] [PATCH] board_f: Only reserve memory for U-Boot if we're going to relocate

[U-Boot] [PATCH] board_f: Only reserve memory for U-Boot if we're going to relocate

[Alexey Brodkin]

In case of no relocation we'll just waste some paceat the very end
of usable memory area. If U-Boot is huge and we cannot use a lot of memory this
loss will be pretty inconvenient.

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: York Sun <york.sun@nxp.com>
Cc: Stefan Roese <sr@denx.de>
---
 common/board_f.c | 28 +++++++++++++++-------------
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/common/board_f.c b/common/board_f.c
index 92743089087e..d1662199a570 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -396,19 +396,21 @@ static int reserve_trace(void)
 
 static int reserve_uboot(void)
 {
-	/*
-	 * reserve memory for U-Boot code, data & bss
-	 * round down to next 4 kB limit
-	 */
-	gd->relocaddr -= gd->mon_len;
-	gd->relocaddr &= ~(4096 - 1);
-#if defined(CONFIG_E500) || defined(CONFIG_MIPS)
-	/* round down to next 64 kB limit so that IVPR stays aligned */
-	gd->relocaddr &= ~(65536 - 1);
-#endif
-
-	debug("Reserving %ldk for U-Boot at: %08lx\n", gd->mon_len >> 10,
-	      gd->relocaddr);
+	if (!(gd->flags & GD_FLG_SKIP_RELOC)) {
+		/*
+		 * reserve memory for U-Boot code, data & bss
+		 * round down to next 4 kB limit
+		 */
+		gd->relocaddr -= gd->mon_len;
+		gd->relocaddr &= ~(4096 - 1);
+	#if defined(CONFIG_E500) || defined(CONFIG_MIPS)
+		/* round down to next 64 kB limit so that IVPR stays aligned */
+		gd->relocaddr &= ~(65536 - 1);
+	#endif
+
+		debug("Reserving %ldk for U-Boot at: %08lx\n",
+		      gd->mon_len >> 10, gd->relocaddr);
+	}
 
 	gd->start_addr_sp = gd->relocaddr;
 
-- 
2.14.3

[U-Boot] [PATCH] board_f: Only reserve memory for U-Boot if we're going to relocate

[Simon Glass]

Hi Alexey,

On 25 January 2018 at 10:56, Alexey Brodkin <Alexey.Brodkin@synopsys.com> wrote:
> In case of no relocation we'll just waste some paceat the very end

space at?

> of usable memory area. If U-Boot is huge and we cannot use a lot of memory this

What do you mean by 'U-Boot is huge'? How huge, and why would it be huge?

> loss will be pretty inconvenient.
>
> Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Bin Meng <bmeng.cn@gmail.com>
> Cc: Heiko Schocher <hs@denx.de>
> Cc: York Sun <york.sun@nxp.com>
> Cc: Stefan Roese <sr@denx.de>
> ---
>  common/board_f.c | 28 +++++++++++++++-------------
>  1 file changed, 15 insertions(+), 13 deletions(-)
>

Other than that:

Reviewed-by: Simon Glass <sjg@chromium.org>

[U-Boot] [PATCH] board_f: Only reserve memory for U-Boot if we're going to relocate

[Alexey Brodkin]

Hi Simon,

On Sun, 2018-02-04 at 06:40 -0700, Simon Glass wrote:
> Hi Alexey,
> 
> On 25 January 2018 at 10:56, Alexey Brodkin <Alexey.Brodkin@synopsys.com> wrote:
> > In case of no relocation we'll just waste some paceat the very end
> 
> space at?

Sure, thanks for pointing out!

> 
> > of usable memory area. If U-Boot is huge and we cannot use a lot of memory this
> 
> What do you mean by 'U-Boot is huge'? How huge, and why would it be huge?

I was talking about relative sizes of U-Boot compared to available RAM.
Consider we have less than 1 Mb of RAM and U-Boot's size is ~200 kB - in that
case looking 20% of RAM is not what we really want.

In more typical case when we have tens, hundreds or thousands of megabytes of RAM
essentially loosing even another megabyte makes not much sense :)


-Alexey

[U-Boot] [PATCH] board_f: Only reserve memory for U-Boot if we're going to relocate

[Simon Glass]

Hi Alexey,

On 20 February 2018 at 09:28, Alexey Brodkin
<Alexey.Brodkin@synopsys.com> wrote:
> Hi Simon,
>
> On Sun, 2018-02-04 at 06:40 -0700, Simon Glass wrote:
>> Hi Alexey,
>>
>> On 25 January 2018 at 10:56, Alexey Brodkin <Alexey.Brodkin@synopsys.com> wrote:
>> > In case of no relocation we'll just waste some paceat the very end
>>
>> space at?
>
> Sure, thanks for pointing out!
>
>>
>> > of usable memory area. If U-Boot is huge and we cannot use a lot of memory this
>>
>> What do you mean by 'U-Boot is huge'? How huge, and why would it be huge?
>
> I was talking about relative sizes of U-Boot compared to available RAM.
> Consider we have less than 1 Mb of RAM and U-Boot's size is ~200 kB - in that
> case looking 20% of RAM is not what we really want.
>
> In more typical case when we have tens, hundreds or thousands of megabytes of RAM
> essentially loosing even another megabyte makes not much sense :)
>
OK I see, so really is it the memory which is small, rather than
U-Boot that is huge? If so, can you please update the commit message?

Regards,
Simon