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

[Sjoerd Simons]

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

-- 
Sjoerd Simons <sjoerd.simons at 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/20141128/ca07d1fe/attachment.bin>