Op 12 mei 2014, om 09:19 heeft Hans de Goede <[email protected]> het volgende geschreven:
> Hi, > > On 05/12/2014 09:16 AM, Koen Kooi wrote: >> >> Op 11 mei 2014, om 22:43 heeft Hans de Goede <[email protected]> het >> volgende geschreven: >> >>> Hi, >>> >>> On 05/11/2014 11:53 AM, Siarhei Siamashka wrote: >>>> It has been confirmed that a substantial percentage of cubieboard2 >>>> and cubietruck users are having stability issues. These issues are >>>> caused by having various voltages optimistically configured way too >>>> low. Because each unit has its own tolerances, not everyone can >>>> easily reproduce these problems. >>>> >>>> To address the issue, we take the updated settings from: >>>> >>>> https://github.com/cubieboard/cubie_configs/tree/09e511721697/sysconfig/linux >>>> This repository is relevant because it is referenced from: >>>> >>>> http://docs.cubieboard.org/tutorials/ct1/development/compiling_latest_kernel_for_cubietruck_cubieboard3 >>>> Please note that there is also a sunxi-boards repository fork at >>>> https://github.com/cubieboard (with bad settings) and this makes >>>> things more confusing than necessary. >>>> >>>> Signed-off-by: Siarhei Siamashka <[email protected]> >>>> --- >>>> sys_config/a20/cubieboard2.fex | 18 +++++++++--------- >>>> sys_config/a20/cubietruck.fex | 16 ++++++++-------- >>>> 2 files changed, 17 insertions(+), 17 deletions(-) >>>> >>>> diff --git a/sys_config/a20/cubieboard2.fex >>>> b/sys_config/a20/cubieboard2.fex >>>> index 1436df8..c8c9c74 100644 >>>> --- a/sys_config/a20/cubieboard2.fex >>>> +++ b/sys_config/a20/cubieboard2.fex >>>> @@ -1,14 +1,14 @@ >>>> [product] >>>> version = "100" >>>> -machine = "cubieboard" >>>> +machine = "cubieboard2" >>>> >>>> [platform] >>>> eraseflag = 0 >>>> >>>> [target] >>>> boot_clock = 912 >>>> -dcdc2_vol = 1400 >>>> -dcdc3_vol = 1250 >>>> +dcdc2_vol = 1450 >>> >>> This makes no sense, since in the dvfs table there is: >>> max_freq = 912000000 >>> >>> LV2_freq = 912000000 >>> LV2_volt = 1425 >>> >>> S0 1.425 volt would make a lot more sense. Also Page 31 >>> of A20+Datasheet+v1.0+20130227.pdf says that the MAX >>> CPU and systemvoltage is 1425 volts. So what this patch >>> effectively does is overvolt the CPU cores and base system. > > UGH, typo from my side, the data sheet says max voltage is 1.400 > >> Keep in mind that the voltage you set is the for for the output pin of the >> PMIC, *not* the input pin on the CPU. And since this is a 'performance' >> operating point, the voltage might sag under load. >> When I was adding 1GHz support to the beagleboneblack DTS the TI hardware >> team recommended a 2% safety margin, so to get 1425mV into the CPU you need >> to configure the PMIC for 1425*102% -> 1453mV. >> I haven't looked at cubieboard schematic nor do I know how accurate the PMIC >> is, but I wouldn't call this 2% 'overvolting', I'd call it a 'safety margin.' > > Ah interesting, so assuming things are similar for the A10 / > A20 this would mean that 1.425 volt on the pmic > output pin would lead to ~ 1.400 V on the SoC input pin, which > is exactly up to spec. > > Thanks for the insight! My argument is very close to "proof by vigorous handwaving", so take it with a grain of salt :) With the original beagleboard we could brute-force solve it due to the volume of boards and the silicon vendor and board manufacturer working closely together. Having access to the RMA'd boards is a great help, having a known 'weak' CPU to test on is invaluable. Dialing in operating points is hard and it always ends up in trial&error mode. regards, Koen > > Regards, > > Hans -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
