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

[Simon Glass]

Hi Kevin,

On 8 December 2014 at 10:58, Kevin Hilman <khilman at kernel.org> wrote:
> Lukasz Majewski <l.majewski at majess.pl> writes:
>
> [...]
>
>>> 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
>>
>
> FWIW, the XU3 firmware is broken in other ways as well which have a
> major impact on power management.
>
> First, with mainline kernels using MCPM, only 6 of 8 CPUs come
> online.  However, even with that fixed[1], it turns out that the kernel
> can't properly manage CCI due to secure firmware[2], which means that MCPM
> (multi-cluster power management) can't work, and thus the low-power
> cluster-idle states can't work, the big.LITTLE switcher cannot work, and
> the ongoing work on energy-aware scheduling will not be useful on this
> platform.
>
> Anyone know what are the chances of getting a non-secure version of the
> firmware for this platform.  The Samsung Chromebook2 with basically the
> same SoC (5800 compared to the 5422 on the XU3) ships with non-secure
> firmware so all of the above mentioned features are working just fine.

I have pushed on this but apparently it is not possible - they need to
sign every BL2. The only implementation I've seen sets up the chip in
BL2 (U-Boot SPL) so I don't think we can work around it. It takes us
back to the 1960s where we sent off our code at night to run it :-)

I think the best bet is the current effort to mainline the rest of the
Chromebook code then try to build it for XU3.

>
> I'm working on getting these same features working on the XU3, but this
> broken firmware as brought a halt to any real progress.

Agreed, but I think this is feasible once U-Boot on XU3 is sorted out.

Regards,
Simon