| Message ID | 20180125175605.6873-1-abrodkin@synopsys.com |
|---|---|
| State | Changes Requested |
| Delegated to: | Simon Glass |
| Headers | show |
| Series | [U-Boot] board_f: Only reserve memory for U-Boot if we're going to relocate | expand |
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>
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
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
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;
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(-)