Re: [U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address
(Corrected the u-boot list address in the cc of this thread and added Kevin hilman who is also quite interested in this topic)
On Tue, 2015-01-20 at 10:36 +0100, Sjoerd Simons wrote:
Hey Suriyan,
I just noticed the patchset Akshay Saraswat sent (Add support for booting multiple cores), which would hopefully fix some issues wrt. booting secondary cores we've seen on the XU3 thusfar. Unfortunately, those fixes need to be applied in the SPL stage, hence coming back to the BL2 story :). Any updates you can share?
Separately i do wonder if getting a (very basic?) signed BL2 to chainload an unsigned SPL might not be the best way forward here. Would allow us to fix SPL issues in u-boot without having to ask hardkernel to sign every time ? :/
On Fri, 2014-12-19 at 15:45 -0800, Suriyan Ramasami wrote:
Just to close the loop.
For the XU3, scanning memory, I found the signed BL2 loaded at address 0x02027000. Regards
- Suriyan
PS: Any pointers with regards to mem_ctrl_init() is appreciated.
On Fri, Dec 19, 2014 at 12:43 PM, Suriyan Ramasami suriyan.r@gmail.com wrote:
Hello All, Greetings!
I have been dabbling with trying to get mainline SPL working onthe Odroid XU3. The issue that I am facing is that currently I do not know what address the BL1 loads and passes control to the SPL (signed BL2). Of course, I could get another SPL signed from Hard kernel and have the address written out in some memory address, but I thought if someone has access to the documents it might be faster to get this information.
As an update ... So far, I have successfully gotten an Hardkernel based SPL to chain load an unsigned SPL from mainline. I am hitting some issues in mem_ctrl_init() or so I think. I was wondering if the issues were cause of it being initialized twice (one from the signed BL2) and the other from the mainline SPL that is chain loaded.
Thanks
- Suriyan
Hello Sjoerd Simons, A signed BL2 which allows unsigned BL2 chain load is already available for experimentation. Refer this link: http://forum.odroid.com/viewtopic.php?f=98&t=6147#p58984 The suriyan.bl2-hkxu3.1212.5422.zip blob contains a signed BL2 which allows the same. The layout of SD card is as follows:
BL1 (1 to 30) 15K BL2 (31 to 62) 16K indicator block (63 to 64) 1K uboot (65 to 2112) 1M tzsw (2113 to 2624) 256K unsigned BL2 (2625 to 2656) 16K
A non zero in the first byte of the indicator block instructs the signed BL2 to load the unsigned BL2 @ offset 2625.
Thanks - Suriyan
On Tue, Jan 20, 2015 at 8:40 AM, Sjoerd Simons sjoerd.simons@collabora.co.uk wrote:
(Corrected the u-boot list address in the cc of this thread and added Kevin hilman who is also quite interested in this topic)
On Tue, 2015-01-20 at 10:36 +0100, Sjoerd Simons wrote:
Hey Suriyan,
I just noticed the patchset Akshay Saraswat sent (Add support for booting multiple cores), which would hopefully fix some issues wrt. booting secondary cores we've seen on the XU3 thusfar. Unfortunately, those fixes need to be applied in the SPL stage, hence coming back to the BL2 story :). Any updates you can share?
Separately i do wonder if getting a (very basic?) signed BL2 to chainload an unsigned SPL might not be the best way forward here. Would allow us to fix SPL issues in u-boot without having to ask hardkernel to sign every time ? :/
On Fri, 2014-12-19 at 15:45 -0800, Suriyan Ramasami wrote:
Just to close the loop.
For the XU3, scanning memory, I found the signed BL2 loaded at address 0x02027000. Regards
- Suriyan
PS: Any pointers with regards to mem_ctrl_init() is appreciated.
On Fri, Dec 19, 2014 at 12:43 PM, Suriyan Ramasami suriyan.r@gmail.com wrote:
Hello All, Greetings!
I have been dabbling with trying to get mainline SPL working onthe Odroid XU3. The issue that I am facing is that currently I do not know what address the BL1 loads and passes control to the SPL (signed BL2). Of course, I could get another SPL signed from Hard kernel and have the address written out in some memory address, but I thought if someone has access to the documents it might be faster to get this information.
As an update ... So far, I have successfully gotten an Hardkernel based SPL to chain load an unsigned SPL from mainline. I am hitting some issues in mem_ctrl_init() or so I think. I was wondering if the issues were cause of it being initialized twice (one from the signed BL2) and the other from the mainline SPL that is chain loaded.
Thanks
- Suriyan
Hello Suriyan,
Suriyan Ramasami suriyan.r@gmail.com writes:
Hello Sjoerd Simons, A signed BL2 which allows unsigned BL2 chain load is already available for experimentation. Refer this link: http://forum.odroid.com/viewtopic.php?f=98&t=6147#p58984 The suriyan.bl2-hkxu3.1212.5422.zip blob contains a signed BL2 which allows the same. The layout of SD card is as follows:
BL1 (1 to 30) 15K BL2 (31 to 62) 16K indicator block (63 to 64) 1K uboot (65 to 2112) 1M tzsw (2113 to 2624) 256K unsigned BL2 (2625 to 2656) 16K
A non zero in the first byte of the indicator block instructs the signed BL2 to load the unsigned BL2 @ offset 2625.
I'm currently running mainline u-boot, and hoping to test the series that powers down secondary cores on the odroid-xu3. That series applies and builds with mainline u-boot (v2015.01-rc3), but for it to work correctly, IIUC, I'll also need to build an SPL from mainline.
Can you share your changes to mainline u-boot that enable the building of SPL?
I'd like to try that using your BL2 that will load an unsigned BL2.
Thanks,
Kevin
Hello Kevin, These are the changes that would be necessary in uboot mainline for SPL:
arch/arm/cpu/armv7/exynos/Kconfig - select OF_CONTROL + select SUPPORT_SPL + select OF_CONTROL if !SPL_BUILD
configs/odroid-xu3_defconfig +CONFIG_SPL=y
include/configs/odroid_xu3.h #undef CONFIG_SPL_TEXT_BASE #define CONFIG_SPL_TEXT_BASE 0x02027000
#undef CONFIG_SEC_FW_SIZE #define CONFIG_SEC_FW_SIZE (15 << 10) /* 15 KB */
FWICT, mainline uboot does not have code to handle secure firmware. For instance when secure firmware is present the address to poke a jump address for the CPU is different (nsram +1c etc). This stems from lowlevel_init.S being moved over to the NS area. This is also missing in uboot mainline or so I think.
I hope this helps you out.
The ddr init functions seem to be not correct for the 5422 (or so I think). I do not have access to any of the Samsung docs, hence, one solution was to copy over HKs ddr init function, and then the mainline SPL runs.
Regards - Suriyan
On Tue, Jan 20, 2015 at 1:30 PM, Kevin Hilman khilman@kernel.org wrote:
Hello Suriyan,
Suriyan Ramasami suriyan.r@gmail.com writes:
Hello Sjoerd Simons, A signed BL2 which allows unsigned BL2 chain load is already available for experimentation. Refer this link: http://forum.odroid.com/viewtopic.php?f=98&t=6147#p58984 The suriyan.bl2-hkxu3.1212.5422.zip blob contains a signed BL2 which allows the same. The layout of SD card is as follows:
BL1 (1 to 30) 15K BL2 (31 to 62) 16K indicator block (63 to 64) 1K uboot (65 to 2112) 1M tzsw (2113 to 2624) 256K unsigned BL2 (2625 to 2656) 16K
A non zero in the first byte of the indicator block instructs the signed BL2 to load the unsigned BL2 @ offset 2625.
I'm currently running mainline u-boot, and hoping to test the series that powers down secondary cores on the odroid-xu3. That series applies and builds with mainline u-boot (v2015.01-rc3), but for it to work correctly, IIUC, I'll also need to build an SPL from mainline.
Can you share your changes to mainline u-boot that enable the building of SPL?
I'd like to try that using your BL2 that will load an unsigned BL2.
Thanks,
Kevin
Suriyan Ramasami suriyan.r@gmail.com writes:
Hello Kevin, These are the changes that would be necessary in uboot mainline for SPL:
arch/arm/cpu/armv7/exynos/Kconfig
select OF_CONTROL
select SUPPORT_SPLselect OF_CONTROL if !SPL_BUILDconfigs/odroid-xu3_defconfig +CONFIG_SPL=y
include/configs/odroid_xu3.h #undef CONFIG_SPL_TEXT_BASE #define CONFIG_SPL_TEXT_BASE 0x02027000
#undef CONFIG_SEC_FW_SIZE #define CONFIG_SEC_FW_SIZE (15 << 10) /* 15 KB */
Thanks. With those changes, a build gives me:
./include/common.h:355:73: fatal error: asm/u-boot-sandbox.h: No such file or directory
Sorry for the dumb questions, but I'm not very familiar with u-boot. I'm more comofortable in the kernel.
FWICT, mainline uboot does not have code to handle secure firmware. For instance when secure firmware is present the address to poke a jump address for the CPU is different (nsram +1c etc). This stems from lowlevel_init.S being moved over to the NS area. This is also missing in uboot mainline or so I think.
Hmm, it seems the XU3 has secure firmware so I guess this wont' be useful for me yet?
Curious what platforms you're testing this on? And are any of them using secure firmware?
Also, I'm still a bit unsure where the switch from secure to NS world happens. Is that in BL1? or somewhere in BL2? If it's in BL2, have you tried switching secure mode off?
I hope this helps you out.
Well, it's certainly a step in the right direction, but not sure yet if I can use it on the odroid-xu3 as I'm still trying to understand the boot sequence.
Kevin
The ddr init functions seem to be not correct for the 5422 (or so I think). I do not have access to any of the Samsung docs, hence, one solution was to copy over HKs ddr init function, and then the mainline SPL runs.
Regards
- Suriyan
On Tue, Jan 20, 2015 at 1:30 PM, Kevin Hilman khilman@kernel.org wrote:
Hello Suriyan,
Suriyan Ramasami suriyan.r@gmail.com writes:
Hello Sjoerd Simons, A signed BL2 which allows unsigned BL2 chain load is already available for experimentation. Refer this link: http://forum.odroid.com/viewtopic.php?f=98&t=6147#p58984 The suriyan.bl2-hkxu3.1212.5422.zip blob contains a signed BL2 which allows the same. The layout of SD card is as follows:
BL1 (1 to 30) 15K BL2 (31 to 62) 16K indicator block (63 to 64) 1K uboot (65 to 2112) 1M tzsw (2113 to 2624) 256K unsigned BL2 (2625 to 2656) 16K
A non zero in the first byte of the indicator block instructs the signed BL2 to load the unsigned BL2 @ offset 2625.
I'm currently running mainline u-boot, and hoping to test the series that powers down secondary cores on the odroid-xu3. That series applies and builds with mainline u-boot (v2015.01-rc3), but for it to work correctly, IIUC, I'll also need to build an SPL from mainline.
Can you share your changes to mainline u-boot that enable the building of SPL?
I'd like to try that using your BL2 that will load an unsigned BL2.
Thanks,
Kevin
Hello Kevin,
On Tue, Jan 20, 2015 at 2:43 PM, Kevin Hilman khilman@kernel.org wrote:
Suriyan Ramasami suriyan.r@gmail.com writes:
Hello Kevin, These are the changes that would be necessary in uboot mainline for SPL:
arch/arm/cpu/armv7/exynos/Kconfig
select OF_CONTROL
select SUPPORT_SPLselect OF_CONTROL if !SPL_BUILDconfigs/odroid-xu3_defconfig +CONFIG_SPL=y
include/configs/odroid_xu3.h #undef CONFIG_SPL_TEXT_BASE #define CONFIG_SPL_TEXT_BASE 0x02027000
#undef CONFIG_SEC_FW_SIZE #define CONFIG_SEC_FW_SIZE (15 << 10) /* 15 KB */
Thanks. With those changes, a build gives me:
./include/common.h:355:73: fatal error: asm/u-boot-sandbox.h: No such file or directory
Sorry for the dumb questions, but I'm not very familiar with u-boot. I'm more comofortable in the kernel.
The above used to work (a month ago). I shall check with current mainline uboot and report back.
FWICT, mainline uboot does not have code to handle secure firmware. For instance when secure firmware is present the address to poke a jump address for the CPU is different (nsram +1c etc). This stems from lowlevel_init.S being moved over to the NS area. This is also missing in uboot mainline or so I think.
Hmm, it seems the XU3 has secure firmware so I guess this wont' be useful for me yet?
It should be relevant to you, as mainline uboot does not overlay the NS area with a bootstrap code from lowlevel_init.S. At least I have seen mainline linux src code using this address for waking up the CPUs (so does XEN).
Curious what platforms you're testing this on? And are any of them using secure firmware?
I am currently working only on the XU3 (I thought there was no interest, so I let it slide). I probably should say that the Exynos secure firmware support needs to be tweaked in U-Boot. Maybe other SoCs are supported? I am not sure.
Also, I'm still a bit unsure where the switch from secure to NS world happens. Is that in BL1? or somewhere in BL2? If it's in BL2, have you tried switching secure mode off?
I know for sure that the signed BL2 does switch from Hyp to NS. This BL2 that I am referring to is HK's nomenclature, which translates to BL1 (SPL) in UBoot lingo. Hence, this adds some confusion in the discussions!
The blobs are as follows: (possibly listed in the HK web pages) BL0 (signed encrypted blob from Samsung). This loads HK's signed BL2 (this is U-Boot SPL) This loads U-Boot (U-Boot BL2) and the Trustzone
Also, no matter what mode the odroid xu3 is in, the linux kernel from what I can tell depending on the secure-firmware dts entry (which is present) will use the NS + 1c area when powering on the CPU. Hence, its mandatory to have code there.
I hope this helps you out.
Well, it's certainly a step in the right direction, but not sure yet if I can use it on the odroid-xu3 as I'm still trying to understand the boot sequence.
Kevin
The ddr init functions seem to be not correct for the 5422 (or so I think). I do not have access to any of the Samsung docs, hence, one solution was to copy over HKs ddr init function, and then the mainline SPL runs.
Regards
- Suriyan
On Tue, Jan 20, 2015 at 1:30 PM, Kevin Hilman khilman@kernel.org wrote:
Hello Suriyan,
Suriyan Ramasami suriyan.r@gmail.com writes:
Hello Sjoerd Simons, A signed BL2 which allows unsigned BL2 chain load is already available for experimentation. Refer this link: http://forum.odroid.com/viewtopic.php?f=98&t=6147#p58984 The suriyan.bl2-hkxu3.1212.5422.zip blob contains a signed BL2 which allows the same. The layout of SD card is as follows:
BL1 (1 to 30) 15K BL2 (31 to 62) 16K indicator block (63 to 64) 1K uboot (65 to 2112) 1M tzsw (2113 to 2624) 256K unsigned BL2 (2625 to 2656) 16K
A non zero in the first byte of the indicator block instructs the signed BL2 to load the unsigned BL2 @ offset 2625.
I'm currently running mainline u-boot, and hoping to test the series that powers down secondary cores on the odroid-xu3. That series applies and builds with mainline u-boot (v2015.01-rc3), but for it to work correctly, IIUC, I'll also need to build an SPL from mainline.
Can you share your changes to mainline u-boot that enable the building of SPL?
I'd like to try that using your BL2 that will load an unsigned BL2.
Thanks,
Kevin
Hello Kevin,
On Tue, Jan 20, 2015 at 3:29 PM, Suriyan Ramasami suriyan.r@gmail.com wrote:
Hello Kevin,
On Tue, Jan 20, 2015 at 2:43 PM, Kevin Hilman khilman@kernel.org wrote:
Suriyan Ramasami suriyan.r@gmail.com writes:
Hello Kevin, These are the changes that would be necessary in uboot mainline for SPL:
arch/arm/cpu/armv7/exynos/Kconfig
select OF_CONTROL
select SUPPORT_SPLselect OF_CONTROL if !SPL_BUILDconfigs/odroid-xu3_defconfig +CONFIG_SPL=y
include/configs/odroid_xu3.h #undef CONFIG_SPL_TEXT_BASE #define CONFIG_SPL_TEXT_BASE 0x02027000
#undef CONFIG_SEC_FW_SIZE #define CONFIG_SEC_FW_SIZE (15 << 10) /* 15 KB */
Thanks. With those changes, a build gives me:
./include/common.h:355:73: fatal error: asm/u-boot-sandbox.h: No such file or directory
Sorry for the dumb questions, but I'm not very familiar with u-boot. I'm more comofortable in the kernel.
The above used to work (a month ago). I shall check with current mainline uboot and report back.
Sorry for the snafu. I t was my mistake. The correct diff for the configs is as below:
diff --git a/arch/arm/cpu/armv7/exynos/Kconfig b/arch/arm/cpu/armv7/exynos/Kconfig index 7fcb5d2..39953e4 100644 --- a/arch/arm/cpu/armv7/exynos/Kconfig +++ b/arch/arm/cpu/armv7/exynos/Kconfig @@ -26,7 +26,8 @@ config TARGET_ODROID
config TARGET_ODROID_XU3 bool "Exynos5422 Odroid board" - select OF_CONTROL + select SUPPORT_SPL + select OF_CONTROL if !SPL_BUILD
config TARGET_ARNDALE bool "Exynos5250 Arndale board" diff --git a/configs/odroid-xu3_defconfig b/configs/odroid-xu3_defconfig index 74aa0cf..6000ec1 100644 --- a/configs/odroid-xu3_defconfig +++ b/configs/odroid-xu3_defconfig @@ -1,4 +1,5 @@ -CONFIG_ARM=y -CONFIG_ARCH_EXYNOS=y -CONFIG_TARGET_ODROID_XU3=y +CONFIG_SPL=y ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_EXYNOS=y ++S:CONFIG_TARGET_ODROID_XU3=y CONFIG_DEFAULT_DEVICE_TREE="exynos5422-odroidxu3"
FWICT, mainline uboot does not have code to handle secure firmware. For instance when secure firmware is present the address to poke a jump address for the CPU is different (nsram +1c etc). This stems from lowlevel_init.S being moved over to the NS area. This is also missing in uboot mainline or so I think.
Hmm, it seems the XU3 has secure firmware so I guess this wont' be useful for me yet?
It should be relevant to you, as mainline uboot does not overlay the NS area with a bootstrap code from lowlevel_init.S. At least I have seen mainline linux src code using this address for waking up the CPUs (so does XEN).
Curious what platforms you're testing this on? And are any of them using secure firmware?
I am currently working only on the XU3 (I thought there was no interest, so I let it slide). I probably should say that the Exynos secure firmware support needs to be tweaked in U-Boot. Maybe other SoCs are supported? I am not sure.
Also, I'm still a bit unsure where the switch from secure to NS world happens. Is that in BL1? or somewhere in BL2? If it's in BL2, have you tried switching secure mode off?
I know for sure that the signed BL2 does switch from Hyp to NS. This BL2 that I am referring to is HK's nomenclature, which translates to BL1 (SPL) in UBoot lingo. Hence, this adds some confusion in the discussions!
The blobs are as follows: (possibly listed in the HK web pages) BL0 (signed encrypted blob from Samsung). This loads HK's signed BL2 (this is U-Boot SPL) This loads U-Boot (U-Boot BL2) and the Trustzone
Also, no matter what mode the odroid xu3 is in, the linux kernel from what I can tell depending on the secure-firmware dts entry (which is present) will use the NS + 1c area when powering on the CPU. Hence, its mandatory to have code there.
I hope this helps you out.
Well, it's certainly a step in the right direction, but not sure yet if I can use it on the odroid-xu3 as I'm still trying to understand the boot sequence.
Kevin
The ddr init functions seem to be not correct for the 5422 (or so I think). I do not have access to any of the Samsung docs, hence, one solution was to copy over HKs ddr init function, and then the mainline SPL runs.
Regards
- Suriyan
On Tue, Jan 20, 2015 at 1:30 PM, Kevin Hilman khilman@kernel.org wrote:
Hello Suriyan,
Suriyan Ramasami suriyan.r@gmail.com writes:
Hello Sjoerd Simons, A signed BL2 which allows unsigned BL2 chain load is already available for experimentation. Refer this link: http://forum.odroid.com/viewtopic.php?f=98&t=6147#p58984 The suriyan.bl2-hkxu3.1212.5422.zip blob contains a signed BL2 which allows the same. The layout of SD card is as follows:
BL1 (1 to 30) 15K BL2 (31 to 62) 16K indicator block (63 to 64) 1K uboot (65 to 2112) 1M tzsw (2113 to 2624) 256K unsigned BL2 (2625 to 2656) 16K
A non zero in the first byte of the indicator block instructs the signed BL2 to load the unsigned BL2 @ offset 2625.
I'm currently running mainline u-boot, and hoping to test the series that powers down secondary cores on the odroid-xu3. That series applies and builds with mainline u-boot (v2015.01-rc3), but for it to work correctly, IIUC, I'll also need to build an SPL from mainline.
Can you share your changes to mainline u-boot that enable the building of SPL?
I'd like to try that using your BL2 that will load an unsigned BL2.
Thanks,
Kevin
Hello Kevin,
On Tue, Jan 20, 2015 at 3:38 PM, Suriyan Ramasami suriyan.r@gmail.com wrote:
Hello Kevin,
On Tue, Jan 20, 2015 at 3:29 PM, Suriyan Ramasami suriyan.r@gmail.com wrote:
Hello Kevin,
On Tue, Jan 20, 2015 at 2:43 PM, Kevin Hilman khilman@kernel.org wrote:
Suriyan Ramasami suriyan.r@gmail.com writes:
Hello Kevin, These are the changes that would be necessary in uboot mainline for SPL:
arch/arm/cpu/armv7/exynos/Kconfig
select OF_CONTROL
select SUPPORT_SPLselect OF_CONTROL if !SPL_BUILDconfigs/odroid-xu3_defconfig +CONFIG_SPL=y
include/configs/odroid_xu3.h #undef CONFIG_SPL_TEXT_BASE #define CONFIG_SPL_TEXT_BASE 0x02027000
#undef CONFIG_SEC_FW_SIZE #define CONFIG_SEC_FW_SIZE (15 << 10) /* 15 KB */
Thanks. With those changes, a build gives me:
./include/common.h:355:73: fatal error: asm/u-boot-sandbox.h: No such file or directory
Sorry for the dumb questions, but I'm not very familiar with u-boot. I'm more comofortable in the kernel.
The above used to work (a month ago). I shall check with current mainline uboot and report back.
Sorry for the snafu. I t was my mistake. The correct diff for the configs is as below:
diff --git a/arch/arm/cpu/armv7/exynos/Kconfig b/arch/arm/cpu/armv7/exynos/Kconfig index 7fcb5d2..39953e4 100644 --- a/arch/arm/cpu/armv7/exynos/Kconfig +++ b/arch/arm/cpu/armv7/exynos/Kconfig @@ -26,7 +26,8 @@ config TARGET_ODROID
config TARGET_ODROID_XU3 bool "Exynos5422 Odroid board"
select OF_CONTROL
select SUPPORT_SPLselect OF_CONTROL if !SPL_BUILDconfig TARGET_ARNDALE bool "Exynos5250 Arndale board" diff --git a/configs/odroid-xu3_defconfig b/configs/odroid-xu3_defconfig index 74aa0cf..6000ec1 100644 --- a/configs/odroid-xu3_defconfig +++ b/configs/odroid-xu3_defconfig @@ -1,4 +1,5 @@ -CONFIG_ARM=y -CONFIG_ARCH_EXYNOS=y -CONFIG_TARGET_ODROID_XU3=y +CONFIG_SPL=y ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_EXYNOS=y ++S:CONFIG_TARGET_ODROID_XU3=y CONFIG_DEFAULT_DEVICE_TREE="exynos5422-odroidxu3"
FWICT, mainline uboot does not have code to handle secure firmware. For instance when secure firmware is present the address to poke a jump address for the CPU is different (nsram +1c etc). This stems from lowlevel_init.S being moved over to the NS area. This is also missing in uboot mainline or so I think.
Hmm, it seems the XU3 has secure firmware so I guess this wont' be useful for me yet?
It should be relevant to you, as mainline uboot does not overlay the NS area with a bootstrap code from lowlevel_init.S. At least I have seen mainline linux src code using this address for waking up the CPUs (so does XEN).
I just checked the patch you were referring to, and Akshay has indeed pulled in the the .S file I was referring to. https://patchwork.ozlabs.org/patch/429425/ (sec_boot.s)
Hence, things should be more doable
- Suriyan
Curious what platforms you're testing this on? And are any of them using secure firmware?
I am currently working only on the XU3 (I thought there was no interest, so I let it slide). I probably should say that the Exynos secure firmware support needs to be tweaked in U-Boot. Maybe other SoCs are supported? I am not sure.
Also, I'm still a bit unsure where the switch from secure to NS world happens. Is that in BL1? or somewhere in BL2? If it's in BL2, have you tried switching secure mode off?
I know for sure that the signed BL2 does switch from Hyp to NS. This BL2 that I am referring to is HK's nomenclature, which translates to BL1 (SPL) in UBoot lingo. Hence, this adds some confusion in the discussions!
The blobs are as follows: (possibly listed in the HK web pages) BL0 (signed encrypted blob from Samsung). This loads HK's signed BL2 (this is U-Boot SPL) This loads U-Boot (U-Boot BL2) and the Trustzone
Also, no matter what mode the odroid xu3 is in, the linux kernel from what I can tell depending on the secure-firmware dts entry (which is present) will use the NS + 1c area when powering on the CPU. Hence, its mandatory to have code there.
I hope this helps you out.
Well, it's certainly a step in the right direction, but not sure yet if I can use it on the odroid-xu3 as I'm still trying to understand the boot sequence.
Kevin
The ddr init functions seem to be not correct for the 5422 (or so I think). I do not have access to any of the Samsung docs, hence, one solution was to copy over HKs ddr init function, and then the mainline SPL runs.
Regards
- Suriyan
On Tue, Jan 20, 2015 at 1:30 PM, Kevin Hilman khilman@kernel.org wrote:
Hello Suriyan,
Suriyan Ramasami suriyan.r@gmail.com writes:
Hello Sjoerd Simons, A signed BL2 which allows unsigned BL2 chain load is already available for experimentation. Refer this link: http://forum.odroid.com/viewtopic.php?f=98&t=6147#p58984 The suriyan.bl2-hkxu3.1212.5422.zip blob contains a signed BL2 which allows the same. The layout of SD card is as follows:
BL1 (1 to 30) 15K BL2 (31 to 62) 16K indicator block (63 to 64) 1K uboot (65 to 2112) 1M tzsw (2113 to 2624) 256K unsigned BL2 (2625 to 2656) 16K
A non zero in the first byte of the indicator block instructs the signed BL2 to load the unsigned BL2 @ offset 2625.
I'm currently running mainline u-boot, and hoping to test the series that powers down secondary cores on the odroid-xu3. That series applies and builds with mainline u-boot (v2015.01-rc3), but for it to work correctly, IIUC, I'll also need to build an SPL from mainline.
Can you share your changes to mainline u-boot that enable the building of SPL?
I'd like to try that using your BL2 that will load an unsigned BL2.
Thanks,
Kevin
Suriyan Ramasami suriyan.r@gmail.com writes:
Hello Kevin,
On Tue, Jan 20, 2015 at 3:29 PM, Suriyan Ramasami suriyan.r@gmail.com wrote:
Hello Kevin,
On Tue, Jan 20, 2015 at 2:43 PM, Kevin Hilman khilman@kernel.org wrote:
Suriyan Ramasami suriyan.r@gmail.com writes:
Hello Kevin, These are the changes that would be necessary in uboot mainline for SPL:
arch/arm/cpu/armv7/exynos/Kconfig
select OF_CONTROL
select SUPPORT_SPLselect OF_CONTROL if !SPL_BUILDconfigs/odroid-xu3_defconfig +CONFIG_SPL=y
include/configs/odroid_xu3.h #undef CONFIG_SPL_TEXT_BASE #define CONFIG_SPL_TEXT_BASE 0x02027000
#undef CONFIG_SEC_FW_SIZE #define CONFIG_SEC_FW_SIZE (15 << 10) /* 15 KB */
Thanks. With those changes, a build gives me:
./include/common.h:355:73: fatal error: asm/u-boot-sandbox.h: No such file or directory
Sorry for the dumb questions, but I'm not very familiar with u-boot. I'm more comofortable in the kernel.
The above used to work (a month ago). I shall check with current mainline uboot and report back.
Sorry for the snafu. I t was my mistake. The correct diff for the configs is as below:
diff --git a/arch/arm/cpu/armv7/exynos/Kconfig b/arch/arm/cpu/armv7/exynos/Kconfig index 7fcb5d2..39953e4 100644 --- a/arch/arm/cpu/armv7/exynos/Kconfig +++ b/arch/arm/cpu/armv7/exynos/Kconfig @@ -26,7 +26,8 @@ config TARGET_ODROID
config TARGET_ODROID_XU3 bool "Exynos5422 Odroid board"
select OF_CONTROL
select SUPPORT_SPLselect OF_CONTROL if !SPL_BUILDconfig TARGET_ARNDALE bool "Exynos5250 Arndale board" diff --git a/configs/odroid-xu3_defconfig b/configs/odroid-xu3_defconfig index 74aa0cf..6000ec1 100644 --- a/configs/odroid-xu3_defconfig +++ b/configs/odroid-xu3_defconfig @@ -1,4 +1,5 @@ -CONFIG_ARM=y -CONFIG_ARCH_EXYNOS=y -CONFIG_TARGET_ODROID_XU3=y +CONFIG_SPL=y ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_EXYNOS=y ++S:CONFIG_TARGET_ODROID_XU3=y CONFIG_DEFAULT_DEVICE_TREE="exynos5422-odroidxu3"
Thanks, that gets things building. Just to double-check, no additional changes to include/configs/odroid_xu3.h?
Also, which image are you using as your unsigned BL2? spl/u-boot-spl.bin or spl/smdk5420-spl.bin?
The later seems to be generated from the former using tools/mkexynosspl, but not sure exactly what it's doing, or if its needed on all boards or just the smdk5420 (as the name implies).
Thanks,
Kevin
On Tue, 2015-01-20 at 15:29 -0800, Suriyan Ramasami wrote:
Hello Kevin,
On Tue, Jan 20, 2015 at 2:43 PM, Kevin Hilman khilman@kernel.org wrote:
Suriyan Ramasami suriyan.r@gmail.com writes:
I am currently working only on the XU3 (I thought there was no interest, so I let it slide). I probably should say that the Exynos secure firmware support needs to be tweaked in U-Boot. Maybe other SoCs are supported? I am not sure.
Thanks for the update!
Also, I'm still a bit unsure where the switch from secure to NS world happens. Is that in BL1? or somewhere in BL2? If it's in BL2, have you tried switching secure mode off?
I know for sure that the signed BL2 does switch from Hyp to NS. This BL2 that I am referring to is HK's nomenclature, which translates to BL1 (SPL) in UBoot lingo. Hence, this adds some confusion in the discussions!
It does!. What i was wondering if there would be potential to get a signed BL2 which does *not* do the switch to the NS world, such that an unsigned chain-loaded SPL could (optionally) do that.
The blobs are as follows: (possibly listed in the HK web pages) BL0 (signed encrypted blob from Samsung). This loads HK's signed BL2 (this is U-Boot SPL) This loads U-Boot (U-Boot BL2) and the Trustzone
Also, no matter what mode the odroid xu3 is in, the linux kernel from what I can tell depending on the secure-firmware dts entry (which is present) will use the NS + 1c area when powering on the CPU. Hence, its mandatory to have code there.
Well this is something we can tune as required in case it would be possible to start linux in both secure and NS mode.
Hi Surijan,
Suriyan Ramasami suriyan.r@gmail.com writes:
Hello Sjoerd Simons, A signed BL2 which allows unsigned BL2 chain load is already available for experimentation. Refer this link: http://forum.odroid.com/viewtopic.php?f=98&t=6147#p58984 The suriyan.bl2-hkxu3.1212.5422.zip blob contains a signed BL2 which allows the same.
The layout of SD card is as follows:
BL1 (1 to 30) 15K BL2 (31 to 62) 16K indicator block (63 to 64) 1K uboot (65 to 2112) 1M tzsw (2113 to 2624) 256K unsigned BL2 (2625 to 2656) 16K
A non zero in the first byte of the indicator block instructs the signed BL2 to load the unsigned BL2 @ offset 2625.
I took the binaries from your .zip file above and put them on the SD card for my odroid-xu3 at the offsets above. I'm using BL1 and TZSW from the u-boot-hardkernel release[1] and using u-boot-dtb.bin from my own mainline u-boot build which inclues the odroid-xu3 patches.
If I leave the indicator block zero'd, everything works fine, and it boots my version of mainline u-boot without any problems.
If I then write a non-zero value to the first byte of the indicator block and write your unsigned BL2 at the appropriate offset, it no longer boots. Is the unsigned BL2 supposed to boot u-boot at offset 65 when it's finished as well?
How are you debugging your SPL images?
I tried adding CONFIG_SPL_SERIAL_SUPPORT so I could printf from SPL, but that doesn't compile because it seems that libfdt support is needed.
Kevin
[1] branch odroidxu3-v2012.07 from https://github.com/hardkernel/u-boot.git has pre-built binaries that support u-boot size up to 1M in the sd_fuse/hardkernel_1mb_uboot directory.
Hello Kevin,
On Wed, Jan 21, 2015 at 4:54 PM, Kevin Hilman khilman@kernel.org wrote:
Hi Surijan,
Suriyan Ramasami suriyan.r@gmail.com writes:
Hello Sjoerd Simons, A signed BL2 which allows unsigned BL2 chain load is already available for experimentation. Refer this link: http://forum.odroid.com/viewtopic.php?f=98&t=6147#p58984 The suriyan.bl2-hkxu3.1212.5422.zip blob contains a signed BL2 which allows the same.
The layout of SD card is as follows:
BL1 (1 to 30) 15K BL2 (31 to 62) 16K indicator block (63 to 64) 1K uboot (65 to 2112) 1M tzsw (2113 to 2624) 256K unsigned BL2 (2625 to 2656) 16K
A non zero in the first byte of the indicator block instructs the signed BL2 to load the unsigned BL2 @ offset 2625.
I took the binaries from your .zip file above and put them on the SD card for my odroid-xu3 at the offsets above. I'm using BL1 and TZSW from the u-boot-hardkernel release[1] and using u-boot-dtb.bin from my own mainline u-boot build which inclues the odroid-xu3 patches.
If I leave the indicator block zero'd, everything works fine, and it boots my version of mainline u-boot without any problems.
If I then write a non-zero value to the first byte of the indicator block and write your unsigned BL2 at the appropriate offset, it no longer boots. Is the unsigned BL2 supposed to boot u-boot at offset 65 when it's finished as well?
The unsigned SPL from mainline used will be spl/u-boot-spl.bin (raw jump to offset 0 in that file will be pure code without headers)
Changes are needed in spl_boot.c to make it next load u-boot-dtb.bin.
I shall try to list most of the changes here: 1.arch/arm/cpu/armv7/exynos/spl_boot.c: The Odroid-XU3's IROM function pointers does not have any code (AFAICT). I checked the locations that are listed in the array table and found all 0's there. We need to replace function copy_uboot_to_ram() with something similar from HK's file, so that it uses exynos_smc() calls to load the bits from SD card, or we could enable MMC code in SPL (haven't tried it) and use those functions instead. For quick results,I just forced an SD card read.
2. #define CONFIG_SEC_FW_SIZE (15 << 10) /* 15 KB */ somewhere, so that the start offset for U-Boot is calculated correctly.
3. for chain loading we define CONFIG_SPL_TEXT_BASE to be, say 0x63E00000 so that when its executed the static global pointers are accessed correctly - static struct spl_machine_param machine_param in file smdk5420_spl.c.
4. mem_ctrl_init() hangs in while (val != FOUTBPLL); One workaround is to use HKs version of this function which again uses some smc calls.
With all these changes, SPL chainloading works.
How are you debugging your SPL images?
I tried adding CONFIG_SPL_SERIAL_SUPPORT so I could printf from SPL, but that doesn't compile because it seems that libfdt support is needed.
I didn't enable SERIAL SUPPORT for debugging. I did study the HK SPL code vs mainline SPL code quite a bit and worked from there. I can try to see if there is an easy way to enable serial printfs.
Thanks! - Suriyan
Kevin
[1] branch odroidxu3-v2012.07 from https://github.com/hardkernel/u-boot.git has pre-built binaries that support u-boot size up to 1M in the sd_fuse/hardkernel_1mb_uboot directory.
Suriyan Ramasami suriyan.r@gmail.com writes:
Hello Kevin,
On Wed, Jan 21, 2015 at 4:54 PM, Kevin Hilman khilman@kernel.org wrote:
Hi Surijan,
Suriyan Ramasami suriyan.r@gmail.com writes:
Hello Sjoerd Simons, A signed BL2 which allows unsigned BL2 chain load is already available for experimentation. Refer this link: http://forum.odroid.com/viewtopic.php?f=98&t=6147#p58984 The suriyan.bl2-hkxu3.1212.5422.zip blob contains a signed BL2 which allows the same.
The layout of SD card is as follows:
BL1 (1 to 30) 15K BL2 (31 to 62) 16K indicator block (63 to 64) 1K uboot (65 to 2112) 1M tzsw (2113 to 2624) 256K unsigned BL2 (2625 to 2656) 16K
A non zero in the first byte of the indicator block instructs the signed BL2 to load the unsigned BL2 @ offset 2625.
I took the binaries from your .zip file above and put them on the SD card for my odroid-xu3 at the offsets above. I'm using BL1 and TZSW from the u-boot-hardkernel release[1] and using u-boot-dtb.bin from my own mainline u-boot build which inclues the odroid-xu3 patches.
If I leave the indicator block zero'd, everything works fine, and it boots my version of mainline u-boot without any problems.
If I then write a non-zero value to the first byte of the indicator block and write your unsigned BL2 at the appropriate offset, it no longer boots. Is the unsigned BL2 supposed to boot u-boot at offset 65 when it's finished as well?
The unsigned SPL from mainline used will be spl/u-boot-spl.bin (raw jump to offset 0 in that file will be pure code without headers)
OK.
Changes are needed in spl_boot.c to make it next load u-boot-dtb.bin.
I shall try to list most of the changes here: 1.arch/arm/cpu/armv7/exynos/spl_boot.c: The Odroid-XU3's IROM function pointers does not have any code (AFAICT). I checked the locations that are listed in the array table and found all 0's there. We need to replace function copy_uboot_to_ram() with something similar from HK's file, so that it uses exynos_smc() calls to load the bits from SD card, or we could enable MMC code in SPL (haven't tried it) and use those functions instead. For quick results,I just forced an SD card read.
- #define CONFIG_SEC_FW_SIZE (15 << 10) /* 15 KB */
somewhere, so that the start offset for U-Boot is calculated correctly.
- for chain loading we define CONFIG_SPL_TEXT_BASE to be, say
0x63E00000 so that when its executed the static global pointers are accessed correctly - static struct spl_machine_param machine_param in file smdk5420_spl.c.
- mem_ctrl_init() hangs in while (val != FOUTBPLL);
One workaround is to use HKs version of this function which again uses some smc calls.
With all these changes, SPL chainloading works.
Do you have a patch against mainline u-boot for all these changes? I'd be happy to test.
How are you debugging your SPL images?
I tried adding CONFIG_SPL_SERIAL_SUPPORT so I could printf from SPL, but that doesn't compile because it seems that libfdt support is needed.
I didn't enable SERIAL SUPPORT for debugging. I did study the HK SPL code vs mainline SPL code quite a bit and worked from there. I can try to see if there is an easy way to enable serial printfs.
Are there any GPIO LEDs to blink?
Thanks,
Kevin
On Thu, Jan 22, 2015 at 9:51 AM, Kevin Hilman khilman@kernel.org wrote:
Suriyan Ramasami suriyan.r@gmail.com writes:
Hello Kevin,
On Wed, Jan 21, 2015 at 4:54 PM, Kevin Hilman khilman@kernel.org wrote:
Hi Surijan,
Suriyan Ramasami suriyan.r@gmail.com writes:
Hello Sjoerd Simons, A signed BL2 which allows unsigned BL2 chain load is already available for experimentation. Refer this link: http://forum.odroid.com/viewtopic.php?f=98&t=6147#p58984 The suriyan.bl2-hkxu3.1212.5422.zip blob contains a signed BL2 which allows the same.
The layout of SD card is as follows:
BL1 (1 to 30) 15K BL2 (31 to 62) 16K indicator block (63 to 64) 1K uboot (65 to 2112) 1M tzsw (2113 to 2624) 256K unsigned BL2 (2625 to 2656) 16K
A non zero in the first byte of the indicator block instructs the signed BL2 to load the unsigned BL2 @ offset 2625.
I took the binaries from your .zip file above and put them on the SD card for my odroid-xu3 at the offsets above. I'm using BL1 and TZSW from the u-boot-hardkernel release[1] and using u-boot-dtb.bin from my own mainline u-boot build which inclues the odroid-xu3 patches.
If I leave the indicator block zero'd, everything works fine, and it boots my version of mainline u-boot without any problems.
If I then write a non-zero value to the first byte of the indicator block and write your unsigned BL2 at the appropriate offset, it no longer boots. Is the unsigned BL2 supposed to boot u-boot at offset 65 when it's finished as well?
The unsigned SPL from mainline used will be spl/u-boot-spl.bin (raw jump to offset 0 in that file will be pure code without headers)
OK.
Changes are needed in spl_boot.c to make it next load u-boot-dtb.bin.
I shall try to list most of the changes here: 1.arch/arm/cpu/armv7/exynos/spl_boot.c: The Odroid-XU3's IROM function pointers does not have any code (AFAICT). I checked the locations that are listed in the array table and found all 0's there. We need to replace function copy_uboot_to_ram() with something similar from HK's file, so that it uses exynos_smc() calls to load the bits from SD card, or we could enable MMC code in SPL (haven't tried it) and use those functions instead. For quick results,I just forced an SD card read.
- #define CONFIG_SEC_FW_SIZE (15 << 10) /* 15 KB */
somewhere, so that the start offset for U-Boot is calculated correctly.
- for chain loading we define CONFIG_SPL_TEXT_BASE to be, say
0x63E00000 so that when its executed the static global pointers are accessed correctly - static struct spl_machine_param machine_param in file smdk5420_spl.c.
- mem_ctrl_init() hangs in while (val != FOUTBPLL);
One workaround is to use HKs version of this function which again uses some smc calls.
With all these changes, SPL chainloading works.
Do you have a patch against mainline u-boot for all these changes? I'd be happy to test.
Give me some time and I shall iron out my notes and get back to creating a patch for this against mainline U-Boot.
How are you debugging your SPL images?
I tried adding CONFIG_SPL_SERIAL_SUPPORT so I could printf from SPL, but that doesn't compile because it seems that libfdt support is needed.
I didn't enable SERIAL SUPPORT for debugging. I did study the HK SPL code vs mainline SPL code quite a bit and worked from there. I can try to see if there is an easy way to enable serial printfs.
Are there any GPIO LEDs to blink?
It does have some LEDs.
Thanks,
Kevin
Hi Suriyan,
On 01/23/2015 10:46 AM, Suriyan Ramasami wrote:
On Thu, Jan 22, 2015 at 9:51 AM, Kevin Hilman khilman@kernel.org wrote:
Suriyan Ramasami suriyan.r@gmail.com writes:
Hello Kevin,
On Wed, Jan 21, 2015 at 4:54 PM, Kevin Hilman khilman@kernel.org wrote:
Hi Surijan,
Suriyan Ramasami suriyan.r@gmail.com writes:
Hello Sjoerd Simons, A signed BL2 which allows unsigned BL2 chain load is already available for experimentation. Refer this link: http://forum.odroid.com/viewtopic.php?f=98&t=6147#p58984 The suriyan.bl2-hkxu3.1212.5422.zip blob contains a signed BL2 which allows the same.
The layout of SD card is as follows:
BL1 (1 to 30) 15K BL2 (31 to 62) 16K indicator block (63 to 64) 1K uboot (65 to 2112) 1M tzsw (2113 to 2624) 256K unsigned BL2 (2625 to 2656) 16K
A non zero in the first byte of the indicator block instructs the signed BL2 to load the unsigned BL2 @ offset 2625.
I took the binaries from your .zip file above and put them on the SD card for my odroid-xu3 at the offsets above. I'm using BL1 and TZSW from the u-boot-hardkernel release[1] and using u-boot-dtb.bin from my own mainline u-boot build which inclues the odroid-xu3 patches.
If I leave the indicator block zero'd, everything works fine, and it boots my version of mainline u-boot without any problems.
If I then write a non-zero value to the first byte of the indicator block and write your unsigned BL2 at the appropriate offset, it no longer boots. Is the unsigned BL2 supposed to boot u-boot at offset 65 when it's finished as well?
The unsigned SPL from mainline used will be spl/u-boot-spl.bin (raw jump to offset 0 in that file will be pure code without headers)
Is it impossible the unsigned BL2(spl/smdk5422-spl.bin) file from hardkernel u-boot with your chaining signed BL2?
OK.
Changes are needed in spl_boot.c to make it next load u-boot-dtb.bin.
I shall try to list most of the changes here: 1.arch/arm/cpu/armv7/exynos/spl_boot.c: The Odroid-XU3's IROM function pointers does not have any code (AFAICT). I checked the locations that are listed in the array table and found all 0's there. We need to replace function copy_uboot_to_ram() with something similar from HK's file, so that it uses exynos_smc() calls to load the bits from SD card, or we could enable MMC code in SPL (haven't tried it) and use those functions instead. For quick results,I just forced an SD card read.
- #define CONFIG_SEC_FW_SIZE (15 << 10) /* 15 KB */
somewhere, so that the start offset for U-Boot is calculated correctly.
- for chain loading we define CONFIG_SPL_TEXT_BASE to be, say
0x63E00000 so that when its executed the static global pointers are accessed correctly - static struct spl_machine_param machine_param in file smdk5420_spl.c.
- mem_ctrl_init() hangs in while (val != FOUTBPLL);
One workaround is to use HKs version of this function which again uses some smc calls.
With all these changes, SPL chainloading works.
Do you have a patch against mainline u-boot for all these changes? I'd be happy to test.
Give me some time and I shall iron out my notes and get back to creating a patch for this against mainline U-Boot.
I'm also waiting. Thanks for your try.
Thanks.
How are you debugging your SPL images?
I tried adding CONFIG_SPL_SERIAL_SUPPORT so I could printf from SPL, but that doesn't compile because it seems that libfdt support is needed.
I didn't enable SERIAL SUPPORT for debugging. I did study the HK SPL code vs mainline SPL code quite a bit and worked from there. I can try to see if there is an easy way to enable serial printfs.
Are there any GPIO LEDs to blink?
It does have some LEDs.
Thanks,
Kevin
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Hi Suriyan,
On Thu, Jan 22, 2015 at 5:46 PM, Suriyan Ramasami suriyan.r@gmail.com wrote:
On Thu, Jan 22, 2015 at 9:51 AM, Kevin Hilman khilman@kernel.org wrote:
Suriyan Ramasami suriyan.r@gmail.com writes:
Hello Kevin,
On Wed, Jan 21, 2015 at 4:54 PM, Kevin Hilman khilman@kernel.org wrote:
Hi Surijan,
Suriyan Ramasami suriyan.r@gmail.com writes:
Hello Sjoerd Simons, A signed BL2 which allows unsigned BL2 chain load is already available for experimentation. Refer this link: http://forum.odroid.com/viewtopic.php?f=98&t=6147#p58984 The suriyan.bl2-hkxu3.1212.5422.zip blob contains a signed BL2 which allows the same.
The layout of SD card is as follows:
BL1 (1 to 30) 15K BL2 (31 to 62) 16K indicator block (63 to 64) 1K uboot (65 to 2112) 1M tzsw (2113 to 2624) 256K unsigned BL2 (2625 to 2656) 16K
A non zero in the first byte of the indicator block instructs the signed BL2 to load the unsigned BL2 @ offset 2625.
I took the binaries from your .zip file above and put them on the SD card for my odroid-xu3 at the offsets above. I'm using BL1 and TZSW from the u-boot-hardkernel release[1] and using u-boot-dtb.bin from my own mainline u-boot build which inclues the odroid-xu3 patches.
If I leave the indicator block zero'd, everything works fine, and it boots my version of mainline u-boot without any problems.
If I then write a non-zero value to the first byte of the indicator block and write your unsigned BL2 at the appropriate offset, it no longer boots. Is the unsigned BL2 supposed to boot u-boot at offset 65 when it's finished as well?
The unsigned SPL from mainline used will be spl/u-boot-spl.bin (raw jump to offset 0 in that file will be pure code without headers)
OK.
Changes are needed in spl_boot.c to make it next load u-boot-dtb.bin.
I shall try to list most of the changes here: 1.arch/arm/cpu/armv7/exynos/spl_boot.c: The Odroid-XU3's IROM function pointers does not have any code (AFAICT). I checked the locations that are listed in the array table and found all 0's there. We need to replace function copy_uboot_to_ram() with something similar from HK's file, so that it uses exynos_smc() calls to load the bits from SD card, or we could enable MMC code in SPL (haven't tried it) and use those functions instead. For quick results,I just forced an SD card read.
- #define CONFIG_SEC_FW_SIZE (15 << 10) /* 15 KB */
somewhere, so that the start offset for U-Boot is calculated correctly.
- for chain loading we define CONFIG_SPL_TEXT_BASE to be, say
0x63E00000 so that when its executed the static global pointers are accessed correctly - static struct spl_machine_param machine_param in file smdk5420_spl.c.
- mem_ctrl_init() hangs in while (val != FOUTBPLL);
One workaround is to use HKs version of this function which again uses some smc calls.
With all these changes, SPL chainloading works.
Do you have a patch against mainline u-boot for all these changes? I'd be happy to test.
Give me some time and I shall iron out my notes and get back to creating a patch for this against mainline U-Boot.
Curious if you've had any time to prepare some patches against mainline u-boot. I'm very curious to try this on the odroid-xu3.
Thanks,
Kevin
Hello Kevin, Sorry to have put this in the back burner. Life knocked me over the head seeking attention. I shall focus back on this soon.
Sorry, once again, - Suriyan
On Wed, Feb 25, 2015 at 1:38 PM, Kevin Hilman khilman@kernel.org wrote:
Hi Suriyan,
On Thu, Jan 22, 2015 at 5:46 PM, Suriyan Ramasami suriyan.r@gmail.com wrote:
On Thu, Jan 22, 2015 at 9:51 AM, Kevin Hilman khilman@kernel.org wrote:
Suriyan Ramasami suriyan.r@gmail.com writes:
Hello Kevin,
On Wed, Jan 21, 2015 at 4:54 PM, Kevin Hilman khilman@kernel.org wrote:
Hi Surijan,
Suriyan Ramasami suriyan.r@gmail.com writes:
Hello Sjoerd Simons, A signed BL2 which allows unsigned BL2 chain load is already available for experimentation. Refer this link: http://forum.odroid.com/viewtopic.php?f=98&t=6147#p58984 The suriyan.bl2-hkxu3.1212.5422.zip blob contains a signed BL2 which allows the same.
The layout of SD card is as follows:
BL1 (1 to 30) 15K BL2 (31 to 62) 16K indicator block (63 to 64) 1K uboot (65 to 2112) 1M tzsw (2113 to 2624) 256K unsigned BL2 (2625 to 2656) 16K
A non zero in the first byte of the indicator block instructs the signed BL2 to load the unsigned BL2 @ offset 2625.
I took the binaries from your .zip file above and put them on the SD card for my odroid-xu3 at the offsets above. I'm using BL1 and TZSW from the u-boot-hardkernel release[1] and using u-boot-dtb.bin from my own mainline u-boot build which inclues the odroid-xu3 patches.
If I leave the indicator block zero'd, everything works fine, and it boots my version of mainline u-boot without any problems.
If I then write a non-zero value to the first byte of the indicator block and write your unsigned BL2 at the appropriate offset, it no longer boots. Is the unsigned BL2 supposed to boot u-boot at offset 65 when it's finished as well?
The unsigned SPL from mainline used will be spl/u-boot-spl.bin (raw jump to offset 0 in that file will be pure code without headers)
OK.
Changes are needed in spl_boot.c to make it next load u-boot-dtb.bin.
I shall try to list most of the changes here: 1.arch/arm/cpu/armv7/exynos/spl_boot.c: The Odroid-XU3's IROM function pointers does not have any code (AFAICT). I checked the locations that are listed in the array table and found all 0's there. We need to replace function copy_uboot_to_ram() with something similar from HK's file, so that it uses exynos_smc() calls to load the bits from SD card, or we could enable MMC code in SPL (haven't tried it) and use those functions instead. For quick results,I just forced an SD card read.
- #define CONFIG_SEC_FW_SIZE (15 << 10) /* 15 KB */
somewhere, so that the start offset for U-Boot is calculated correctly.
- for chain loading we define CONFIG_SPL_TEXT_BASE to be, say
0x63E00000 so that when its executed the static global pointers are accessed correctly - static struct spl_machine_param machine_param in file smdk5420_spl.c.
- mem_ctrl_init() hangs in while (val != FOUTBPLL);
One workaround is to use HKs version of this function which again uses some smc calls.
With all these changes, SPL chainloading works.
Do you have a patch against mainline u-boot for all these changes? I'd be happy to test.
Give me some time and I shall iron out my notes and get back to creating a patch for this against mainline U-Boot.
Curious if you've had any time to prepare some patches against mainline u-boot. I'm very curious to try this on the odroid-xu3.
Thanks,
Kevin
participants (4)
-
Joonyoung Shim -
Kevin Hilman -
Sjoerd Simons -
Suriyan Ramasami