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

[Simon Glass]

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