Hi all,
Below are raw power data on Hikey board; with this power data i'd like to create the power model for Hikey.
- Measure method:
On Hikey board, we cannot measure buck1 which is dedicated for AP subsystem; so turned to measure VDD_4V2 to remove R247 and remount shunt resistor 470mOhm. At a result, the power data includes many other LDO's power data.
+--------------+ +-------------+ 4.2v | | Buck1 | | ---- Shunt Resistor --->| PMIC: Hi6553 |------>| SoC: Hi6220 | ^ ^ | | | ACPU | | | +--------------+ +-------------+ |-> Energy Probe <-|
- Measured raw data:
sys_suspend: AP system suspend state cluster_off: two clusters are powered off cluster_on: 1 cluster is powered on, all cpus are powered off cpu_wfi: 1 cluster is powered on, last cpu enters 'wfi' but other cpus are powered off voltage: voltage for every OPP
# OPP sys_suspend cluster_off cluster_on cpu_wfi cpu_on voltage 208 328 347 366 374 435 1.04 432 328 344 374 388 499 1.04 729 331 351 400 409 606 1.09 960 329 353 430 443 750 1.18 1200 331 365 486 506 988 1.33
Hikey Power Model Power [mW] 500 ++--------+-------------+---------+---------++ cluster_off **A*** + + + + D cluster_on ##B### 450 ++.........................................%%+ cpu_wfi $$C$$$ 400 ++.......................................%%.++ cpu p-state %%D%%% | : : : %% | 350 ++...................................%%.....++ | : : :%% | 300 ++...............................%D.........++ 250 ++...........................%%%%...........++ | : : %%% : | 200 ++....................%%D%..................++ | : %%%%% : : | 150 ++...........%%%%...........................++ | %%D%% : : #####B 100 ++.%%%%%.....................#####B#####....++ 50 D%%..............#######B####...............++ A*********A*************A*********A**********A 0 C$$$$$$$$$C$$$$$$$$$$$$$C$$$$$$$$$C$$$$$----++ 208 432 729 960 1200 Frequency [MHz]
Hikey Power Efficiency Power Efficiency [mW/MHz] Voltage [v] 0.45 ++-------+----------+--------+-------++ 3 Cluster Power **A*** + + + + + CPU Static Power ##B### 0.4 ++...................................$C CPU Dynamic power $$C$$$ | : : : $$$++ 2.5 Voltage %%D%%% 0.35 ++.............................$$$...++ | : : $$C$ | 0.3 C$$$$$$$$..............$$$$..........++ 2 | C$$$$$$$$$$C$$ : | 0.25 ++...................................++ 1.5 0.2 ++................................%%%%D | : : %%%%D%%%% | 0.15 D%%%%%%%%D%%%%%%%%%%D%%%%............++ 1 | : : : | 0.1 A********.........................****A | A**********A********A**** ++ 0.5 0.05 ++...................................++ B########B##########+ ####B########B 0 ++-------+----------B####----+-------++ 0 208 432 729 960 1200 Frequency [MHz]
- Power Model On Hikey:
According to before we have discussed for power model, i think below is the prefered power data for Hikey which calculated from raw power date:
static struct idle_state idle_states_cluster_a53[] = { { .power = 0 }, { .power = 0 }, };
/* * Use (cluster_on - cluster_off) for every OPP */ static struct capacity_state cap_states_cluster_a53[] = { /* Power per cluster */ { .cap = 178, .power = 19, }, { .cap = 369, .power = 30, }, { .cap = 622, .power = 49, }, { .cap = 819, .power = 77, }, { .cap = 1024, .power = 121, }, };
/* * Use (cpu_wfi - cluster_on) for every OPP, then calculate the * average value for wfi's power data; But we can see actually * the idle state of "WFI" will be impacted by voltage. */ static struct idle_state idle_states_core_a53[] = { { .power = 12 }, { .power = 0 }, };
/* * Use (cpu_on - cluster_off) for every OPP */ static struct capacity_state cap_states_core_a53[] = { /* Power per cpu */ { .cap = 178, .power = 69, }, /* 208MHz */ { .cap = 369, .power = 125, }, /* 432MHz */ { .cap = 622, .power = 206, }, /* 729MHz */ { .cap = 819, .power = 320, }, /* 960MHz */ { .cap = 1024, .power = 502, }, /* 1.2GHz */ };
If have any questions or issues for upper energy model data, please let me know; Appreciate review and comments in advance.
- Some other questions
Q1: Jian & Dan, voltage for 1.2GHz is quite high, could you help check the voltage table for OPPs, if there have any unexpected value?
Q2: Morten, if i want to do more profiling on EAS, do you suggest i should refer which branch now? I think now EASv5 patches are relative old, so want to check if we have better candidate or not.
i downloaded the git repo: git://www.linux-arm.org/linux-power.git, branch energy_model_rfc_v5.1; but there have no sched-dvfs related patches.
Thanks, Leo Yan
Hi Leo,
On 14/10/15 17:30, Leo Yan wrote:
Hi all,
Below are raw power data on Hikey board; with this power data i'd like to create the power model for Hikey.
- Measure method:
On Hikey board, we cannot measure buck1 which is dedicated for AP subsystem; so turned to measure VDD_4V2 to remove R247 and remount shunt resistor 470mOhm. At a result, the power data includes many other LDO's power data.
+--------------+ +-------------+ 4.2v | | Buck1 | |---- Shunt Resistor --->| PMIC: Hi6553 |------>| SoC: Hi6220 | ^ ^ | | | ACPU | | | +--------------+ +-------------+ |-> Energy Probe <-|
Measured raw data:
sys_suspend: AP system suspend state cluster_off: two clusters are powered off cluster_on: 1 cluster is powered on, all cpus are powered off cpu_wfi: 1 cluster is powered on, last cpu enters 'wfi' but other cpus are powered off voltage: voltage for every OPP
# OPP sys_suspend cluster_off cluster_on cpu_wfi cpu_on voltage 208 328 347 366 374 435 1.04 432 328 344 374 388 499 1.04 729 331 351 400 409 606 1.09 960 329 353 430 443 750 1.18 1200 331 365 486 506 988 1.33
Hikey Power ModelPower [mW] 500 ++--------+-------------+---------+---------++ cluster_off **A*** + + + + D cluster_on ##B### 450 ++.........................................%%+ cpu_wfi $$C$$$ 400 ++.......................................%%.++ cpu p-state %%D%%% | : : : %% | 350 ++...................................%%.....++ | : : :%% | 300 ++...............................%D.........++ 250 ++...........................%%%%...........++ | : : %%% : | 200 ++....................%%D%..................++ | : %%%%% : : | 150 ++...........%%%%...........................++ | %%D%% : : #####B 100 ++.%%%%%.....................#####B#####....++ 50 D%%..............#######B####...............++ A*********A*************A*********A**********A 0 C$$$$$$$$$C$$$$$$$$$$$$$C$$$$$$$$$C$$$$$----++ 208 432 729 960 1200 Frequency [MHz]
Hikey Power EfficiencyPower Efficiency [mW/MHz] Voltage [v] 0.45 ++-------+----------+--------+-------++ 3 Cluster Power **A*** + + + + + CPU Static Power ##B### 0.4 ++...................................$C CPU Dynamic power $$C$$$ | : : : $$$++ 2.5 Voltage %%D%%% 0.35 ++.............................$$$...++ | : : $$C$ | 0.3 C$$$$$$$$..............$$$$..........++ 2 | C$$$$$$$$$$C$$ : | 0.25 ++...................................++ 1.5 0.2 ++................................%%%%D | : : %%%%D%%%% | 0.15 D%%%%%%%%D%%%%%%%%%%D%%%%............++ 1 | : : : | 0.1 A********.........................****A | A**********A********A**** ++ 0.5 0.05 ++...................................++ B########B##########+ ####B########B 0 ++-------+----------B####----+-------++ 0 208 432 729 960 1200 Frequency [MHz]
- Power Model On Hikey:
According to before we have discussed for power model, i think below is the prefered power data for Hikey which calculated from raw power date:
static struct idle_state idle_states_cluster_a53[] = { { .power = 0 }, { .power = 0 }, };
/*
- Use (cluster_on - cluster_off) for every OPP
*/ static struct capacity_state cap_states_cluster_a53[] = { /* Power per cluster */ { .cap = 178, .power = 19, }, { .cap = 369, .power = 30, }, { .cap = 622, .power = 49, }, { .cap = 819, .power = 77, }, { .cap = 1024, .power = 121, }, };
/*
- Use (cpu_wfi - cluster_on) for every OPP, then calculate the
- average value for wfi's power data; But we can see actually
- the idle state of "WFI" will be impacted by voltage.
*/ static struct idle_state idle_states_core_a53[] = { { .power = 12 }, { .power = 0 }, };
/*
- Use (cpu_on - cluster_off) for every OPP
*/ static struct capacity_state cap_states_core_a53[] = { /* Power per cpu */ { .cap = 178, .power = 69, }, /* 208MHz */ { .cap = 369, .power = 125, }, /* 432MHz */ { .cap = 622, .power = 206, }, /* 729MHz */ { .cap = 819, .power = 320, }, /* 960MHz */ { .cap = 1024, .power = 502, }, /* 1.2GHz */ };
If have any questions or issues for upper energy model data, please let me know; Appreciate review and comments in advance.
Some other questions
Q1: Jian & Dan, voltage for 1.2GHz is quite high, could you help check the voltage table for OPPs, if there have any unexpected value?
Q2: Morten, if i want to do more profiling on EAS, do you suggest i should refer which branch now? I think now EASv5 patches are relative old, so want to check if we have better candidate or not.
Please continue to use EASv5 since we're still testing EASv5.1 (including SchedDvfs) on Juno board.
BTW, the issues you and Steve M. raised against 22/46 and 32/46 of RFCv5 seen on the Hikey board (SMP) haven't been addressed in RFCv5.1 yet.
Once we get the right results for the RFCv5 test cases on Juno for EASv5.1 (including SchedDvfs) we will share it on linux-arm.org.
-- Dietmar
i downloaded the git repo: git://www.linux-arm.org/linux-power.git, branch energy_model_rfc_v5.1; but there have no sched-dvfs related patches.
Thanks, Leo Yan
Hi Dietmar,
On Tue, Oct 20, 2015 at 08:04:30PM +0100, Dietmar Eggemann wrote:
On 14/10/15 17:30, Leo Yan wrote:
Hi all,
Below are raw power data on Hikey board; with this power data i'd like to create the power model for Hikey.
- Measure method:
On Hikey board, we cannot measure buck1 which is dedicated for AP subsystem; so turned to measure VDD_4V2 to remove R247 and remount shunt resistor 470mOhm. At a result, the power data includes many other LDO's power data.
+--------------+ +-------------+ 4.2v | | Buck1 | |---- Shunt Resistor --->| PMIC: Hi6553 |------>| SoC: Hi6220 | ^ ^ | | | ACPU | | | +--------------+ +-------------+ |-> Energy Probe <-|
Measured raw data:
sys_suspend: AP system suspend state cluster_off: two clusters are powered off cluster_on: 1 cluster is powered on, all cpus are powered off cpu_wfi: 1 cluster is powered on, last cpu enters 'wfi' but other cpus are powered off voltage: voltage for every OPP
# OPP sys_suspend cluster_off cluster_on cpu_wfi cpu_on voltage 208 328 347 366 374 435 1.04 432 328 344 374 388 499 1.04 729 331 351 400 409 606 1.09 960 329 353 430 443 750 1.18 1200 331 365 486 506 988 1.33
Hikey Power ModelPower [mW] 500 ++--------+-------------+---------+---------++ cluster_off **A*** + + + + D cluster_on ##B### 450 ++.........................................%%+ cpu_wfi $$C$$$ 400 ++.......................................%%.++ cpu p-state %%D%%% | : : : %% | 350 ++...................................%%.....++ | : : :%% | 300 ++...............................%D.........++ 250 ++...........................%%%%...........++ | : : %%% : | 200 ++....................%%D%..................++ | : %%%%% : : | 150 ++...........%%%%...........................++ | %%D%% : : #####B 100 ++.%%%%%.....................#####B#####....++ 50 D%%..............#######B####...............++ A*********A*************A*********A**********A 0 C$$$$$$$$$C$$$$$$$$$$$$$C$$$$$$$$$C$$$$$----++ 208 432 729 960 1200 Frequency [MHz]
Hikey Power EfficiencyPower Efficiency [mW/MHz] Voltage [v] 0.45 ++-------+----------+--------+-------++ 3 Cluster Power **A*** + + + + + CPU Static Power ##B### 0.4 ++...................................$C CPU Dynamic power $$C$$$ | : : : $$$++ 2.5 Voltage %%D%%% 0.35 ++.............................$$$...++ | : : $$C$ | 0.3 C$$$$$$$$..............$$$$..........++ 2 | C$$$$$$$$$$C$$ : | 0.25 ++...................................++ 1.5 0.2 ++................................%%%%D | : : %%%%D%%%% | 0.15 D%%%%%%%%D%%%%%%%%%%D%%%%............++ 1 | : : : | 0.1 A********.........................****A | A**********A********A**** ++ 0.5 0.05 ++...................................++ B########B##########+ ####B########B 0 ++-------+----------B####----+-------++ 0 208 432 729 960 1200 Frequency [MHz]
- Power Model On Hikey:
According to before we have discussed for power model, i think below is the prefered power data for Hikey which calculated from raw power date:
static struct idle_state idle_states_cluster_a53[] = { { .power = 0 }, { .power = 0 }, };
/*
- Use (cluster_on - cluster_off) for every OPP
*/ static struct capacity_state cap_states_cluster_a53[] = { /* Power per cluster */ { .cap = 178, .power = 19, }, { .cap = 369, .power = 30, }, { .cap = 622, .power = 49, }, { .cap = 819, .power = 77, }, { .cap = 1024, .power = 121, }, };
/*
- Use (cpu_wfi - cluster_on) for every OPP, then calculate the
- average value for wfi's power data; But we can see actually
- the idle state of "WFI" will be impacted by voltage.
*/ static struct idle_state idle_states_core_a53[] = { { .power = 12 }, { .power = 0 }, };
/*
- Use (cpu_on - cluster_off) for every OPP
*/ static struct capacity_state cap_states_core_a53[] = { /* Power per cpu */ { .cap = 178, .power = 69, }, /* 208MHz */ { .cap = 369, .power = 125, }, /* 432MHz */ { .cap = 622, .power = 206, }, /* 729MHz */ { .cap = 819, .power = 320, }, /* 960MHz */ { .cap = 1024, .power = 502, }, /* 1.2GHz */ };
If have any questions or issues for upper energy model data, please let me know; Appreciate review and comments in advance.
Some other questions
Q1: Jian & Dan, voltage for 1.2GHz is quite high, could you help check the voltage table for OPPs, if there have any unexpected value?
Q2: Morten, if i want to do more profiling on EAS, do you suggest i should refer which branch now? I think now EASv5 patches are relative old, so want to check if we have better candidate or not.
Please continue to use EASv5 since we're still testing EASv5.1 (including SchedDvfs) on Juno board.
BTW, the issues you and Steve M. raised against 22/46 and 32/46 of RFCv5 seen on the Hikey board (SMP) haven't been addressed in RFCv5.1 yet.
Once we get the right results for the RFCv5 test cases on Juno for EASv5.1 (including SchedDvfs) we will share it on linux-arm.org.
Thanks for suggestion.
Acutally i have took some time to port EASv5.1 patches on my own branch, it's quite smooth to apply these patches. And i tried to port Juri and Mike's patches for SchedDVFS, there have several conflicts need to manually fix based on EASv5.1.
Anyway, i will go back to use EASv5 for power profiling. Suppose i can get some profiling result and send out for review in next 1~2 weeks :)
Thanks, Leo Yan
-- Dietmar
i downloaded the git repo: git://www.linux-arm.org/linux-power.git, branch energy_model_rfc_v5.1; but there have no sched-dvfs related patches.
Thanks, Leo Yan
On 21/10/15 02:56, Leo Yan wrote:
Hi Dietmar,
On Tue, Oct 20, 2015 at 08:04:30PM +0100, Dietmar Eggemann wrote:
On 14/10/15 17:30, Leo Yan wrote:
Hi all,
Below are raw power data on Hikey board; with this power data i'd like to create the power model for Hikey.
- Measure method:
On Hikey board, we cannot measure buck1 which is dedicated for AP subsystem; so turned to measure VDD_4V2 to remove R247 and remount shunt resistor 470mOhm. At a result, the power data includes many other LDO's power data.
+--------------+ +-------------+ 4.2v | | Buck1 | |---- Shunt Resistor --->| PMIC: Hi6553 |------>| SoC: Hi6220 | ^ ^ | | | ACPU | | | +--------------+ +-------------+ |-> Energy Probe <-|
Measured raw data:
sys_suspend: AP system suspend state cluster_off: two clusters are powered off cluster_on: 1 cluster is powered on, all cpus are powered off cpu_wfi: 1 cluster is powered on, last cpu enters 'wfi' but other cpus are powered off voltage: voltage for every OPP
# OPP sys_suspend cluster_off cluster_on cpu_wfi cpu_on voltage 208 328 347 366 374 435 1.04 432 328 344 374 388 499 1.04 729 331 351 400 409 606 1.09 960 329 353 430 443 750 1.18 1200 331 365 486 506 988 1.33
Hikey Power ModelPower [mW] 500 ++--------+-------------+---------+---------++ cluster_off **A*** + + + + D cluster_on ##B### 450 ++.........................................%%+ cpu_wfi $$C$$$ 400 ++.......................................%%.++ cpu p-state %%D%%% | : : : %% | 350 ++...................................%%.....++ | : : :%% | 300 ++...............................%D.........++ 250 ++...........................%%%%...........++ | : : %%% : | 200 ++....................%%D%..................++ | : %%%%% : : | 150 ++...........%%%%...........................++ | %%D%% : : #####B 100 ++.%%%%%.....................#####B#####....++ 50 D%%..............#######B####...............++ A*********A*************A*********A**********A 0 C$$$$$$$$$C$$$$$$$$$$$$$C$$$$$$$$$C$$$$$----++ 208 432 729 960 1200 Frequency [MHz]
Hikey Power EfficiencyPower Efficiency [mW/MHz] Voltage [v] 0.45 ++-------+----------+--------+-------++ 3 Cluster Power **A*** + + + + + CPU Static Power ##B### 0.4 ++...................................$C CPU Dynamic power $$C$$$ | : : : $$$++ 2.5 Voltage %%D%%% 0.35 ++.............................$$$...++ | : : $$C$ | 0.3 C$$$$$$$$..............$$$$..........++ 2 | C$$$$$$$$$$C$$ : | 0.25 ++...................................++ 1.5 0.2 ++................................%%%%D | : : %%%%D%%%% | 0.15 D%%%%%%%%D%%%%%%%%%%D%%%%............++ 1 | : : : | 0.1 A********.........................****A | A**********A********A**** ++ 0.5 0.05 ++...................................++ B########B##########+ ####B########B 0 ++-------+----------B####----+-------++ 0 208 432 729 960 1200 Frequency [MHz]
- Power Model On Hikey:
According to before we have discussed for power model, i think below is the prefered power data for Hikey which calculated from raw power date:
static struct idle_state idle_states_cluster_a53[] = { { .power = 0 }, { .power = 0 }, };
/*
- Use (cluster_on - cluster_off) for every OPP
*/ static struct capacity_state cap_states_cluster_a53[] = { /* Power per cluster */ { .cap = 178, .power = 19, }, { .cap = 369, .power = 30, }, { .cap = 622, .power = 49, }, { .cap = 819, .power = 77, }, { .cap = 1024, .power = 121, }, };
/*
- Use (cpu_wfi - cluster_on) for every OPP, then calculate the
- average value for wfi's power data; But we can see actually
- the idle state of "WFI" will be impacted by voltage.
*/ static struct idle_state idle_states_core_a53[] = { { .power = 12 }, { .power = 0 }, };
/*
- Use (cpu_on - cluster_off) for every OPP
*/ static struct capacity_state cap_states_core_a53[] = { /* Power per cpu */ { .cap = 178, .power = 69, }, /* 208MHz */ { .cap = 369, .power = 125, }, /* 432MHz */ { .cap = 622, .power = 206, }, /* 729MHz */ { .cap = 819, .power = 320, }, /* 960MHz */ { .cap = 1024, .power = 502, }, /* 1.2GHz */ };
If have any questions or issues for upper energy model data, please let me know; Appreciate review and comments in advance.
Some other questions
Q1: Jian & Dan, voltage for 1.2GHz is quite high, could you help check the voltage table for OPPs, if there have any unexpected value?
Q2: Morten, if i want to do more profiling on EAS, do you suggest i should refer which branch now? I think now EASv5 patches are relative old, so want to check if we have better candidate or not.
Please continue to use EASv5 since we're still testing EASv5.1 (including SchedDvfs) on Juno board.
BTW, the issues you and Steve M. raised against 22/46 and 32/46 of RFCv5 seen on the Hikey board (SMP) haven't been addressed in RFCv5.1 yet.
Once we get the right results for the RFCv5 test cases on Juno for EASv5.1 (including SchedDvfs) we will share it on linux-arm.org.
Thanks for suggestion.
I've pushed EASv5.1 (including SchedDfvs and rebased to current /tip/sched/core (Linux 4.3-rc5)) to:
git://linux-arm.org/linux-power.git energy_model_rfc_v5.1
The problem I saw on JUNO board (too much packing on one cpu forcing the system into over-utilized state which then spread the tasks among the little cpus and this process repeating itself over and over again leading to bad performance numbers was down to CONFIG_SCHED_AUTOGROUP=y). So make sure it's not enabled.
Acutally i have took some time to port EASv5.1 patches on my own branch, it's quite smooth to apply these patches. And i tried to port Juri and Mike's patches for SchedDVFS, there have several conflicts need to manually fix based on EASv5.1.
Anyway, i will go back to use EASv5 for power profiling. Suppose i can get some profiling result and send out for review in next 1~2 weeks :)
The way we present indexes into the 'struct idle_state' vectors has changed between 5 and 5.1. have a look into the JUNO energy model and static int group_idle_state(struct sched_group *sg).
Cheers,
-- Dietmar
Thanks, Leo Yan
-- Dietmar
i downloaded the git repo: git://www.linux-arm.org/linux-power.git, branch energy_model_rfc_v5.1; but there have no sched-dvfs related patches.
Thanks, Leo Yan
On 29/10/15 14:36, Dietmar Eggemann wrote:
On 21/10/15 02:56, Leo Yan wrote:
Hi Dietmar,
On Tue, Oct 20, 2015 at 08:04:30PM +0100, Dietmar Eggemann wrote:
On 14/10/15 17:30, Leo Yan wrote:
[...]
Some other questions
Q1: Jian & Dan, voltage for 1.2GHz is quite high, could you help check the voltage table for OPPs, if there have any unexpected value?
Q2: Morten, if i want to do more profiling on EAS, do you suggest i should refer which branch now? I think now EASv5 patches are relative old, so want to check if we have better candidate or not.
Please continue to use EASv5 since we're still testing EASv5.1 (including SchedDvfs) on Juno board.
BTW, the issues you and Steve M. raised against 22/46 and 32/46 of RFCv5 seen on the Hikey board (SMP) haven't been addressed in RFCv5.1 yet.
Once we get the right results for the RFCv5 test cases on Juno for EASv5.1 (including SchedDvfs) we will share it on linux-arm.org.
Thanks for suggestion.
I've pushed EASv5.1 (including SchedDfvs and rebased to current /tip/sched/core (Linux 4.3-rc5)) to:
git://linux-arm.org/linux-power.git energy_model_rfc_v5.1
The problem I saw on JUNO board (too much packing on one cpu forcing the system into over-utilized state which then spread the tasks among the little cpus and this process repeating itself over and over again leading to bad performance numbers was down to CONFIG_SCHED_AUTOGROUP=y). So make sure it's not enabled.
Acutally i have took some time to port EASv5.1 patches on my own branch, it's quite smooth to apply these patches. And i tried to port Juri and Mike's patches for SchedDVFS, there have several conflicts need to manually fix based on EASv5.1.
Anyway, i will go back to use EASv5 for power profiling. Suppose i can get some profiling result and send out for review in next 1~2 weeks :)
The way we present indexes into the 'struct idle_state' vectors has changed between 5 and 5.1. have a look into the JUNO energy model and static int group_idle_state(struct sched_group *sg).
Hi Leo,
I'm trying to get my hikey board running with your EASv5 kernel (https://github.com/Leo-Yan/linux/tree/profile_easv5_hikey_round3)
What's working for me is the 'Debian Linux' installation described under https://github.com/96boards/documentation/wiki/HiKeyGettingStarted .
What's the easiest way to get ARM secure firmware and your kernel running? Would be nice if you can share information about how to build and deploy both on the board.
I use the Debug UART (UART0) for a serial connection to the board.
Thanks,
-- Dietmar
[...]
Hi Dietmar,
On Thu, Oct 29, 2015 at 04:30:00PM +0000, Dietmar Eggemann wrote:
On 29/10/15 14:36, Dietmar Eggemann wrote:
On 21/10/15 02:56, Leo Yan wrote:
[...]
Hi Leo,
I'm trying to get my hikey board running with your EASv5 kernel (https://github.com/Leo-Yan/linux/tree/profile_easv5_hikey_round3)
I have updated the git tree for my round4's code base: https://github.com/Leo-Yan/linux/tree/profile_easv5_hikey_round4. this branch enables USB OTG so that we can configure ethernet on USB, finally can send ssh command for automatic testing.
BTW, sorry for i wrongly deleted profile_easv5_hikey_round3 branch :(, so suggest you can go to use round4's branch.
What's working for me is the 'Debian Linux' installation described under https://github.com/96boards/documentation/wiki/HiKeyGettingStarted .
What's the easiest way to get ARM secure firmware and your kernel running? Would be nice if you can share information about how to build and deploy both on the board.
I shared my building env: http://people.linaro.org/~leo.yan/hi6220_dev/; suggest to download and keep same directory layout.
- For build firmware (ATF, UEFI): http://people.linaro.org/~leo.yan/hi6220_dev/boot/build_fw.sh
This command will download repos and build all images; finally it will copy l-loader.bin and fip.bin into output folder ./build_fw.sh download
This command will build all images and copy images to output folder ./build_fw.sh
You also can refer the doc: https://github.com/96boards/documentation/wiki/HiKeyUEFI
- For build kernel: git clone https://github.com/Leo-Yan/linux git checkout -b EASv5 origin/profile_easv5_hikey_round4
export ARCH=arm64 export CROSS_COMPILE=aarch64-linux-gnu-
make defconfig make -j4
- Generate boot.img
http://people.linaro.org/~leo.yan/hi6220_dev/output/gen_uefi_boot_img.sh
After build kernel successfully, you can run command to build boot.img: ./gen_uefi_boot_img.sh
- Burn images to board:
Please refer the script: http://people.linaro.org/~leo.yan/hi6220_dev/output/burn_boot_images.sh
I use the Debug UART (UART0) for a serial connection to the board.
Please NOTE, now hi6220's code base have changed to use UART3 as default console. If you have not a extenstion board for UART3, you can use UART0 still.
So before build firmwares, should firstly apply the patch: http://people.linaro.org/~leo.yan/hi6220_dev/boot/0001-Change-to-use-UART0.p...
For kernel and filesystem, below two files have used UART0 as console, so you could directly boot kernel and rootfs with UART0: http://people.linaro.org/~leo.yan/hi6220_dev/output/grub_AMA0.cfg. http://people.linaro.org/~leo.yan/hi6220_dev/output/ramdisk.tgz
Usually at beginning guys create enviornment for Hikey will be a little painful, just let me know if you have any problem.
Thanks,
-- Dietmar
[...]
Hi Leo,
On 30/10/15 03:12, Leo Yan wrote:
Hi Dietmar,
On Thu, Oct 29, 2015 at 04:30:00PM +0000, Dietmar Eggemann wrote:
On 29/10/15 14:36, Dietmar Eggemann wrote:
On 21/10/15 02:56, Leo Yan wrote:
[...]
Please NOTE, now hi6220's code base have changed to use UART3 as default console. If you have not a extenstion board for UART3, you can use UART0 still.
thanks for sharing the build environment! I guess it was because of the UART change (from UART0 to UART3) that I didn't succeed initially following the info provided on https://github.com/96boards/documentation/wiki/HiKeyUEFI .
I was able to build:
l-loader.bin fip.bin ptable-linux.img and AndroidFastbootApp.efi
from the sources and took
grubaa64.efi initrd.img nvme.img grub_AMA0.cfg
from http://people.linaro.org/~leo.yan/hi6220_dev/output ,
flashed it onto my hikey board and got my Debian FS on the sdcard booting.
---
After a couple of tries the hikey board is not responding any more to fastboot commands after I loaded l-loaded.bin in recovery mode (pin1-pin2 and pin3-pin4 on J15 are set).
$ sudo python hisi-idt.py -d /dev/ttyUSB2 --img1=l-loader.bin +----------------------+ Serial: /dev/ttyUSB2 Image1: l-loader.bin Image2: +----------------------+
Sending l-loader.bin ... Done
$ sudo env "PATH=$PATH" fastboot flash ptable ptable-linux.img < waiting for device >
... waits here forever with User LED 0 on.
If I boot in 'normal' mode (pin1-pin2 set) I get the following output on UART0:
debug EMMC boot: print init OK debug EMMC boot: send RST_N . debug EMMC boot: start eMMC boot...... load fastboot1!
Switch to aarch64 mode. CPU0 executes at 0xf9801000! NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.1(release):1b9a4b277314 NOTICE: BL1: Built : 13:43:57, Nov 3 2015 NOTICE: syspll frequency:1190494208Hz INFO: rdet ds fail INFO: rdet ds fail INFO: rdet ds fail ...
If I try to prepare fastboot with hisi-idt.py it fails too (in recovery mode):
$ sudo python hisi-idt.py -d /dev/ttyUSB2 --img1 fastboot1.img --img2 fastboot2.img +----------------------+ Serial: /dev/ttyUSB2 Image1: fastboot1.img Image2: fastboot2.img +----------------------+
Sending fastboot1.img ... Done
Sending fastboot2.img ... failed
I hope that this board isn't bricked? Any help highly appreciated!
Thanks,
-- Dietmar
So before build firmwares, should firstly apply the patch: http://people.linaro.org/~leo.yan/hi6220_dev/boot/0001-Change-to-use-UART0.p...
For kernel and filesystem, below two files have used UART0 as console, so you could directly boot kernel and rootfs with UART0: http://people.linaro.org/~leo.yan/hi6220_dev/output/grub_AMA0.cfg. http://people.linaro.org/~leo.yan/hi6220_dev/output/ramdisk.tgz
Usually at beginning guys create enviornment for Hikey will be a little painful, just let me know if you have any problem.
Thanks,
-- Dietmar
[...]
On Tue, Nov 03, 2015 at 08:33:33PM +0000, Dietmar Eggemann wrote:
Hi Leo,
On 30/10/15 03:12, Leo Yan wrote:
Hi Dietmar,
On Thu, Oct 29, 2015 at 04:30:00PM +0000, Dietmar Eggemann wrote:
On 29/10/15 14:36, Dietmar Eggemann wrote:
On 21/10/15 02:56, Leo Yan wrote:
[...]
Please NOTE, now hi6220's code base have changed to use UART3 as default console. If you have not a extenstion board for UART3, you can use UART0 still.
thanks for sharing the build environment! I guess it was because of the UART change (from UART0 to UART3) that I didn't succeed initially following the info provided on https://github.com/96boards/documentation/wiki/HiKeyUEFI .
I was able to build:
l-loader.bin fip.bin ptable-linux.img and AndroidFastbootApp.efi
from the sources and took
grubaa64.efi initrd.img nvme.img grub_AMA0.cfg
from http://people.linaro.org/~leo.yan/hi6220_dev/output ,
flashed it onto my hikey board and got my Debian FS on the sdcard booting.
After a couple of tries the hikey board is not responding any more to fastboot commands after I loaded l-loaded.bin in recovery mode (pin1-pin2 and pin3-pin4 on J15 are set).
$ sudo python hisi-idt.py -d /dev/ttyUSB2 --img1=l-loader.bin +----------------------+ Serial: /dev/ttyUSB2 Image1: l-loader.bin Image2: +----------------------+
Sending l-loader.bin ... Done
$ sudo env "PATH=$PATH" fastboot flash ptable ptable-linux.img < waiting for device >
... waits here forever with User LED 0 on.
Have no questions for the steps of burning images.
After burn image 'l-loader.bin', you can check PC side if dump below info:
leoy@leoy-linaro:~$ sudo dmesg -c [52045.180850] usb 1-1.1.3: USB disconnect, device number 46 [52045.181032] option1 ttyUSB1: GSM modem (1-port) converter now disconnected from ttyUSB1 [52045.181048] option 1-1.1.3:1.0: device disconnected [52045.393983] usb 1-1.1.3: new high-speed USB device number 47 using ehci-pci [52045.499062] usb 1-1.1.3: New USB device found, idVendor=18d1, idProduct=d00d [52045.499067] usb 1-1.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [52045.499069] usb 1-1.1.3: Product: Android 2.0 [52045.499071] usb 1-1.1.3: Manufacturer: Androi [52045.499072] usb 1-1.1.3: SerialNumber: 0123456789ABCDEF
leoy@leoy-linaro:~/Work/hisi/boot/l-loader$ sudo fastboot devices 0123456789ABCDEF fastboot
So that means it has prepared successfully for "fastboot", otherwise we can get to know 'l-loader.bin' has not successfully initialized protocol for "fastboot".
If I boot in 'normal' mode (pin1-pin2 set) I get the following output on UART0:
debug EMMC boot: print init OK debug EMMC boot: send RST_N . debug EMMC boot: start eMMC boot...... load fastboot1!
Switch to aarch64 mode. CPU0 executes at 0xf9801000! NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.1(release):1b9a4b277314 NOTICE: BL1: Built : 13:43:57, Nov 3 2015 NOTICE: syspll frequency:1190494208Hz INFO: rdet ds fail INFO: rdet ds fail INFO: rdet ds fail ...
"INFO: rdet ds fail", it's related with DDR's initialization; below log info is when bl1 has initailized DDR successfully.
Switch to aarch64 mode. CPU0 executes at 0xf9801000! NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.1(release):ca9f7ed NOTICE: BL1: Built : 11:05:40, Nov 4 2015 NOTICE: syspll frequency:1190494208Hz NOTICE: succeed to init lpddr3 rank0 dram phy INFO: lpddr3_freq_init, set ddrc 533mhz INFO: init ddr3 rank0 INFO: ddr3 rank1 init pass INFO: lpddr3_freq_init, set ddrc 800mhz INFO: init ddr3 rank0 INFO: ddr3 rank1 init pass INFO: Elpida DDR NOTICE: Enter fastboot mode...
At least below things are deserved to get a quick try:
- Could you directly try below images: http://people.linaro.org/~leo.yan/hi6220_dev/output/l-loader_DDR_533MHz.bin http://people.linaro.org/~leo.yan/hi6220_dev/output/fip_DDR_533MHz.bin
We can use this way to confirm DDR can work well;
- If it's lucky with upper images, can continue to try 800MHz DRR: http://people.linaro.org/~leo.yan/hi6220_dev/output/l-loader_DDR_800MHz.bin http://people.linaro.org/~leo.yan/hi6220_dev/output/fip_DDR_800MHz.bin
- If all of them can work well, then we can check if build enviornment is same b/t both sides. Before we found some toolchain will introduce DDR initialization failed.
leoy@leoy-linaro:~/Work/hisi/boot$ aarch64-linux-gnu-gcc --version aarch64-linux-gnu-gcc (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) 4.9.2 20140904 (prerelease) Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
leoy@leoy-linaro:~/Work/hisi/boot/l-loader$ arm-linux-gnueabi-gcc --version arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Also Loop in Haojian for DDR initialization, who is best know this. Haojian, could you please review upper log and give suggestion as needed?
If I try to prepare fastboot with hisi-idt.py it fails too (in recovery mode):
$ sudo python hisi-idt.py -d /dev/ttyUSB2 --img1 fastboot1.img --img2 fastboot2.img +----------------------+ Serial: /dev/ttyUSB2 Image1: fastboot1.img Image2: fastboot2.img +----------------------+
Sending fastboot1.img ... Done
Sending fastboot2.img ... failed
I hope that this board isn't bricked? Any help highly appreciated!
From upper log, at least we can know SoC works well (internal SRAM, on chip ROM);
but we need firstly narrow down for DDR. Hope it's only a software issue.
[...]
Thanks, Leo Yan
On 04/11/15 03:47, Leo Yan wrote:
On Tue, Nov 03, 2015 at 08:33:33PM +0000, Dietmar Eggemann wrote:
Hi Leo,
On 30/10/15 03:12, Leo Yan wrote:
Hi Dietmar,
On Thu, Oct 29, 2015 at 04:30:00PM +0000, Dietmar Eggemann wrote:
On 29/10/15 14:36, Dietmar Eggemann wrote:
On 21/10/15 02:56, Leo Yan wrote:
[...]
After burn image 'l-loader.bin', you can check PC side if dump below info:
leoy@leoy-linaro:~$ sudo dmesg -c [52045.180850] usb 1-1.1.3: USB disconnect, device number 46 [52045.181032] option1 ttyUSB1: GSM modem (1-port) converter now disconnected from ttyUSB1 [52045.181048] option 1-1.1.3:1.0: device disconnected [52045.393983] usb 1-1.1.3: new high-speed USB device number 47 using ehci-pci [52045.499062] usb 1-1.1.3: New USB device found, idVendor=18d1, idProduct=d00d [52045.499067] usb 1-1.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [52045.499069] usb 1-1.1.3: Product: Android 2.0 [52045.499071] usb 1-1.1.3: Manufacturer: Androi [52045.499072] usb 1-1.1.3: SerialNumber: 0123456789ABCDEF
Yeah, there is no dmesg output for the board in question but I can see this output using a fresh hikey board so I guess the l-loader.bin I built is OK.
leoy@leoy-linaro:~/Work/hisi/boot/l-loader$ sudo fastboot devices 0123456789ABCDEF fastboot
So that means it has prepared successfully for "fastboot", otherwise we can get to know 'l-loader.bin' has not successfully initialized protocol for "fastboot".
Yes, 'fastboot devices' is not working for the board in question where as it works fine for the fresh hikey board.
If I boot in 'normal' mode (pin1-pin2 set) I get the following output on UART0:
debug EMMC boot: print init OK debug EMMC boot: send RST_N . debug EMMC boot: start eMMC boot...... load fastboot1!
Switch to aarch64 mode. CPU0 executes at 0xf9801000! NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.1(release):1b9a4b277314 NOTICE: BL1: Built : 13:43:57, Nov 3 2015 NOTICE: syspll frequency:1190494208Hz INFO: rdet ds fail INFO: rdet ds fail INFO: rdet ds fail ...
"INFO: rdet ds fail", it's related with DDR's initialization; below log info is when bl1 has initailized DDR successfully.
Switch to aarch64 mode. CPU0 executes at 0xf9801000! NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.1(release):ca9f7ed NOTICE: BL1: Built : 11:05:40, Nov 4 2015 NOTICE: syspll frequency:1190494208Hz NOTICE: succeed to init lpddr3 rank0 dram phy INFO: lpddr3_freq_init, set ddrc 533mhz INFO: init ddr3 rank0 INFO: ddr3 rank1 init pass INFO: lpddr3_freq_init, set ddrc 800mhz INFO: init ddr3 rank0 INFO: ddr3 rank1 init pass INFO: Elpida DDR NOTICE: Enter fastboot mode...
I don't see the output related to the DDR initialization, instead I see the 'INFO: rdet ds fail'.
At least below things are deserved to get a quick try:
- Could you directly try below images: http://people.linaro.org/~leo.yan/hi6220_dev/output/l-loader_DDR_533MHz.bin
No change in case I load l-loader_DDR_533MHz.bin. Same behaviour on both hikey boards.
http://people.linaro.org/~leo.yan/hi6220_dev/output/fip_DDR_533MHz.bin
We can use this way to confirm DDR can work well;
If it's lucky with upper images, can continue to try 800MHz DRR: http://people.linaro.org/~leo.yan/hi6220_dev/output/l-loader_DDR_800MHz.bin http://people.linaro.org/~leo.yan/hi6220_dev/output/fip_DDR_800MHz.bin
If all of them can work well, then we can check if build enviornment is same b/t both sides. Before we found some toolchain will introduce DDR initialization failed.
Since the l-loader.bin is working as expected on the fresh hikey board and was working on the board in question till yesterday afternoon I'm quite sure I'm building something sane here.
Thanks,
-- Dietmar
[...]
On 04/11/15 19:12, Dietmar Eggemann wrote:
On 04/11/15 03:47, Leo Yan wrote:
On Tue, Nov 03, 2015 at 08:33:33PM +0000, Dietmar Eggemann wrote:
Hi Leo,
On 30/10/15 03:12, Leo Yan wrote:
Hi Dietmar,
On Thu, Oct 29, 2015 at 04:30:00PM +0000, Dietmar Eggemann wrote:
On 29/10/15 14:36, Dietmar Eggemann wrote:
On 21/10/15 02:56, Leo Yan wrote:
[...]
Switch to aarch64 mode. CPU0 executes at 0xf9801000! NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.1(release):ca9f7ed NOTICE: BL1: Built : 11:05:40, Nov 4 2015 NOTICE: syspll frequency:1190494208Hz NOTICE: succeed to init lpddr3 rank0 dram phy INFO: lpddr3_freq_init, set ddrc 533mhz INFO: init ddr3 rank0 INFO: ddr3 rank1 init pass INFO: lpddr3_freq_init, set ddrc 800mhz INFO: init ddr3 rank0 INFO: ddr3 rank1 init pass INFO: Elpida DDR NOTICE: Enter fastboot mode...
I don't see the output related to the DDR initialization, instead I see the 'INFO: rdet ds fail'.
Just to be clear, this is in 'normal' mode (pin1-pin2 set).
If I connect the Debug UART while downloading the l-loader.bin (in recovery mode (pin1-pin2 and pin3-pin4 on J15 are set)) I get:
Switch to aarch64 mode. CPU0 executes at 0xf9801000! NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.1(release):1b9a4b277314 NOTICE: BL1: Built : 09:46:37, Nov 4 2015 NOTICE: syspll frequency:1190494208Hz NOTICE: succeed to init lpddr3 rank0 dram phy INFO: lpddr3_freq_init, set ddrc 533mhz INFO: init ddr3 rank0 INFO: rdet ds fail INFO: rdet ds fail
so in this case I don't see the messages indicating successful DDR initialization, like 'INFO: ddr3 rank1 init pass' and so on
[...]
On Wed, Nov 04, 2015 at 07:30:45PM +0000, Dietmar Eggemann wrote:
On 04/11/15 19:12, Dietmar Eggemann wrote:
On 04/11/15 03:47, Leo Yan wrote:
On Tue, Nov 03, 2015 at 08:33:33PM +0000, Dietmar Eggemann wrote:
Hi Leo,
On 30/10/15 03:12, Leo Yan wrote:
Hi Dietmar,
On Thu, Oct 29, 2015 at 04:30:00PM +0000, Dietmar Eggemann wrote:
On 29/10/15 14:36, Dietmar Eggemann wrote: > On 21/10/15 02:56, Leo Yan wrote:
[...]
Switch to aarch64 mode. CPU0 executes at 0xf9801000! NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.1(release):ca9f7ed NOTICE: BL1: Built : 11:05:40, Nov 4 2015 NOTICE: syspll frequency:1190494208Hz NOTICE: succeed to init lpddr3 rank0 dram phy INFO: lpddr3_freq_init, set ddrc 533mhz INFO: init ddr3 rank0 INFO: ddr3 rank1 init pass INFO: lpddr3_freq_init, set ddrc 800mhz INFO: init ddr3 rank0 INFO: ddr3 rank1 init pass INFO: Elpida DDR NOTICE: Enter fastboot mode...
I don't see the output related to the DDR initialization, instead I see the 'INFO: rdet ds fail'.
Just to be clear, this is in 'normal' mode (pin1-pin2 set).
If I connect the Debug UART while downloading the l-loader.bin (in recovery mode (pin1-pin2 and pin3-pin4 on J15 are set)) I get:
Switch to aarch64 mode. CPU0 executes at 0xf9801000! NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.1(release):1b9a4b277314 NOTICE: BL1: Built : 09:46:37, Nov 4 2015 NOTICE: syspll frequency:1190494208Hz NOTICE: succeed to init lpddr3 rank0 dram phy INFO: lpddr3_freq_init, set ddrc 533mhz INFO: init ddr3 rank0 INFO: rdet ds fail INFO: rdet ds fail
so in this case I don't see the messages indicating successful DDR initialization, like 'INFO: ddr3 rank1 init pass' and so on
Could you try another way for downloading l-loader.bin:
- Boot with recovery mode as usual (pin1-pin2 and pin3-pin4 on J15);
- UART will print below info: USB:: Err!! Unknown USB setup packet! NULL package USB:: Err!! Unknown USB setup packet! NULL package USB:: Err!! Unknown USB setup packet! NULL package
- Wait for about 1 minutes and don't send l-loader.bin;
- UART will print below info: usb data recieving 60s time out.... Switch to UART download...
- So now you can download l-loader.bin from Debug UART:
sudo python hisi-idt.py -d /dev/ttyUSB0 --img1=l-loader_DDR_533MHz.bin
Please note, here should use ttyUSB0 which is the Debug UART's device node but not ttyUSB2 for USB OTG port.
We can use this way to get rid of the potential impaction from USB connection.
Thanks, Leo Yan
On 05/11/15 01:55, Leo Yan wrote:
On Wed, Nov 04, 2015 at 07:30:45PM +0000, Dietmar Eggemann wrote:
On 04/11/15 19:12, Dietmar Eggemann wrote:
On 04/11/15 03:47, Leo Yan wrote:
On Tue, Nov 03, 2015 at 08:33:33PM +0000, Dietmar Eggemann wrote:
Hi Leo,
On 30/10/15 03:12, Leo Yan wrote:
Hi Dietmar,
On Thu, Oct 29, 2015 at 04:30:00PM +0000, Dietmar Eggemann wrote: > On 29/10/15 14:36, Dietmar Eggemann wrote: >> On 21/10/15 02:56, Leo Yan wrote:
[...]
Could you try another way for downloading l-loader.bin:
Boot with recovery mode as usual (pin1-pin2 and pin3-pin4 on J15);
UART will print below info: USB:: Err!! Unknown USB setup packet! NULL package USB:: Err!! Unknown USB setup packet! NULL package USB:: Err!! Unknown USB setup packet! NULL package
Wait for about 1 minutes and don't send l-loader.bin;
UART will print below info: usb data recieving 60s time out.... Switch to UART download...
So now you can download l-loader.bin from Debug UART:
sudo python hisi-idt.py -d /dev/ttyUSB0 --img1=l-loader_DDR_533MHz.bin
Please note, here should use ttyUSB0 which is the Debug UART's device node but not ttyUSB2 for USB OTG port.
We can use this way to get rid of the potential impaction from USB connection.
Loaded the l-loader_DDR_533MHz.bin via the Debug UART but same error behaviour on the board in question.
NOTICE: succeed to init lpddr3 rank0 dram phy INFO: lpddr3_freq_init, set ddrc 533mhz INFO: init ddr3 rank0 in 533MHz INFO: rdet ds fail INFO: rdet ds fail ...
Thanks,
-- Dietmar
On Wed, Nov 04, 2015 at 07:12:36PM +0000, Dietmar Eggemann wrote:
On 04/11/15 03:47, Leo Yan wrote:
On Tue, Nov 03, 2015 at 08:33:33PM +0000, Dietmar Eggemann wrote:
Hi Leo,
On 30/10/15 03:12, Leo Yan wrote:
Hi Dietmar,
On Thu, Oct 29, 2015 at 04:30:00PM +0000, Dietmar Eggemann wrote:
On 29/10/15 14:36, Dietmar Eggemann wrote:
On 21/10/15 02:56, Leo Yan wrote:
[...]
After burn image 'l-loader.bin', you can check PC side if dump below info:
leoy@leoy-linaro:~$ sudo dmesg -c [52045.180850] usb 1-1.1.3: USB disconnect, device number 46 [52045.181032] option1 ttyUSB1: GSM modem (1-port) converter now disconnected from ttyUSB1 [52045.181048] option 1-1.1.3:1.0: device disconnected [52045.393983] usb 1-1.1.3: new high-speed USB device number 47 using ehci-pci [52045.499062] usb 1-1.1.3: New USB device found, idVendor=18d1, idProduct=d00d [52045.499067] usb 1-1.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [52045.499069] usb 1-1.1.3: Product: Android 2.0 [52045.499071] usb 1-1.1.3: Manufacturer: Androi [52045.499072] usb 1-1.1.3: SerialNumber: 0123456789ABCDEF
Yeah, there is no dmesg output for the board in question but I can see this output using a fresh hikey board so I guess the l-loader.bin I built is OK.
leoy@leoy-linaro:~/Work/hisi/boot/l-loader$ sudo fastboot devices 0123456789ABCDEF fastboot
So that means it has prepared successfully for "fastboot", otherwise we can get to know 'l-loader.bin' has not successfully initialized protocol for "fastboot".
Yes, 'fastboot devices' is not working for the board in question where as it works fine for the fresh hikey board.
So for fresh hikey board, can burn fip.bin image successfully? And in normal mode, can boot successfully into UEFI?
[...]
Thanks, Leo Yan
On 05/11/15 01:38, Leo Yan wrote:
On Wed, Nov 04, 2015 at 07:12:36PM +0000, Dietmar Eggemann wrote:
On 04/11/15 03:47, Leo Yan wrote:
On Tue, Nov 03, 2015 at 08:33:33PM +0000, Dietmar Eggemann wrote:
Hi Leo,
On 30/10/15 03:12, Leo Yan wrote:
Hi Dietmar,
On Thu, Oct 29, 2015 at 04:30:00PM +0000, Dietmar Eggemann wrote:
On 29/10/15 14:36, Dietmar Eggemann wrote: > On 21/10/15 02:56, Leo Yan wrote:
[...]
So for fresh hikey board, can burn fip.bin image successfully? And in normal mode, can boot successfully into UEFI?
Yes. I can run your burn_boot_images.sh on it and it finishes successfully (like it did with the other board until Tuesday afternoon).
I don't have the Debug Uart on the fresh hikey board but I noticed that User LED switched from 0 to 1 & 3 being on. I was able to boot UEFI on the other board successfully until I ran into this DDR issue.
Thanks,
-- Dietmar
On Thu, Nov 05, 2015 at 11:12:52AM +0000, Dietmar Eggemann wrote:
On 05/11/15 01:38, Leo Yan wrote:
On Wed, Nov 04, 2015 at 07:12:36PM +0000, Dietmar Eggemann wrote:
On 04/11/15 03:47, Leo Yan wrote:
On Tue, Nov 03, 2015 at 08:33:33PM +0000, Dietmar Eggemann wrote:
Hi Leo,
On 30/10/15 03:12, Leo Yan wrote:
Hi Dietmar,
On Thu, Oct 29, 2015 at 04:30:00PM +0000, Dietmar Eggemann wrote: > On 29/10/15 14:36, Dietmar Eggemann wrote: >> On 21/10/15 02:56, Leo Yan wrote:
[...]
So for fresh hikey board, can burn fip.bin image successfully? And in normal mode, can boot successfully into UEFI?
Yes. I can run your burn_boot_images.sh on it and it finishes successfully (like it did with the other board until Tuesday afternoon).
I don't have the Debug Uart on the fresh hikey board but I noticed that User LED switched from 0 to 1 & 3 being on.
Looks like the fresh board can work well, could you firstly use this one and solder pins for Debug UART?
BTW, it's interesting for turning on LED 1 & 3, in ATF it will report panic with LED. In ATF, LED 1 & 3 (0xa) means a FIQ is triggered in ATF. This is not likely happend. Later kernel will enable it as CPU running indicators. But i don't know if UEFI will use it or not.
Just give more info at here, it's better you can check log after solder pins for Debug UART.
I was able to boot UEFI on the other board successfully until I ran into this DDR issue.
So far have no idea for this error; Looks like a hardware issue. Will loop in Guodong and Amit for further check in another mail.
Thanks, Leo Yan
On Thu, Oct 29, 2015 at 02:36:43PM +0000, Dietmar Eggemann wrote:
On 21/10/15 02:56, Leo Yan wrote:
Hi Dietmar,
On Tue, Oct 20, 2015 at 08:04:30PM +0100, Dietmar Eggemann wrote:
On 14/10/15 17:30, Leo Yan wrote:
Hi all,
Below are raw power data on Hikey board; with this power data i'd like to create the power model for Hikey.
- Measure method:
On Hikey board, we cannot measure buck1 which is dedicated for AP subsystem; so turned to measure VDD_4V2 to remove R247 and remount shunt resistor 470mOhm. At a result, the power data includes many other LDO's power data.
+--------------+ +-------------+ 4.2v | | Buck1 | |---- Shunt Resistor --->| PMIC: Hi6553 |------>| SoC: Hi6220 | ^ ^ | | | ACPU | | | +--------------+ +-------------+ |-> Energy Probe <-|
Measured raw data:
sys_suspend: AP system suspend state cluster_off: two clusters are powered off cluster_on: 1 cluster is powered on, all cpus are powered off cpu_wfi: 1 cluster is powered on, last cpu enters 'wfi' but other cpus are powered off voltage: voltage for every OPP
# OPP sys_suspend cluster_off cluster_on cpu_wfi cpu_on voltage 208 328 347 366 374 435 1.04 432 328 344 374 388 499 1.04 729 331 351 400 409 606 1.09 960 329 353 430 443 750 1.18 1200 331 365 486 506 988 1.33
Hikey Power ModelPower [mW] 500 ++--------+-------------+---------+---------++ cluster_off **A*** + + + + D cluster_on ##B### 450 ++.........................................%%+ cpu_wfi $$C$$$ 400 ++.......................................%%.++ cpu p-state %%D%%% | : : : %% | 350 ++...................................%%.....++ | : : :%% | 300 ++...............................%D.........++ 250 ++...........................%%%%...........++ | : : %%% : | 200 ++....................%%D%..................++ | : %%%%% : : | 150 ++...........%%%%...........................++ | %%D%% : : #####B 100 ++.%%%%%.....................#####B#####....++ 50 D%%..............#######B####...............++ A*********A*************A*********A**********A 0 C$$$$$$$$$C$$$$$$$$$$$$$C$$$$$$$$$C$$$$$----++ 208 432 729 960 1200 Frequency [MHz]
Hikey Power EfficiencyPower Efficiency [mW/MHz] Voltage [v] 0.45 ++-------+----------+--------+-------++ 3 Cluster Power **A*** + + + + + CPU Static Power ##B### 0.4 ++...................................$C CPU Dynamic power $$C$$$ | : : : $$$++ 2.5 Voltage %%D%%% 0.35 ++.............................$$$...++ | : : $$C$ | 0.3 C$$$$$$$$..............$$$$..........++ 2 | C$$$$$$$$$$C$$ : | 0.25 ++...................................++ 1.5 0.2 ++................................%%%%D | : : %%%%D%%%% | 0.15 D%%%%%%%%D%%%%%%%%%%D%%%%............++ 1 | : : : | 0.1 A********.........................****A | A**********A********A**** ++ 0.5 0.05 ++...................................++ B########B##########+ ####B########B 0 ++-------+----------B####----+-------++ 0 208 432 729 960 1200 Frequency [MHz]
- Power Model On Hikey:
According to before we have discussed for power model, i think below is the prefered power data for Hikey which calculated from raw power date:
static struct idle_state idle_states_cluster_a53[] = { { .power = 0 }, { .power = 0 }, };
/*
- Use (cluster_on - cluster_off) for every OPP
*/ static struct capacity_state cap_states_cluster_a53[] = { /* Power per cluster */ { .cap = 178, .power = 19, }, { .cap = 369, .power = 30, }, { .cap = 622, .power = 49, }, { .cap = 819, .power = 77, }, { .cap = 1024, .power = 121, }, };
/*
- Use (cpu_wfi - cluster_on) for every OPP, then calculate the
- average value for wfi's power data; But we can see actually
- the idle state of "WFI" will be impacted by voltage.
*/ static struct idle_state idle_states_core_a53[] = { { .power = 12 }, { .power = 0 }, };
/*
- Use (cpu_on - cluster_off) for every OPP
*/ static struct capacity_state cap_states_core_a53[] = { /* Power per cpu */ { .cap = 178, .power = 69, }, /* 208MHz */ { .cap = 369, .power = 125, }, /* 432MHz */ { .cap = 622, .power = 206, }, /* 729MHz */ { .cap = 819, .power = 320, }, /* 960MHz */ { .cap = 1024, .power = 502, }, /* 1.2GHz */ };
If have any questions or issues for upper energy model data, please let me know; Appreciate review and comments in advance.
Some other questions
Q1: Jian & Dan, voltage for 1.2GHz is quite high, could you help check the voltage table for OPPs, if there have any unexpected value?
Q2: Morten, if i want to do more profiling on EAS, do you suggest i should refer which branch now? I think now EASv5 patches are relative old, so want to check if we have better candidate or not.
Please continue to use EASv5 since we're still testing EASv5.1 (including SchedDvfs) on Juno board.
BTW, the issues you and Steve M. raised against 22/46 and 32/46 of RFCv5 seen on the Hikey board (SMP) haven't been addressed in RFCv5.1 yet.
Once we get the right results for the RFCv5 test cases on Juno for EASv5.1 (including SchedDvfs) we will share it on linux-arm.org.
Thanks for suggestion.
I've pushed EASv5.1 (including SchedDfvs and rebased to current /tip/sched/core (Linux 4.3-rc5)) to:
git://linux-arm.org/linux-power.git energy_model_rfc_v5.1
Thanks for sharing this. I have finished round4 profiling on Hikey with EASv5, and gathered power data for it. So in next several days i will send out the slides for review, and also will summary the measurement tools, automatic testing method at my side, power modeling method on Hikey, and the power comparasion for EASv5.
After i finish these summaries, i'd like to get your suggestion for next step, whether need switch to EASv5.1 ASAP or still need stick to EASv5 for following questions.
The problem I saw on JUNO board (too much packing on one cpu forcing the system into over-utilized state which then spread the tasks among the little cpus and this process repeating itself over and over again leading to bad performance numbers was down to CONFIG_SCHED_AUTOGROUP=y). So make sure it's not enabled.
Thanks for reminding.
Acutally i have took some time to port EASv5.1 patches on my own branch, it's quite smooth to apply these patches. And i tried to port Juri and Mike's patches for SchedDVFS, there have several conflicts need to manually fix based on EASv5.1.
Anyway, i will go back to use EASv5 for power profiling. Suppose i can get some profiling result and send out for review in next 1~2 weeks :)
The way we present indexes into the 'struct idle_state' vectors has changed between 5 and 5.1. have a look into the JUNO energy model and static int group_idle_state(struct sched_group *sg).
Yes, i have noticed that. And i think this is one thing i should focus on firstly.
Thanks, Leo Yan
On Thu, Oct 15, 2015 at 12:30:36AM +0800, Leo Yan wrote:
Hi all,
Below are raw power data on Hikey board; with this power data i'd like to create the power model for Hikey.
- Measure method:
On Hikey board, we cannot measure buck1 which is dedicated for AP subsystem; so turned to measure VDD_4V2 to remove R247 and remount shunt resistor 470mOhm. At a result, the power data includes many other LDO's power data.
+--------------+ +-------------+ 4.2v | | Buck1 | |---- Shunt Resistor --->| PMIC: Hi6553 |------>| SoC: Hi6220 | ^ ^ | | | ACPU | | | +--------------+ +-------------+ |-> Energy Probe <-|
Just reminding and correct one thing at here. If you are using ARM energy probe, there have limitation for "voltage between the two sense leads, limited to 165mV" (quoted from Andy's slides arm-energy-probe-101.pdf), so should change to use 33mOhm resistor.
Otherwise, when 8 CPUs run at high OPP (such like 960Mhz or 1.2GHz), it's very easily to reach the measurement limitation. Using 33mOhm will have no this issue.
[...]
Thanks, Leo Yan
Hi all,
Because email is hard to explain EAS profiling and power modeling on Hikey, so i used one slides to do this:
https://docs.google.com/presentation/d/1WKIHQRLzbkucBwc2wL1s0se7c6UI4iJHWIDz...
But we still can use this thread for related discussion. So far i think there still have questions need to dig further more, and the power profiling is big workload, so suggetion is always welcome.
Thanks, Leo Yan
On Tue, Nov 03, 2015 at 11:04:17AM +0800, Leo Yan wrote:
Hi all,
Because email is hard to explain EAS profiling and power modeling on Hikey, so i used one slides to do this:
https://docs.google.com/presentation/d/1WKIHQRLzbkucBwc2wL1s0se7c6UI4iJHWIDz...
Shared one offline copy, in cases some guys cannot access it. Later if there have updates for this slides, also will update the offline slides.
http://people.linaro.org/~leo.yan/EAS_Profiling_On_Hikey.pdf
But we still can use this thread for related discussion. So far i think there still have questions need to dig further more, and the power profiling is big workload, so suggetion is always welcome.
Thanks, Leo Yan
-
Dietmar Eggemann -
Leo Yan