On Sat, Mar 14, 2015 at 09:09:05AM +0800, Haojian Zhuang wrote:
On 14 March 2015 at 08:26, Scott Bambrough scott.bambrough@linaro.org wrote:
My thoughts are: current dtb + hisilicon bootloader should be the default for the next week
- we should revisit this at the end of the week, or earlier if development
progress warrants it
My concerns with: psci enabled dtb + UEFI as a default
- can we reliably flash the eMMC using UEFI? If that isn't working the
only way to update the eMMC will be to use the tool in burn-boot.
At first, we can't flash the eMMC using UEFI since USB driver isn't ready in UEFI yet. In the second, burn-boot can't flash anything into eMMC. We could download l-loader.bin into SRAM, and l-loader.bin flash itself into eMMC. And there's a limitation on l-loader.bin could only flash 128KB into eMMC. In the third, we could only flash images into eMMC in recovery mode (implemented in ATF). And there's the limitation on flashing image within 128MB size.
If we stick to use ATF+UEFI as release, the simplest way is to fix the limitation in recovery mode. I doubt that implementing flashing in UEFI may cost a lot time.
We can enhance hisi-idt.py, and let it can finish two operations within one shot: 1. Fristly download hisilicon bootloader into sram; 2. According user command, use fastboot command to flash partition;
The best choice is still using uefi/u-boot to finish flash emmc operations, but if it need take long time to finish the related functionality in uefi, maybe we can consider to implement upper enhancement in hisi-idt.py, suppose it can be finished in 2~3 days.
- we lose the ability to boot from SD card if we do this as SD support
isn't implemented in UEFI at this time.
- at present I believe we have only implemented enough of PSCI to allow
all the cores to be enabled
Yes. And system reset in PSCI is also ready. It'll be merged right now.
Haojian has gave me some suggestion, I will commit the patch for system reset by tommorrow.
Here have mainly three functionalities need to finish for PSCI: - CPUIdle; - System suspend; - Hotplug;
Personally i think hotplug is more important than other two items, the reason is the developer usually want to use hotplug to get only one core running, so it can help for debugging w/o concurrency for some cases.
- i believe we need to check if the missing PSCI calls cause a problem
when PSCI is enabled in the kernel, particularly with thermal/power management, we don't want unsuspecting people frying their SoC's
There's no any relationship between PSCI and thermal/power management. The thermal driver works without any dependance on boot loader. cpufreq driver is depend on loading MCU.
Here need note one thing, now thermal driver is dependent on cpufreq driver to limit cpu frequency; the cpufreq driver is dependent on mcu image loading.
If we resolve mcu image loading issue, then cpufreq driver and theral driver can be easily enabled. So now the first priority is mcu image loading.
i will focus on mcu image loading in next 1~2 days, the more detailed info pls see another email thread for mcu image loading issue.
- i believe MCU loading isn't finished yet in ATF, this will cause power
management problems, and possible overheating - it is needed
Yes.
From ARM's power data, A53 cores's power efficiency is 0.13mw/MHz (28nm HPM),
so that if we run only 4 core's @729MHz, the cpus will only consume: 729MHz * 0.13mw/MHz * 4 = 379mw; the CPU part will not introduce too much power.
A few weeks ago, when i debugged thermal driver, the thermal sensor also told the temperature is not very high, usually less than 30'c. Here have one thing need note: on my board, i just use ramdisk fs, so i think GPU/VPU also have been disabled as well.
So how about we firstly enable ATF + PSCI, but only boot up first 4 cores (maxcpus=4)? So that we can easily move forward to the solution of ATF + UEFI, and also it will not introduce overheating issue.
I'm all for moving to ARM TF + UEFI as the default ASAP, but I'm not sure this is quite the right time. I don't want to lose precious development time due to flashing issues or dead boards. That being said I haven't had a chance to play with ARM TF + UEFI yet. Anyone have any comments based on experience?
DDR800 isn't ready in ATF yet. Sometimes (50%) may cause board hang. We compared the code with hisilicon bootloader. It seems that everything is same already.
Regards Haojian
Scott
On Fri, Mar 13, 2015 at 4:23 AM, Koen Kooi koen.kooi@linaro.org wrote:
On 13 March 2015 at 08:52, Fathi Boudra fathi.boudra@linaro.org wrote:
Hi,
There's a change pending to enable PSCI on HiKey: https://github.com/96boards/linux/pull/15
A regression is introduced when using HiSilicon bootloader: we'll have one core when using Hisilicon's bootloader.
Here's the summary:
- current dtb + hisilicon bootloader: boot images, all cores enabled
- current dtb + uefi: boot images, one core enabled
- psci enabled dtb + hisilicon bootloader: boot images, one core enabled
- psci enabled dtb + uefi: boot images, all cores enabled
It won't be much of an issue since the long term plan is to deprecate HiSilicon bootloader in favor of UEFI. Unfortunately, UEFI isn't feature complete (SD card support missing, flash to eMMC limited to 128M, etc...).
In the meantime, moving forward it's proposed to provide a legacy dtb
A dt*b*, not a dt*s*, right?
and use the PSCI enabled combination (UEFI + kernel) as the default as it is the long term plan. It mitigates the issue for people using HiSilicon bootloader while it enables people using UEFI.
Another option is to keep the status quo until UEFI is there (speculation is "in 2 weeks") and switch the default dtb at that time.
The question is which default dtb should be used? Opinions?
I would apply the psci patch and encourage people to upgrade their binary only vendor bootloader to the uefi one. If someone wants to stay with the huawei bootloader, they'll get one core or they can fix it themselves. The hikey isn't for sale yet, so I'd grab onto every chance to get people to use the release sw.
If that's too harsh I can see the value in providing a download for the non-psci dtb.
regards,
Koen
-- Scott Bambrough Technical Director, Member Services Linaro http://www.linaro.org