Skip to contentSkip to conversation

arm: discard relocation entries for secure text

PATCH New Peng Fan 6 participants 12 messages Oct 23, 2015 – Mar 31, 2016

Subsystems (2)
lore
Share & tools
lore

Peng Fan

author
#0 lore raw

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.

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:
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
index 03cd9f6..d48a905 100644
@@ -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
author
#1 lore raw

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.

Cc Stefano Babic <[email protected]>
Cc Fabio Estevam <[email protected]>

---

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
index e6ecef0..d21f87f 100644
@@ -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
index 2ed05ea..dbae868 100644
@@ -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
index 4dc11ee..9213374 100644
@@ -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
#2 lore raw

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. 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.

Cc Stefano Babic <[email protected]>
Cc Fabio Estevam <[email protected]>

---
[snip]

arch/arm/include/asm/arch-mx7/imx-regs.h +0 -0
index 4dc11ee..9213374 100644

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

#3 lore raw

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. 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.

Cc Stefano Babic <[email protected]>
Cc Fabio Estevam <[email protected]>

---
[snip]

arch/arm/include/asm/arch-mx7/imx-regs.h +0 -0
index 4dc11ee..9213374 100644

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?

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.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

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

#4 lore raw

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. 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.

Cc Stefano Babic <[email protected]>
Cc Fabio Estevam <[email protected]>

---
[snip]

arch/arm/include/asm/arch-mx7/imx-regs.h +0 -0
index 4dc11ee..9213374 100644

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?

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.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

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

author
#5 lore raw

PATCH v4 3/3 imx: mx7: default enable non-secure mode

In reply to Peng Fan

Support PSCI and switch to non-secure mode when booting linux.

Cc Stefano Babic <[email protected]>
Cc Fabio Estevam <[email protected]>

---

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
index ea2be49..508d1d3 100644
@@ -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
#6 lore raw

PATCH v4 1/3 arm: discard relocation entries for secure text

In reply to 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.

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.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.

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:
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 +0 -0
index 03cd9f6..d48a905 100644
@@ -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
#7 lore raw

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.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.

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:
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 +0 -0
index 03cd9f6..d48a905 100644
@@ -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
#8 lore raw

PATCH v4 1/3 arm: discard relocation entries for secure text

In reply to Peng Fan

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.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.

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:
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
index 03cd9f6..d48a905 100644
@@ -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.
#9 lore raw

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.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.

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:
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
index 03cd9f6..d48a905 100644
@@ -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.4

Can you please take a look at the patch set and merge?

Thanks,
Peng.

Quoted 3 lines

Amicalement,

Signature · 1 line
Albert.
#10 lore raw

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.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.

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:
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
index 03cd9f6..d48a905 100644
@@ -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.4
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
=====================================================================
#11 lore raw

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.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.

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:
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
index 03cd9f6..d48a905 100644
@@ -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
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
=====================================================================