dolphs

After reading these promising results I fired up my enigines and compiled a new dev image " Armbian_5.78_Orangepioneplus_Debian_stretch_dev_5.0.7 " . As I am still waiting the SDCARD to be prepared I am replying to these this is quite " funny " as that makes two of us, I actually disabled NetworkManager as I thought this was the issue and besides that I am used to editing in to " interfaces "... is this our guy who silently fixed stuff committing/updating a patch? if so KUDO's now it is time to insert my freshly built sdcard image in to the OpiOnePlus... setting root password, do absolutely nothing else than creating another login account and after that executing a " reboot " ( shutdown -r now ) on the command line It looks like the shutdown takes longer than before, eg red light goes off a little later, however I can be mistaken as it is like 05.15am here It all looked promising till the moment I realise the result improved somewhat having a red light back and an orange blining LAN light, with sometimes green popping up , BUT: unable to access remotely ( SSH )... Thus .... back to powercycling device ... perhaps the newer U-Boot v2019.04 might be of help after all as currently it is still 01 ... Almost there, but not just yet as @martinayotte which means the ghost happily resides now in my machine ... cheers :-), we're close ... let's stay positive and off to bed now ... ...

which means, once I will return home I can rebuild image and give it another shot on mu opioneplus devices? cheers

Errr from " H6 famous reboot problem " it seems just the orangepi's are affected (opioneplus and opilite2, opi3 )? reiniting eth0 did work from cold boot ( of course ): root@orangepioneplus:~# ip link set dev eth0 down && ip link set dev eth0 up Apr 11 05:05:48 localhost kernel: [ 425.696366] dwmac-sun8i 5020000.ethernet eth0: Link is Down Apr 11 05:05:48 localhost kernel: [ 425.705231] RTL8211E Gigabit Ethernet stmmac-0:01: attached PHY driver [RTL8211E Gigabit Ethernet] (mii_bus:phy_addr=stmmac-0:01, irq=POLL) Apr 11 05:05:48 localhost kernel: [ 425.707898] dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found Apr 11 05:05:48 localhost kernel: [ 425.707918] dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available Apr 11 05:05:48 localhost kernel: [ 425.707930] dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW Apr 11 05:05:53 localhost kernel: [ 430.819302] dwmac-sun8i 5020000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx so after that I thought to be fresh and smart but naye: no joy, bringing in a WiFi dongle should help possibly to get more logs at this stage ... ... root@orangepioneplus:~# ip link set dev eth0 down && reboot

@t3l3m4k0 OK thanks for sharing that with us, so I am not the only one struggling. Will check back tomorrow for more updates, thanks all!

debian NOK, no go after reboot... " tail -f /var/log/messages " did not report anything after executing reboot wil do another attempt in next 1-2 hours... UPDATE: session 1, logged in as ROOT session 2, logged in as ROOT and watching dmesg like a hawk root@orangepioneplus:~# watch -n1 "dmesg | tail -20" Every 1.0s: dmesg | tail -20 orangepioneplus: Wed Apr 10 18:40:16 2019 [ 8.650903] zram1: detected capacity change from 0 to 519761920 [ 8.885526] Adding 507576k swap on /dev/zram1. Priority:5 extents:1 across:507576k SSFS [ 8.891518] thermal thermal_zone0: failed to read out thermal zone (-16) [ 8.891582] thermal thermal_zone1: failed to read out thermal zone (-16) [ 8.958035] cpu cpu0: Linked as a consumer to regulator.3 [ 8.958075] cpu cpu0: Dropping the link to regulator.3 [ 8.958248] cpu cpu0: Linked as a consumer to regulator.3 [ 8.959047] cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 912000 KHz [ 8.959571] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed to: 1080000 KHz [ 8.959812] thermal thermal_zone0: failed to read out thermal zone (-16) [ 9.266006] random: crng init done [ 9.266014] random: 7 urandom warning(s) missed due to ratelimiting [ 9.279440] zram0: detected capacity change from 0 to 52428800 [ 9.711854] EXT4-fs (zram0): mounted filesystem without journal. Opts: discard [ 16.681299] RTL8211E Gigabit Ethernet stmmac-0:01: attached PHY driver [RTL8211E Gigabit Ethernet] (mii_bus:phy_addr=stmmac-0:01, irq=POLL) [ 16.682480] dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found [ 16.682490] dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available [ 16.682494] dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW [ 21.792787] dwmac-sun8i 5020000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx [ 21.792818] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Executed " reboot " in session 1, but no trace of dmesg As mentioned earlier unfortunately I do not owe a " USB To TTL Serial UART STC Cable " yet and also tried HDMI output but no output to screen either. Perhaps I can mount a USB stick and store a particular log file to it, so after reboot ( powercycle ) it can be opened for review ... not sure at this stage what to do .... Meanwhile should we compare photos from several OPiOnePlus boards so we can determine if other revision ( eg v1.1 ) have been releases and that is why things work slightly different? Would be interested in @@lex findings, currently thinking of disabling neworkmanager as mentioned once here by @johanvdw. Will give it a shot and will report back once more UPDATE: negative disabling networkmanager and updating it to " static " with "hwaddress ether" reboot #NOK ip link set eth0 down && reboot #neither - just another attempt Well guess that is it for now, perhaps new inspiration tomorrow. Almost forgot output of dmesg on powercycle, reboot I cannot capture... root@orangepioneplus:~# dmesg |grep ethernet [ 1.960862] dwmac-sun8i 5020000.ethernet: PTP uses main clock [ 2.070417] dwmac-sun8i 5020000.ethernet: PTP uses main clock [ 2.070476] dwmac-sun8i 5020000.ethernet: Linked as a consumer to regulator.19 [ 2.176334] dwmac-sun8i 5020000.ethernet: Current syscon value is not the default 58000 (expect 50000) [ 2.176353] dwmac-sun8i 5020000.ethernet: No HW DMA feature register supported [ 2.176358] dwmac-sun8i 5020000.ethernet: RX Checksum Offload Engine supported [ 2.176363] dwmac-sun8i 5020000.ethernet: COE Type 2 [ 2.176367] dwmac-sun8i 5020000.ethernet: TX Checksum insertion supported [ 2.176372] dwmac-sun8i 5020000.ethernet: Normal descriptors [ 2.176377] dwmac-sun8i 5020000.ethernet: Chain mode enabled [ 9.444966] dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found [ 9.444977] dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available [ 9.444983] dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW [ 14.560771] dwmac-sun8i 5020000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx

err I did put https://dl.armbian.com/orangepi3/nightly/ for OpiOnePlus: https://dl.armbian.com/orangepioneplus/nightly/ hope this is clear now

reboot issue, please check here for me was NOK so far, both stretch and bionic. You might want to try the nightly build, to be found here and report back in this section please rgd reboot issue, although I tested things building from scratch ( opiplus ) I did not test the nightly but for me so far NOK cheers!

built just now another " Armbian_5.78_Orangepioneplus_Debian_stretch_dev_5.0.7.img " server image and initial boot OK: - red light on - LAN blinking root@orangepioneplus:~# uname -a Linux orangepioneplus 5.0.7-sunxi64 #5.78 SMP Wed Apr 10 02:44:21 CEST 2019 aarch64 GNU/Linux root@orangepioneplus:~# shutdown -r now I can actually see the red light switches off for a while, which appears to me the "reboot" is kickin in, but little later it appears LAN does not come up... As I dont have a " USB To TTL Serial UART STC Cable " yet I tried the HDMI output instead which reveals no output to screen ( also not after power cycling the device: WIP I suppose ). Yet I will await the nightly image, although I do not expect miracles to happen as what would be the different from images just built ....

OK will rebuild image within next 30 minutes and will report back ( although it seems things applied succesfully ) UPDATE1: NO GO ... Built and flashed " Armbian_5.78_Orangepioneplus_Debian_stretch_dev_5.0.7.img " Powering down/up brings back my board. UPDATE 2: NO GO.... This lets me believe I should refresh my build environment entirely and start from scratch as "dreddit" reported a succesfull reboot earlier ? although initially I thoughy that image came from https://dl.armbian.com/ I didn't find a build later than 2018-08-23 ... Must be using my spectacles, meanwhile prepping my new fresh build environment. UPDATE 3: NO GO.... Tried my 2nd board with another sdcard and experience similar issues ... Acquired these boards few weeks back, another revision ? Last, but not least. also would one be so kind to eg WeTransfer a working fresghly built image, just to verify it does (not) work (PM)? cheers

just in these I retrieved entries: dolphs@armbian:~/armbian/output/debug$ grep 0001-Fix *.log output.log:Displaying message: * [\e[32ml\e[0m][\e[32mc\e[0m] 0001-Fix-reset-issue-on-H6-by-using-R_WDOG.patch info patching.log:Processing file /home/dolphs/armbian/patch/atf/atf-sunxi64/0001-Fix-reset-issue-on-H6-by-using-R_WDOG.patch The Patching log reads: Processing file /home/dolphs/armbian/patch/atf/atf-sunxi64/0001-Fix-reset-issue-on-H6-by-using-R_WDOG.patch Processing file /home/dolphs/armbian/patch/atf/atf-sunxi64/enable-additional-regulators.patch The text leading up to this was: -------------------------- |diff --git a/plat/sun50iw1p1/sunxi_power.c b/plat/sun50iw1p1/sunxi_power.c |index a2ded04..75574b9 |--- a/plat/sun50iw1p1/sunxi_power.c |+++ b/plat/sun50iw1p1/sunxi_power.c -------------------------- No file to patch. Skipping patch. 2 out of 2 hunks ignored <snip snip> Did not see any additional logs after, perhaps that is a lead? Processing file /home/dolphs/armbian/patch/atf/atf-sunxi64/0001-Fix-reset-issue-on-H6-by-using-R_WDOG.patch

just compiled fresh full OS image ( Armbian_5.78_Orangepioneplus_Debian_stretch_dev_5.0.7.img ) but alas " reboot " hangs, so therefore my guess is I was too early and will wait another few days building from scratch, thanks for your efforts! :~/armbian/patch/atf/atf-sunxi64$ ls -la total 36 drwxrwxr-x 4 dolphs dolphs 4096 Apr 9 16:32 . drwxrwxr-x 5 dolphs dolphs 4096 Mar 11 00:03 .. -rw-r--r-- 1 root root 902 Apr 9 16:32 0001-Fix-reset-issue-on-H6-by-using-R_WDOG.patch -rw-rw-r-- 1 dolphs dolphs 1112 Mar 11 00:03 add-SRAM-mapping-for-SCPI.patch.disabled drwxrwxr-x 2 dolphs dolphs 4096 Apr 9 16:32 board_pine64so drwxrwxr-x 2 dolphs dolphs 4096 Mar 11 00:03 board_pinebook-a64 -rw-rw-r-- 1 dolphs dolphs 1079 Mar 11 00:03 enable-a53-errata-workaround.patch.disabled -rw-rw-r-- 1 dolphs dolphs 1315 Mar 11 00:03 enable-additional-regulators.patch -rw-rw-r-- 1 dolphs dolphs 525 Mar 11 00:03 set-rsb-to-nonsec.patch Just noticed the patch is added with root user instead of mine, perhaps need to chown it and give it another try?

@gounthar - If you do not mind you cannot reboot ( hangs for the moment ) what about the orangepi Lite 2? It can do 1,8GHz BUT H6 SoC is still in developement (WIP), it is half the price of a RockPi4, model A 1GB (RK3399). had promising results using a OPiOnePlus with ovpn ( near 200Mbit maybe more as my upload is CAPped ). A +/- 12Mbit stream resulted in 40% CPU usage, pushing it to the max ( iperf single/ multiple threads ) got it easily to 1,8GHz : my findings, incl temp increase, can be found here Anyway the board has BT, both WiFi and LAN gigabit - but as mentioned DEV image ( kernel 5.x ) needs to be build to have it " somewhat stable " , for VPN (LAN) it works at least. hope this helps

Please refer to this topic rgd issue 1) Also to create some more awareness I contacted "Allwinner Customer Service Team" recently and they made this a Xunlong issue, their response: " After a short discussion internally, we suggest you contact Xunlong for clarification. Let's hope for a satisfactory solution, little/ some hope this can be increased as Xunlog is partnering with armbian ... ... let's keep fingers crossed...

pity, oh well let's hope the best of it honestly had the feeling it was so close to a satisfactory solution, but alas ... thanks for all your efforts though it is appreciated. cheers

omg, let's bump dev to 5.05 ( current kernel ) and build a fresh debian image. Mr martinayotte, I should like to express my respect to you for your work! Will check back later as duty calls ( cooking for the wife ;-) )

rats - it would have been too easy, thanks for the feedback although it is somewhat disappointing. The watchdog being used is " sunxi_wdt ", right? hmm just a log shot using the software watchdog instead, remember a post somewhere which describes something like " echoing " the watchdog with value 1 and then it reboots after so many seconds ( 20? ). not sure if that is the key to success, as said just a long shot. thanks!

Hi katerkoff - As martinayotte wrote in that topic and lanefu explained litte more it comes all down to that Fex is not used with linux mainline kernels, and that is what armbian is based on. It is incorporated however in their legacy kernel, but if you want my opinion that "ubuntu server" image is a joke ... First you need a HDMI cable to enable SSH server before you can log in and next .. well too much disapointment, BUT it does reboot ... Please check also the URLs in that "h6 famous reboot problem" both armbian's documentation and the Fex Guide ( sunxi ). Let's hope either in kernel development ( Linus ) this reboot thingie will be incorporated to handle " reboot on h6 boards " or a workaround ( patch ) here is being developed somehow. I wish I had the magic to do so, but I am afraid I am not skilled enough for that

thanks for enlighten me, so it is fex that has been used in their stuff. I did find just now documentation here at armbian docs cheers

Hi - I just tried ubuntu server built by Xunlong. Indeed, as "dreddit" already wrote earlier, I can also confirm my " OrangePi One Plus " reboots perfectly fine. This is good news in terms it should be possible to make things work, but reading comments above there are some hurdles to overcome? Now if you would please excuse my ignorance, but could someone be so kind to explain why from link provided, part of the code cannot be adapted except "stuff cannot be mixed" . I am not a developer, just a silly end user and therefore I cannot fully oversee the efforts that need to be done, eg. would it be a patch to kernel 5.x versions, is it a feature that needs to be incorporated and addressed first at kernel mailinglist, etc etc. Please enlighten me, it is appreciated and aye I do foresee a solution in the long run keeping my patience. cheers

next reboot I will revert " MIN_SPEED=120000 " to "480000". In terms of power consumption indeed hardly difference, was just a trying. thanks, 1.3GHz it is ( as well 480MHz ) :-)

just to report back all three LTS boards are working great at 1,3GHz ( when needed ). However I checked recently v1.1. ( NanoPi NEO2 LTS ) page and it states under CPU: " Frequency:4* Cortex-A53 1.5GHz " Any chance to get this stable, or is 1.3GHz really the utmost that can be squeezed out? Also updated " MIN_SPEED=120000 " ( instead of 480000 )

well have been testing it for ovpn purposes and that works well, till the moment a reboot is being sent - it won't come up at this stage ( kernel 5.0.4 ) . This is known and hopefully a workaround/ decent solution will be there sooner or later. For now I stick with my H5 boards ( 1,3GHz )

Hi, in terms of I can concur, though all cores go to 1,8GHz if high speed is required ( measured +/-150Mbit, still tuning to do to get to 200 or up and also both ends need a H6 board ). Mostly it does not exceed 720MHz :-), when streaming data from one side to the other ( as +/- 15-20Mbit is needed only ): :~# cpufreq-info |grep stats cpufreq stats: 480 MHz:84.86%, 720 MHz:12.58%, 816 MHz:1.62%, 888 MHz:0.00%, 1.08 GHz:0.00%, 1.32 GHz:0.00%, 1.49 GHz:0.00%, 1.80 GHz:0.94% (64750) cpufreq stats: 480 MHz:84.86%, 720 MHz:12.58%, 816 MHz:1.62%, 888 MHz:0.00%, 1.08 GHz:0.00%, 1.32 GHz:0.00%, 1.49 GHz:0.00%, 1.80 GHz:0.94% (64750) cpufreq stats: 480 MHz:84.86%, 720 MHz:12.58%, 816 MHz:1.62%, 888 MHz:0.00%, 1.08 GHz:0.00%, 1.32 GHz:0.00%, 1.49 GHz:0.00%, 1.80 GHz:0.94% (64750) cpufreq stats: 480 MHz:84.86%, 720 MHz:12.58%, 816 MHz:1.62%, 888 MHz:0.00%, 1.08 GHz:0.00%, 1.32 GHz:0.00%, 1.49 GHz:0.00%, 1.80 GHz:0.94% (64750) If I dump ( iperf3 ) TCP packets and increase it with multiple threads it hits 1.8GHZ and see my initial posts about that, resumee: :~# cpufreq-info |grep current current policy: frequency should be within 480 MHz and 1.80 GHz. current CPU frequency is 1.80 GHz (asserted by call to hardware). current policy: frequency should be within 480 MHz and 1.80 GHz. current CPU frequency is 1.80 GHz (asserted by call to hardware). current policy: frequency should be within 480 MHz and 1.80 GHz. current CPU frequency is 1.80 GHz (asserted by call to hardware). current policy: frequency should be within 480 MHz and 1.80 GHz. current CPU frequency is 1.80 GHz (asserted by call to hardware). :~# paste <(cat /sys/class/thermal/thermal_zone*/type) <(cat /sys/class/thermal/thermal_zone*/temp) | column -s $'\t' -t | sed 's/\(.\)..$/.\1°C/' cpu_thermal 55.4°C gpu_thermal 49.9°C Also thanks for the suggestion rgd. MAC address, I will try this out when I have time later this week, possibly today already :-). Once that is stable, indeed the major remaining issue is the board still shuts down on a reboot - something to dig in - thanks so far!

hmm all this seems similar to what I experience on my Orange Pi One Plus board once I reboot. The board gets stuck ( 5.0.2 dev image ) and powering on device manually is the only way to get it back to business. I was hoping as a fall back WoL could be used, but alas as currently it lists " (D)isabled " # ethtool eth0 |grep Wake-on Supports Wake-on: d Wake-on: d Even after installing " apt-get -t stretch-backports install firmware-realtek " it does not show anything else as " d " . Then I discovered RTL8211 is not included ( yet ) in to this package, so back to square one again ... How to get this board properly rebooted ( aka telinit 6/ shutdown -r now , etc etc ) @martinayotte - Perhaps you found anything useful after comparing the OPi's and PINE H64 hw? BTW can I update to 5.0.4 kernel or should I build a new image in my dev environment? thanks