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. - 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 - 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 - i believe MCU loading isn't finished yet in ATF, this will cause power management problems, and possible overheating - it is needed

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?

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

Please don't top-post, especially not in the middle of a thread.

Op 14 mrt. 2015, om 01:26 heeft Scott Bambrough scott.bambrough@linaro.org het volgende geschreven:

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.
• 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
• 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
• i believe MCU loading isn't finished yet in ATF, this will cause power management problems, and possible overheating - it is needed

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.

From my previous experiences with boards and switching bootloaders: do it now, don't go soft on the hard requirements. If there are issues they will have to be worked out since ATF+UEFI is the only viable option. Recovery mode works and in a pinch you can use 'dd' in linux to update ATF and UEFI.

That being said I haven't had a chance to play with ARM TF + UEFI yet. Anyone have any comments based on experience?

It boots most of the times and works. And all the sources are there, so things can get fixed quickly and deployed, not this "skype the right hisilicon person to get a fix you can't give to anyone else" process we have now.

Speaking of sources, what's the story on mainlining hi6220 linux support, any updates?

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

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

On Tue, Mar 17, 2015 at 10:50:05AM +0530, Amit Kucheria wrote:

On Sun, Mar 15, 2015 at 8:28 PM, Leo Yan leo.yan@linaro.org wrote:

...

On Sat, Mar 14, 2015 at 09:09:05AM +0800, Haojian Zhuang wrote:

<snip>

...

...

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.

Good to see that you're using the cpufreq cooling device in the thermal framework now.

Yes, also thanks for the guidance before u gave to us ;)

...

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.

You could also cap the frequency on the cores i.e. don't add DT entries for OPPs above, say 600MHz, in the default image. That might allow you to enable all 8 cores w/o reaching overheating conditions while you fix various dependencies. You will need to measure this with all 8 cores enabled and loaded (and GPU too) before picking a value, though.

So far i'm working on mcu image loading, which is the firmware for hi6220's power controller. After this enabled, we can set a lower frequency/voltage so that can be safe for 8 cores, just like your suggestion.

I also will check with hisilicon for the default frequency of cpu.

Thanks, Leo Yan