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.sim...@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.sim...@collabora.co.uk> Collabora Ltd.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
