Re: [U-Boot] [PATCH v4 3/4] generic board patch of manual reloc and zero gd_t
On Thu, Aug 22, 2013 at 09:31:35AM +0800, FengHua wrote:
-----????????????----- ?????????: "Scott Wood" scottwood@freescale.com ????????????: 2013???8???22??? ????????? ?????????: "Simon Glass" sjg@chromium.org ??????: FengHua fenghua@phytium.com.cn, "trini@ti.com" trini@ti.com, "U-Boot Mailing List" u-boot@lists.denx.de ??????: Re: [U-Boot] [PATCH v4 3/4] generic board patch of manual reloc and zero gd_t
On Tue, 2013-08-20 at 23:27 -0600, Simon Glass wrote:
Hi David,
On Tue, Aug 20, 2013 at 4:48 AM, fenghua@phytium.com.cn wrote:
diff --git a/common/board_r.c b/common/board_r.c index 86ca1cb..1b4bdd2 100644 --- a/common/board_r.c +++ b/common/board_r.c @@ -157,6 +157,13 @@ static int initr_reloc_global_data(void) */ gd->env_addr += gd->relocaddr - CONFIG_SYS_MONITOR_BASE; #endif +#ifdef CONFIG_NEEDS_MANUAL_RELOC
/** We have to relocate the command table manually*/fixup_cmdtable(ll_entry_start(cmd_tbl_t, cmd),ll_entry_count(cmd_tbl_t, cmd));+#endif /* CONFIG_NEEDS_MANUAL_RELOC */
Should this be done here or in main_loop()? How is this currently done when not using generic board?
It shouldn't be done at all -- let's not revive manual relocations. I'll try to get proper relocation working.
Even the rela relocation of aarch64 works we should keep this here. The generic board could be used by any other platform that need manual relocation.
No, the point is that manual relocation is legacy and new platforms should be using proper relocation.
Of course, manual relocation is not good. But I noticed that there are serveral architecture use manual relocation now, maybe we should keep this for compatibility. Another way, I am not sure whether we can get rid of manual relocation on all architecture. I used manual relocation on aarch64 because I found the initial addresses of data in rela mode are all zero whatever the text base is, and I don't know how to solve this problem.
Hi,
On Thu, Aug 22, 2013 at 8:55 AM, FengHua fenghua@phytium.com.cn wrote:
On Thu, Aug 22, 2013 at 09:31:35AM +0800, FengHua wrote:
-----????????????----- ?????????: "Scott Wood" scottwood@freescale.com ????????????: 2013???8???22??? ????????? ?????????: "Simon Glass" sjg@chromium.org ??????: FengHua fenghua@phytium.com.cn, "trini@ti.com" trini@ti.com, "U-Boot Mailing List" u-boot@lists.denx.de ??????: Re: [U-Boot] [PATCH v4 3/4] generic board patch of manual reloc and zero gd_t
On Tue, 2013-08-20 at 23:27 -0600, Simon Glass wrote:
Hi David,
On Tue, Aug 20, 2013 at 4:48 AM, fenghua@phytium.com.cn wrote:
diff --git a/common/board_r.c b/common/board_r.c index 86ca1cb..1b4bdd2 100644 --- a/common/board_r.c +++ b/common/board_r.c @@ -157,6 +157,13 @@ static int initr_reloc_global_data(void) */ gd->env_addr += gd->relocaddr - CONFIG_SYS_MONITOR_BASE; #endif +#ifdef CONFIG_NEEDS_MANUAL_RELOC
/** We have to relocate the command table manually*/fixup_cmdtable(ll_entry_start(cmd_tbl_t, cmd),ll_entry_count(cmd_tbl_t, cmd));+#endif /* CONFIG_NEEDS_MANUAL_RELOC */
Should this be done here or in main_loop()? How is this currently done when not using generic board?
It shouldn't be done at all -- let's not revive manual relocations. I'll try to get proper relocation working.
Even the rela relocation of aarch64 works we should keep this here. The generic board could be used by any other platform that need manual relocation.
No, the point is that manual relocation is legacy and new platforms should be using proper relocation.
Of course, manual relocation is not good. But I noticed that there are serveral architecture use manual relocation now, maybe we should keep this for compatibility. Another way, I am not sure whether we can get rid of manual relocation on all architecture. I used manual relocation on aarch64 because I found the initial addresses of data in rela mode are all zero whatever the text base is, and I don't know how to solve this problem.
Possible there is a new relocation type that you need to support?
Regards, Simon
On Fri, 2013-08-23 at 18:12 -0600, Simon Glass wrote:
Hi,
On Thu, Aug 22, 2013 at 8:55 AM, FengHua fenghua@phytium.com.cn wrote:
On Thu, Aug 22, 2013 at 09:31:35AM +0800, FengHua wrote:
-----????????????----- ?????????: "Scott Wood" scottwood@freescale.com ????????????: 2013???8???22??? ????????? ?????????: "Simon Glass" sjg@chromium.org ??????: FengHua fenghua@phytium.com.cn, "trini@ti.com" trini@ti.com, "U-Boot Mailing List" u-boot@lists.denx.de ??????: Re: [U-Boot] [PATCH v4 3/4] generic board patch of manual reloc and zero gd_t
On Tue, 2013-08-20 at 23:27 -0600, Simon Glass wrote:
Hi David,
On Tue, Aug 20, 2013 at 4:48 AM, fenghua@phytium.com.cn wrote:
diff --git a/common/board_r.c b/common/board_r.c index 86ca1cb..1b4bdd2 100644 --- a/common/board_r.c +++ b/common/board_r.c @@ -157,6 +157,13 @@ static int initr_reloc_global_data(void) */ gd->env_addr += gd->relocaddr - CONFIG_SYS_MONITOR_BASE; #endif +#ifdef CONFIG_NEEDS_MANUAL_RELOC
/** We have to relocate the command table manually*/fixup_cmdtable(ll_entry_start(cmd_tbl_t, cmd),ll_entry_count(cmd_tbl_t, cmd));+#endif /* CONFIG_NEEDS_MANUAL_RELOC */
Should this be done here or in main_loop()? How is this currently done when not using generic board?
It shouldn't be done at all -- let's not revive manual relocations. I'll try to get proper relocation working.
Even the rela relocation of aarch64 works we should keep this here. The generic board could be used by any other platform that need manual relocation.
No, the point is that manual relocation is legacy and new platforms should be using proper relocation.
Of course, manual relocation is not good. But I noticed that there are serveral architecture use manual relocation now, maybe we should keep this for compatibility. Another way, I am not sure whether we can get rid of manual relocation on all architecture. I used manual relocation on aarch64 because I found the initial addresses of data in rela mode are all zero whatever the text base is, and I don't know how to solve this problem.
Possible there is a new relocation type that you need to support?
Yes, it's rela instead of rel. FengHua claimed to have run into problems supporting it; I'll try to debug it hopefully somewhat soon (though I'll be on vacation most of next week, so probably not until at least the week after).
-Scott
-----原始邮件----- 发件人: "Scott Wood" scottwood@freescale.com 发送时间: 2013年8月24日 星期六 收件人: "Simon Glass" sjg@chromium.org 抄送: FengHua fenghua@phytium.com.cn, trini trini@ti.com, u-boot u-boot@lists.denx.de 主题: Re: Re: [U-Boot] [PATCH v4 3/4] generic board patch of manual reloc and zero gd_t
On Fri, 2013-08-23 at 18:12 -0600, Simon Glass wrote:
Hi,
On Thu, Aug 22, 2013 at 8:55 AM, FengHua fenghua@phytium.com.cn wrote:
On Thu, Aug 22, 2013 at 09:31:35AM +0800, FengHua wrote:
-----????????????----- ?????????: "Scott Wood" scottwood@freescale.com ????????????: 2013???8???22??? ????????? ?????????: "Simon Glass" sjg@chromium.org ??????: FengHua fenghua@phytium.com.cn, "trini@ti.com" trini@ti.com, "U-Boot Mailing List" u-boot@lists.denx.de ??????: Re: [U-Boot] [PATCH v4 3/4] generic board patch of manual reloc and zero gd_t
On Tue, 2013-08-20 at 23:27 -0600, Simon Glass wrote:
Hi David,
On Tue, Aug 20, 2013 at 4:48 AM, fenghua@phytium.com.cn wrote: > diff --git a/common/board_r.c b/common/board_r.c > index 86ca1cb..1b4bdd2 100644 > --- a/common/board_r.c > +++ b/common/board_r.c > @@ -157,6 +157,13 @@ static int initr_reloc_global_data(void) > */ > gd->env_addr += gd->relocaddr - CONFIG_SYS_MONITOR_BASE; > #endif > +#ifdef CONFIG_NEEDS_MANUAL_RELOC > + /* > + * We have to relocate the command table manually > + */ > + fixup_cmdtable(ll_entry_start(cmd_tbl_t, cmd), > + ll_entry_count(cmd_tbl_t, cmd)); > +#endif /* CONFIG_NEEDS_MANUAL_RELOC */
Should this be done here or in main_loop()? How is this currently done when not using generic board?
It shouldn't be done at all -- let's not revive manual relocations. I'll try to get proper relocation working.
Even the rela relocation of aarch64 works we should keep this here. The generic board could be used by any other platform that need manual relocation.
No, the point is that manual relocation is legacy and new platforms should be using proper relocation.
Of course, manual relocation is not good. But I noticed that there are serveral architecture use manual relocation now, maybe we should keep this for compatibility. Another way, I am not sure whether we can get rid of manual relocation on all architecture. I used manual relocation on aarch64 because I found the initial addresses of data in rela mode are all zero whatever the text base is, and I don't know how to solve this problem.
Possible there is a new relocation type that you need to support?
Yes, it's rela instead of rel. FengHua claimed to have run into problems supporting it; I'll try to debug it hopefully somewhat soon (though I'll be on vacation most of next week, so probably not until at least the week after).
-Scott
hi scott, I am looking forward to your result. In my knowledge, the RELA format relocation has no initial addend encoded. So application should be relocated before it runs. But u-boot make the relocation during it's running, it can not reference global variables and functions before it is copied to RAM and relocated. I don't know how to encode the initial addend to variables. Wish you make it! br, david
On Fri, 2013-08-23 at 19:17 -0500, Scott Wood wrote:
On Fri, 2013-08-23 at 18:12 -0600, Simon Glass wrote:
Hi,
On Thu, Aug 22, 2013 at 8:55 AM, FengHua fenghua@phytium.com.cn wrote:
On Thu, Aug 22, 2013 at 09:31:35AM +0800, FengHua wrote:
-----????????????----- ?????????: "Scott Wood" scottwood@freescale.com ????????????: 2013???8???22??? ????????? ?????????: "Simon Glass" sjg@chromium.org ??????: FengHua fenghua@phytium.com.cn, "trini@ti.com" trini@ti.com, "U-Boot Mailing List" u-boot@lists.denx.de ??????: Re: [U-Boot] [PATCH v4 3/4] generic board patch of manual reloc and zero gd_t
On Tue, 2013-08-20 at 23:27 -0600, Simon Glass wrote:
Hi David,
On Tue, Aug 20, 2013 at 4:48 AM, fenghua@phytium.com.cn wrote: > diff --git a/common/board_r.c b/common/board_r.c > index 86ca1cb..1b4bdd2 100644 > --- a/common/board_r.c > +++ b/common/board_r.c > @@ -157,6 +157,13 @@ static int initr_reloc_global_data(void) > */ > gd->env_addr += gd->relocaddr - CONFIG_SYS_MONITOR_BASE; > #endif > +#ifdef CONFIG_NEEDS_MANUAL_RELOC > + /* > + * We have to relocate the command table manually > + */ > + fixup_cmdtable(ll_entry_start(cmd_tbl_t, cmd), > + ll_entry_count(cmd_tbl_t, cmd)); > +#endif /* CONFIG_NEEDS_MANUAL_RELOC */
Should this be done here or in main_loop()? How is this currently done when not using generic board?
It shouldn't be done at all -- let's not revive manual relocations. I'll try to get proper relocation working.
Even the rela relocation of aarch64 works we should keep this here. The generic board could be used by any other platform that need manual relocation.
No, the point is that manual relocation is legacy and new platforms should be using proper relocation.
Of course, manual relocation is not good. But I noticed that there are serveral architecture use manual relocation now, maybe we should keep this for compatibility. Another way, I am not sure whether we can get rid of manual relocation on all architecture. I used manual relocation on aarch64 because I found the initial addresses of data in rela mode are all zero whatever the text base is, and I don't know how to solve this problem.
Possible there is a new relocation type that you need to support?
Yes, it's rela instead of rel. FengHua claimed to have run into problems supporting it; I'll try to debug it hopefully somewhat soon (though I'll be on vacation most of next week, so probably not until at least the week after).
It seems the problem is that when rela is used, the linker *only* puts the symbol in the rela struct. The value in the data section itself is zero, which means we can't run without relocation even if the address hasn't changed.
Unless there's some way to change this linker behavior, the options I can think of are:
1. Write a utility to apply the relocations (for the pre-relocation address) at build time, or
2. Use SPL. The SPL itself would not use -pie and would not relocate. The main U-Boot would know that it has been loaded into RAM, and apply relocations prior to entering C code. Interactions with SPL being used for other purposes could be awkward.
Any preferences, or other suggestions? I think either of these options is preferable to CONFIG_NEEDS_MANUAL_RELOC. I'm inclined toward option #1 as it avoids interactions with other SPL uses and in general doesn't change the runtime flow.
-Scott
On Mon, 2013-09-09 at 20:54 -0500, Scott Wood wrote:
It seems the problem is that when rela is used, the linker *only* puts the symbol in the rela struct. The value in the data section itself is zero, which means we can't run without relocation even if the address hasn't changed.
Unless there's some way to change this linker behavior, the options I can think of are:
- Write a utility to apply the relocations (for the pre-relocation
address) at build time, or
- Use SPL. The SPL itself would not use -pie and would not relocate.
The main U-Boot would know that it has been loaded into RAM, and apply relocations prior to entering C code. Interactions with SPL being used for other purposes could be awkward.
Any preferences, or other suggestions? I think either of these options is preferable to CONFIG_NEEDS_MANUAL_RELOC. I'm inclined toward option #1 as it avoids interactions with other SPL uses and in general doesn't change the runtime flow.
#1 is easier to do on the u-boot.bin rather than on the ELF file[1], but apparently that doesn't do us any good with the model because it wants an ELF file. Shouldn't the model be applying the relocations if it's an ELF loader? Is there any way to get the foundation model to load a raw binary? I tried --data and --nsdata at 0x80000000 (alone or in combination with --image) and wasn't able to do a write to the LEDs immediately after reset (which works when I load it as ELF).
It works when I convert the binary back into an ELF using objcopy and ld, but it would be nice to avoid that...
-Scott
[1] I tried using libelf -- it made getting the relocations easy, but it wasn't obvious how to go about poking the actual image data by address (or even by segment), rather than by section. Other than use libelf to read out the translated relas and phdrs, then close the libelf handle and do the rest manually. :-P
-----原始邮件----- 发件人: "Scott Wood" scottwood@freescale.com 发送时间: 2013年10月1日 星期二 收件人: "Simon Glass" sjg@chromium.org 抄送: trini trini@ti.com, u-boot u-boot@lists.denx.de, FengHua fenghua@phytium.com.cn 主题: Re: [U-Boot] [PATCH v4 3/4] generic board patch of manual reloc and zero gd_t
On Mon, 2013-09-09 at 20:54 -0500, Scott Wood wrote:
It seems the problem is that when rela is used, the linker *only* puts the symbol in the rela struct. The value in the data section itself is zero, which means we can't run without relocation even if the address hasn't changed.
Unless there's some way to change this linker behavior, the options I can think of are:
- Write a utility to apply the relocations (for the pre-relocation
address) at build time, or
- Use SPL. The SPL itself would not use -pie and would not relocate.
The main U-Boot would know that it has been loaded into RAM, and apply relocations prior to entering C code. Interactions with SPL being used for other purposes could be awkward.
Any preferences, or other suggestions? I think either of these options is preferable to CONFIG_NEEDS_MANUAL_RELOC. I'm inclined toward option #1 as it avoids interactions with other SPL uses and in general doesn't change the runtime flow.
#1 is easier to do on the u-boot.bin rather than on the ELF file[1], but apparently that doesn't do us any good with the model because it wants an ELF file. Shouldn't the model be applying the relocations if it's an ELF loader? Is there any way to get the foundation model to load a raw binary? I tried --data and --nsdata at 0x80000000 (alone or in combination with --image) and wasn't able to do a write to the LEDs immediately after reset (which works when I load it as ELF).
It works when I convert the binary back into an ELF using objcopy and ld, but it would be nice to avoid that...
How about place u-boot.bin at 0x90000000 and write a piece of code (elf format) jumping from 0x80000000 to 0x90000000.
David,
On Tue, 2013-10-01 at 19:05 +0800, FengHua wrote:
-----原始邮件----- 发件人: "Scott Wood" scottwood@freescale.com 发送时间: 2013年10月1日 星期二 收件人: "Simon Glass" sjg@chromium.org 抄送: trini trini@ti.com, u-boot u-boot@lists.denx.de, FengHua fenghua@phytium.com.cn 主题: Re: [U-Boot] [PATCH v4 3/4] generic board patch of manual reloc and zero gd_t
On Mon, 2013-09-09 at 20:54 -0500, Scott Wood wrote:
It seems the problem is that when rela is used, the linker *only* puts the symbol in the rela struct. The value in the data section itself is zero, which means we can't run without relocation even if the address hasn't changed.
Unless there's some way to change this linker behavior, the options I can think of are:
- Write a utility to apply the relocations (for the pre-relocation
address) at build time, or
- Use SPL. The SPL itself would not use -pie and would not relocate.
The main U-Boot would know that it has been loaded into RAM, and apply relocations prior to entering C code. Interactions with SPL being used for other purposes could be awkward.
Any preferences, or other suggestions? I think either of these options is preferable to CONFIG_NEEDS_MANUAL_RELOC. I'm inclined toward option #1 as it avoids interactions with other SPL uses and in general doesn't change the runtime flow.
#1 is easier to do on the u-boot.bin rather than on the ELF file[1], but apparently that doesn't do us any good with the model because it wants an ELF file. Shouldn't the model be applying the relocations if it's an ELF loader? Is there any way to get the foundation model to load a raw binary? I tried --data and --nsdata at 0x80000000 (alone or in combination with --image) and wasn't able to do a write to the LEDs immediately after reset (which works when I load it as ELF).
It works when I convert the binary back into an ELF using objcopy and ld, but it would be nice to avoid that...
How about place u-boot.bin at 0x90000000 and write a piece of code (elf format) jumping from 0x80000000 to 0x90000000.
That seems even worse than converting the .bin back into an ELF...
Do you know why loading the raw image at 0x80000000 isn't working?
-Scott
-----原始邮件----- 发件人: "Scott Wood" scottwood@freescale.com 发送时间: 2013年10月1日 星期二 收件人: FengHua fenghua@phytium.com.cn 抄送: "Simon Glass" sjg@chromium.org, trini trini@ti.com, u-boot u-boot@lists.denx.de 主题: Re: Re: [U-Boot] [PATCH v4 3/4] generic board patch of manual reloc and zero gd_t
On Tue, 2013-10-01 at 19:05 +0800, FengHua wrote:
-----原始邮件----- 发件人: "Scott Wood" scottwood@freescale.com 发送时间: 2013年10月1日 星期二 收件人: "Simon Glass" sjg@chromium.org 抄送: trini trini@ti.com, u-boot u-boot@lists.denx.de, FengHua fenghua@phytium.com.cn 主题: Re: [U-Boot] [PATCH v4 3/4] generic board patch of manual reloc and zero gd_t
On Mon, 2013-09-09 at 20:54 -0500, Scott Wood wrote:
It seems the problem is that when rela is used, the linker *only* puts the symbol in the rela struct. The value in the data section itself is zero, which means we can't run without relocation even if the address hasn't changed.
Unless there's some way to change this linker behavior, the options I can think of are:
- Write a utility to apply the relocations (for the pre-relocation
address) at build time, or
- Use SPL. The SPL itself would not use -pie and would not relocate.
The main U-Boot would know that it has been loaded into RAM, and apply relocations prior to entering C code. Interactions with SPL being used for other purposes could be awkward.
Any preferences, or other suggestions? I think either of these options is preferable to CONFIG_NEEDS_MANUAL_RELOC. I'm inclined toward option #1 as it avoids interactions with other SPL uses and in general doesn't change the runtime flow.
#1 is easier to do on the u-boot.bin rather than on the ELF file[1], but apparently that doesn't do us any good with the model because it wants an ELF file. Shouldn't the model be applying the relocations if it's an ELF loader? Is there any way to get the foundation model to load a raw binary? I tried --data and --nsdata at 0x80000000 (alone or in combination with --image) and wasn't able to do a write to the LEDs immediately after reset (which works when I load it as ELF).
It works when I convert the binary back into an ELF using objcopy and ld, but it would be nice to avoid that...
How about place u-boot.bin at 0x90000000 and write a piece of code (elf format) jumping from 0x80000000 to 0x90000000.
That seems even worse than converting the .bin back into an ELF...
Why? I could load u-boot.bin at 0x90000000 as data, I think it should works. Or maybe secure state make the program jumping to secure memory. so try switching to el2 before jumping.
Do you know why loading the raw image at 0x80000000 isn't working?
The foundation model require a elf(axf) image being loaded, it use it to determine the entry point.
David
On Wed, 2013-10-02 at 09:52 +0800, FengHua wrote:
-----原始邮件----- 发件人: "Scott Wood" scottwood@freescale.com 发送时间: 2013年10月1日 星期二 收件人: FengHua fenghua@phytium.com.cn 抄送: "Simon Glass" sjg@chromium.org, trini trini@ti.com, u-boot u-boot@lists.denx.de 主题: Re: Re: [U-Boot] [PATCH v4 3/4] generic board patch of manual reloc and zero gd_t
On Tue, 2013-10-01 at 19:05 +0800, FengHua wrote:
How about place u-boot.bin at 0x90000000 and write a piece of code (elf format) jumping from 0x80000000 to 0x90000000.
That seems even worse than converting the .bin back into an ELF...
Why? I could load u-boot.bin at 0x90000000 as data, I think it should works. Or maybe secure state make the program jumping to secure memory. so try switching to el2 before jumping.
It requires building another program image (even if it's a relatively simple one), as opposed to just invoking objcopy and ld, and it makes invoking the simulator more complicated.
Do you know why loading the raw image at 0x80000000 isn't working?
The foundation model require a elf(axf) image being loaded, it use it to determine the entry point.
Then why does it even try to start without an ELF being supplied (but won't try to start if I don't supply ELF *or* raw data)? Why is there no other way to supply an entry point (even just defaulting to the beginning of the raw image if no ELF is provided)? Why does it fail when I supply *both* the ELF and the raw image, in either order?
-Scott
-----原始邮件----- 发件人: "Scott Wood" scottwood@freescale.com 发送时间: 2013年10月1日 星期二 收件人: FengHua fenghua@phytium.com.cn 抄送: "Simon Glass" sjg@chromium.org, trini trini@ti.com, u-boot u-boot@lists.denx.de 主题: Re: Re: [U-Boot] [PATCH v4 3/4] generic board patch of manual reloc and zero gd_t
On Tue, 2013-10-01 at 19:05 +0800, FengHua wrote:
How about place u-boot.bin at 0x90000000 and write a piece of code (elf format) jumping from 0x80000000 to 0x90000000.
That seems even worse than converting the .bin back into an ELF...
Why? I could load u-boot.bin at 0x90000000 as data, I think it should works. Or maybe secure state make the program jumping to secure memory. so try switching to el2 before jumping.
It requires building another program image (even if it's a relatively simple one), as opposed to just invoking objcopy and ld, and it makes invoking the simulator more complicated.
Do not need to write a new program, just add the jumping code immediately after setup_el3 of current aarch64-uboot, it's the first booting program. compile another u-boot without jumping code at 0x90000000, it's the data.
Do you know why loading the raw image at 0x80000000 isn't working?
The foundation model require a elf(axf) image being loaded, it use it to determine the entry point.
Then why does it even try to start without an ELF being supplied (but won't try to start if I don't supply ELF *or* raw data)? Why is there no other way to supply an entry point (even just defaulting to the beginning of the raw image if no ELF is provided)?
Fast model for aarch64 support all of these. Maybe that's why Foundatiom model is free.
Why does it fail when I supply *both* the ELF and the raw image, in either order?
The elf file will override the raw image if they are loaded at same address.
David
participants (3)
-
FengHua -
Scott Wood -
Simon Glass