Hi Kevin, On 8 December 2014 at 10:58, Kevin Hilman <khil...@kernel.org> wrote: > Lukasz Majewski <l.majew...@majess.pl> writes: > > [...] > >>> On 28 November 2014 at 06:46, Lukasz Majewski <l.majew...@majess.pl> >>> wrote: >>> > Hello Javier, >>> > >>> >> Hello Lukasz, >>> >> >>> >> On Fri, Nov 28, 2014 at 9:39 AM, Lukasz Majewski >>> >> <l.majew...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
