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
