Hello Kevin, On Tue, Jan 20, 2015 at 3:29 PM, Suriyan Ramasami <suriya...@gmail.com> wrote: > Hello Kevin, > > On Tue, Jan 20, 2015 at 2:43 PM, Kevin Hilman <khil...@kernel.org> wrote: >> Suriyan Ramasami <suriya...@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_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 */ >> >> 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 <khil...@kernel.org> wrote: >>>> Hello Suriyan, >>>> >>>> Suriyan Ramasami <suriya...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot