[U-Boot] [RFC PATCH] dm: Add support for all targets which requires MANUAL_RELOC
Targets with CONFIG_NEEDS_MANUAL_RELOC do not use REL/RELA relocation (mostly only GOT) where functions aray are not updated. This patch is fixing function pointers for DM core and serial-uclass to ensure that relocated functions are called.
Signed-off-by: Michal Simek michal.simek@xilinx.com ---
drivers/core/root.c | 64 ++++++++++++++++++++++++++++++++++++++++++ drivers/serial/serial-uclass.c | 16 +++++++++++ 2 files changed, 80 insertions(+)
diff --git a/drivers/core/root.c b/drivers/core/root.c index 47b3acfbe981..1a5287b2fe08 100644 --- a/drivers/core/root.c +++ b/drivers/core/root.c @@ -36,6 +36,65 @@ struct udevice *dm_root(void) return gd->dm_root; }
+#if defined(CONFIG_NEEDS_MANUAL_RELOC) +void fix_drivers(void) +{ + struct driver *drv = + ll_entry_start(struct driver, driver); + const int n_ents = ll_entry_count(struct driver, driver); + struct driver *entry; + + for (entry = drv; entry != drv + n_ents; entry++) { + if (entry->of_match) + entry->of_match = (const struct udevice_id *) + ((u32)entry->of_match + gd->reloc_off); + if (entry->bind) + entry->bind += gd->reloc_off; + if (entry->probe) + entry->probe += gd->reloc_off; + if (entry->remove) + entry->remove += gd->reloc_off; + if (entry->unbind) + entry->unbind += gd->reloc_off; + if (entry->ofdata_to_platdata) + entry->ofdata_to_platdata += gd->reloc_off; + if (entry->child_pre_probe) + entry->child_pre_probe += gd->reloc_off; + if (entry->child_post_remove) + entry->child_post_remove += gd->reloc_off; + /* OPS are fixed in every uclass post_probe function */ + if (entry->ops) + entry->ops += gd->reloc_off; + } +} + +void fix_uclass(void) +{ + struct uclass_driver *uclass = + ll_entry_start(struct uclass_driver, uclass); + const int n_ents = ll_entry_count(struct uclass_driver, uclass); + struct uclass_driver *entry; + + for (entry = uclass; entry != uclass + n_ents; entry++) { + if (entry->post_bind) + entry->post_bind += gd->reloc_off; + if (entry->pre_unbind) + entry->pre_unbind += gd->reloc_off; + if (entry->post_probe) + entry->post_probe += gd->reloc_off; + if (entry->pre_remove) + entry->pre_remove += gd->reloc_off; + if (entry->init) + entry->init += gd->reloc_off; + if (entry->destroy) + entry->destroy += gd->reloc_off; + /* FIXME maybe also need to fix these ops */ + if (entry->ops) + entry->ops += gd->reloc_off; + } +} +#endif + int dm_init(void) { int ret; @@ -46,6 +105,11 @@ int dm_init(void) } INIT_LIST_HEAD(&DM_UCLASS_ROOT_NON_CONST);
+#if defined(CONFIG_NEEDS_MANUAL_RELOC) + fix_drivers(); + fix_uclass(); +#endif + ret = device_bind_by_name(NULL, false, &root_info, &DM_ROOT_NON_CONST); if (ret) return ret; diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c index d1b5777cecda..f13484b8539c 100644 --- a/drivers/serial/serial-uclass.c +++ b/drivers/serial/serial-uclass.c @@ -258,6 +258,22 @@ static int serial_post_probe(struct udevice *dev) #endif int ret;
+#if defined(CONFIG_NEEDS_MANUAL_RELOC) + if (ops->setbrg) + ops->setbrg += gd->reloc_off; + if (ops->getc) + ops->getc += gd->reloc_off; + if (ops->putc) + ops->putc += gd->reloc_off; + if (ops->pending) + ops->pending += gd->reloc_off; + if (ops->clear) + ops->clear += gd->reloc_off; +#if CONFIG_POST & CONFIG_SYS_POST_UART + if (ops->loop) + ops->loop += gd->reloc_off +#endif +#endif /* Set the baud rate */ if (ops->setbrg) { ret = ops->setbrg(dev, gd->baudrate); -- 1.8.2.3
Hi Michal,
On 2 February 2015 at 08:31, Michal Simek michal.simek@xilinx.com wrote:
Targets with CONFIG_NEEDS_MANUAL_RELOC do not use REL/RELA relocation (mostly only GOT) where functions aray are not updated. This patch is fixing function pointers for DM core and serial-uclass to ensure that relocated functions are called.
Signed-off-by: Michal Simek michal.simek@xilinx.com
drivers/core/root.c | 64 ++++++++++++++++++++++++++++++++++++++++++ drivers/serial/serial-uclass.c | 16 +++++++++++ 2 files changed, 80 insertions(+)
How long will we have to carry this patch? It seems that if we add any new driver we will have to add more code like this?
Regards, Simon
Hi.
On Mon, 2 Feb 2015 16:57:15 -0700 Simon Glass sjg@chromium.org wrote:
Hi Michal,
On 2 February 2015 at 08:31, Michal Simek michal.simek@xilinx.com wrote:
Targets with CONFIG_NEEDS_MANUAL_RELOC do not use REL/RELA relocation (mostly only GOT) where functions aray are not updated. This patch is fixing function pointers for DM core and serial-uclass to ensure that relocated functions are called.
Signed-off-by: Michal Simek michal.simek@xilinx.com
drivers/core/root.c | 64 ++++++++++++++++++++++++++++++++++++++++++ drivers/serial/serial-uclass.c | 16 +++++++++++ 2 files changed, 80 insertions(+)
How long will we have to carry this patch? It seems that if we add any new driver we will have to add more code like this?
This patch is unfortunate. Can we discontinue CONFIG_NEEDS_MANUAL_RELOC some day?
If we use SPL, we do not have to relocate code, I think.
Best Regards Masahiro Yamada
Hi Simon,
On 02/03/2015 03:02 AM, Masahiro Yamada wrote:
Hi.
On Mon, 2 Feb 2015 16:57:15 -0700 Simon Glass sjg@chromium.org wrote:
Hi Michal,
On 2 February 2015 at 08:31, Michal Simek michal.simek@xilinx.com wrote:
Targets with CONFIG_NEEDS_MANUAL_RELOC do not use REL/RELA relocation (mostly only GOT) where functions aray are not updated. This patch is fixing function pointers for DM core and serial-uclass to ensure that relocated functions are called.
Signed-off-by: Michal Simek michal.simek@xilinx.com
drivers/core/root.c | 64 ++++++++++++++++++++++++++++++++++++++++++ drivers/serial/serial-uclass.c | 16 +++++++++++ 2 files changed, 80 insertions(+)
How long will we have to carry this patch? It seems that if we add any new driver we will have to add more code like this?
This patch is unfortunate. Can we discontinue CONFIG_NEEDS_MANUAL_RELOC some day?
This patch (or similar one) has to be alive when we have platform which requires CONFIG_NEEDS_MANUAL_RELOC for full u-boot. There is an option to move to REL/RELA but the question is if all platforms have it/support it. Unfortunately I think that it will be in the tree for a long time.
If we use SPL, we do not have to relocate code, I think.
SPL doesn't have relocation that's why this code is not used there.
Thanks, Michal
Hi Michal,
On 3 February 2015 at 02:11, Michal Simek michal.simek@xilinx.com wrote:
Hi Simon,
On 02/03/2015 03:02 AM, Masahiro Yamada wrote:
Hi.
On Mon, 2 Feb 2015 16:57:15 -0700 Simon Glass sjg@chromium.org wrote:
Hi Michal,
On 2 February 2015 at 08:31, Michal Simek michal.simek@xilinx.com wrote:
Targets with CONFIG_NEEDS_MANUAL_RELOC do not use REL/RELA relocation (mostly only GOT) where functions aray are not updated. This patch is fixing function pointers for DM core and serial-uclass to ensure that relocated functions are called.
Signed-off-by: Michal Simek michal.simek@xilinx.com
drivers/core/root.c | 64 ++++++++++++++++++++++++++++++++++++++++++ drivers/serial/serial-uclass.c | 16 +++++++++++ 2 files changed, 80 insertions(+)
How long will we have to carry this patch? It seems that if we add any new driver we will have to add more code like this?
This patch is unfortunate. Can we discontinue CONFIG_NEEDS_MANUAL_RELOC some day?
This patch (or similar one) has to be alive when we have platform which requires CONFIG_NEEDS_MANUAL_RELOC for full u-boot. There is an option to move to REL/RELA but the question is if all platforms have it/support it. Unfortunately I think that it will be in the tree for a long time.
If we use SPL, we do not have to relocate code, I think.
SPL doesn't have relocation that's why this code is not used there.
Maybe I asked this before, but when can we remove CONFIG_NEEDS_MANUAL_RELOC? What platforms need it?
Regards, Simon
Hi Simon,
Maybe I asked this before, but when can we remove CONFIG_NEEDS_MANUAL_RELOC? What platforms need it?
A quick grep yields a global define of CONFIG_NEEDS_MANUAL_RELOC for avr32, m68k, nds32, and sparc
Next question is - which of these platforms have toolchains which lack the ability to generate the relocation tables that we need?
Regards,
Graeme
Hi,
On 02/04/2015 06:48 AM, Graeme Russ wrote:
Hi Simon,
Maybe I asked this before, but when can we remove CONFIG_NEEDS_MANUAL_RELOC? What platforms need it?
A quick grep yields a global define of CONFIG_NEEDS_MANUAL_RELOC for avr32, m68k, nds32, and sparc
+ Microblaze to move to generic board support now.
Next question is - which of these platforms have toolchains which lack the ability to generate the relocation tables that we need?
Microblaze have the option to generate relocation tables without need to use CONFIG_NEEDS_MANUAL_RELOC.
Thanks, Michal
Hi Michal,
On 3 February 2015 at 17:40, Simon Glass sjg@chromium.org wrote:
Hi Michal,
On 3 February 2015 at 02:11, Michal Simek michal.simek@xilinx.com wrote:
Hi Simon,
On 02/03/2015 03:02 AM, Masahiro Yamada wrote:
Hi.
On Mon, 2 Feb 2015 16:57:15 -0700 Simon Glass sjg@chromium.org wrote:
Hi Michal,
On 2 February 2015 at 08:31, Michal Simek michal.simek@xilinx.com wrote:
Targets with CONFIG_NEEDS_MANUAL_RELOC do not use REL/RELA relocation (mostly only GOT) where functions aray are not updated. This patch is fixing function pointers for DM core and serial-uclass to ensure that relocated functions are called.
Signed-off-by: Michal Simek michal.simek@xilinx.com
drivers/core/root.c | 64 ++++++++++++++++++++++++++++++++++++++++++ drivers/serial/serial-uclass.c | 16 +++++++++++ 2 files changed, 80 insertions(+)
How long will we have to carry this patch? It seems that if we add any new driver we will have to add more code like this?
This patch is unfortunate. Can we discontinue CONFIG_NEEDS_MANUAL_RELOC some day?
This patch (or similar one) has to be alive when we have platform which requires CONFIG_NEEDS_MANUAL_RELOC for full u-boot. There is an option to move to REL/RELA but the question is if all platforms have it/support it. Unfortunately I think that it will be in the tree for a long time.
If we use SPL, we do not have to relocate code, I think.
SPL doesn't have relocation that's why this code is not used there.
Maybe I asked this before, but when can we remove CONFIG_NEEDS_MANUAL_RELOC? What platforms need it?
Sorry if you answered these questions but can you please resend if so as I missed it.
Thanks, Simon
Hi,
On 02/05/2015 04:07 AM, Simon Glass wrote:
Hi Michal,
On 3 February 2015 at 17:40, Simon Glass sjg@chromium.org wrote:
Hi Michal,
On 3 February 2015 at 02:11, Michal Simek michal.simek@xilinx.com wrote:
Hi Simon,
On 02/03/2015 03:02 AM, Masahiro Yamada wrote:
Hi.
On Mon, 2 Feb 2015 16:57:15 -0700 Simon Glass sjg@chromium.org wrote:
Hi Michal,
On 2 February 2015 at 08:31, Michal Simek michal.simek@xilinx.com wrote:
Targets with CONFIG_NEEDS_MANUAL_RELOC do not use REL/RELA relocation (mostly only GOT) where functions aray are not updated. This patch is fixing function pointers for DM core and serial-uclass to ensure that relocated functions are called.
Signed-off-by: Michal Simek michal.simek@xilinx.com
drivers/core/root.c | 64 ++++++++++++++++++++++++++++++++++++++++++ drivers/serial/serial-uclass.c | 16 +++++++++++ 2 files changed, 80 insertions(+)
How long will we have to carry this patch? It seems that if we add any new driver we will have to add more code like this?
This patch is unfortunate. Can we discontinue CONFIG_NEEDS_MANUAL_RELOC some day?
This patch (or similar one) has to be alive when we have platform which requires CONFIG_NEEDS_MANUAL_RELOC for full u-boot. There is an option to move to REL/RELA but the question is if all platforms have it/support it. Unfortunately I think that it will be in the tree for a long time.
If we use SPL, we do not have to relocate code, I think.
SPL doesn't have relocation that's why this code is not used there.
Maybe I asked this before, but when can we remove CONFIG_NEEDS_MANUAL_RELOC? What platforms need it?
Sorry if you answered these questions but can you please resend if so as I missed it.
Graeme has answered it + my response here. http://lists.denx.de/pipermail/u-boot/2015-February/203911.html
removing: When all platforms are moved to REL/RELA we can remove this manual reloc option.
Thanks, Michal
On 4 February 2015 at 23:31, Michal Simek michal.simek@xilinx.com wrote:
Hi,
On 02/05/2015 04:07 AM, Simon Glass wrote:
Hi Michal,
On 3 February 2015 at 17:40, Simon Glass sjg@chromium.org wrote:
Hi Michal,
On 3 February 2015 at 02:11, Michal Simek michal.simek@xilinx.com wrote:
Hi Simon,
On 02/03/2015 03:02 AM, Masahiro Yamada wrote:
Hi.
On Mon, 2 Feb 2015 16:57:15 -0700 Simon Glass sjg@chromium.org wrote:
Hi Michal,
On 2 February 2015 at 08:31, Michal Simek michal.simek@xilinx.com wrote: > Targets with CONFIG_NEEDS_MANUAL_RELOC do not use REL/RELA > relocation (mostly only GOT) where functions aray are not > updated. This patch is fixing function pointers for DM core > and serial-uclass to ensure that relocated functions are called. > > Signed-off-by: Michal Simek michal.simek@xilinx.com > --- > > drivers/core/root.c | 64 ++++++++++++++++++++++++++++++++++++++++++ > drivers/serial/serial-uclass.c | 16 +++++++++++ > 2 files changed, 80 insertions(+)
How long will we have to carry this patch? It seems that if we add any new driver we will have to add more code like this?
This patch is unfortunate. Can we discontinue CONFIG_NEEDS_MANUAL_RELOC some day?
This patch (or similar one) has to be alive when we have platform which requires CONFIG_NEEDS_MANUAL_RELOC for full u-boot. There is an option to move to REL/RELA but the question is if all platforms have it/support it. Unfortunately I think that it will be in the tree for a long time.
If we use SPL, we do not have to relocate code, I think.
SPL doesn't have relocation that's why this code is not used there.
Maybe I asked this before, but when can we remove CONFIG_NEEDS_MANUAL_RELOC? What platforms need it?
Sorry if you answered these questions but can you please resend if so as I missed it.
Graeme has answered it + my response here. http://lists.denx.de/pipermail/u-boot/2015-February/203911.html
removing: When all platforms are moved to REL/RELA we can remove this manual reloc option.
With a heavy heart:
Acked-by: Simon Glass sjg@chromium.org
Hi Simon,
On 02/06/2015 06:45 AM, Simon Glass wrote:
On 4 February 2015 at 23:31, Michal Simek michal.simek@xilinx.com wrote:
Hi,
On 02/05/2015 04:07 AM, Simon Glass wrote:
Hi Michal,
On 3 February 2015 at 17:40, Simon Glass sjg@chromium.org wrote:
Hi Michal,
On 3 February 2015 at 02:11, Michal Simek michal.simek@xilinx.com wrote:
Hi Simon,
On 02/03/2015 03:02 AM, Masahiro Yamada wrote:
Hi.
On Mon, 2 Feb 2015 16:57:15 -0700 Simon Glass sjg@chromium.org wrote:
> Hi Michal, > > On 2 February 2015 at 08:31, Michal Simek michal.simek@xilinx.com wrote: >> Targets with CONFIG_NEEDS_MANUAL_RELOC do not use REL/RELA >> relocation (mostly only GOT) where functions aray are not >> updated. This patch is fixing function pointers for DM core >> and serial-uclass to ensure that relocated functions are called. >> >> Signed-off-by: Michal Simek michal.simek@xilinx.com >> --- >> >> drivers/core/root.c | 64 ++++++++++++++++++++++++++++++++++++++++++ >> drivers/serial/serial-uclass.c | 16 +++++++++++ >> 2 files changed, 80 insertions(+) > > How long will we have to carry this patch? It seems that if we add any > new driver we will have to add more code like this?
This patch is unfortunate. Can we discontinue CONFIG_NEEDS_MANUAL_RELOC some day?
This patch (or similar one) has to be alive when we have platform which requires CONFIG_NEEDS_MANUAL_RELOC for full u-boot. There is an option to move to REL/RELA but the question is if all platforms have it/support it. Unfortunately I think that it will be in the tree for a long time.
If we use SPL, we do not have to relocate code, I think.
SPL doesn't have relocation that's why this code is not used there.
Maybe I asked this before, but when can we remove CONFIG_NEEDS_MANUAL_RELOC? What platforms need it?
Sorry if you answered these questions but can you please resend if so as I missed it.
Graeme has answered it + my response here. http://lists.denx.de/pipermail/u-boot/2015-February/203911.html
removing: When all platforms are moved to REL/RELA we can remove this manual reloc option.
With a heavy heart:
Acked-by: Simon Glass sjg@chromium.org
Are you going to take this patch to your DM tree?
Thanks, Michal
Hi MIchal,
On 9 February 2015 at 03:27, Michal Simek michal.simek@xilinx.com wrote:
Hi Simon,
On 02/06/2015 06:45 AM, Simon Glass wrote:
On 4 February 2015 at 23:31, Michal Simek michal.simek@xilinx.com wrote:
Hi,
On 02/05/2015 04:07 AM, Simon Glass wrote:
Hi Michal,
On 3 February 2015 at 17:40, Simon Glass sjg@chromium.org wrote:
Hi Michal,
On 3 February 2015 at 02:11, Michal Simek michal.simek@xilinx.com wrote:
Hi Simon,
On 02/03/2015 03:02 AM, Masahiro Yamada wrote: > Hi. > > > On Mon, 2 Feb 2015 16:57:15 -0700 > Simon Glass sjg@chromium.org wrote: > >> Hi Michal, >> >> On 2 February 2015 at 08:31, Michal Simek michal.simek@xilinx.com wrote: >>> Targets with CONFIG_NEEDS_MANUAL_RELOC do not use REL/RELA >>> relocation (mostly only GOT) where functions aray are not >>> updated. This patch is fixing function pointers for DM core >>> and serial-uclass to ensure that relocated functions are called. >>> >>> Signed-off-by: Michal Simek michal.simek@xilinx.com >>> --- >>> >>> drivers/core/root.c | 64 ++++++++++++++++++++++++++++++++++++++++++ >>> drivers/serial/serial-uclass.c | 16 +++++++++++ >>> 2 files changed, 80 insertions(+) >> >> How long will we have to carry this patch? It seems that if we add any >> new driver we will have to add more code like this? > > > > This patch is unfortunate. > Can we discontinue CONFIG_NEEDS_MANUAL_RELOC some day?
This patch (or similar one) has to be alive when we have platform which requires CONFIG_NEEDS_MANUAL_RELOC for full u-boot. There is an option to move to REL/RELA but the question is if all platforms have it/support it. Unfortunately I think that it will be in the tree for a long time.
> > If we use SPL, we do not have to relocate code, I think.
SPL doesn't have relocation that's why this code is not used there.
Maybe I asked this before, but when can we remove CONFIG_NEEDS_MANUAL_RELOC? What platforms need it?
Sorry if you answered these questions but can you please resend if so as I missed it.
Graeme has answered it + my response here. http://lists.denx.de/pipermail/u-boot/2015-February/203911.html
removing: When all platforms are moved to REL/RELA we can remove this manual reloc option.
With a heavy heart:
Acked-by: Simon Glass sjg@chromium.org
Are you going to take this patch to your DM tree?
I'm hoping to bring in the Kconfig patches and send a pull request this week, so could do that if it suits. But it is up to you, so let's do whatever makes your life easier. Let me know.
Regards, Simon
On 02/09/2015 11:14 PM, Simon Glass wrote:
Hi MIchal,
On 9 February 2015 at 03:27, Michal Simek michal.simek@xilinx.com wrote:
Hi Simon,
On 02/06/2015 06:45 AM, Simon Glass wrote:
On 4 February 2015 at 23:31, Michal Simek michal.simek@xilinx.com wrote:
Hi,
On 02/05/2015 04:07 AM, Simon Glass wrote:
Hi Michal,
On 3 February 2015 at 17:40, Simon Glass sjg@chromium.org wrote:
Hi Michal,
On 3 February 2015 at 02:11, Michal Simek michal.simek@xilinx.com wrote: > Hi Simon, > > On 02/03/2015 03:02 AM, Masahiro Yamada wrote: >> Hi. >> >> >> On Mon, 2 Feb 2015 16:57:15 -0700 >> Simon Glass sjg@chromium.org wrote: >> >>> Hi Michal, >>> >>> On 2 February 2015 at 08:31, Michal Simek michal.simek@xilinx.com wrote: >>>> Targets with CONFIG_NEEDS_MANUAL_RELOC do not use REL/RELA >>>> relocation (mostly only GOT) where functions aray are not >>>> updated. This patch is fixing function pointers for DM core >>>> and serial-uclass to ensure that relocated functions are called. >>>> >>>> Signed-off-by: Michal Simek michal.simek@xilinx.com >>>> --- >>>> >>>> drivers/core/root.c | 64 ++++++++++++++++++++++++++++++++++++++++++ >>>> drivers/serial/serial-uclass.c | 16 +++++++++++ >>>> 2 files changed, 80 insertions(+) >>> >>> How long will we have to carry this patch? It seems that if we add any >>> new driver we will have to add more code like this? >> >> >> >> This patch is unfortunate. >> Can we discontinue CONFIG_NEEDS_MANUAL_RELOC some day? > > This patch (or similar one) has to be alive when we have platform > which requires CONFIG_NEEDS_MANUAL_RELOC for full u-boot. > There is an option to move to REL/RELA but the question is if > all platforms have it/support it. Unfortunately I think that > it will be in the tree for a long time. > >> >> If we use SPL, we do not have to relocate code, I think. > > SPL doesn't have relocation that's why this code is not used there.
Maybe I asked this before, but when can we remove CONFIG_NEEDS_MANUAL_RELOC? What platforms need it?
Sorry if you answered these questions but can you please resend if so as I missed it.
Graeme has answered it + my response here. http://lists.denx.de/pipermail/u-boot/2015-February/203911.html
removing: When all platforms are moved to REL/RELA we can remove this manual reloc option.
With a heavy heart:
Acked-by: Simon Glass sjg@chromium.org
Are you going to take this patch to your DM tree?
I'm hoping to bring in the Kconfig patches and send a pull request this week, so could do that if it suits. But it is up to you, so let's do whatever makes your life easier. Let me know.
works for me. Taking it via your tree is the right way to reach master branch.
Thanks, Michal
On 10 February 2015 at 02:55, Michal Simek michal.simek@xilinx.com wrote:
On 02/09/2015 11:14 PM, Simon Glass wrote:
Hi MIchal,
On 9 February 2015 at 03:27, Michal Simek michal.simek@xilinx.com wrote:
Hi Simon,
On 02/06/2015 06:45 AM, Simon Glass wrote:
With a heavy heart:
Acked-by: Simon Glass sjg@chromium.org
Are you going to take this patch to your DM tree?
I'm hoping to bring in the Kconfig patches and send a pull request this week, so could do that if it suits. But it is up to you, so let's do whatever makes your life easier. Let me know.
works for me. Taking it via your tree is the right way to reach master branch.
Applied to u-boot-dm, thanks!
Hi Michal,
On Tue, 3 Feb 2015 10:11:39 +0100 Michal Simek michal.simek@xilinx.com wrote:
Hi Simon,
On 02/03/2015 03:02 AM, Masahiro Yamada wrote:
Hi.
On Mon, 2 Feb 2015 16:57:15 -0700 Simon Glass sjg@chromium.org wrote:
Hi Michal,
On 2 February 2015 at 08:31, Michal Simek michal.simek@xilinx.com wrote:
Targets with CONFIG_NEEDS_MANUAL_RELOC do not use REL/RELA relocation (mostly only GOT) where functions aray are not updated. This patch is fixing function pointers for DM core and serial-uclass to ensure that relocated functions are called.
Signed-off-by: Michal Simek michal.simek@xilinx.com
drivers/core/root.c | 64 ++++++++++++++++++++++++++++++++++++++++++ drivers/serial/serial-uclass.c | 16 +++++++++++ 2 files changed, 80 insertions(+)
How long will we have to carry this patch? It seems that if we add any new driver we will have to add more code like this?
This patch is unfortunate. Can we discontinue CONFIG_NEEDS_MANUAL_RELOC some day?
This patch (or similar one) has to be alive when we have platform which requires CONFIG_NEEDS_MANUAL_RELOC for full u-boot. There is an option to move to REL/RELA but the question is if all platforms have it/support it. Unfortunately I think that it will be in the tree for a long time.
If we use SPL, we do not have to relocate code, I think.
SPL doesn't have relocation that's why this code is not used there.
It is not what I meant.
If SPL can directly load the main u-boot image to the DRAM address where it is linked, we do not relocate the code in the main image.
Best Regards Masahiro Yamada
On 02/04/2015 04:11 AM, Masahiro Yamada wrote:
Hi Michal,
On Tue, 3 Feb 2015 10:11:39 +0100 Michal Simek michal.simek@xilinx.com wrote:
Hi Simon,
On 02/03/2015 03:02 AM, Masahiro Yamada wrote:
Hi.
On Mon, 2 Feb 2015 16:57:15 -0700 Simon Glass sjg@chromium.org wrote:
Hi Michal,
On 2 February 2015 at 08:31, Michal Simek michal.simek@xilinx.com wrote:
Targets with CONFIG_NEEDS_MANUAL_RELOC do not use REL/RELA relocation (mostly only GOT) where functions aray are not updated. This patch is fixing function pointers for DM core and serial-uclass to ensure that relocated functions are called.
Signed-off-by: Michal Simek michal.simek@xilinx.com
drivers/core/root.c | 64 ++++++++++++++++++++++++++++++++++++++++++ drivers/serial/serial-uclass.c | 16 +++++++++++ 2 files changed, 80 insertions(+)
How long will we have to carry this patch? It seems that if we add any new driver we will have to add more code like this?
This patch is unfortunate. Can we discontinue CONFIG_NEEDS_MANUAL_RELOC some day?
This patch (or similar one) has to be alive when we have platform which requires CONFIG_NEEDS_MANUAL_RELOC for full u-boot. There is an option to move to REL/RELA but the question is if all platforms have it/support it. Unfortunately I think that it will be in the tree for a long time.
If we use SPL, we do not have to relocate code, I think.
SPL doesn't have relocation that's why this code is not used there.
It is not what I meant.
If SPL can directly load the main u-boot image to the DRAM address where it is linked, we do not relocate the code in the main image.
Current behavior is that SPL is reading u-boot.img entry point which can be in any location and jump to it and u-boot self relocate to the end of memory. If SPL adds u-boot directly to the location where it should run after relocation then relocation is not needed. To ensure this capability (based on my poor GOT/REL/RELA) experience it means that SPL loads u-boot to that location and patch REL/RELA section based on this location and internal relocation should be skipped. This is definitely doable for REL/RELA case and it can also speedup boot process (I don't think there is easy way how to solve this with just GOT relocation because of that MANUAL_RELOC code which is patching arrays with function pointers).
Thanks, Michal
Hello Michal,
On Wed, 4 Feb 2015 10:56:02 +0100, Michal Simek michal.simek@xilinx.com wrote:
On 02/04/2015 04:11 AM, Masahiro Yamada wrote:
Hi Michal,
On Tue, 3 Feb 2015 10:11:39 +0100 Michal Simek michal.simek@xilinx.com wrote:
Hi Simon,
On 02/03/2015 03:02 AM, Masahiro Yamada wrote:
Hi.
On Mon, 2 Feb 2015 16:57:15 -0700 Simon Glass sjg@chromium.org wrote:
Hi Michal,
On 2 February 2015 at 08:31, Michal Simek michal.simek@xilinx.com wrote:
Targets with CONFIG_NEEDS_MANUAL_RELOC do not use REL/RELA relocation (mostly only GOT) where functions aray are not updated. This patch is fixing function pointers for DM core and serial-uclass to ensure that relocated functions are called.
Signed-off-by: Michal Simek michal.simek@xilinx.com
drivers/core/root.c | 64 ++++++++++++++++++++++++++++++++++++++++++ drivers/serial/serial-uclass.c | 16 +++++++++++ 2 files changed, 80 insertions(+)
How long will we have to carry this patch? It seems that if we add any new driver we will have to add more code like this?
This patch is unfortunate. Can we discontinue CONFIG_NEEDS_MANUAL_RELOC some day?
This patch (or similar one) has to be alive when we have platform which requires CONFIG_NEEDS_MANUAL_RELOC for full u-boot. There is an option to move to REL/RELA but the question is if all platforms have it/support it. Unfortunately I think that it will be in the tree for a long time.
If we use SPL, we do not have to relocate code, I think.
SPL doesn't have relocation that's why this code is not used there.
It is not what I meant.
If SPL can directly load the main u-boot image to the DRAM address where it is linked, we do not relocate the code in the main image.
Current behavior is that SPL is reading u-boot.img entry point which can be in any location and jump to it and u-boot self relocate to the end of memory. If SPL adds u-boot directly to the location where it should run after relocation then relocation is not needed. To ensure this capability (based on my poor GOT/REL/RELA) experience it means that SPL loads u-boot to that location and patch REL/RELA section based on this location and internal relocation should be skipped.
IOW, that SPL perform the work of relocate_code() in U-Boot -- at least, on ARM, where REL/RELA is used.
This is definitely doable for REL/RELA case and it can also speedup boot process
Not sure about the speed-up, but never mind.
(I don't think there is easy way how to solve this with just GOT relocation because of that MANUAL_RELOC code which is patching arrays with function pointers).
Even without importing SPL in the equation, switching from GOT to REL/RELA has enourmous advantages.
Thanks, Michal
Amicalement,
Hi Albert,
On 02/04/2015 11:34 AM, Albert ARIBAUD wrote:
Hello Michal,
On Wed, 4 Feb 2015 10:56:02 +0100, Michal Simek michal.simek@xilinx.com wrote:
On 02/04/2015 04:11 AM, Masahiro Yamada wrote:
Hi Michal,
On Tue, 3 Feb 2015 10:11:39 +0100 Michal Simek michal.simek@xilinx.com wrote:
Hi Simon,
On 02/03/2015 03:02 AM, Masahiro Yamada wrote:
Hi.
On Mon, 2 Feb 2015 16:57:15 -0700 Simon Glass sjg@chromium.org wrote:
Hi Michal,
On 2 February 2015 at 08:31, Michal Simek michal.simek@xilinx.com wrote: > Targets with CONFIG_NEEDS_MANUAL_RELOC do not use REL/RELA > relocation (mostly only GOT) where functions aray are not > updated. This patch is fixing function pointers for DM core > and serial-uclass to ensure that relocated functions are called. > > Signed-off-by: Michal Simek michal.simek@xilinx.com > --- > > drivers/core/root.c | 64 ++++++++++++++++++++++++++++++++++++++++++ > drivers/serial/serial-uclass.c | 16 +++++++++++ > 2 files changed, 80 insertions(+)
How long will we have to carry this patch? It seems that if we add any new driver we will have to add more code like this?
This patch is unfortunate. Can we discontinue CONFIG_NEEDS_MANUAL_RELOC some day?
This patch (or similar one) has to be alive when we have platform which requires CONFIG_NEEDS_MANUAL_RELOC for full u-boot. There is an option to move to REL/RELA but the question is if all platforms have it/support it. Unfortunately I think that it will be in the tree for a long time.
If we use SPL, we do not have to relocate code, I think.
SPL doesn't have relocation that's why this code is not used there.
It is not what I meant.
If SPL can directly load the main u-boot image to the DRAM address where it is linked, we do not relocate the code in the main image.
Current behavior is that SPL is reading u-boot.img entry point which can be in any location and jump to it and u-boot self relocate to the end of memory. If SPL adds u-boot directly to the location where it should run after relocation then relocation is not needed. To ensure this capability (based on my poor GOT/REL/RELA) experience it means that SPL loads u-boot to that location and patch REL/RELA section based on this location and internal relocation should be skipped.
IOW, that SPL perform the work of relocate_code() in U-Boot -- at least, on ARM, where REL/RELA is used.
Maybe we don't understand each other. SPL is not relocate self to any other location. It just copies full u-boot to memory and jump to it and then full U-Boot relocate self to the end of memory.
This is definitely doable for REL/RELA case and it can also speedup boot process
Not sure about the speed-up, but never mind.
What I wanted to describe is that imagine case that SPL will does a little bit more steps when full u-boot should be loaded. It loads full u-boot to the end of memory and fix rel/rela section before passing control to it. IMHO (and not expert) removes one u-boot copy which current full u-boot does. (On the other hand if you want speedup boot you can boot OS directly).
(I don't think there is easy way how to solve this with just GOT relocation because of that MANUAL_RELOC code which is patching arrays with function pointers).
Even without importing SPL in the equation, switching from GOT to REL/RELA has enourmous advantages.
I believe you - I haven't finish this on Microblaze as we talked on IRC some time ago. I have to do what arm64 is doing in tools/relocate-rela.c.
Thanks, Michal
Hi Albert,
If we use SPL, we do not have to relocate code, I think.
SPL doesn't have relocation that's why this code is not used there.
It is not what I meant.
If SPL can directly load the main u-boot image to the DRAM address where it is linked, we do not relocate the code in the main image.
Current behavior is that SPL is reading u-boot.img entry point which can be in any location and jump to it and u-boot self relocate to the end of memory. If SPL adds u-boot directly to the location where it should run after relocation then relocation is not needed. To ensure this capability (based on my poor GOT/REL/RELA) experience it means that SPL loads u-boot to that location and patch REL/RELA section based on this location and internal relocation should be skipped.
I've always thought the logical approach would be for SPL to calculate where U-Boot would end up in RAM, copy it from wherever (NAND, NOR, MMC, whatever) to the final location, perform the relocation fixups, then jump straight into U-Boot. It's pretty much what the Dynamic Loader does (particularly with address space layout randomization)
IOW, that SPL perform the work of relocate_code() in U-Boot -- at least, on ARM, where REL/RELA is used.
This is definitely doable for REL/RELA case and it can also speedup boot process
Not sure about the speed-up, but never mind.
It will save a RAM to RAM copy of u-boot's text and data sections. However, running the relocation code in SPL may be even slower (depending on configuration of caches).
(I don't think there is easy way how to solve this with just GOT relocation because of that MANUAL_RELOC code which is patching arrays with function pointers).
Even without importing SPL in the equation, switching from GOT to REL/RELA has enourmous advantages.
I must admit, I'm really rusty with GOT vs REL/RELA - anyone care to give me a refresher?
But yes, only having to deal with REL/RELA sections will make the relocation procedures much simpler
Regards,
Graeme
participants (5)
-
Albert ARIBAUD -
Graeme Russ -
Masahiro Yamada -
Michal Simek -
Simon Glass