[U-Boot] [PATCH v2] board_f: Only reserve memory for U-Boot if we're going to relocate
In case of no relocation we'll just waste some space at the very end of usable memory area. If target device has very limited amount of memory (for example 256 kB) this loss will be pretty inconvenient.
Signed-off-by: Alexey Brodkin abrodkin@synopsys.com Reviewed-by: 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 ---
Changes v1 -> v2: * Updated commit message as suggested by Simon
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 fa667c764bc6..e943347ce3df 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -394,19 +394,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;
On 25 May 2018 at 07:08, Alexey Brodkin Alexey.Brodkin@synopsys.com wrote:
In case of no relocation we'll just waste some space at the very end of usable memory area. If target device has very limited amount of memory (for example 256 kB) this loss will be pretty inconvenient.
Signed-off-by: Alexey Brodkin abrodkin@synopsys.com Reviewed-by: 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
Changes v1 -> v2:
- Updated commit message as suggested by Simon
common/board_f.c | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
Hi Tom,
On Sat, 2018-05-26 at 18:53 -0600, Simon Glass wrote:
On 25 May 2018 at 07:08, Alexey Brodkin Alexey.Brodkin@synopsys.com wrote:
In case of no relocation we'll just waste some space at the very end of usable memory area. If target device has very limited amount of memory (for example 256 kB) this loss will be pretty inconvenient.
Signed-off-by: Alexey Brodkin abrodkin@synopsys.com Reviewed-by: 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
Changes v1 -> v2:
- Updated commit message as suggested by Simon
common/board_f.c | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
Any chance to get this one applied? It's been sitting in patchwork for some time now.
-Alexey
On Fri, May 25, 2018 at 04:08:14PM +0300, Alexey Brodkin wrote:
In case of no relocation we'll just waste some space at the very end of usable memory area. If target device has very limited amount of memory (for example 256 kB) this loss will be pretty inconvenient.
Signed-off-by: Alexey Brodkin abrodkin@synopsys.com Reviewed-by: 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 Reviewed-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!
participants (3)
-
Alexey Brodkin -
Simon Glass -
Tom Rini