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

[Lukasz Majewski]

Hi Kevin,

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

I've stumbled upon the "imprecise aborts" in Exynos5422. Moreover I've
heard about problems with bringing up all 8 CPUs on that 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.

You can look into the HardKernle's u-boot from their github:
https://github.com/hardkernel/u-boot

then tune it and send to hardkernel to be signed.


I guess that the described above problem might be with TZSW software -
the one from Chromebook2 might be different from the one from
Hard Kernel.

Correct me if I'm wrong, but isn't power management governed by TZSW -
by calling smc instruction with proper parameter?


Regarding Hard Kernel - their u-boot/u-boot-spl(SPL/BL2) is from 2012.
It is quite old. Problem here is that to update (SPL/BL2) one needs to
send this binary to Hard Kernel for signing.


However, in my opinion working BL1 and BL2 for XU3 should be delivered
by Hard Kernel. Period.

Therefore, please ask them on support/forum why do we experience such
problems with cluster/power management on mainline Linux .

> 
> I'm working on getting these same features working on the XU3, but
> this broken firmware as brought a halt to any real progress.
> 
> Kevin
> 
> [1]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/305790.html
> [2]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/306480.html



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group