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

[Lukasz Majewski]

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

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

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/20141128/d52a3fa0/attachment.pgp>