
Hi Alexey,
On 20 February 2018 at 10:54, Alexey Brodkin Alexey.Brodkin@synopsys.com wrote:
Hi Simon, Tom,
On Sun, 2018-02-04 at 06:40 -0700, Simon Glass wrote:
On 25 January 2018 at 11:22, Alexey Brodkin Alexey.Brodkin@synopsys.com wrote:
From: Alexey Brodkin Alexey.Brodkin@synopsys.com
Disabling relocation might be useful on ARC for 2 reasons: a) For advanced debugging with Synopsys proprietary MetaWare debugger which is capable of accessing much more specific hardware resources compared to gdb. For example it may show contents of L1 and L2 caches, internal states of some hardware blocks etc.
But on the downside MetaWare debugger still cannot work with PIE. Even though that limitation could be work-arounded with change of ELF's header and stripping down all debug info but with it we won't have debug info for source-level debugging which is quite inconvenient.
b) Some platforms which might benefit from usage of U-Boot basically don't have enough RAM to accommodate relocation of U-Boot so we keep code in flash and use as much of RAM as possible for more interesting things.
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
arch/arc/lib/relocate.c | 6 ++++++ arch/arc/lib/start.S | 8 +++++++- common/board_f.c | 3 ++- 3 files changed, 15 insertions(+), 2 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
Is it OK if I pull this into my "next" tree?
I'm asking because common/board_f.c is affected even though that's just an addition of CONFIG_ARC in one #ifdef.
It is OK with me.
Regards, Simon