[U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address

[U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address

[Sjoerd Simons]

(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 on
> > > the 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
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6170 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150120/b85f821d/attachment.bin>

[U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address

[Suriyan Ramasami]

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 on
>> > > the 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
>>
>>
>
>

[U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address

[Kevin Hilman]

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

[U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address

[Suriyan Ramasami]

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

[U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address

[Kevin Hilman]

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

>  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

[U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address

[Suriyan Ramasami]

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

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

[U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address

[Suriyan Ramasami]

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

[U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address

[Suriyan Ramasami]

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

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

[U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address

[Sjoerd Simons]

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.

-- 
Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Collabora Ltd.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6170 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150121/e0bcbc0d/attachment.bin>

[U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address

[Kevin Hilman]

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_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"

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

[U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address

[Kevin Hilman]

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.

[U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address

[Suriyan Ramasami]

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.

[U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address

[Kevin Hilman]

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

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

[U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address

[Suriyan Ramasami]

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

[U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address

[Joonyoung Shim]

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.
>>>
>>> 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.
>>
>> 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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 

[U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address

[Kevin Hilman]

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

[U-Boot] Odroid XU3 - exynos5422 - SPL - iRAM/sRAM address

[Suriyan Ramasami]

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