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