willmore Posted March 15, 2017 Posted March 15, 2017 I just did an apt-get update on the mainline version of armbian and now the machine won't boot. I'l looking at the uboot output and it appears not to load the full kernel in and boot it. The strange thing is it seems to hang, but when I unplug the power, the kernel load info shows up on the serial output. U-Boot SPL 2017.03-armbian (Mar 15 2017 - 06:57) DRAM: 512 MiB Trying to boot from MMC1 U-Boot 2017.03-armbian (Mar 15 2017 - 06:571 +0100) Allwinner Technology CPU: Allwier H3 (SUN8I 1680) Model: Xunlong Orange Pi Zero DRAM: 512 MiB MMC: SUNXI SD/MMC0 *** Warning - bad CRC, usig default environment r serialial Net: phy interface0 eth0: ethernet@1c30000 Hit any key to stop autoboot: 0 switch to partitions #0, OK.1 KiB/s) mmc0 is current device Scanning mmc 0 After I unplug the power I also get: ... Found U-Boot script /boot/boot.scr 2092 bytes read in 216 ms (8.8 KiB/s) ## Executing script at 43100000 Booting from SD 114 bytes read in 185 ms (0 Bytes/s) 5084171 bytes read in 535 ms (9.1 MiB/s) 5720128 bytes read in 579 ms (9.4 MiB/s) 0 byt Any suggestions? I can always reimage the uSD card with a new version. But it might be useful to know what went wrong.
zador.blood.stained Posted March 15, 2017 Posted March 15, 2017 8 minutes ago, lanefu said: Did you build the image with a VM or a container? I think this 1 hour ago, willmore said: I just did an apt-get update on the mainline version of armbian and now the machine won't boot. means that he most likely used a prebuilt nightly image and upgraded it from the repository. Anyway missing characters in the logs don't look good. Maybe voltage regulator or CPU frequency limits were lost during u-boot patches upgrade and now the board is undervolted/overclocked. I'll check the commits later. Edit: CPU frequency limit and CVBS output settings was lost, I'll add a patch to fix this. 2
zador.blood.stained Posted March 15, 2017 Posted March 15, 2017 I pushed the patch so next nightly and packages in beta repository should have the fix. @willmore you'll have to extract the u-boot binary from the appropriate package (default for the legacy kernel or dev for the mainline kernel) and reflash the u-boot binary to the SD card. If this fixes the issue for you maybe MoeIcenowy should be pinged about this (since she is the maintainer for the OPi Zero u-boot defconfig) u-boot packages: u-boots-opizero.zip Edit: According to the schematic CPU on Zero should be powered with 1.3V by default, so it shouldn't be an undervoltage? Edit 2: At least my board is powered with 1.3V by default 2
willmore Posted March 15, 2017 Author Posted March 15, 2017 Okay, I will test tomorrow. Thank you for all of your work!
zador.blood.stained Posted March 15, 2017 Posted March 15, 2017 Also the DT file needs to be renamed from sun8i-h2plus-orangepi-zero.dtb to sun8i-h2-plus-orangepi-zero.dtb, so it's even possible that this change broke your system and serial console issues are related to something else and don't really affect the system.
krasoffski Posted March 15, 2017 Posted March 15, 2017 Previously 1.3v was used only for high CPU freq like 1200 or 1008 Mhz. In other cases it can be problem with overheating. @tkaiser
tkaiser Posted March 15, 2017 Posted March 15, 2017 25 minutes ago, krasoffski said: Previously 1.3v was used only for high CPU freq like 1200 or 1008 Mhz. Here it's about board bring up. Which voltage is the SoC being fed with if no software started to control anything? Zero can switch between 1.1V and 1.3V but there's a default state when powering up and control is later turned over to software which then decides based on clockspeed which voltage to chose (remaining at 1.1V with lower clockspeeds and switching to 1.3V when exceeding 816MHz -- mainline -- or 912MHz -- legacy) Edit: to elaborate on that a bit (and to stand corrected if necessary and also to add stuff to @zador.blood.stained's TODO list ): So the board's VDD_CPUX voltage is 1.3V when the board boots regardless of clockspeed set anywhere (what's happening when a 'reboot' has been issued before?). This should prevent any undervoltage issues at boot. Next step is booting u-boot, here a static cpufreq will be set (either u-boot default, IIRC 1008 MHz with sun8i, or in our case it's 480 MHz -- we chose this value since we prefer minimum consumption over boot duration) Next step is booting the kernel, with H2+/H3 legacy kernel here the userspace governor is set so the board remains at 480 MHz clockspeed while with mainline kernel schedutil governor takes over and results are not really predictable, at least now CPU cores might clock up to the highest limit allowed with sun8i dev kernel -- what's the value? 1296 MHz? -- and since DVFS is now active voltage starts to jump between 1.1V and 1.3V based on cpufreq) As soon as cpufreq-utils daemon is started it looks really weird since now we switch with legacy kernel from userspace to interactive governor while with mainline from schedutil to ondemand (everything ok, interactive is the better choice with legacy and we switched just recently to ondemand due to some strange reports regarding schedutil). From now on maximum cpufreq can be set by the user (h3consumption tool or /etc/defaults/cpufrequtils -- defaults for large H3 boards 1296MHz, for smaller H3 boards 1200 MHz and for NanoPi NEO/Air 912 MHz) DVFS settings switch voltage above 816MHz with mainline (since that's defined in official DT for Orange Pi One which we use for the Zero) and above 912MHz with legacy since after some extensive internal testing we don't give a sh*t about Allwinner's recommended defaults and let a few thousand Armbian H2+/H3 board users do some reliability testing in the field For me personally questions 1 and 3 are interesting. What happens at reboot and what's maximum cpufreq with sun8i dev kernel before cpufrequtils daemon is loaded? And then I would propose to switch to userspace governor in sun8i dev kernel config too for obvious reasons (we discussed this back then when developing IoT settings for the smaller H3 boards and my tests revealed that boot times for the large boards aren't affected that much since their boot clockspeed in N° 2 above is 1008MHz and not 480MHz). Also I would prefer to switch voltages with mainline kernel on the primitive H3/H2+ board also above 912MHz and not 816MHz any more to get more test feedback for mainline DVFS implementation. But no need to hurry, opinions first! 3
zador.blood.stained Posted March 15, 2017 Posted March 15, 2017 1 hour ago, tkaiser said: (what's happening when a 'reboot' has been issued before?) Depends on whether reset affects the pin controller. Most likely it is reset too, so Zero switches back to 1.3V 1 hour ago, tkaiser said: And then I would propose to switch to userspace governor in sun8i dev kernel config too for obvious reasons (we discussed this back then when developing IoT settings for the smaller H3 boards and my tests revealed that boot times for the large boards aren't affected that much since their boot clockspeed in N° 2 above is 1008MHz and not 480MHz). Agree 1 hour ago, tkaiser said: Also I would prefer to switch voltages with mainline kernel on the primitive H3/H2+ board also above 912MHz and not 816MHz any more to get more test feedback for mainline DVFS implementation. Obviously needs testing, which is a bit time consuming (preparing and running xhpl on as many different boards as possible with fixed frequency)
tkaiser Posted March 15, 2017 Posted March 15, 2017 6 minutes ago, zador.blood.stained said: Obviously needs testing, which is a bit time consuming (preparing and running xhpl on as many different boards as possible with fixed frequency) Hmm... maybe I'm missing something. But I believe that we're talking about 816 vs 912 legacy/mainline? Or does voltage switching happen at the same clockspeed and it's just different notation in fex vs. DT? Anyway: @ErwinHcame up with https://github.com/ehoutsma/StabilityTester for H5 testing, so all that's needed is the same with a statically linked xhpl32 binary? And then I would focus more on oscillating cpufreq than static/fixed. Since I would assume there might be timing problems also?
willmore Posted March 15, 2017 Author Posted March 15, 2017 @zador.blood.stained, are you refering to running StabilityTester on a large number of boards at a series of fixed clock speeds and voltages? I'd like to do this for the boards I have. Would the Sunxi-linux wiki be a good place to collect the results?
zador.blood.stained Posted March 15, 2017 Posted March 15, 2017 8 minutes ago, willmore said: @zador.blood.stained, are you refering to running StabilityTester on a large number of boards at a series of fixed clock speeds and voltages? Yes (already forgot about precompiled binaries), but at 912MHz/1.1v operating point specifically (and making sure it doesn't throttle down if it gets to the point of overheating even if it shouldn't do it) 8 minutes ago, tkaiser said: Hmm... maybe I'm missing something. But I believe that we're talking about 816 vs 912 legacy/mainline? Or does voltage switching happen at the same clockspeed and it's just different notation in fex vs. DT? I don't remember what settings do we have for the legacy kernel, so in case it's already used on legacy it should be safe to use. But we could also test to find how far we can push the frequency on 1.1V until it reaches the point of instability (I don't remember if this already was tested before and don't see these kind of tests on the wiki)
zador.blood.stained Posted March 15, 2017 Posted March 15, 2017 15 minutes ago, willmore said: are you refering to running StabilityTester on a large number of boards at a series of fixed clock speeds and voltages? Also this is arm64 xhpl so we'll need to make armhf one if we want to make these tests.
tkaiser Posted March 15, 2017 Posted March 15, 2017 3 minutes ago, zador.blood.stained said: already forgot about precompiled binaries Well, we need a custom build (OpenBLAS, NEON optimizations) since Debian/Ubuntu hpl packages are an insane bad joke. In the meantime I was able to switch on my brain and propose now the opposite than before I remembered having different thermal behaviour with NanoPi NEO based on USB cable used to power. Crappy cable --> lower temperatures, 20AWG rated cable --> higher temperatures. That would indicate voltage regulation dependent on input voltage (I collected material to create another annoying forum post but it's lost somewhere here on my laptop). So first step would be a simple test whether variable input voltage (using a bench PSU) changes VDD_CPUX on testpoints. If we identify boards where that's the case then it's time to overthink the whole approach and instead lower switching clockspeed for these boards from 912MHz to 816MHz with legacy. All my NanoPi and the OPi with primitive voltage regulators are dev samples (so PCB rev 1.0 or below) so it's useless if I test -- users with recently bought boards should do this (am I'm the only one thinking of @willmorenow? )
willmore Posted March 15, 2017 Author Posted March 15, 2017 Okay, you want me to do a custom (from source) build of xhpl. Then you want me to instrument a recently purchased Orange Pi Zero with a meter on the CPU voltage line and a bench power supply. Then you want me to run xhpl at a series of fixed clock speeds and measure the voltages/temperatures/currents? I'm good on all of that but I may need some hand holding on how to do the fixed clock speed and on how to tell if there is throttling occuring.
zador.blood.stained Posted March 15, 2017 Posted March 15, 2017 2 minutes ago, tkaiser said: So first step would be a simple test whether variable input voltage (using a bench PSU) changes VDD_CPUX on testpoints. Not so simple. How much variable voltage? I don't know which board I am ready to burn yet. Voltage difference may also depend on current, so we have to test at idle and with some load like sysbench. DRAM voltage differences may also affect temperature and stability
tkaiser Posted March 15, 2017 Posted March 15, 2017 9 minutes ago, zador.blood.stained said: Voltage difference may also depend on current, so we have to test at idle and with some load like sysbench. I believe that's the most important first step. Simply use a bench PSU with 4.6V and later 5.2V, adjust cpufreq to 816MHz (editing /etc/defaults/cpufrequtils followed by '/etc/init.d/cpufrequtils restart'), measure idle VDD_CPUX, then start the usual sysbench and measure again. Then switch PSU voltage and try again. Same test then with 912 MHz. If VDD_CPUX varies more than ~30mV we can already stop and lower switching cpufreq with legacy settings. NanoPis also need testing (hey, that's the first time I like BPi M2+ since broken/no voltage regulation --> no need to test!)
kutysam Posted March 16, 2017 Posted March 16, 2017 8 hours ago, zador.blood.stained said: Also the DT file needs to be renamed from sun8i-h2plus-orangepi-zero.dtb to sun8i-h2-plus-orangepi-zero.dtb, so it's even possible that this change broke your system and serial console issues are related to something else and don't really affect the system. My opi also bricked. And it's due to this change. Uboot via serial stated that it can't find the mentioned file above. Btw could I have the link for the GitHub repo for these changes too!
mbee Posted September 1, 2017 Posted September 1, 2017 Hi, It seems this is an issue with the latest mainline nightly available for download as well. It seems the orange pi zero is stuck at 480MHz (or so). When running minerd --benchmark with mainline I only get half of the performance I get when downloading and running the legacy image. Anyone else noticed this? regards,
raschid Posted September 1, 2017 Posted September 1, 2017 @mbee, mainline cpufreq scaling is still broken for the orange pi zero. Currently there is no support for DVFS in the zeros DTS (no operating points, no cpu voltage regulator def, no thermal stuff). U-boot sets cpu freq to 480MHz and that's it.
mbee Posted September 2, 2017 Posted September 2, 2017 On 9/1/2017 at 7:52 PM, raschid said: @mbee, mainline cpufreq scaling is still broken for the orange pi zero. Currently there is no support for DVFS in the zeros DTS (no operating points, no cpu voltage regulator def, no thermal stuff). U-boot sets cpu freq to 480MHz and that's it. Ahh ok, Thank you. It seems that the voltage regulator on the zero is supported (its just GPIO) and it has the same regulator as one the orangepi-one. So it should just be a matter of adapting that from the orangepi-one dts and to add DVFS and higher speed to the zero as well. It's a bit odd that this has not been done but it seems to be implemented on later kernel version. Thank for your answer! regards, 1
Igor Posted September 3, 2017 Posted September 3, 2017 11 hours ago, mbee said: It's a bit odd that this has not been done but it seems to be implemented on later kernel version. Basic characteristic from the kernel in development is that things are missing and regressions are possible. Linux kernel and Armbian are community projects, a common work. If all would only wait that things are fixed, they never are or very late: https://docs.armbian.com/Process_Contribute/ 1
mbee Posted September 3, 2017 Posted September 3, 2017 11 hours ago, Igor said: Basic characteristic from the kernel in development is that things are missing and regressions are possible. Linux kernel and Armbian are community projects, a common work. If all would only wait that things are fixed, they never are or very late: https://docs.armbian.com/Process_Contribute/ Hi Igor, Yes completely understandably. I just meant odd in the sense that it's look to be more of a copy paste from opione. I will have a look and see if I can get it going and contribute. regards, 1
Igor Posted September 3, 2017 Posted September 3, 2017 7 minutes ago, mbee said: I just meant odd in the sense that it's look to be more of a copy paste from opione. You are welcome! Those boards (Zero and One) are very similar and configuration copy paste is usually the first step. Adjusting to hardware diff/reality is a next one.
raschid Posted September 4, 2017 Posted September 4, 2017 the following patch fixes cpufreq for the Orange Pi Zero, Mainline 4.11.12. @mbee, to give it a try save it as e.g. "orangepi-zero-add-cpufreqscaling.patch" and place it in build/userpatches. Don't forget to freeze the kernel version in armbian-config to avoid loosing this functionality when running apdate/upgrade. This patch also fixes some temperature issues since the CPU is not fed 1.3V all the time. My OPiZ is right now idling happily at 30 deg (21 deg ambient temp). Armbianmonitor now reports the current cpu-freq. @igor, please consider to include this patch. diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts index 69b4a35..506c462 100644 --- a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts +++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts @@ -50,10 +50,11 @@ #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/input/input.h> #include <dt-bindings/pinctrl/sun4i-a10.h> +#include <dt-bindings/thermal/thermal.h> / { model = "Xunlong Orange Pi Zero"; - compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h2-plus"; + compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h3"; aliases { serial0 = &uart0; @@ -94,6 +95,77 @@ reset-gpios = <&r_pio 0 7 GPIO_ACTIVE_LOW>; post-power-on-delay-ms = <200>; }; + + vdd_cpux: gpio-regulator { + compatible = "regulator-gpio"; + regulator-name = "vdd-cpux"; + regulator-type = "voltage"; + regulator-boot-on; + regulator-always-on; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1300000>; + regulator-ramp-delay = <50>; /* 4ms */ + gpios = <&r_pio 0 6 GPIO_ACTIVE_HIGH>; + gpios-states = <0x1>; + states = <1100000 0x0 + 1300000 0x1>; + }; +}; + +&cpu0 { + operating-points = < + 1008000 1300000 + 816000 1100000 + 624000 1100000 + 480000 1100000 + 312000 1100000 + 240000 1100000 + 120000 1100000 + >; + #cooling-cells = <2>; + cooling-min-level = <0>; + cooling-max-level = <6>; + cpu0-supply = <&vdd_cpux>; +}; + +&cpu_thermal { + trips { + cpu_warm: cpu_warm { + temperature = <65000>; + hysteresis = <2000>; + type = "passive"; + }; + cpu_hot: cpu_hot { + temperature = <75000>; + hysteresis = <2000>; + type = "passive"; + }; + cpu_very_hot: cpu_very_hot { + temperature = <90000>; + hysteresis = <2000>; + type = "passive"; + }; + cpu_crit: cpu_crit { + temperature = <105000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + + cooling-maps { + cpu_warm_limit_cpu { + trip = <&cpu_warm>; + cooling-device = <&cpu0 THERMAL_NO_LIMIT 1>; + }; + cpu_hot_limit_cpu { + trip = <&cpu_hot>; + cooling-device = <&cpu0 2 3>; + }; + cpu_very_hot_limit_cpu { + trip = <&cpu_very_hot>; + cooling-device = <&cpu0 5 THERMAL_NO_LIMIT>; + }; + }; }; &ehci0 { 1
Igor Posted September 4, 2017 Posted September 4, 2017 Check tomorrow's beta build ... but expect that we soon move to 4.13, where this might be broken or need to be adjusted again ... @raschid Thanks!
raschid Posted September 4, 2017 Posted September 4, 2017 @Igor, sorry, I misspelled "patch" in my original post and I think you copy&pasted that typo when uploading the patch. 1
Recommended Posts