Lukasz Majewski l.majewski@majess.pl writes:
[...]
On 28 November 2014 at 06:46, Lukasz Majewski l.majewski@majess.pl wrote:
Hello Javier,
Hello Lukasz,
On Fri, Nov 28, 2014 at 9:39 AM, Lukasz Majewski l.majewski@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:
- 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.
- All the documentation on the HardKernel wiki site refers to the
default BL2.
- We will have "new" BL2, which source code is based on 2012.07
mainline u-boot.
- 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:
- Provide updated BL2.img
- 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:
- 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)
- 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'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.h... [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/306480.h...
Hi Kevin,
On 8 December 2014 at 10:58, Kevin Hilman khilman@kernel.org wrote:
Lukasz Majewski l.majewski@majess.pl writes:
[...]
On 28 November 2014 at 06:46, Lukasz Majewski l.majewski@majess.pl wrote:
Hello Javier,
Hello Lukasz,
On Fri, Nov 28, 2014 at 9:39 AM, Lukasz Majewski l.majewski@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:
- 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.
- All the documentation on the HardKernel wiki site refers to the
default BL2.
- We will have "new" BL2, which source code is based on 2012.07
mainline u-boot.
- 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:
- Provide updated BL2.img
- 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:
- 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)
- 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
Hi Simon,
Simon Glass sjg@chromium.org writes:
On 8 December 2014 at 10:58, Kevin Hilman khilman@kernel.org wrote:
[...]
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.
Not quite sure I'm following...
So is secure-mode enabled before BL2 is started? Or do you mean BL2 is where secure-mode is enabled? If it's done in BL2, and if the hardkernel folks are willing to sign BL2 images (which I gathered from discussions elsewhere in this series) then it seems possible to turn off secure-mode.
So I went to look in the u-boot-samsung repo and didn't see the code for the SPL there. Is the BL2 source (which I understood to be u-boot SPL) in some other repo?
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.
What's the status of that effort?
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.
Let's hope so.
Kevin
Hi,
On 8 December 2014 at 18:27, Kevin Hilman khilman@kernel.org wrote:
Hi Simon,
Simon Glass sjg@chromium.org writes:
On 8 December 2014 at 10:58, Kevin Hilman khilman@kernel.org wrote:
[...]
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.
Not quite sure I'm following...
So is secure-mode enabled before BL2 is started? Or do you mean BL2 is where secure-mode is enabled? If it's done in BL2, and if the hardkernel folks are willing to sign BL2 images (which I gathered from discussions elsewhere in this series) then it seems possible to turn off secure-mode.
Yes it is possible - and easy - to do in BL2 / U-Boot SPL. This is what the Chromebooks do.
So I went to look in the u-boot-samsung repo and didn't see the code for the SPL there. Is the BL2 source (which I understood to be u-boot SPL) in some other repo?
It's in mainline U-Boot so no particular need to go to the Samsung tree. See arch/arm/cpu/armv7/exynos/spl_boot.c and tzpc.c for the TrustZone stuff.
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.
What's the status of that effort?
Coming along but the big/little support is still not there. The display works and most core peripherals. Needs more SPL work.
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.
Let's hope so.
Kevin
Regards, Simon
Simon Glass sjg@chromium.org writes:
On 8 December 2014 at 18:27, Kevin Hilman khilman@kernel.org wrote:
[...]
So is secure-mode enabled before BL2 is started? Or do you mean BL2 is where secure-mode is enabled? If it's done in BL2, and if the hardkernel folks are willing to sign BL2 images (which I gathered from discussions elsewhere in this series) then it seems possible to turn off secure-mode.
Yes it is possible - and easy - to do in BL2 / U-Boot SPL. This is what the Chromebooks do.
OK, good.
So I went to look in the u-boot-samsung repo and didn't see the code for the SPL there. Is the BL2 source (which I understood to be u-boot SPL) in some other repo?
It's in mainline U-Boot so no particular need to go to the Samsung tree.
I went to the samsung tree since the cover letter for this series pointed me there. But I just tried the latest version of this series (v11) using mainlin u-boot. Thanks for the pointer.
See arch/arm/cpu/armv7/exynos/spl_boot.c and tzpc.c for the TrustZone stuff.
OK, thanks. Any pointers on how to get this building with mainline u-boot? Just adding CONFIG_SPL to odroid_xu3.h doesn't seem to work (compile errors.) I'm quite comfortable in the kernel, but I'm not very familiar with u-boot, especially SPL.
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.
What's the status of that effort?
Coming along but the big/little support is still not there. The display works and most core peripherals. Needs more SPL work.
OK, I'll be glad to be a beta tester if/when you get to that point.
Thanks,
Kevin
Hi Kevin,
On 9 December 2014 at 17:03, Kevin Hilman khilman@kernel.org wrote:
Simon Glass sjg@chromium.org writes:
On 8 December 2014 at 18:27, Kevin Hilman khilman@kernel.org wrote:
[...]
So is secure-mode enabled before BL2 is started? Or do you mean BL2 is where secure-mode is enabled? If it's done in BL2, and if the hardkernel folks are willing to sign BL2 images (which I gathered from discussions elsewhere in this series) then it seems possible to turn off secure-mode.
Yes it is possible - and easy - to do in BL2 / U-Boot SPL. This is what the Chromebooks do.
OK, good.
So I went to look in the u-boot-samsung repo and didn't see the code for the SPL there. Is the BL2 source (which I understood to be u-boot SPL) in some other repo?
It's in mainline U-Boot so no particular need to go to the Samsung tree.
I went to the samsung tree since the cover letter for this series pointed me there. But I just tried the latest version of this series (v11) using mainlin u-boot. Thanks for the pointer.
See arch/arm/cpu/armv7/exynos/spl_boot.c and tzpc.c for the TrustZone stuff.
OK, thanks. Any pointers on how to get this building with mainline u-boot? Just adding CONFIG_SPL to odroid_xu3.h doesn't seem to work (compile errors.) I'm quite comfortable in the kernel, but I'm not very familiar with u-boot, especially SPL.
It's normally automatic unless some special disabling was done - see spl/u-boot-spl.bin in the output. You need to sign it though :-(
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.
What's the status of that effort?
Coming along but the big/little support is still not there. The display works and most core peripherals. Needs more SPL work.
OK, I'll be glad to be a beta tester if/when you get to that point.
Thanks,
Kevin
Regards, Simon
Simon Glass sjg@chromium.org writes:
[...]
OK, thanks. Any pointers on how to get this building with mainline u-boot? Just adding CONFIG_SPL to odroid_xu3.h doesn't seem to work (compile errors.) I'm quite comfortable in the kernel, but I'm not very familiar with u-boot, especially SPL.
It's normally automatic unless some special disabling was done - see spl/u-boot-spl.bin in the output. You need to sign it though :-(
Right, I'm used to finding it there, but there's nothing there when buildling using odroid-xu3_config with $SUBJECT series.
Kevin
Dear Kevin,
On Wed, 10 Dec 2014 11:20:43 -0800 Kevin Hilman khilman@kernel.org wrote:
Simon Glass sjg@chromium.org writes:
[...]
OK, thanks. Any pointers on how to get this building with mainline u-boot? Just adding CONFIG_SPL to odroid_xu3.h doesn't seem to work (compile errors.) I'm quite comfortable in the kernel, but I'm not very familiar with u-boot, especially SPL.
It's normally automatic unless some special disabling was done - see spl/u-boot-spl.bin in the output. You need to sign it though :-(
Right, I'm used to finding it there, but there's nothing there when buildling using odroid-xu3_config with $SUBJECT series.
CONFIG_SPL_BUILD must be turn on for that(You can find the detailesin doc/README.SPL). But neither common exynos config files nor odroid xu3 specific config file contain the config option. Before I turned on that option, but not work at the moment. Some work should be done by someone. I am sorry to say, but I cannot assure I can do that immediately.
Kevin
Best regards, Hyungwon Hwang
Hi Kevin,
Lukasz Majewski l.majewski@majess.pl writes:
[...]
On 28 November 2014 at 06:46, Lukasz Majewski l.majewski@majess.pl wrote:
Hello Javier,
Hello Lukasz,
On Fri, Nov 28, 2014 at 9:39 AM, Lukasz Majewski l.majewski@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:
- 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.
- All the documentation on the HardKernel wiki site refers to
the default BL2.
- We will have "new" BL2, which source code is based on 2012.07
mainline u-boot.
- 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:
- Provide updated BL2.img
- 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:
- 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)
- 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.h... [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/306480.h...
linaro-kernel@lists.linaro.org
-
Hyungwon Hwang -
Kevin Hilman -
Lukasz Majewski -
Simon Glass