arm: discard relocation entries for secure text
Subsystems (2)
PATCH v4 1/3 arm: discard relocation entries for secure text
The code such as PSCI in section named secure is bundled with u-boot image, and when bootm, the code will be copied to their runtime address same to compliation/linking address - CONFIG_ARMV7_SECURE_BASE.
When compile the PSCI code and link it into the u-boot image, there will be relocation entries in .rel.dyn section for PSCI. Actually, we do not needs these relocation entries.
If still keep the relocation entries in .rel.dyn section, r0 at line 103 and 106 in arch/arm/lib/relocate.S may be an invalid address which may not support read/write for one SoC.
102 /* relative fix: increase location by offset */ 103 add r0, r0, r4 104 ldr r1, [r0] 105 add r1, r1, r4 106 str r1, [r0]
So discard them to avoid touching the relocation entry in arch/arm/lib/relocate.S.
---
Changes v4:
none
V2 thread: http://lists.denx.de/pipermail/u-boot/2015-October/230755.html
Changes v3:
Move the relocation entries to the very begining and discard them.
V1 thread: http://lists.denx.de/pipermail/u-boot/2015-October/229426.html
Changes V2:
Refine commit msg.
Discard the relocation entry section for secure text.
arch/arm/cpu/u-boot.lds | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)
arch/arm/cpu/u-boot.lds +17 -0
@@ -14,6 +14,23 @@ OUTPUT_ARCH(arm) ENTRY(_start) SECTIONS { + /* + * Discard the relocation entries for secure text. + * The secure code is bundled with u-boot image, so there will + * be relocations entries for the secure code, since we use + * "-mword-relocations" to compile and "-pie" to link into the + * final image. We do not need the relocation entries for secure + * code, because secure code will not be relocated, it only needs + * to be copied from loading address to CONFIG_ARMV7_SECURE_BASE, + * which is the linking and running address for secure code. + * If keep the relocation entries in .rel.dyn section, + * "relocation offset + linking address" may locates into an + * address that is reserved by SoC, then will trigger data abort. + * + * The reason that move .rel._secure at the beginning, is to + * avoid hole in the final image. + */ + /DISCARD/ : { *(.rel._secure*) } . = 0x00000000; . = ALIGN(4);
Signature · 1 line
1.8.4
PATCH v4 2/3 mx7: psci: add basic psci support
1. add basic psci support for imx7 chip.
2. support cpu_on and cpu_off.
3. switch to non-secure mode when boot linux kernel.
4. set csu allow accessing all peripherial register in non-secure mode.
---
Changes V4:
Use macros but not magic number for init CSU.
Changes V3:
Addressed Fabio and Frank's comments.
http://lists.denx.de/pipermail/u-boot/2015-October/230756.html
Changes V2:
Refine commit msg.
arch/arm/cpu/armv7/mx7/Makefile | 4 ++ arch/arm/cpu/armv7/mx7/psci-mx7.c | 69 ++++++++++++++++++++++++++++++++ arch/arm/cpu/armv7/mx7/psci.S | 54 +++++++++++++++++++++++++ arch/arm/cpu/armv7/mx7/soc.c | 9 +++++ arch/arm/include/asm/arch-mx7/imx-regs.h | 3 ++ 5 files changed, 139 insertions(+) create mode 100644 arch/arm/cpu/armv7/mx7/psci-mx7.c create mode 100644 arch/arm/cpu/armv7/mx7/psci.S
arch/arm/cpu/armv7/mx7/Makefile +4 -0
@@ -6,3 +6,7 @@ # obj-y := soc.o clock.o clock_slice.o + +ifdef CONFIG_ARMV7_PSCI +obj-y += psci-mx7.o psci.o +endif
arch/arm/cpu/armv7/mx7/psci-mx7.c new file +69 -0
69 lines not on this page · raw message
arch/arm/cpu/armv7/mx7/psci.S new file +54 -0
54 lines not on this page · raw message
arch/arm/cpu/armv7/mx7/soc.c +9 -0
@@ -114,10 +114,19 @@ u32 __weak get_board_rev(void) }#endif +/* enable all periherial can be accessed in nosec mode */ +static void init_csu (void ) +{ +int i =0 ; +for (i =0 ; i <CSU_NUM_REGS ; i++) +writel (CSU_INIT_SEC_LEVEL0 ,CSU_IPS_BASE_ADDR + i *4 ); +} +int arch_cpu_init (void ) {init_aips (); +init_csu ();/* Disable PDE bit of WMCR register */ imx_set_wdog_powerdown (false);
arch/arm/include/asm/arch-mx7/imx-regs.h +3 -0
@@ -866,6 +866,9 @@ struct cspi_regs {ECSPI3_BASE_ADDR , \ ECSPI4_BASE_ADDR +#define CSU_INIT_SEC_LEVEL0 0x00FF00FF +#define CSU_NUM_REGS 64 +struct ocotp_regs {u32 ctrl;u32 ctrl_set;
Signature · 1 line
1.8.4
PATCH v4 2/3 mx7: psci: add basic psci support
Hi all,
Sorry to revive an old thread but I have some questions about thit patch.
Quoted 16 lines · Peng Fan
1. add basic psci support for imx7 chip.
2. supportcpu_onandcpu_off.
3. switch to non-secure mode when boot linux kernel.
4. set csu allow accessing all peripherial register in non-secure mode.Signed-off-by Frank Li <[email protected]>Signed-off-by Peng Fan <[email protected]>Cc Stefano Babic <[email protected]>Cc Fabio Estevam <[email protected]>---
[snip]arch/arm/include/asm/arch-mx7/imx-regs.h +0
-0
arch/arm/include/asm/arch-mx7/imx-regs.h struct cspi_regs { · line 870
Quoted 5 lines
arch/arm/include/asm/arch-mx7/imx-regs.h +2
-0@@ -866,6 +866,9 @@ struct cspi_regs {ECSPI3_BASE_ADDR , \ ECSPI4_BASE_ADDR +#define CSU_INIT_SEC_LEVEL0 0x00FF00FF +#define CSU_NUM_REGS 64
In the security documentation (revA) it is said that there are 40 CSL, why is it 64 here?
Also, although this seems to work, later on when the kernel boots I get the following CAAM errors:
caam 30900000.caam: failed to acquire DECO 0
...
caam 30900000.caam: failed to acquire DECO 0
caam 30900000.caam: failed to instantiate RNG
caam: probe of 30900000.caam failed with error -11
If I revert this patch and therefore leave the CSU to its default state at bootup the above CAAM issue disappears, do you have any idea why?
As a FYI, I am using U-Boot v2016.03 + a few patches that adds support for our i.MX7 Nitrogen7 board. You can find the repo here:
https://github.com/boundarydevices/u-boot-imx6/tree/boundary-v2016.03
Also, if I base U-Boot on top of NXP repo it works too since this csu/psci support isn't there:
http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/tree/?id=rel_imx_3.14.52_1.1.0_ga
Regards,
Gary
PATCH v4 2/3 mx7: psci: add basic psci support
Hi Gary,
Quoted 30 lines · Gary Bisson
Hi all,
Sorry to revive an old thread but I have some questions about thit patch.
Quoted 16 lines · Peng Fan
1. add basic psci support for imx7 chip.
2. supportcpu_onandcpu_off.
3. switch to non-secure mode when boot linux kernel.
4. set csu allow accessing all peripherial register in non-secure mode.Signed-off-by Frank Li <[email protected]>Signed-off-by Peng Fan <[email protected]>Cc Stefano Babic <[email protected]>Cc Fabio Estevam <[email protected]>---
[snip]arch/arm/include/asm/arch-mx7/imx-regs.h +0
-0arch/arm/include/asm/arch-mx7/imx-regs.h struct cspi_regs { · line 870
Quoted 5 lines
arch/arm/include/asm/arch-mx7/imx-regs.h +2
-0@@ -866,6 +866,9 @@ struct cspi_regs {ECSPI3_BASE_ADDR , \ ECSPI4_BASE_ADDR +#define CSU_INIT_SEC_LEVEL0 0x00FF00FF +#define CSU_NUM_REGS 64In the security documentation (revA) it is said that there are 40 CSL, why is it 64 here?
Quoted 7 lines
Also, although this seems to work, later on when the kernel boots I get the following CAAM errors:
caam 30900000.caam: failed to acquire DECO 0
...
caam 30900000.caam: failed to acquire DECO 0
caam 30900000.caam: failed to instantiate RNG
caam: probe of 30900000.caam failed with error -11
This patch will let SoC switch to non sec mode. I have little knowledge of CAAM, I guess it works in sec mode. So when kernel boots up, it will complains a lot...
Quoted 3 lines
If I revert this patch and therefore leave the CSU to its default state at bootup the above CAAM issue disappears, do you have any idea why?
Revert this patch, then all code runs in sec mode.
Quoted 8 lines
As a FYI, I am using U-Boot v2016.03 + a few patches that adds support for our i.MX7 Nitrogen7 board. You can find the repo here:
https://github.com/boundarydevices/u-boot-imx6/tree/boundary-v2016.03Also, if I base U-Boot on top of NXP repo it works too since this csu/psci support isn't there:
http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/tree/?id=rel_imx_3.14.52_1.1.0_ga
Yeah. NXP code not switch to non sec mode.
You can revert this patch in your vendor tree. I am not sure whether you have tested linux upstream tree, or you use caam code from NXP vendor tree. If you use NXP vendor tree, and use uboot upstream code, sure caam will complain errros. We would like to use PSCI and work in non-sec mode, but still some works need to be done.
Regards,
Peng.
Quoted 7 lines
Regards,
Gary
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
PATCH v4 2/3 mx7: psci: add basic psci support
Hi Peng,
Quoted 41 lines · Peng Fan
Hi Gary,
Quoted 30 lines · Gary Bisson
Hi all,
Sorry to revive an old thread but I have some questions about thit patch.
Quoted 16 lines · Peng Fan
1. add basic psci support for imx7 chip.
2. supportcpu_onandcpu_off.
3. switch to non-secure mode when boot linux kernel.
4. set csu allow accessing all peripherial register in non-secure mode.Signed-off-by Frank Li <[email protected]>Signed-off-by Peng Fan <[email protected]>Cc Stefano Babic <[email protected]>Cc Fabio Estevam <[email protected]>---
[snip]arch/arm/include/asm/arch-mx7/imx-regs.h +0
-0arch/arm/include/asm/arch-mx7/imx-regs.h struct cspi_regs { · line 870
Quoted 5 lines
arch/arm/include/asm/arch-mx7/imx-regs.h +2
-0@@ -866,6 +866,9 @@ struct cspi_regs {ECSPI3_BASE_ADDR , \ ECSPI4_BASE_ADDR +#define CSU_INIT_SEC_LEVEL0 0x00FF00FF +#define CSU_NUM_REGS 64In the security documentation (revA) it is said that there are 40 CSL, why is it 64 here?
Quoted 7 lines
Also, although this seems to work, later on when the kernel boots I get the following CAAM errors:
caam 30900000.caam: failed to acquire DECO 0
...
caam 30900000.caam: failed to acquire DECO 0
caam 30900000.caam: failed to instantiate RNG
caam: probe of 30900000.caam failed with error -11
Quoted 3 lines
This patch will let SoC switch to non sec mode. I have little knowledge of CAAM, I guess it works in sec mode. So when kernel boots up, it will complains a lot...
Seems like a safe assumption to say CAAM requires to be run in secure mode.
Quoted 15 lines
Quoted 2 lines
If I revert this patch and therefore leave the CSU to its default state at bootup the above CAAM issue disappears, do you have any idea why?
Revert this patch, then all code runs in sec mode.
Quoted 8 lines
As a FYI, I am using U-Boot v2016.03 + a few patches that adds support for our i.MX7 Nitrogen7 board. You can find the repo here:
https://github.com/boundarydevices/u-boot-imx6/tree/boundary-v2016.03Also, if I base U-Boot on top of NXP repo it works too since this csu/psci support isn't there:
http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/tree/?id=rel_imx_3.14.52_1.1.0_ga
Quoted 7 lines
Yeah. NXP code not switch to non sec mode.
You can revert this patch in your vendor tree. I am not sure whether you have tested linux upstream tree, or you use caam code from NXP vendor tree. If you use NXP vendor tree, and use uboot upstream code, sure caam will complain errros. We would like to use PSCI and work in non-sec mode, but still some works need to be done.
Thanks for your feedback. We are using our own tree based on NXP vendor one (3.14.52_1.1.0_ga).
We usually use upstream U-Boot with this kernel tree. I guess the easiest option here is actually to add CONFIG_MX7_SEC to our board config, this avoids to revert the patches.
Thanks,
Gary
PATCH v4 3/3 imx: mx7: default enable non-secure mode
In reply to Peng FanSupport PSCI and switch to non-secure mode when booting linux.
---
Changes v4:
Discard unused 1's when define macros.
Changes V3:
none
Changes V2:
default no enable CONFIG_ARMV7_VIRT
include/configs/mx7_common.h | 11 +++++++++++ 1 file changed, 11 insertions(+)
include/configs/mx7_common.h +11 -0
@@ -92,4 +92,15 @@#define CONFIG_CMD_FUSE #define CONFIG_MXC_OCOTP +/* +* Default boot linux kernel in no secure mode. +* If want to boot kernel in secure mode, please define CONFIG_MX7_SEC +*/ +#ifndef CONFIG_MX7_SEC +#define CONFIG_ARMV7_NONSEC +#define CONFIG_ARMV7_PSCI +#define CONFIG_ARMV7_PSCI_NR_CPUS 2 +#define CONFIG_ARMV7_SECURE_BASE 0x00900000 +#endif +#endif
Signature · 1 line
1.8.4
PATCH v4 1/3 arm: discard relocation entries for secure text
In reply to Peng FanHi Albert,
Are you fine with this patch?
I'd like the patch go through i.MX tree, since the other two patches needs this patch to work.
Thanks,
Peng.
Quoted 79 lines · Peng Fan
The code such as PSCI in section named secure is bundled with u-boot image, and when bootm, the code will be copied to their runtime address same to compliation/linking address -
CONFIG_ARMV7_SECURE_BASE.When compile the PSCI code and link it into the u-boot image, there will be relocation entries in .rel.dyn section for PSCI. Actually, we do not needs these relocation entries.
If still keep the relocation entries in .rel.dyn section, r0 at line 103 and 106 in
arch/arm/lib/relocate.Smay be an invalid address which may not support read/write for one SoC.102 /* relative fix: increase location by offset */ 103 add r0, r0, r4 104 ldr r1, [r0] 105 add r1, r1, r4 106 str r1, [r0]So discard them to avoid touching the relocation entry in
arch/arm/lib/relocate.S.Signed-off-by Peng Fan <[email protected]>Cc Tom Warren <[email protected]>Cc York Sun <[email protected]>Cc Hans De Goede <[email protected]>Cc Ian Campbell <[email protected]>Cc Albert Aribaud <[email protected]>Cc Tom Rini <[email protected]>Cc Jan Kiszka <[email protected]>Cc Stefano Babic <[email protected]>---
Changes v4:
noneV2 thread: http://lists.denx.de/pipermail/u-boot/2015-October/230755.html
Changes v3:
Move the relocation entries to the very begining and discard them.V1 thread: http://lists.denx.de/pipermail/u-boot/2015-October/229426.html
Changes V2:
Refine commit msg.
Discard the relocation entry section for secure text.
arch/arm/cpu/u-boot.lds| 17 +++++++++++++++++1 file changed, 17 insertions(+)arch/arm/cpu/u-boot.lds +0
-0@@ -14,6 +14,23 @@ OUTPUT_ARCH(arm) ENTRY(_start)SECTIONS
{arch/arm/cpu/u-boot.lds +17
-0+ /* + * Discard the relocation entries for secure text. + * The secure code is bundled with u-boot image, so there will + * be relocations entries for the secure code, since we use + * "-mword-relocations" to compile and "-pie" to link into the + * final image. We do not need the relocation entries for secure + * code, because secure code will not be relocated, it only needs + * to be copied from loading address to CONFIG_ARMV7_SECURE_BASE, + * which is the linking and running address for secure code. + * If keep the relocation entries in .rel.dyn section, + * "relocation offset + linking address" may locates into an + * address that is reserved by SoC, then will trigger data abort. + * + * The reason that move .rel._secure at the beginning, is to + * avoid hole in the final image. + */ + /DISCARD/ : { *(.rel._secure*) }. = 0x00000000; . = ALIGN(4);Signature · 1 line
1.8.4
PATCH v4 1/3 arm: discard relocation entries for secure text
Quoted 6 lines · Peng Fan
Hi Albert,
Are you fine with this patch?
I'd like the patch go through i.MX tree, since the other two patches needs this patch to work.
Ping..
Thanks,
Peng.
Quoted 86 lines
Thanks,
Peng.Quoted 79 lines · Peng Fan
The code such as PSCI in section named secure is bundled with u-boot image, and when bootm, the code will be copied to their runtime address same to compliation/linking address -
CONFIG_ARMV7_SECURE_BASE.When compile the PSCI code and link it into the u-boot image, there will be relocation entries in .rel.dyn section for PSCI. Actually, we do not needs these relocation entries.
If still keep the relocation entries in .rel.dyn section, r0 at line 103 and 106 in
arch/arm/lib/relocate.Smay be an invalid address which may not support read/write for one SoC.102 /* relative fix: increase location by offset */ 103 add r0, r0, r4 104 ldr r1, [r0] 105 add r1, r1, r4 106 str r1, [r0]So discard them to avoid touching the relocation entry in
arch/arm/lib/relocate.S.Signed-off-by Peng Fan <[email protected]>Cc Tom Warren <[email protected]>Cc York Sun <[email protected]>Cc Hans De Goede <[email protected]>Cc Ian Campbell <[email protected]>Cc Albert Aribaud <[email protected]>Cc Tom Rini <[email protected]>Cc Jan Kiszka <[email protected]>Cc Stefano Babic <[email protected]>---
Changes v4:
noneV2 thread: http://lists.denx.de/pipermail/u-boot/2015-October/230755.html
Changes v3:
Move the relocation entries to the very begining and discard them.V1 thread: http://lists.denx.de/pipermail/u-boot/2015-October/229426.html
Changes V2:
Refine commit msg.
Discard the relocation entry section for secure text.
arch/arm/cpu/u-boot.lds| 17 +++++++++++++++++1 file changed, 17 insertions(+)arch/arm/cpu/u-boot.lds +0
-0@@ -14,6 +14,23 @@ OUTPUT_ARCH(arm) ENTRY(_start)SECTIONS
{arch/arm/cpu/u-boot.lds +17
-0+ /* + * Discard the relocation entries for secure text. + * The secure code is bundled with u-boot image, so there will + * be relocations entries for the secure code, since we use + * "-mword-relocations" to compile and "-pie" to link into the + * final image. We do not need the relocation entries for secure + * code, because secure code will not be relocated, it only needs + * to be copied from loading address to CONFIG_ARMV7_SECURE_BASE, + * which is the linking and running address for secure code. + * If keep the relocation entries in .rel.dyn section, + * "relocation offset + linking address" may locates into an + * address that is reserved by SoC, then will trigger data abort. + * + * The reason that move .rel._secure at the beginning, is to + * avoid hole in the final image. + */ + /DISCARD/ : { *(.rel._secure*) }. = 0x00000000; . = ALIGN(4);Signature · 1 line
1.8.4
PATCH v4 1/3 arm: discard relocation entries for secure text
In reply to Peng FanHello Peng,
Quoted 79 lines · Peng Fan
The code such as PSCI in section named secure is bundled with u-boot image, and when bootm, the code will be copied to their runtime address same to compliation/linking address -
CONFIG_ARMV7_SECURE_BASE.When compile the PSCI code and link it into the u-boot image, there will be relocation entries in .rel.dyn section for PSCI. Actually, we do not needs these relocation entries.
If still keep the relocation entries in .rel.dyn section, r0 at line 103 and 106 in
arch/arm/lib/relocate.Smay be an invalid address which may not support read/write for one SoC.102 /* relative fix: increase location by offset */ 103 add r0, r0, r4 104 ldr r1, [r0] 105 add r1, r1, r4 106 str r1, [r0]So discard them to avoid touching the relocation entry in
arch/arm/lib/relocate.S.Signed-off-by Peng Fan <[email protected]>Cc Tom Warren <[email protected]>Cc York Sun <[email protected]>Cc Hans De Goede <[email protected]>Cc Ian Campbell <[email protected]>Cc Albert Aribaud <[email protected]>Cc Tom Rini <[email protected]>Cc Jan Kiszka <[email protected]>Cc Stefano Babic <[email protected]>---
Changes v4:
noneV2 thread: http://lists.denx.de/pipermail/u-boot/2015-October/230755.html
Changes v3:
Move the relocation entries to the very begining and discard them.V1 thread: http://lists.denx.de/pipermail/u-boot/2015-October/229426.html
Changes V2:
Refine commit msg.
Discard the relocation entry section for secure text.arch/arm/cpu/u-boot.lds | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)arch/arm/cpu/u-boot.lds +17
-0@@ -14,6 +14,23 @@ OUTPUT_ARCH(arm) ENTRY(_start) SECTIONS { + /* + * Discard the relocation entries for secure text. + * The secure code is bundled with u-boot image, so there will + * be relocations entries for the secure code, since we use + * "-mword-relocations" to compile and "-pie" to link into the + * final image. We do not need the relocation entries for secure + * code, because secure code will not be relocated, it only needs + * to be copied from loading address to CONFIG_ARMV7_SECURE_BASE, + * which is the linking and running address for secure code. + * If keep the relocation entries in .rel.dyn section, + * "relocation offset + linking address" may locates into an + * address that is reserved by SoC, then will trigger data abort. + * + * The reason that move .rel._secure at the beginning, is to + * avoid hole in the final image. + */ + /DISCARD/ : { *(.rel._secure*) } . = 0x00000000; . = ALIGN(4);Signature · 1 line
1.8.4
Amicalement,
Signature · 1 line
Albert.
PATCH v4 1/3 arm: discard relocation entries for secure text
Hi Stefano,
Quoted 78 lines · Albert ARIBAUD
Hello Peng,
Quoted 74 lines · Peng Fan
The code such as PSCI in section named secure is bundled with u-boot image, and when bootm, the code will be copied to their runtime address same to compliation/linking address -
CONFIG_ARMV7_SECURE_BASE.When compile the PSCI code and link it into the u-boot image, there will be relocation entries in .rel.dyn section for PSCI. Actually, we do not needs these relocation entries.
If still keep the relocation entries in .rel.dyn section, r0 at line 103 and 106 in
arch/arm/lib/relocate.Smay be an invalid address which may not support read/write for one SoC.102 /* relative fix: increase location by offset */ 103 add r0, r0, r4 104 ldr r1, [r0] 105 add r1, r1, r4 106 str r1, [r0]So discard them to avoid touching the relocation entry in
arch/arm/lib/relocate.S.Signed-off-by Peng Fan <[email protected]>Cc Tom Warren <[email protected]>Cc York Sun <[email protected]>Cc Hans De Goede <[email protected]>Cc Ian Campbell <[email protected]>Cc Albert Aribaud <[email protected]>Cc Tom Rini <[email protected]>Cc Jan Kiszka <[email protected]>Cc Stefano Babic <[email protected]>---
Changes v4:
noneV2 thread: http://lists.denx.de/pipermail/u-boot/2015-October/230755.html
Changes v3:
Move the relocation entries to the very begining and discard them.V1 thread: http://lists.denx.de/pipermail/u-boot/2015-October/229426.html
Changes V2:
Refine commit msg.
Discard the relocation entry section for secure text.arch/arm/cpu/u-boot.lds | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)arch/arm/cpu/u-boot.lds +17
-0@@ -14,6 +14,23 @@ OUTPUT_ARCH(arm) ENTRY(_start) SECTIONS { + /* + * Discard the relocation entries for secure text. + * The secure code is bundled with u-boot image, so there will + * be relocations entries for the secure code, since we use + * "-mword-relocations" to compile and "-pie" to link into the + * final image. We do not need the relocation entries for secure + * code, because secure code will not be relocated, it only needs + * to be copied from loading address to CONFIG_ARMV7_SECURE_BASE, + * which is the linking and running address for secure code. + * If keep the relocation entries in .rel.dyn section, + * "relocation offset + linking address" may locates into an + * address that is reserved by SoC, then will trigger data abort. + * + * The reason that move .rel._secure at the beginning, is to + * avoid hole in the final image. + */ + /DISCARD/ : { *(.rel._secure*) } . = 0x00000000;
Quoted 8 lines
Quoted 5 lines
arch/arm/cpu/u-boot.lds +0
-0. = ALIGN(4);Signature · 1 line
1.8.4Acked-by Albert ARIBAUD <[email protected]>
Can you please take a look at the patch set and merge?
Thanks,
Peng.
Quoted 3 lines
Amicalement,
Signature · 1 line
Albert.
PATCH v4 1/3 arm: discard relocation entries for secure text
Quoted 90 lines · Peng Fan
Hi Stefano,
Quoted 78 lines · Albert ARIBAUD
Hello Peng,
Quoted 74 lines · Peng Fan
The code such as PSCI in section named secure is bundled with u-boot image, and when bootm, the code will be copied to their runtime address same to compliation/linking address -
CONFIG_ARMV7_SECURE_BASE.When compile the PSCI code and link it into the u-boot image, there will be relocation entries in .rel.dyn section for PSCI. Actually, we do not needs these relocation entries.
If still keep the relocation entries in .rel.dyn section, r0 at line 103 and 106 in
arch/arm/lib/relocate.Smay be an invalid address which may not support read/write for one SoC.102 /* relative fix: increase location by offset */ 103 add r0, r0, r4 104 ldr r1, [r0] 105 add r1, r1, r4 106 str r1, [r0]So discard them to avoid touching the relocation entry in
arch/arm/lib/relocate.S.Signed-off-by Peng Fan <[email protected]>Cc Tom Warren <[email protected]>Cc York Sun <[email protected]>Cc Hans De Goede <[email protected]>Cc Ian Campbell <[email protected]>Cc Albert Aribaud <[email protected]>Cc Tom Rini <[email protected]>Cc Jan Kiszka <[email protected]>Cc Stefano Babic <[email protected]>---
Changes v4:
noneV2 thread: http://lists.denx.de/pipermail/u-boot/2015-October/230755.html
Changes v3:
Move the relocation entries to the very begining and discard them.V1 thread: http://lists.denx.de/pipermail/u-boot/2015-October/229426.html
Changes V2:
Refine commit msg.
Discard the relocation entry section for secure text.arch/arm/cpu/u-boot.lds | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)arch/arm/cpu/u-boot.lds +17
-0@@ -14,6 +14,23 @@ OUTPUT_ARCH(arm) ENTRY(_start) SECTIONS { + /* + * Discard the relocation entries for secure text. + * The secure code is bundled with u-boot image, so there will + * be relocations entries for the secure code, since we use + * "-mword-relocations" to compile and "-pie" to link into the + * final image. We do not need the relocation entries for secure + * code, because secure code will not be relocated, it only needs + * to be copied from loading address to CONFIG_ARMV7_SECURE_BASE, + * which is the linking and running address for secure code. + * If keep the relocation entries in .rel.dyn section, + * "relocation offset + linking address" may locates into an + * address that is reserved by SoC, then will trigger data abort. + * + * The reason that move .rel._secure at the beginning, is to + * avoid hole in the final image. + */ + /DISCARD/ : { *(.rel._secure*) } . = 0x00000000;Quoted 8 lines
Quoted 5 lines
arch/arm/cpu/u-boot.lds +0
-0. = ALIGN(4);Signature · 1 line
1.8.4Acked-by Albert ARIBAUD <[email protected]>
Quoted 1 line
Can you please take a look at the patch set and merge?
I'll do
Best regards,
Stefano Babic
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================
PATCH v4 1/3 arm: discard relocation entries for secure text
Quoted 91 lines · Stefano Babic
Quoted 90 lines · Peng Fan
Hi Stefano,
Quoted 86 lines · Albert ARIBAUD
Hello Peng,
Quoted 79 lines · Peng Fan
The code such as PSCI in section named secure is bundled with u-boot image, and when bootm, the code will be copied to their runtime address same to compliation/linking address -
CONFIG_ARMV7_SECURE_BASE.When compile the PSCI code and link it into the u-boot image, there will be relocation entries in .rel.dyn section for PSCI. Actually, we do not needs these relocation entries.
If still keep the relocation entries in .rel.dyn section, r0 at line 103 and 106 in
arch/arm/lib/relocate.Smay be an invalid address which may not support read/write for one SoC.102 /* relative fix: increase location by offset */ 103 add r0, r0, r4 104 ldr r1, [r0] 105 add r1, r1, r4 106 str r1, [r0]So discard them to avoid touching the relocation entry in
arch/arm/lib/relocate.S.Signed-off-by Peng Fan <[email protected]>Cc Tom Warren <[email protected]>Cc York Sun <[email protected]>Cc Hans De Goede <[email protected]>Cc Ian Campbell <[email protected]>Cc Albert Aribaud <[email protected]>Cc Tom Rini <[email protected]>Cc Jan Kiszka <[email protected]>Cc Stefano Babic <[email protected]>---
Changes v4:
noneV2 thread: http://lists.denx.de/pipermail/u-boot/2015-October/230755.html
Changes v3:
Move the relocation entries to the very begining and discard them.V1 thread: http://lists.denx.de/pipermail/u-boot/2015-October/229426.html
Changes V2:
Refine commit msg.
Discard the relocation entry section for secure text.arch/arm/cpu/u-boot.lds | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)arch/arm/cpu/u-boot.lds +17
-0@@ -14,6 +14,23 @@ OUTPUT_ARCH(arm) ENTRY(_start) SECTIONS { + /* + * Discard the relocation entries for secure text. + * The secure code is bundled with u-boot image, so there will + * be relocations entries for the secure code, since we use + * "-mword-relocations" to compile and "-pie" to link into the + * final image. We do not need the relocation entries for secure + * code, because secure code will not be relocated, it only needs + * to be copied from loading address to CONFIG_ARMV7_SECURE_BASE, + * which is the linking and running address for secure code. + * If keep the relocation entries in .rel.dyn section, + * "relocation offset + linking address" may locates into an + * address that is reserved by SoC, then will trigger data abort. + * + * The reason that move .rel._secure at the beginning, is to + * avoid hole in the final image. + */ + /DISCARD/ : { *(.rel._secure*) } . = 0x00000000; . = ALIGN(4);Signature · 1 line
1.8.4Acked-by Albert ARIBAUD <[email protected]>
Quoted 2 lines
Quoted 1 line
Can you please take a look at the patch set and merge?
Applied (whole series) to u-boot-imx, thanks !
Best regards,
Stefano Babic
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================