[U-Boot,v9,2/2] Odroid-XU3: Add documentation for Odroid-XU3

This patch adds documentation for Odroid-XU3. This documentation is
based on that of Odroid (doc/README-odroid) made by Przemyslaw Marczak.
The documentation includes basic information about boot media layout,
environment, partition layout, and the instruction to burn the u-boot
image to boot media.

Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Cc: Minkyu Kang <mk7.kang@samsung.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
---
Changes for v6:
- Newly added

Changes for v7:
- Fix several errata in the documentation

Changes for v8:
- None

Changes for v9:
- Add the new contents to the documentation of Odroid X2/U2, instead of
making new document for Odorid XU3

 doc/README.odroid | 46 ++++++++++++++++++++++++++++++----------------
 1 file changed, 30 insertions(+), 16 deletions(-)

On Thu, 2014-11-27 at 22:21 +0900, Hyungwon Hwang wrote:
> This patch adds documentation for Odroid-XU3. This documentation is
> based on that of Odroid (doc/README-odroid) made by Przemyslaw Marczak.
> The documentation includes basic information about boot media layout,
> environment, partition layout, and the instruction to burn the u-boot
> image to boot media.

>  4. Boot media layout
>  ====================
>  The table below shows SD/eMMC cards layout for U-boot.
> @@ -35,18 +46,20 @@ The block offset is starting from 0 and the block size is 512B.
>  | Bl2       | 31   | 30   |  1 (boot) |
>  | U-boot    | 63   | 62   |  1 (boot) |
>  | Tzsw      | 2111 | 2110 |  1 (boot) |
> -| Uboot Env | 2500 | 2500 |  0 (user) |
> +| Uboot Env | 2560 | 2560 |  0 (user) |
>   -------------------------------------

Where the previous values incorrect? Also this doesn't seem to match the
hardkerel script which has:

signed_bl1_position=1
bl2_position=31
uboot_position=63
tzsw_position=719
env_position=1231

for the various locations.. Which also explains the limit 335872 bytes
in your initial mail.. Awkward one though. Wonder if that's an SoC issue
or something hardkernel could fix by having a different bl1/bl2?

On 11/27/2014 10:21 PM, Hyungwon Hwang wrote:
> This patch adds documentation for Odroid-XU3. This documentation is
> based on that of Odroid (doc/README-odroid) made by Przemyslaw Marczak.
> The documentation includes basic information about boot media layout,
> environment, partition layout, and the instruction to burn the u-boot
> image to boot media.
> 
> Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com>
> Tested-by: Lukasz Majewski <l.majewski@samsung.com>
> Acked-by: Lukasz Majewski <l.majewski@samsung.com>
> Cc: Minkyu Kang <mk7.kang@samsung.com>
> Cc: Lukasz Majewski <l.majewski@samsung.com>
> ---
> Changes for v6:
> - Newly added
> 
> Changes for v7:
> - Fix several errata in the documentation
> 
> Changes for v8:
> - None
> 
> Changes for v9:
> - Add the new contents to the documentation of Odroid X2/U2, instead of
> making new document for Odorid XU3
> 
>  doc/README.odroid | 46 ++++++++++++++++++++++++++++++----------------
>  1 file changed, 30 insertions(+), 16 deletions(-)
> 
> diff --git a/doc/README.odroid b/doc/README.odroid
> index 25b962b..99693d4 100644
> --- a/doc/README.odroid
> +++ b/doc/README.odroid
> @@ -1,28 +1,39 @@
> - U-boot for Odroid X2/U3
> + U-boot for Odroid X2/U3/XU3
>  ========================
>  
>  1. Summary
>  ==========
> -This is a quick instruction for setup Odroid boards based on Exynos4412.

s/Exynos4412/Exynos/ ?

Best Regards,
Jaehoon Chung

> -Board config: odroid_config
> +This is a quick instruction for setup Odroid boards.
> +Board config: odroid_config for X2/U3
> +Board config: odroid-xu3_config for XU3
>  
>  2. Supported devices
>  ====================
> -This U-BOOT config can be used on two boards:
> +This U-BOOT config can be used on three boards:
>  - Odroid U3
>  - Odroid X2
>  with CPU Exynos 4412 rev 2.0 and 2GB of RAM
> +- Odroid XU3
> +with CPU Exynos5422 and 2GB of RAM
>  
>  3. Boot sequence
>  ================
>  iROM->BL1->(BL2 + TrustZone)->U-BOOT
>  
> -This version of U-BOOT doesn't implement SPL but it is required(BL2)
> -and can be found in "boot.tar.gz" from here:
> +This version of U-BOOT doesn't implement SPL. So, BL1, BL2, and TrustZone
> +binaries are needed to boot up.
> +
> +<< X2/U3 >>
> +It can be found in "boot.tar.gz" from here:
>  http://dev.odroid.com/projects/4412boot/wiki/FrontPage?action=download&value=boot.tar.gz
>  or here:
>  http://odroid.in/guides/ubuntu-lfs/boot.tar.gz
>  
> +<< XU3 >>
> +It can be downloaded from:
> +https://github.com/hardkernel/u-boot/tree/odroidxu3-v2012.07/sd_fuse/hardkernel
> +
> +
>  4. Boot media layout
>  ====================
>  The table below shows SD/eMMC cards layout for U-boot.
> @@ -35,18 +46,20 @@ The block offset is starting from 0 and the block size is 512B.
>  | Bl2       | 31   | 30   |  1 (boot) |
>  | U-boot    | 63   | 62   |  1 (boot) |
>  | Tzsw      | 2111 | 2110 |  1 (boot) |
> -| Uboot Env | 2500 | 2500 |  0 (user) |
> +| Uboot Env | 2560 | 2560 |  0 (user) |
>   -------------------------------------
>  
>  5. Prepare the SD boot card - with SD card reader
>  =================================================
>  To prepare bootable media you need boot binaries provided by hardkernel.
> -File "boot.tar.gz" (link in point 3.) contains:
> -- E4412_S.bl1.HardKernel.bin
> -- E4412_S.tzsw.signed.bin
> -- bl2.signed.bin
> +From the downloaded files, You can find:
> +- bl1.bin
> +- tzsw.bin
> +- bl2.bin
>  - sd_fusing.sh
>  - u-boot.bin
> +(The file names can be slightly different, but you can distinguish what they are
> +without problem)
>  
>  This is all you need to boot this board. But if you want to use your custom
>  u-boot then you need to change u-boot.bin with your own u-boot binary*
> @@ -56,7 +69,7 @@ and run the script "sd_fusing.sh" - this script is valid only for SD card.
>  The proper binary file of current U-boot is u-boot-dtb.bin.
>  
>  quick steps for Linux:
> -- extract boot.tar.gz
> +- Download all files from the link at point 3 and extract it if needed.
>  - put any SD card into the SD reader
>  - check the device with "dmesg"
>  - run ./sd_fusing.sh /dev/sdX - where X is SD card device (but not a partition)
> @@ -66,7 +79,7 @@ Check if Hardkernel U-boot is booting, and next do the same with your U-boot.
>     with a eMMC card reader (boot from eMMC card slot)
>  =====================================================
>  To boot the device from the eMMC slot you should use a special card reader
> -which supports eMMC partiion switch. All of the boot binaries are stored
> +which supports eMMC partition switch. All of the boot binaries are stored
>  on the eMMC boot partition which is normally hidden.
>  
>  The "sd_fusing.sh" script can be used after updating offsets of binaries
> @@ -81,8 +94,8 @@ But then the device can boot only from the SD card slot.
>  
>  8. Prepare the boot media using Hardkernel U-boot
>  =================================================
> -You can update the U-boot to the custom one if you have an working bootloader
> -delivered with the board on a eMMC/SD card. Then follow the steps:
> +You can update the U-boot to the custom one if you have a working bootloader
> +delivered with the board on the eMMC/SD card. Then follow the steps:
>  - install the android fastboot tool
>  - connect a micro usb cable to the board
>  - on the U-boot prompt, run command: fastboot (as a root)
> @@ -91,7 +104,7 @@ delivered with the board on a eMMC/SD card. Then follow the steps:
>  
>  9. Partition layout
>  ====================
> -Default U-boot environment is setup for fixed partiion layout.
> +Default U-boot environment is setup for fixed partition layout.
>  
>  Partition table: MSDOS. Disk layout and files as listed in the table below.
>   ----- ------ ------ ------ -------- ---------------------------------
> @@ -106,6 +119,7 @@ Partition table: MSDOS. Disk layout and files as listed in the table below.
>  Supported fdt files are:
>  - exynos4412-odroidx2.dtb
>  - exynos4412-odroidu3.dtb
> +- exynos5422-odroidxu3.dtb
>  
>  Supported kernel files are:
>  - Image.itb
>

On Thu, 27 Nov 2014 15:33:05 +0100
Sjoerd Simons <sjoerd.simons@collabora.co.uk> wrote:

> On Thu, 2014-11-27 at 22:21 +0900, Hyungwon Hwang wrote:
> > This patch adds documentation for Odroid-XU3. This documentation is
> > based on that of Odroid (doc/README-odroid) made by Przemyslaw
> > Marczak. The documentation includes basic information about boot
> > media layout, environment, partition layout, and the instruction to
> > burn the u-boot image to boot media.
> 
> >  4. Boot media layout
> >  ====================
> >  The table below shows SD/eMMC cards layout for U-boot.
> > @@ -35,18 +46,20 @@ The block offset is starting from 0 and the
> > block size is 512B. | Bl2       | 31   | 30   |  1 (boot) |
> >  | U-boot    | 63   | 62   |  1 (boot) |
> >  | Tzsw      | 2111 | 2110 |  1 (boot) |
> > -| Uboot Env | 2500 | 2500 |  0 (user) |
> > +| Uboot Env | 2560 | 2560 |  0 (user) |
> >   -------------------------------------
> 
> Where the previous values incorrect? Also this doesn't seem to match
> the hardkerel script which has:

This boot media layout is for x2/u3. I will update it in next version.

But the env offset is
#define CONFIG_ENV_OFFSET	(SZ_1K * 1280) /* 1.25 MiB offset */
as you can see in odroid.h and odroid_xu3.h.

CONFIG_ENV_OFFSET / 512 = 2560, not 2500.


> 
> signed_bl1_position=1
> bl2_position=31
> uboot_position=63
> tzsw_position=719
> env_position=1231
> 
> for the various locations.. Which also explains the limit 335872 bytes
> in your initial mail.. Awkward one though. Wonder if that's an SoC
> issue or something hardkernel could fix by having a different bl1/bl2?
> 

(719 - 63) * 512 = 335876 bytes. The limitation is needed not to
overwrite tzsw.

Are you saying that the limitation can be removed? Yes, with different
bl1/bl2. But I do not think that another bl1/bl2 will be released to
relieve the limitation.

On Fri, 2014-11-28 at 13:45 +0900, Hyungwon Hwang wrote:
> On Thu, 27 Nov 2014 15:33:05 +0100
> Sjoerd Simons <sjoerd.simons@collabora.co.uk> wrote:

> > signed_bl1_position=1
> > bl2_position=31
> > uboot_position=63
> > tzsw_position=719
> > env_position=1231
> > 
> > for the various locations.. Which also explains the limit 335872 bytes
> > in your initial mail.. Awkward one though. Wonder if that's an SoC
> > issue or something hardkernel could fix by having a different bl1/bl2?
> > 
> 
> (719 - 63) * 512 = 335876 bytes. The limitation is needed not to
> overwrite tzsw.
> 
> Are you saying that the limitation can be removed? Yes, with different
> bl1/bl2. But I do not think that another bl1/bl2 will be released to
> relieve the limitation.

It was a something i was wondering. After send this e-mail i had a chat
with Mauro Ribeiro on #linux-exynos. He indicate that the BL2 determines
the u-boot load location and that it's an u-boot SPL build from their
u-boot branch. Also he indicated that he would be happy to sign a
modified SPL build which e.g. loads u-boot from behind the TZSW.

You can find the IRC log here:
http://irclog.whitequark.org/linux-exynos/2014-11-27

I have yet to take him up on that offer though, but it sounds like a
good way forward. The current layout really isn't practical.

Hi Sjoerd,

> On Fri, 2014-11-28 at 13:45 +0900, Hyungwon Hwang wrote:
> > On Thu, 27 Nov 2014 15:33:05 +0100
> > Sjoerd Simons <sjoerd.simons@collabora.co.uk> wrote:
> 
> > > signed_bl1_position=1
> > > bl2_position=31
> > > uboot_position=63
> > > tzsw_position=719
> > > env_position=1231
> > > 
> > > for the various locations.. Which also explains the limit 335872
> > > bytes in your initial mail.. Awkward one though. Wonder if that's
> > > an SoC issue or something hardkernel could fix by having a
> > > different bl1/bl2?
> > > 
> > 
> > (719 - 63) * 512 = 335876 bytes. The limitation is needed not to
> > overwrite tzsw.
> > 
> > Are you saying that the limitation can be removed? Yes, with
> > different bl1/bl2. But I do not think that another bl1/bl2 will be
> > released to relieve the limitation.
> 
> It was a something i was wondering. After send this e-mail i had a
> chat with Mauro Ribeiro on #linux-exynos. He indicate that the BL2
> determines the u-boot load location and that it's an u-boot SPL build
> from their u-boot branch. Also he indicated that he would be happy to
> sign a modified SPL build which e.g. loads u-boot from behind the
> TZSW.
> 
> You can find the IRC log here:
> http://irclog.whitequark.org/linux-exynos/2014-11-27
> 
> I have yet to take him up on that offer though, but it sounds like a
> good way forward. The current layout really isn't practical.
> 

It indeed isn't very practical, but this is what you received from
HardKernel when you buy XU3 board.

Of course you can grab their sources, modify the layout, prepare
u-boot's SPL and send it to them to be signed.
However, it is not the way the "normal" user do things.

He or she would like to replace standard (and outdated) HardKernel
u-boot on their SD card and go forward with booting kernel.

For now we _must_ focus on supporting XU3 with default BL1/BL2 and hence
we are obliged to have u-boot size smaller than 328 KiB.

It is challenging but for sure doable.

Best regards,
Lukasz Majewski

On Fri, 2014-11-28 at 09:39 +0100, Lukasz Majewski wrote:
> Hi Sjoerd,
> 
> > On Fri, 2014-11-28 at 13:45 +0900, Hyungwon Hwang wrote:
> > > On Thu, 27 Nov 2014 15:33:05 +0100
> > > Sjoerd Simons <sjoerd.simons@collabora.co.uk> wrote:
> > 
> > > > signed_bl1_position=1
> > > > bl2_position=31
> > > > uboot_position=63
> > > > tzsw_position=719
> > > > env_position=1231
> > > > 
> > > > for the various locations.. Which also explains the limit 335872
> > > > bytes in your initial mail.. Awkward one though. Wonder if that's
> > > > an SoC issue or something hardkernel could fix by having a
> > > > different bl1/bl2?
> > > > 
> > > 
> > > (719 - 63) * 512 = 335876 bytes. The limitation is needed not to
> > > overwrite tzsw.
> > > 
> > > Are you saying that the limitation can be removed? Yes, with
> > > different bl1/bl2. But I do not think that another bl1/bl2 will be
> > > released to relieve the limitation.
> > 
> > It was a something i was wondering. After send this e-mail i had a
> > chat with Mauro Ribeiro on #linux-exynos. He indicate that the BL2
> > determines the u-boot load location and that it's an u-boot SPL build
> > from their u-boot branch. Also he indicated that he would be happy to
> > sign a modified SPL build which e.g. loads u-boot from behind the
> > TZSW.
> > 
> > You can find the IRC log here:
> > http://irclog.whitequark.org/linux-exynos/2014-11-27
> > 
> > I have yet to take him up on that offer though, but it sounds like a
> > good way forward. The current layout really isn't practical.
> > 
> 
> It indeed isn't very practical, but this is what you received from
> HardKernel when you buy XU3 board.
> 
> Of course you can grab their sources, modify the layout, prepare
> u-boot's SPL and send it to them to be signed.
> However, it is not the way the "normal" user do things.
> 
> He or she would like to replace standard (and outdated) HardKernel
> u-boot on their SD card and go forward with booting kernel.

> For now we _must_ focus on supporting XU3 with default BL1/BL2 and hence
> we are obliged to have u-boot size smaller than 328 KiB.

I don't see a big issue with telling the "normal" user[0] to replace
both the BL2 and u-boot itself. If the hardkernel folks indeed do sign
the BL2 for us, i'm more then happy to make that publically available.


0: Do normal users replace u-boot?

Hello Lukasz,

On Fri, Nov 28, 2014 at 9:39 AM, Lukasz Majewski <l.majewski@majess.pl> wrote:
>> I have yet to take him up on that offer though, but it sounds like a
>> good way forward. The current layout really isn't practical.
>>
>
> It indeed isn't very practical, but this is what you received from
> HardKernel when you buy XU3 board.
>
> Of course you can grab their sources, modify the layout, prepare
> u-boot's SPL and send it to them to be signed.
> However, it is not the way the "normal" user do things.
>
> He or she would like to replace standard (and outdated) HardKernel
> u-boot on their SD card and go forward with booting kernel.
>

I agree with Sjoed that normal users don't replace the low-level
components that are provided by the board vendor.

After all you can boot a mainline kernel using the vendor u-boot, just
append the DTB and create a uImage. The practical reason why someone
would want to replace the vendor u-boot is to have more features but
is very hard to do if there is a constraint in the maximum u-boot
image size (even harder if the maximum is such small like in the XU3).

> For now we _must_ focus on supporting XU3 with default BL1/BL2 and hence
> we are obliged to have u-boot size smaller than 328 KiB.
>
> It is challenging but for sure doable.
>

It is doable but I don't see why the default BL2 _must_ be used.

A user that wants to replace the kernel or u-boot is already tech-savy
and can for sure replace the BL2 as well if it's publicly available.
Maybe hardkernel folks can even make the modified BL2 available on
their website and the link added in the comment explaining the layout?

Also, it is an artificial constraint after all and can be easily
modified. In fact I think we should push hardkernel to change that
layout by default and use a BL2/SPL that has more sensible size for
the u-boot binary even if they don't need it for their vendor u-boot
which seems to be quite small.

> Best regards,
> Lukasz Majewski
>

Best regards,
Javier

Hi Sjoerd,

> On Fri, 2014-11-28 at 09:39 +0100, Lukasz Majewski wrote:
> > Hi Sjoerd,
> > 
> > > On Fri, 2014-11-28 at 13:45 +0900, Hyungwon Hwang wrote:
> > > > On Thu, 27 Nov 2014 15:33:05 +0100
> > > > Sjoerd Simons <sjoerd.simons@collabora.co.uk> wrote:
> > > 
> > > > > signed_bl1_position=1
> > > > > bl2_position=31
> > > > > uboot_position=63
> > > > > tzsw_position=719
> > > > > env_position=1231
> > > > > 
> > > > > for the various locations.. Which also explains the limit
> > > > > 335872 bytes in your initial mail.. Awkward one though.
> > > > > Wonder if that's an SoC issue or something hardkernel could
> > > > > fix by having a different bl1/bl2?
> > > > > 
> > > > 
> > > > (719 - 63) * 512 = 335876 bytes. The limitation is needed not to
> > > > overwrite tzsw.
> > > > 
> > > > Are you saying that the limitation can be removed? Yes, with
> > > > different bl1/bl2. But I do not think that another bl1/bl2 will
> > > > be released to relieve the limitation.
> > > 
> > > It was a something i was wondering. After send this e-mail i had a
> > > chat with Mauro Ribeiro on #linux-exynos. He indicate that the BL2
> > > determines the u-boot load location and that it's an u-boot SPL
> > > build from their u-boot branch. Also he indicated that he would
> > > be happy to sign a modified SPL build which e.g. loads u-boot
> > > from behind the TZSW.
> > > 
> > > You can find the IRC log here:
> > > http://irclog.whitequark.org/linux-exynos/2014-11-27
> > > 
> > > I have yet to take him up on that offer though, but it sounds
> > > like a good way forward. The current layout really isn't
> > > practical.
> > > 
> > 
> > It indeed isn't very practical, but this is what you received from
> > HardKernel when you buy XU3 board.
> > 
> > Of course you can grab their sources, modify the layout, prepare
> > u-boot's SPL and send it to them to be signed.
> > However, it is not the way the "normal" user do things.
> > 
> > He or she would like to replace standard (and outdated) HardKernel
> > u-boot on their SD card and go forward with booting kernel.
> 
> > For now we _must_ focus on supporting XU3 with default BL1/BL2 and
> > hence we are obliged to have u-boot size smaller than 328 KiB.
> 
> I don't see a big issue with telling the "normal" user[0] to replace
> both the BL2 and u-boot itself. If the hardkernel folks indeed do sign
> the BL2 for us, i'm more then happy to make that publically available.
> 

I just would like to avoid having two incompatible BL2s floating
around.

Does your use case require u-boot size larger than 328 KiB?
Hyungwon has managed to provide functional one with size less than 328
KiB.

Another issue is the exact SPL source code from which you would like to
build BL2 with modified layout.

Do you plan to use HardKernel's source code and only modify the layout
or use SPL from cutting edge mainline?

Please note that even for tests BL2 must be signed by HardKernel to
cooperate with Samsung's proprietary BL1.

> 
> 0: Do normal users replace u-boot?
> 

I know a few developers who did this because they needed new features
missing in HardKernel's version (like UMS support).

Best regards,
Lukasz Majewski

On Fri, 2014-11-28 at 13:47 +0100, Lukasz Majewski wrote:
> Hi Sjoerd,
> 
> > On Fri, 2014-11-28 at 09:39 +0100, Lukasz Majewski wrote:
> > > Hi Sjoerd,
> > > 
> > > > On Fri, 2014-11-28 at 13:45 +0900, Hyungwon Hwang wrote:
> > > > > On Thu, 27 Nov 2014 15:33:05 +0100
> > > > > Sjoerd Simons <sjoerd.simons@collabora.co.uk> wrote:
> > > > 
> > > > > > signed_bl1_position=1
> > > > > > bl2_position=31
> > > > > > uboot_position=63
> > > > > > tzsw_position=719
> > > > > > env_position=1231
> > > > > > 
> > > > > > for the various locations.. Which also explains the limit
> > > > > > 335872 bytes in your initial mail.. Awkward one though.
> > > > > > Wonder if that's an SoC issue or something hardkernel could
> > > > > > fix by having a different bl1/bl2?
> > > > > > 
> > > > > 
> > > > > (719 - 63) * 512 = 335876 bytes. The limitation is needed not to
> > > > > overwrite tzsw.
> > > > > 
> > > > > Are you saying that the limitation can be removed? Yes, with
> > > > > different bl1/bl2. But I do not think that another bl1/bl2 will
> > > > > be released to relieve the limitation.
> > > > 
> > > > It was a something i was wondering. After send this e-mail i had a
> > > > chat with Mauro Ribeiro on #linux-exynos. He indicate that the BL2
> > > > determines the u-boot load location and that it's an u-boot SPL
> > > > build from their u-boot branch. Also he indicated that he would
> > > > be happy to sign a modified SPL build which e.g. loads u-boot
> > > > from behind the TZSW.
> > > > 
> > > > You can find the IRC log here:
> > > > http://irclog.whitequark.org/linux-exynos/2014-11-27
> > > > 
> > > > I have yet to take him up on that offer though, but it sounds
> > > > like a good way forward. The current layout really isn't
> > > > practical.
> > > > 
> > > 
> > > It indeed isn't very practical, but this is what you received from
> > > HardKernel when you buy XU3 board.
> > > 
> > > Of course you can grab their sources, modify the layout, prepare
> > > u-boot's SPL and send it to them to be signed.
> > > However, it is not the way the "normal" user do things.
> > > 
> > > He or she would like to replace standard (and outdated) HardKernel
> > > u-boot on their SD card and go forward with booting kernel.
> > 
> > > For now we _must_ focus on supporting XU3 with default BL1/BL2 and
> > > hence we are obliged to have u-boot size smaller than 328 KiB.
> > 
> > I don't see a big issue with telling the "normal" user[0] to replace
> > both the BL2 and u-boot itself. If the hardkernel folks indeed do sign
> > the BL2 for us, i'm more then happy to make that publically available.
> > 
> 
> I just would like to avoid having two incompatible BL2s floating
> around.
> 
> Does your use case require u-boot size larger than 328 KiB?
> Hyungwon has managed to provide functional one with size less than 328
> KiB.

Even with that functionality it's incredibly on the edge, if build with
gcc-4.7 it's too big. gcc-4.9 manages to make it *just* small enough.
And that's without support for USB networking, which is pretty useful.

I've done some quick hacks locally to add USB/tftp boot support and
re-use exynos5-dt-common.h/exynos5420-common.h, which already resulted
in it growing to ~440kb.

> Another issue is the exact SPL source code from which you would like to
> build BL2 with modified layout.
> 
> Do you plan to use HardKernel's source code and only modify the layout
> or use SPL from cutting edge mainline?

> Please note that even for tests BL2 must be signed by HardKernel to
> cooperate with Samsung's proprietary BL1.

Yeah, I was planning to just use the SPL from Hardkernels source code
and modify the layout so the behaviour SPL only differ in where they
load u-boot from not in other behaviour.

> > 0: Do normal users replace u-boot?
> > 
> 
> I know a few developers who did this because they needed new features
> missing in HardKernel's version (like UMS support).

That was a bit tongue in cheek. I'm currently chainloading my u-boot
(which is too big to boot from SD) over tftp from hardkernels u-boot, so
that i can tftp boot a kernel + initramfs with the new version.. As
hardkernels u-boot seems to corrupt the initramfs (fun!)..

But apart from that anecdote, the main reason developers replace u-boot
is that the vendors one is missing features. So ideally the default
build of upstream u-boot should be feature-packed, which means the size
gets bigger, which means this limitation in itself is quite annoying
again.

Hello Javier,

> Hello Lukasz,
> 
> On Fri, Nov 28, 2014 at 9:39 AM, Lukasz Majewski
> <l.majewski@majess.pl> wrote:
> >> I have yet to take him up on that offer though, but it sounds like
> >> a good way forward. The current layout really isn't practical.
> >>
> >
> > It indeed isn't very practical, but this is what you received from
> > HardKernel when you buy XU3 board.
> >
> > Of course you can grab their sources, modify the layout, prepare
> > u-boot's SPL and send it to them to be signed.
> > However, it is not the way the "normal" user do things.
> >
> > He or she would like to replace standard (and outdated) HardKernel
> > u-boot on their SD card and go forward with booting kernel.
> >
> 
> I agree with Sjoed that normal users don't replace the low-level
> components that are provided by the board vendor.
> 
> After all you can boot a mainline kernel using the vendor u-boot, just
> append the DTB and create a uImage. The practical reason why someone
> would want to replace the vendor u-boot is to have more features but
> is very hard to do if there is a constraint in the maximum u-boot
> image size (even harder if the maximum is such small like in the XU3).

I agree that 328 KiB size for u-boot is a constraint. I don't know
HardKernel's justification for this.

> 
> > For now we _must_ focus on supporting XU3 with default BL1/BL2 and
> > hence we are obliged to have u-boot size smaller than 328 KiB.
> >
> > It is challenging but for sure doable.
> >
> 
> It is doable but I don't see why the default BL2 _must_ be used.

For practical/pragmatic reasons:

1. It is difficult to have signed BL2 - each time we need to ask
HardKernel for signing it. It is impractical and hampers usage of
mainline SPL (BL2) with XU3. 

2. All the documentation on the HardKernel wiki site refers to the
default BL2.

3. We will have "new" BL2, which source code is based on 2012.07
mainline u-boot.

4. Two BL2 binaries - IMHO will hurt (i.e. brick) some device sooner
or latter.

> 
> A user that wants to replace the kernel or u-boot is already tech-savy
> and can for sure replace the BL2 as well if it's publicly available.

Sorry, but I'm a bit sceptical about updating such low level code. Bad
things do happen.

> Maybe hardkernel folks can even make the modified BL2 available on
> their website and the link added in the comment explaining the layout?

We would then require HardKernel to:

1. Provide updated BL2.img
2. Update their wiki to reflect the new BL2.

> 
> Also, it is an artificial constraint after all and can be easily
> modified. In fact I think we should push hardkernel to change that
> layout by default and use a BL2/SPL that has more sensible size for
> the u-boot binary even if they don't need it for their vendor u-boot
> which seems to be quite small.

I totally agree.

I'd like to propose a following plan:

1. Accept Hyungwon's patches to have XU3 u-boot < 328 KiB (with link to
default BL2) to have XU3 support in place (and treat it as a starting
point)

2. If u-boot's size less than 328 KiB is _really_ a problem to somebody
then ask hardkernel to change BL2 or:
	- modify their sources to change the layout (I regard this as a
	  "quick hack" solution)
	- with a lot of pain develop BL2/SPL (by whom?) which base on
	  newest mainline (then for each test hardkernel must sign the
	  binary).

> 
> > Best regards,
> > Lukasz Majewski
> >
> 
> Best regards,
> Javier

Best regards,
Lukasz Majewski

On Fri, 2014-11-28 at 14:46 +0100, Lukasz Majewski wrote:
> Hello Javier,
> 
> > Hello Lukasz,
> > 
> > On Fri, Nov 28, 2014 at 9:39 AM, Lukasz Majewski
> > <l.majewski@majess.pl> wrote:

> I'd like to propose a following plan:
> 
> 1. Accept Hyungwon's patches to have XU3 u-boot < 328 KiB (with link to
> default BL2) to have XU3 support in place (and treat it as a starting
> point)

Oh, i never said this is a blocker for his patches. So yeah, ofcourse,
lets polish these further so they can land :)

On Fri, 28 Nov 2014 16:06:54 +0100
Sjoerd Simons <sjoerd.simons@collabora.co.uk> wrote:

> On Fri, 2014-11-28 at 14:46 +0100, Lukasz Majewski wrote:
> > Hello Javier,
> > 
> > > Hello Lukasz,
> > > 
> > > On Fri, Nov 28, 2014 at 9:39 AM, Lukasz Majewski
> > > <l.majewski@majess.pl> wrote:
> 
> > I'd like to propose a following plan:
> > 
> > 1. Accept Hyungwon's patches to have XU3 u-boot < 328 KiB (with
> > link to default BL2) to have XU3 support in place (and treat it as
> > a starting point)
> 
> Oh, i never said this is a blocker for his patches. So yeah, ofcourse,
> lets polish these further so they can land :)
> 

+1 :-)

> 
> 
> 

Best regards,
Lukasz Majewski

Hi,

On 28 November 2014 at 06:46, Lukasz Majewski <l.majewski@majess.pl> wrote:
> Hello Javier,
>
>> Hello Lukasz,
>>
>> On Fri, Nov 28, 2014 at 9:39 AM, Lukasz Majewski
>> <l.majewski@majess.pl> wrote:
>> >> I have yet to take him up on that offer though, but it sounds like
>> >> a good way forward. The current layout really isn't practical.
>> >>
>> >
>> > It indeed isn't very practical, but this is what you received from
>> > HardKernel when you buy XU3 board.
>> >
>> > Of course you can grab their sources, modify the layout, prepare
>> > u-boot's SPL and send it to them to be signed.
>> > However, it is not the way the "normal" user do things.
>> >
>> > He or she would like to replace standard (and outdated) HardKernel
>> > u-boot on their SD card and go forward with booting kernel.
>> >
>>
>> I agree with Sjoed that normal users don't replace the low-level
>> components that are provided by the board vendor.
>>
>> After all you can boot a mainline kernel using the vendor u-boot, just
>> append the DTB and create a uImage. The practical reason why someone
>> would want to replace the vendor u-boot is to have more features but
>> is very hard to do if there is a constraint in the maximum u-boot
>> image size (even harder if the maximum is such small like in the XU3).
>
> I agree that 328 KiB size for u-boot is a constraint. I don't know
> HardKernel's justification for this.
>
>>
>> > For now we _must_ focus on supporting XU3 with default BL1/BL2 and
>> > hence we are obliged to have u-boot size smaller than 328 KiB.
>> >
>> > It is challenging but for sure doable.
>> >
>>
>> It is doable but I don't see why the default BL2 _must_ be used.
>
> For practical/pragmatic reasons:
>
> 1. It is difficult to have signed BL2 - each time we need to ask
> HardKernel for signing it. It is impractical and hampers usage of
> mainline SPL (BL2) with XU3.
>
> 2. All the documentation on the HardKernel wiki site refers to the
> default BL2.
>
> 3. We will have "new" BL2, which source code is based on 2012.07
> mainline u-boot.
>
> 4. Two BL2 binaries - IMHO will hurt (i.e. brick) some device sooner
> or latter.
>
>>
>> A user that wants to replace the kernel or u-boot is already tech-savy
>> and can for sure replace the BL2 as well if it's publicly available.
>
> Sorry, but I'm a bit sceptical about updating such low level code. Bad
> things do happen.
>
>> Maybe hardkernel folks can even make the modified BL2 available on
>> their website and the link added in the comment explaining the layout?
>
> We would then require HardKernel to:
>
> 1. Provide updated BL2.img
> 2. Update their wiki to reflect the new BL2.
>
>>
>> Also, it is an artificial constraint after all and can be easily
>> modified. In fact I think we should push hardkernel to change that
>> layout by default and use a BL2/SPL that has more sensible size for
>> the u-boot binary even if they don't need it for their vendor u-boot
>> which seems to be quite small.
>
> I totally agree.
>
> I'd like to propose a following plan:
>
> 1. Accept Hyungwon's patches to have XU3 u-boot < 328 KiB (with link to
> default BL2) to have XU3 support in place (and treat it as a starting
> point)
>
> 2. If u-boot's size less than 328 KiB is _really_ a problem to somebody
> then ask hardkernel to change BL2 or:
>         - modify their sources to change the layout (I regard this as a
>           "quick hack" solution)
>         - with a lot of pain develop BL2/SPL (by whom?) which base on
>           newest mainline (then for each test hardkernel must sign the
>           binary).

My 2p worth...

The current Hardkernel BL1 looks broken to me - it is just too old.
While it is shipped with the board if you get an eMMC, the main way
people will get this is by downloading it from their site. So why not
download something different?

Re the plan, I think 1 is fine so long as it is protected by a big
ugly hack CONFIG and we can turn it off soon and revert the code.

For 2, the size issue is one problem, but the clock code in U-Boot is
another IMO. We should try to get both resolved. Maybe it is possible
to use the peach-pit BL2 and get hardkernel to test it and sign it?
Then people will download that one instead.

is there a contact at hardkernel on the mailing list?

Regards,
Simon

Hi Simon,

> Hi,
> 
> On 28 November 2014 at 06:46, Lukasz Majewski <l.majewski@majess.pl>
> wrote:
> > Hello Javier,
> >
> >> Hello Lukasz,
> >>
> >> On Fri, Nov 28, 2014 at 9:39 AM, Lukasz Majewski
> >> <l.majewski@majess.pl> wrote:
> >> >> I have yet to take him up on that offer though, but it sounds
> >> >> like a good way forward. The current layout really isn't
> >> >> practical.
> >> >>
> >> >
> >> > It indeed isn't very practical, but this is what you received
> >> > from HardKernel when you buy XU3 board.
> >> >
> >> > Of course you can grab their sources, modify the layout, prepare
> >> > u-boot's SPL and send it to them to be signed.
> >> > However, it is not the way the "normal" user do things.
> >> >
> >> > He or she would like to replace standard (and outdated)
> >> > HardKernel u-boot on their SD card and go forward with booting
> >> > kernel.
> >> >
> >>
> >> I agree with Sjoed that normal users don't replace the low-level
> >> components that are provided by the board vendor.
> >>
> >> After all you can boot a mainline kernel using the vendor u-boot,
> >> just append the DTB and create a uImage. The practical reason why
> >> someone would want to replace the vendor u-boot is to have more
> >> features but is very hard to do if there is a constraint in the
> >> maximum u-boot image size (even harder if the maximum is such
> >> small like in the XU3).
> >
> > I agree that 328 KiB size for u-boot is a constraint. I don't know
> > HardKernel's justification for this.
> >
> >>
> >> > For now we _must_ focus on supporting XU3 with default BL1/BL2
> >> > and hence we are obliged to have u-boot size smaller than 328
> >> > KiB.
> >> >
> >> > It is challenging but for sure doable.
> >> >
> >>
> >> It is doable but I don't see why the default BL2 _must_ be used.
> >
> > For practical/pragmatic reasons:
> >
> > 1. It is difficult to have signed BL2 - each time we need to ask
> > HardKernel for signing it. It is impractical and hampers usage of
> > mainline SPL (BL2) with XU3.
> >
> > 2. All the documentation on the HardKernel wiki site refers to the
> > default BL2.
> >
> > 3. We will have "new" BL2, which source code is based on 2012.07
> > mainline u-boot.
> >
> > 4. Two BL2 binaries - IMHO will hurt (i.e. brick) some device sooner
> > or latter.
> >
> >>
> >> A user that wants to replace the kernel or u-boot is already
> >> tech-savy and can for sure replace the BL2 as well if it's
> >> publicly available.
> >
> > Sorry, but I'm a bit sceptical about updating such low level code.
> > Bad things do happen.
> >
> >> Maybe hardkernel folks can even make the modified BL2 available on
> >> their website and the link added in the comment explaining the
> >> layout?
> >
> > We would then require HardKernel to:
> >
> > 1. Provide updated BL2.img
> > 2. Update their wiki to reflect the new BL2.
> >
> >>
> >> Also, it is an artificial constraint after all and can be easily
> >> modified. In fact I think we should push hardkernel to change that
> >> layout by default and use a BL2/SPL that has more sensible size for
> >> the u-boot binary even if they don't need it for their vendor
> >> u-boot which seems to be quite small.
> >
> > I totally agree.
> >
> > I'd like to propose a following plan:
> >
> > 1. Accept Hyungwon's patches to have XU3 u-boot < 328 KiB (with
> > link to default BL2) to have XU3 support in place (and treat it as
> > a starting point)
> >
> > 2. If u-boot's size less than 328 KiB is _really_ a problem to
> > somebody then ask hardkernel to change BL2 or:
> >         - modify their sources to change the layout (I regard this
> > as a "quick hack" solution)
> >         - with a lot of pain develop BL2/SPL (by whom?) which base
> > on newest mainline (then for each test hardkernel must sign the
> >           binary).
> 
> My 2p worth...
> 
> The current Hardkernel BL1 looks broken to me - it is just too old.

+1

> While it is shipped with the board if you get an eMMC, the main way
> people will get this is by downloading it from their site. So why not
> download something different?

As far as I remember U3 and probably XU3 in their README only points
for HardKernel's site to grab BL1 and BL2. We don't plan to include
their binaries to u-boot repository.

> 
> Re the plan, I think 1 is fine so long as it is protected by a big
> ugly hack CONFIG and we can turn it off soon and revert the code.

Hyungwon's patches only touch u-boot and rely (temporary I hope) on BL1
and BL2/SPL from Hardkernel.

> 
> For 2, the size issue is one problem, but the clock code in U-Boot is
> another IMO. We should try to get both resolved. Maybe it is possible
> to use the peach-pit BL2 and get hardkernel to test it and sign it?

I guess that SPL from peach-pit should be tunable to work with XU3 (in
a finite number of iterations including signing from HardKernel).

As it is based on recent u-boot it should be easy to produce BL2/SPL
only for XU3 (if needed).

> Then people will download that one instead.
> 
> is there a contact at hardkernel on the mailing list?

As fair as I know no.

I was posting questions on their forum. Maybe it is a right place to
ask for contact point?
As fair as I remember they were willing to sign SPL/BL2 when sent to
them.

> 
> Regards,
> Simon

Best regards,
Lukasz Majewski

Hello Simon, Lukasz,

On Tue, Dec 2, 2014 at 2:29 PM, Lukasz Majewski <l.majewski@majess.pl> wrote:
> Hi Simon,
>
>> Hi,
>>
>> On 28 November 2014 at 06:46, Lukasz Majewski <l.majewski@majess.pl>
>> wrote:
>> > Hello Javier,
>> >
>> >> Hello Lukasz,
>> >>
>> >> On Fri, Nov 28, 2014 at 9:39 AM, Lukasz Majewski
>> >> <l.majewski@majess.pl> wrote:
>> >> >> I have yet to take him up on that offer though, but it sounds
>> >> >> like a good way forward. The current layout really isn't
>> >> >> practical.
>> >> >>
>> >> >
>> >> > It indeed isn't very practical, but this is what you received
>> >> > from HardKernel when you buy XU3 board.
>> >> >
>> >> > Of course you can grab their sources, modify the layout, prepare
>> >> > u-boot's SPL and send it to them to be signed.
>> >> > However, it is not the way the "normal" user do things.
>> >> >
>> >> > He or she would like to replace standard (and outdated)
>> >> > HardKernel u-boot on their SD card and go forward with booting
>> >> > kernel.
>> >> >
>> >>
>> >> I agree with Sjoed that normal users don't replace the low-level
>> >> components that are provided by the board vendor.
>> >>
>> >> After all you can boot a mainline kernel using the vendor u-boot,
>> >> just append the DTB and create a uImage. The practical reason why
>> >> someone would want to replace the vendor u-boot is to have more
>> >> features but is very hard to do if there is a constraint in the
>> >> maximum u-boot image size (even harder if the maximum is such
>> >> small like in the XU3).
>> >
>> > I agree that 328 KiB size for u-boot is a constraint. I don't know
>> > HardKernel's justification for this.
>> >
>> >>
>> >> > For now we _must_ focus on supporting XU3 with default BL1/BL2
>> >> > and hence we are obliged to have u-boot size smaller than 328
>> >> > KiB.
>> >> >
>> >> > It is challenging but for sure doable.
>> >> >
>> >>
>> >> It is doable but I don't see why the default BL2 _must_ be used.
>> >
>> > For practical/pragmatic reasons:
>> >
>> > 1. It is difficult to have signed BL2 - each time we need to ask
>> > HardKernel for signing it. It is impractical and hampers usage of
>> > mainline SPL (BL2) with XU3.
>> >
>> > 2. All the documentation on the HardKernel wiki site refers to the
>> > default BL2.
>> >
>> > 3. We will have "new" BL2, which source code is based on 2012.07
>> > mainline u-boot.
>> >
>> > 4. Two BL2 binaries - IMHO will hurt (i.e. brick) some device sooner
>> > or latter.
>> >
>> >>
>> >> A user that wants to replace the kernel or u-boot is already
>> >> tech-savy and can for sure replace the BL2 as well if it's
>> >> publicly available.
>> >
>> > Sorry, but I'm a bit sceptical about updating such low level code.
>> > Bad things do happen.
>> >
>> >> Maybe hardkernel folks can even make the modified BL2 available on
>> >> their website and the link added in the comment explaining the
>> >> layout?
>> >
>> > We would then require HardKernel to:
>> >
>> > 1. Provide updated BL2.img
>> > 2. Update their wiki to reflect the new BL2.
>> >
>> >>
>> >> Also, it is an artificial constraint after all and can be easily
>> >> modified. In fact I think we should push hardkernel to change that
>> >> layout by default and use a BL2/SPL that has more sensible size for
>> >> the u-boot binary even if they don't need it for their vendor
>> >> u-boot which seems to be quite small.
>> >
>> > I totally agree.
>> >
>> > I'd like to propose a following plan:
>> >
>> > 1. Accept Hyungwon's patches to have XU3 u-boot < 328 KiB (with
>> > link to default BL2) to have XU3 support in place (and treat it as
>> > a starting point)
>> >
>> > 2. If u-boot's size less than 328 KiB is _really_ a problem to
>> > somebody then ask hardkernel to change BL2 or:
>> >         - modify their sources to change the layout (I regard this
>> > as a "quick hack" solution)
>> >         - with a lot of pain develop BL2/SPL (by whom?) which base
>> > on newest mainline (then for each test hardkernel must sign the
>> >           binary).
>>
>> My 2p worth...
>>
>> The current Hardkernel BL1 looks broken to me - it is just too old.
>
> +1
>
>> While it is shipped with the board if you get an eMMC, the main way
>> people will get this is by downloading it from their site. So why not
>> download something different?
>
> As far as I remember U3 and probably XU3 in their README only points
> for HardKernel's site to grab BL1 and BL2. We don't plan to include
> their binaries to u-boot repository.
>
>>
>> Re the plan, I think 1 is fine so long as it is protected by a big
>> ugly hack CONFIG and we can turn it off soon and revert the code.
>
> Hyungwon's patches only touch u-boot and rely (temporary I hope) on BL1
> and BL2/SPL from Hardkernel.
>
>>
>> For 2, the size issue is one problem, but the clock code in U-Boot is
>> another IMO. We should try to get both resolved. Maybe it is possible
>> to use the peach-pit BL2 and get hardkernel to test it and sign it?
>
> I guess that SPL from peach-pit should be tunable to work with XU3 (in
> a finite number of iterations including signing from HardKernel).
>
> As it is based on recent u-boot it should be easy to produce BL2/SPL
> only for XU3 (if needed).
>
>> Then people will download that one instead.
>>
>> is there a contact at hardkernel on the mailing list?
>
> As fair as I know no.
>
> I was posting questions on their forum. Maybe it is a right place to
> ask for contact point?
> As fair as I remember they were willing to sign SPL/BL2 when sent to
> them.
>

I have gotten a BL2 signed (based of their repository) which allows a
bigger U-Boot for testing, and it works. I have currently requested
another signed BL2 which lets one use a 1MB U-Boot image which should
be adequate. This is in the works.
I do not work for hardkernel but I do have a working relationship with
them. From the looks of it they are more than willing to accomodate
this BL2 change.
I can take this action point of getting this BL2 and its related
paraphernalia hosted on their website once they are OK with its
testing.

Regards
- Suriyan

>>
>> Regards,
>> Simon
>
> Best regards,
> Lukasz Majewski
>
> _______________________________________________
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

Lukasz Majewski <l.majewski@majess.pl> writes:

[...]

>> On 28 November 2014 at 06:46, Lukasz Majewski <l.majewski@majess.pl>
>> wrote:
>> > Hello Javier,
>> >
>> >> Hello Lukasz,
>> >>
>> >> On Fri, Nov 28, 2014 at 9:39 AM, Lukasz Majewski
>> >> <l.majewski@majess.pl> wrote:
>> >> >> I have yet to take him up on that offer though, but it sounds
>> >> >> like a good way forward. The current layout really isn't
>> >> >> practical.
>> >> >>
>> >> >
>> >> > It indeed isn't very practical, but this is what you received
>> >> > from HardKernel when you buy XU3 board.
>> >> >
>> >> > Of course you can grab their sources, modify the layout, prepare
>> >> > u-boot's SPL and send it to them to be signed.
>> >> > However, it is not the way the "normal" user do things.
>> >> >
>> >> > He or she would like to replace standard (and outdated)
>> >> > HardKernel u-boot on their SD card and go forward with booting
>> >> > kernel.
>> >> >
>> >>
>> >> I agree with Sjoed that normal users don't replace the low-level
>> >> components that are provided by the board vendor.
>> >>
>> >> After all you can boot a mainline kernel using the vendor u-boot,
>> >> just append the DTB and create a uImage. The practical reason why
>> >> someone would want to replace the vendor u-boot is to have more
>> >> features but is very hard to do if there is a constraint in the
>> >> maximum u-boot image size (even harder if the maximum is such
>> >> small like in the XU3).
>> >
>> > I agree that 328 KiB size for u-boot is a constraint. I don't know
>> > HardKernel's justification for this.
>> >
>> >>
>> >> > For now we _must_ focus on supporting XU3 with default BL1/BL2
>> >> > and hence we are obliged to have u-boot size smaller than 328
>> >> > KiB.
>> >> >
>> >> > It is challenging but for sure doable.
>> >> >
>> >>
>> >> It is doable but I don't see why the default BL2 _must_ be used.
>> >
>> > For practical/pragmatic reasons:
>> >
>> > 1. It is difficult to have signed BL2 - each time we need to ask
>> > HardKernel for signing it. It is impractical and hampers usage of
>> > mainline SPL (BL2) with XU3.
>> >
>> > 2. All the documentation on the HardKernel wiki site refers to the
>> > default BL2.
>> >
>> > 3. We will have "new" BL2, which source code is based on 2012.07
>> > mainline u-boot.
>> >
>> > 4. Two BL2 binaries - IMHO will hurt (i.e. brick) some device sooner
>> > or latter.
>> >
>> >>
>> >> A user that wants to replace the kernel or u-boot is already
>> >> tech-savy and can for sure replace the BL2 as well if it's
>> >> publicly available.
>> >
>> > Sorry, but I'm a bit sceptical about updating such low level code.
>> > Bad things do happen.
>> >
>> >> Maybe hardkernel folks can even make the modified BL2 available on
>> >> their website and the link added in the comment explaining the
>> >> layout?
>> >
>> > We would then require HardKernel to:
>> >
>> > 1. Provide updated BL2.img
>> > 2. Update their wiki to reflect the new BL2.
>> >
>> >>
>> >> Also, it is an artificial constraint after all and can be easily
>> >> modified. In fact I think we should push hardkernel to change that
>> >> layout by default and use a BL2/SPL that has more sensible size for
>> >> the u-boot binary even if they don't need it for their vendor
>> >> u-boot which seems to be quite small.
>> >
>> > I totally agree.
>> >
>> > I'd like to propose a following plan:
>> >
>> > 1. Accept Hyungwon's patches to have XU3 u-boot < 328 KiB (with
>> > link to default BL2) to have XU3 support in place (and treat it as
>> > a starting point)
>> >
>> > 2. If u-boot's size less than 328 KiB is _really_ a problem to
>> > somebody then ask hardkernel to change BL2 or:
>> >         - modify their sources to change the layout (I regard this
>> > as a "quick hack" solution)
>> >         - with a lot of pain develop BL2/SPL (by whom?) which base
>> > on newest mainline (then for each test hardkernel must sign the
>> >           binary).
>> 
>> My 2p worth...
>> 
>> The current Hardkernel BL1 looks broken to me - it is just too old.
>
> +1
>

FWIW, the XU3 firmware is broken in other ways as well which have a
major impact on power management.  

First, with mainline kernels using MCPM, only 6 of 8 CPUs come
online.  However, even with that fixed[1], it turns out that the kernel
can't properly manage CCI due to secure firmware[2], which means that MCPM
(multi-cluster power management) can't work, and thus the low-power
cluster-idle states can't work, the big.LITTLE switcher cannot work, and
the ongoing work on energy-aware scheduling will not be useful on this
platform.

Anyone know what are the chances of getting a non-secure version of the
firmware for this platform.  The Samsung Chromebook2 with basically the
same SoC (5800 compared to the 5422 on the XU3) ships with non-secure
firmware so all of the above mentioned features are working just fine.

I'm working on getting these same features working on the XU3, but this
broken firmware as brought a halt to any real progress.

Kevin

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/305790.html
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/306480.html

Hi Kevin,

On 8 December 2014 at 10:58, Kevin Hilman <khilman@kernel.org> wrote:
> Lukasz Majewski <l.majewski@majess.pl> writes:
>
> [...]
>
>>> On 28 November 2014 at 06:46, Lukasz Majewski <l.majewski@majess.pl>
>>> wrote:
>>> > Hello Javier,
>>> >
>>> >> Hello Lukasz,
>>> >>
>>> >> On Fri, Nov 28, 2014 at 9:39 AM, Lukasz Majewski
>>> >> <l.majewski@majess.pl> wrote:
>>> >> >> I have yet to take him up on that offer though, but it sounds
>>> >> >> like a good way forward. The current layout really isn't
>>> >> >> practical.
>>> >> >>
>>> >> >
>>> >> > It indeed isn't very practical, but this is what you received
>>> >> > from HardKernel when you buy XU3 board.
>>> >> >
>>> >> > Of course you can grab their sources, modify the layout, prepare
>>> >> > u-boot's SPL and send it to them to be signed.
>>> >> > However, it is not the way the "normal" user do things.
>>> >> >
>>> >> > He or she would like to replace standard (and outdated)
>>> >> > HardKernel u-boot on their SD card and go forward with booting
>>> >> > kernel.
>>> >> >
>>> >>
>>> >> I agree with Sjoed that normal users don't replace the low-level
>>> >> components that are provided by the board vendor.
>>> >>
>>> >> After all you can boot a mainline kernel using the vendor u-boot,
>>> >> just append the DTB and create a uImage. The practical reason why
>>> >> someone would want to replace the vendor u-boot is to have more
>>> >> features but is very hard to do if there is a constraint in the
>>> >> maximum u-boot image size (even harder if the maximum is such
>>> >> small like in the XU3).
>>> >
>>> > I agree that 328 KiB size for u-boot is a constraint. I don't know
>>> > HardKernel's justification for this.
>>> >
>>> >>
>>> >> > For now we _must_ focus on supporting XU3 with default BL1/BL2
>>> >> > and hence we are obliged to have u-boot size smaller than 328
>>> >> > KiB.
>>> >> >
>>> >> > It is challenging but for sure doable.
>>> >> >
>>> >>
>>> >> It is doable but I don't see why the default BL2 _must_ be used.
>>> >
>>> > For practical/pragmatic reasons:
>>> >
>>> > 1. It is difficult to have signed BL2 - each time we need to ask
>>> > HardKernel for signing it. It is impractical and hampers usage of
>>> > mainline SPL (BL2) with XU3.
>>> >
>>> > 2. All the documentation on the HardKernel wiki site refers to the
>>> > default BL2.
>>> >
>>> > 3. We will have "new" BL2, which source code is based on 2012.07
>>> > mainline u-boot.
>>> >
>>> > 4. Two BL2 binaries - IMHO will hurt (i.e. brick) some device sooner
>>> > or latter.
>>> >
>>> >>
>>> >> A user that wants to replace the kernel or u-boot is already
>>> >> tech-savy and can for sure replace the BL2 as well if it's
>>> >> publicly available.
>>> >
>>> > Sorry, but I'm a bit sceptical about updating such low level code.
>>> > Bad things do happen.
>>> >
>>> >> Maybe hardkernel folks can even make the modified BL2 available on
>>> >> their website and the link added in the comment explaining the
>>> >> layout?
>>> >
>>> > We would then require HardKernel to:
>>> >
>>> > 1. Provide updated BL2.img
>>> > 2. Update their wiki to reflect the new BL2.
>>> >
>>> >>
>>> >> Also, it is an artificial constraint after all and can be easily
>>> >> modified. In fact I think we should push hardkernel to change that
>>> >> layout by default and use a BL2/SPL that has more sensible size for
>>> >> the u-boot binary even if they don't need it for their vendor
>>> >> u-boot which seems to be quite small.
>>> >
>>> > I totally agree.
>>> >
>>> > I'd like to propose a following plan:
>>> >
>>> > 1. Accept Hyungwon's patches to have XU3 u-boot < 328 KiB (with
>>> > link to default BL2) to have XU3 support in place (and treat it as
>>> > a starting point)
>>> >
>>> > 2. If u-boot's size less than 328 KiB is _really_ a problem to
>>> > somebody then ask hardkernel to change BL2 or:
>>> >         - modify their sources to change the layout (I regard this
>>> > as a "quick hack" solution)
>>> >         - with a lot of pain develop BL2/SPL (by whom?) which base
>>> > on newest mainline (then for each test hardkernel must sign the
>>> >           binary).
>>>
>>> My 2p worth...
>>>
>>> The current Hardkernel BL1 looks broken to me - it is just too old.
>>
>> +1
>>
>
> FWIW, the XU3 firmware is broken in other ways as well which have a
> major impact on power management.
>
> First, with mainline kernels using MCPM, only 6 of 8 CPUs come
> online.  However, even with that fixed[1], it turns out that the kernel
> can't properly manage CCI due to secure firmware[2], which means that MCPM
> (multi-cluster power management) can't work, and thus the low-power
> cluster-idle states can't work, the big.LITTLE switcher cannot work, and
> the ongoing work on energy-aware scheduling will not be useful on this
> platform.
>
> Anyone know what are the chances of getting a non-secure version of the
> firmware for this platform.  The Samsung Chromebook2 with basically the
> same SoC (5800 compared to the 5422 on the XU3) ships with non-secure
> firmware so all of the above mentioned features are working just fine.

I have pushed on this but apparently it is not possible - they need to
sign every BL2. The only implementation I've seen sets up the chip in
BL2 (U-Boot SPL) so I don't think we can work around it. It takes us
back to the 1960s where we sent off our code at night to run it :-)

I think the best bet is the current effort to mainline the rest of the
Chromebook code then try to build it for XU3.

>
> I'm working on getting these same features working on the XU3, but this
> broken firmware as brought a halt to any real progress.

Agreed, but I think this is feasible once U-Boot on XU3 is sorted out.

Regards,
Simon

Hi Simon,

Simon Glass <sjg@chromium.org> writes:

> On 8 December 2014 at 10:58, Kevin Hilman <khilman@kernel.org> wrote:

[...]

>> FWIW, the XU3 firmware is broken in other ways as well which have a
>> major impact on power management.
>>
>> First, with mainline kernels using MCPM, only 6 of 8 CPUs come
>> online.  However, even with that fixed[1], it turns out that the kernel
>> can't properly manage CCI due to secure firmware[2], which means that MCPM
>> (multi-cluster power management) can't work, and thus the low-power
>> cluster-idle states can't work, the big.LITTLE switcher cannot work, and
>> the ongoing work on energy-aware scheduling will not be useful on this
>> platform.
>>
>> Anyone know what are the chances of getting a non-secure version of the
>> firmware for this platform.  The Samsung Chromebook2 with basically the
>> same SoC (5800 compared to the 5422 on the XU3) ships with non-secure
>> firmware so all of the above mentioned features are working just fine.
>
> I have pushed on this but apparently it is not possible - they need to
> sign every BL2. The only implementation I've seen sets up the chip in
> BL2 (U-Boot SPL) so I don't think we can work around it. 

Not quite sure I'm following...

So is secure-mode enabled before BL2 is started?  Or do you mean BL2 is
where secure-mode is enabled?  If it's done in BL2, and if the
hardkernel folks are willing to sign BL2 images (which I gathered from
discussions elsewhere in this series) then it seems possible to turn off
secure-mode.

So I went to look in the u-boot-samsung repo and didn't see the code for
the SPL there.  Is the BL2 source (which I understood to be u-boot SPL)
in some other repo?

> It takes us back to the 1960s where we sent off our code at night to
> run it :-)
>
> I think the best bet is the current effort to mainline the rest of the
> Chromebook code then try to build it for XU3.

What's the status of that effort?  

>>
>> I'm working on getting these same features working on the XU3, but this
>> broken firmware as brought a halt to any real progress.
>
> Agreed, but I think this is feasible once U-Boot on XU3 is sorted out.

Let's hope so.

Kevin

Hi Kevin,

> Lukasz Majewski <l.majewski@majess.pl> writes:
> 
> [...]
> 
> >> On 28 November 2014 at 06:46, Lukasz Majewski
> >> <l.majewski@majess.pl> wrote:
> >> > Hello Javier,
> >> >
> >> >> Hello Lukasz,
> >> >>
> >> >> On Fri, Nov 28, 2014 at 9:39 AM, Lukasz Majewski
> >> >> <l.majewski@majess.pl> wrote:
> >> >> >> I have yet to take him up on that offer though, but it sounds
> >> >> >> like a good way forward. The current layout really isn't
> >> >> >> practical.
> >> >> >>
> >> >> >
> >> >> > It indeed isn't very practical, but this is what you received
> >> >> > from HardKernel when you buy XU3 board.
> >> >> >
> >> >> > Of course you can grab their sources, modify the layout,
> >> >> > prepare u-boot's SPL and send it to them to be signed.
> >> >> > However, it is not the way the "normal" user do things.
> >> >> >
> >> >> > He or she would like to replace standard (and outdated)
> >> >> > HardKernel u-boot on their SD card and go forward with booting
> >> >> > kernel.
> >> >> >
> >> >>
> >> >> I agree with Sjoed that normal users don't replace the low-level
> >> >> components that are provided by the board vendor.
> >> >>
> >> >> After all you can boot a mainline kernel using the vendor
> >> >> u-boot, just append the DTB and create a uImage. The practical
> >> >> reason why someone would want to replace the vendor u-boot is
> >> >> to have more features but is very hard to do if there is a
> >> >> constraint in the maximum u-boot image size (even harder if the
> >> >> maximum is such small like in the XU3).
> >> >
> >> > I agree that 328 KiB size for u-boot is a constraint. I don't
> >> > know HardKernel's justification for this.
> >> >
> >> >>
> >> >> > For now we _must_ focus on supporting XU3 with default BL1/BL2
> >> >> > and hence we are obliged to have u-boot size smaller than 328
> >> >> > KiB.
> >> >> >
> >> >> > It is challenging but for sure doable.
> >> >> >
> >> >>
> >> >> It is doable but I don't see why the default BL2 _must_ be used.
> >> >
> >> > For practical/pragmatic reasons:
> >> >
> >> > 1. It is difficult to have signed BL2 - each time we need to ask
> >> > HardKernel for signing it. It is impractical and hampers usage of
> >> > mainline SPL (BL2) with XU3.
> >> >
> >> > 2. All the documentation on the HardKernel wiki site refers to
> >> > the default BL2.
> >> >
> >> > 3. We will have "new" BL2, which source code is based on 2012.07
> >> > mainline u-boot.
> >> >
> >> > 4. Two BL2 binaries - IMHO will hurt (i.e. brick) some device
> >> > sooner or latter.
> >> >
> >> >>
> >> >> A user that wants to replace the kernel or u-boot is already
> >> >> tech-savy and can for sure replace the BL2 as well if it's
> >> >> publicly available.
> >> >
> >> > Sorry, but I'm a bit sceptical about updating such low level
> >> > code. Bad things do happen.
> >> >
> >> >> Maybe hardkernel folks can even make the modified BL2 available
> >> >> on their website and the link added in the comment explaining
> >> >> the layout?
> >> >
> >> > We would then require HardKernel to:
> >> >
> >> > 1. Provide updated BL2.img
> >> > 2. Update their wiki to reflect the new BL2.
> >> >
> >> >>
> >> >> Also, it is an artificial constraint after all and can be easily
> >> >> modified. In fact I think we should push hardkernel to change
> >> >> that layout by default and use a BL2/SPL that has more sensible
> >> >> size for the u-boot binary even if they don't need it for their
> >> >> vendor u-boot which seems to be quite small.
> >> >
> >> > I totally agree.
> >> >
> >> > I'd like to propose a following plan:
> >> >
> >> > 1. Accept Hyungwon's patches to have XU3 u-boot < 328 KiB (with
> >> > link to default BL2) to have XU3 support in place (and treat it
> >> > as a starting point)
> >> >
> >> > 2. If u-boot's size less than 328 KiB is _really_ a problem to
> >> > somebody then ask hardkernel to change BL2 or:
> >> >         - modify their sources to change the layout (I regard
> >> > this as a "quick hack" solution)
> >> >         - with a lot of pain develop BL2/SPL (by whom?) which
> >> > base on newest mainline (then for each test hardkernel must sign
> >> > the binary).
> >> 
> >> My 2p worth...
> >> 
> >> The current Hardkernel BL1 looks broken to me - it is just too old.
> >
> > +1
> >
> 
> FWIW, the XU3 firmware is broken in other ways as well which have a
> major impact on power management.  
> 
> First, with mainline kernels using MCPM, only 6 of 8 CPUs come
> online.  However, even with that fixed[1], it turns out that the
> kernel can't properly manage CCI due to secure firmware[2], which
> means that MCPM (multi-cluster power management) can't work, and thus
> the low-power cluster-idle states can't work, the big.LITTLE switcher
> cannot work, and the ongoing work on energy-aware scheduling will not
> be useful on this platform.

I've stumbled upon the "imprecise aborts" in Exynos5422. Moreover I've
heard about problems with bringing up all 8 CPUs on that platform.

> 
> Anyone know what are the chances of getting a non-secure version of
> the firmware for this platform.  The Samsung Chromebook2 with
> basically the same SoC (5800 compared to the 5422 on the XU3) ships
> with non-secure firmware so all of the above mentioned features are
> working just fine.

You can look into the HardKernle's u-boot from their github:
https://github.com/hardkernel/u-boot

then tune it and send to hardkernel to be signed.


I guess that the described above problem might be with TZSW software -
the one from Chromebook2 might be different from the one from
Hard Kernel.

Correct me if I'm wrong, but isn't power management governed by TZSW -
by calling smc instruction with proper parameter?


Regarding Hard Kernel - their u-boot/u-boot-spl(SPL/BL2) is from 2012.
It is quite old. Problem here is that to update (SPL/BL2) one needs to
send this binary to Hard Kernel for signing.


However, in my opinion working BL1 and BL2 for XU3 should be delivered
by Hard Kernel. Period.

Therefore, please ask them on support/forum why do we experience such
problems with cluster/power management on mainline Linux .

> 
> I'm working on getting these same features working on the XU3, but
> this broken firmware as brought a halt to any real progress.
> 
> Kevin
> 
> [1]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/305790.html
> [2]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/306480.html

Hi,

On 8 December 2014 at 18:27, Kevin Hilman <khilman@kernel.org> wrote:
>
> Hi Simon,
>
> Simon Glass <sjg@chromium.org> writes:
>
> > On 8 December 2014 at 10:58, Kevin Hilman <khilman@kernel.org> wrote:
>
> [...]
>
> >> FWIW, the XU3 firmware is broken in other ways as well which have a
> >> major impact on power management.
> >>
> >> First, with mainline kernels using MCPM, only 6 of 8 CPUs come
> >> online.  However, even with that fixed[1], it turns out that the kernel
> >> can't properly manage CCI due to secure firmware[2], which means that MCPM
> >> (multi-cluster power management) can't work, and thus the low-power
> >> cluster-idle states can't work, the big.LITTLE switcher cannot work, and
> >> the ongoing work on energy-aware scheduling will not be useful on this
> >> platform.
> >>
> >> Anyone know what are the chances of getting a non-secure version of the
> >> firmware for this platform.  The Samsung Chromebook2 with basically the
> >> same SoC (5800 compared to the 5422 on the XU3) ships with non-secure
> >> firmware so all of the above mentioned features are working just fine.
> >
> > I have pushed on this but apparently it is not possible - they need to
> > sign every BL2. The only implementation I've seen sets up the chip in
> > BL2 (U-Boot SPL) so I don't think we can work around it.
>
> Not quite sure I'm following...
>
> So is secure-mode enabled before BL2 is started?  Or do you mean BL2 is
> where secure-mode is enabled?  If it's done in BL2, and if the
> hardkernel folks are willing to sign BL2 images (which I gathered from
> discussions elsewhere in this series) then it seems possible to turn off
> secure-mode.


Yes it is possible - and easy - to do in BL2 / U-Boot SPL. This is
what the Chromebooks do.

>
>
> So I went to look in the u-boot-samsung repo and didn't see the code for
> the SPL there.  Is the BL2 source (which I understood to be u-boot SPL)
> in some other repo?


It's in mainline U-Boot so no particular need to go to the Samsung
tree. See arch/arm/cpu/armv7/exynos/spl_boot.c and tzpc.c for the
TrustZone stuff.

>
> > It takes us back to the 1960s where we sent off our code at night to
> > run it :-)
> >
> > I think the best bet is the current effort to mainline the rest of the
> > Chromebook code then try to build it for XU3.
>
> What's the status of that effort?

Coming along but the big/little support is still not there. The
display works and most core peripherals. Needs more SPL work.

>
>
> >>
> >> I'm working on getting these same features working on the XU3, but this
> >> broken firmware as brought a halt to any real progress.
> >
> > Agreed, but I think this is feasible once U-Boot on XU3 is sorted out.
>
> Let's hope so.
>
> Kevin
>

Regards,
Simon

Simon Glass <sjg@chromium.org> writes:

> On 8 December 2014 at 18:27, Kevin Hilman <khilman@kernel.org> wrote:
>>

[...]

>> So is secure-mode enabled before BL2 is started?  Or do you mean BL2 is
>> where secure-mode is enabled?  If it's done in BL2, and if the
>> hardkernel folks are willing to sign BL2 images (which I gathered from
>> discussions elsewhere in this series) then it seems possible to turn off
>> secure-mode.
>
> Yes it is possible - and easy - to do in BL2 / U-Boot SPL. This is
> what the Chromebooks do.

OK, good.

>>
>> So I went to look in the u-boot-samsung repo and didn't see the code for
>> the SPL there.  Is the BL2 source (which I understood to be u-boot SPL)
>> in some other repo?
>
>
> It's in mainline U-Boot so no particular need to go to the Samsung
> tree. 

I went to the samsung tree since the cover letter for this series
pointed me there.  But I just tried the latest version of this series
(v11) using mainlin u-boot.  Thanks for the pointer.

> See arch/arm/cpu/armv7/exynos/spl_boot.c and tzpc.c for the
> TrustZone stuff.

OK, thanks.  Any pointers on how to get this building with mainline
u-boot?  Just adding CONFIG_SPL to odroid_xu3.h doesn't seem to work
(compile errors.)  I'm quite comfortable in the kernel, but I'm not very
familiar with u-boot, especially SPL.

>> > It takes us back to the 1960s where we sent off our code at night to
>> > run it :-)
>> >
>> > I think the best bet is the current effort to mainline the rest of the
>> > Chromebook code then try to build it for XU3.
>>
>> What's the status of that effort?
>
> Coming along but the big/little support is still not there. The
> display works and most core peripherals. Needs more SPL work.

OK, I'll be glad to be a beta tester if/when you get to that point.

Thanks,

Kevin

Hi Kevin,

On 9 December 2014 at 17:03, Kevin Hilman <khilman@kernel.org> wrote:

> Simon Glass <sjg@chromium.org> writes:
>
> > On 8 December 2014 at 18:27, Kevin Hilman <khilman@kernel.org> wrote:
> >>
>
> [...]
>
> >> So is secure-mode enabled before BL2 is started?  Or do you mean BL2 is
> >> where secure-mode is enabled?  If it's done in BL2, and if the
> >> hardkernel folks are willing to sign BL2 images (which I gathered from
> >> discussions elsewhere in this series) then it seems possible to turn off
> >> secure-mode.
> >
> > Yes it is possible - and easy - to do in BL2 / U-Boot SPL. This is
> > what the Chromebooks do.
>
> OK, good.
>
> >>
> >> So I went to look in the u-boot-samsung repo and didn't see the code for
> >> the SPL there.  Is the BL2 source (which I understood to be u-boot SPL)
> >> in some other repo?
> >
> >
> > It's in mainline U-Boot so no particular need to go to the Samsung
> > tree.
>
> I went to the samsung tree since the cover letter for this series
> pointed me there.  But I just tried the latest version of this series
> (v11) using mainlin u-boot.  Thanks for the pointer.
>
> > See arch/arm/cpu/armv7/exynos/spl_boot.c and tzpc.c for the
> > TrustZone stuff.
>
> OK, thanks.  Any pointers on how to get this building with mainline
> u-boot?  Just adding CONFIG_SPL to odroid_xu3.h doesn't seem to work
> (compile errors.)  I'm quite comfortable in the kernel, but I'm not very
> familiar with u-boot, especially SPL.
>

It's normally automatic unless some special disabling was done - see
spl/u-boot-spl.bin in the output. You need to sign it though :-(


> >> > It takes us back to the 1960s where we sent off our code at night to
> >> > run it :-)
> >> >
> >> > I think the best bet is the current effort to mainline the rest of the
> >> > Chromebook code then try to build it for XU3.
> >>
> >> What's the status of that effort?
> >
> > Coming along but the big/little support is still not there. The
> > display works and most core peripherals. Needs more SPL work.
>
> OK, I'll be glad to be a beta tester if/when you get to that point.
>
> Thanks,
>
> Kevin
>

Regards,
Simon

Simon Glass <sjg@chromium.org> writes:

[...]

>> OK, thanks.  Any pointers on how to get this building with mainline
>> u-boot?  Just adding CONFIG_SPL to odroid_xu3.h doesn't seem to work
>> (compile errors.)  I'm quite comfortable in the kernel, but I'm not very
>> familiar with u-boot, especially SPL.
>>
>
> It's normally automatic unless some special disabling was done - see
> spl/u-boot-spl.bin in the output. You need to sign it though :-(

Right, I'm used to finding it there, but there's nothing there when
buildling using odroid-xu3_config with $SUBJECT series.

Kevin

Dear Kevin,

On Wed, 10 Dec 2014 11:20:43 -0800
Kevin Hilman <khilman@kernel.org> wrote:

> Simon Glass <sjg@chromium.org> writes:
> 
> [...]
> 
> >> OK, thanks.  Any pointers on how to get this building with mainline
> >> u-boot?  Just adding CONFIG_SPL to odroid_xu3.h doesn't seem to
> >> work (compile errors.)  I'm quite comfortable in the kernel, but
> >> I'm not very familiar with u-boot, especially SPL.
> >>
> >
> > It's normally automatic unless some special disabling was done - see
> > spl/u-boot-spl.bin in the output. You need to sign it though :-(
> 
> Right, I'm used to finding it there, but there's nothing there when
> buildling using odroid-xu3_config with $SUBJECT series.

CONFIG_SPL_BUILD must be turn on for that(You can find the detailesin
doc/README.SPL). But neither common exynos config files nor odroid xu3
specific config file contain the config option. Before I turned on that
option, but not work at the moment. Some work should be done by
someone. I am sorry to say, but I cannot assure I can do that
immediately.

> 
> Kevin
> 

Best regards,
Hyungwon Hwang