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

[Lukasz Majewski]

Hi Simon,

> Hi,
> 
> On 28 November 2014 at 06:46, Lukasz Majewski <l.majewski at majess.pl>
> wrote:
> > Hello Javier,
> >
> >> Hello Lukasz,
> >>
> >> On Fri, Nov 28, 2014 at 9:39 AM, Lukasz Majewski
> >> <l.majewski at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141202/2af452fc/attachment.pgp>