martinayotte Posted April 9, 2019 Author Posted April 9, 2019 1 hour ago, dolphs said: but alas " reboot " hangs, That is strange ... It worked for me on 3 boards ... Did you check in output/debug/compilation.log that it has been actually applied ? 1 hour ago, dolphs said: perhaps need to chown it and give it another try? I don't think so. It appeared as root because the git update was done under sudo. 0 Quote
dolphs Posted April 9, 2019 Posted April 9, 2019 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 0 Quote
moneyrain Posted April 9, 2019 Posted April 9, 2019 I have done a apt upgrade and the reboot bung still there, 0 Quote
martinayotte Posted April 9, 2019 Author Posted April 9, 2019 5 minutes ago, dolphs said: Did not see any additional logs after, perhaps that is a lead? This means it has been applied successfully ... 0 Quote
dreddit Posted April 9, 2019 Posted April 9, 2019 Works for me fresh debian stretch build last night, reboots fine. Thanks everyone who made this happen. 0 Quote
martinayotte Posted April 9, 2019 Author Posted April 9, 2019 3 minutes ago, moneyrain said: I have done a apt upgrade and the reboot bung still there, You won't get the fix using "apt upgrade", you need to get a full image from https://dl.armbian.com/ 0 Quote
dolphs Posted April 9, 2019 Posted April 9, 2019 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 0 Quote
moneyrain Posted April 9, 2019 Posted April 9, 2019 I flash again latest img of bionic to test, and it still the same, seem like trouble not solved here 0 Quote
greg798 Posted April 9, 2019 Posted April 9, 2019 17 minutes ago, moneyrain said: I flash again latest img of bionic to test, and it still the same, seem like trouble not solved here Same on 5.78.190407 bionic nighty my opi3 with emmc Maybe fix later... maybe another boards... 0 Quote
martinayotte Posted April 9, 2019 Author Posted April 9, 2019 46 minutes ago, greg798 said: Same on 5.78.190407 The fix has been committed yesterday, so you need to try with 5.78.190408 or later ... 1 Quote
kexec Posted April 9, 2019 Posted April 9, 2019 reboot works. opi3 with emmc booted from sd card. image which i used 1 Quote
martinayotte Posted April 9, 2019 Author Posted April 9, 2019 3 hours ago, dolphs said: I didn't find a build later than 2018-08-23 ... I've activated nigthly builds for OPiOnePlus, you should be able to get it tomorrow ... 0 Quote
dolphs Posted April 10, 2019 Posted April 10, 2019 6 hours ago, moneyrain said: I flash again latest img of bionic to test, and it still the same, seem like trouble not solved here 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 .... 0 Quote
may Posted April 10, 2019 Posted April 10, 2019 after taking some time on "how to install u-boot on allwinner chip" and some wiki info of MBR. And then digging into u-boot post installation script. I have figured out how to solve this problem without reflashing the whole sdcard. We have to flash u-boot and spl after run 'apt upgrade -y' because the post installation script don't flash u-boot automatically. This script will help you flash the new u-boot and spl . #!/bin/sh # run apt upgrade first . /usr/lib/u-boot/platform_install.sh setup_write_uboot_platform write_uboot_platform $DIR $DEVICE 0 Quote
@lex Posted April 10, 2019 Posted April 10, 2019 12 hours ago, dolphs said: but little later it appears LAN does not come up... I would like to mention that I have reported a similar issue to @froezus , although i am using a different u-boot (in fact it's his u-boot) and latest kernel to experiment with. It seems u-boot and minor .config changes plays an important role in this case. If you can grab some dmesg output, check if you have something similar to this: dmesg|grep ethernet [ 0.879244] dwmac-sun8i 5020000.ethernet: EMAC reset timeout [ 0.879786] dwmac-sun8i: probe of 5020000.ethernet failed with error -14 [ 4.388248] platform 5020000.ethernet eth0: device MAC address c6:70:90:27:15:44 [ 4.388263] platform 5020000.ethernet eth0: Could not attach to PHY [ 4.394739] platform 5020000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) This usually occurs on the first reboot, subsequent reboots restore ethernet connection. I have tested his previous patch and latest patch he submitted and for some reason, i got different behavior on reboot. 0 Quote
martinayotte Posted April 10, 2019 Author Posted April 10, 2019 13 hours ago, dolphs said: Yet I will await the nightly image Builds are done this morning ... 0 Quote
dolphs Posted April 10, 2019 Posted April 10, 2019 4 hours ago, martinayotte said: Builds are done this morning ... 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 0 Quote
t3l3m4k0 Posted April 10, 2019 Posted April 10, 2019 @dolphsI have one opioneplus, and same problem as you, when reboot doesn't get ip address also if i disconnect rj45 wire and reconnect. I must poweroff / poweron to restart. Last days i have compiled kernel and u-boot from sources with last patches and install it with no luck. Patches, i confirm, are applied to sources but orangepioneplus no reboot and no fixed mac, today i have download and install nighties and mac is fixed, it reboots but on reboot not gets ip. Thx for your work 0 Quote
dolphs Posted April 10, 2019 Posted April 10, 2019 @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! 0 Quote
martinayotte Posted April 10, 2019 Author Posted April 10, 2019 20 minutes ago, t3l3m4k0 said: install nighties and mac is fixed, it reboots but on reboot not gets ip. Oh ! I didn't catch it early, since I'm using mainly WiFi dongles ... Here is what I see with "dmesg | grep eth" : [ 12.448558] dwmac-sun8i 5020000.ethernet eth0: Could not attach to PHY [ 12.448569] dwmac-sun8i 5020000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19) 0 Quote
@lex Posted April 10, 2019 Posted April 10, 2019 I changed the timeout value from 100 ms (stmac had 10 ms and now has 100 ms) to 200 ms to see if could help,i get stmac crashes with this value. If i issue a sudo reboot from this session (100 ms default) again the OPI One Plus reboot normally. Changing u-boot version ethernet works on reboot but not hdmi. I also patched only ATF and not u-boot and i get random results, sometimes it works some times not. I am not sure u-boot must be patched. 0 Quote
martinayotte Posted April 10, 2019 Author Posted April 10, 2019 9 minutes ago, @lex said: I am not sure u-boot must be patched. Not having "reset" command at u-boot prompt is a pain. But not having ethernet is worst. The sad thing is that I don't see how it is related ... On my OPi3, ethernet is not even working anymore, I didn't catch this early here too, since I'm mostly using WiFi. Maybe @froezus has some clue ... 0 Quote
frozeus Posted April 10, 2019 Posted April 10, 2019 Ethernet is still working at first cold boot right ? So my thought is the PHY is still powered at boot and doesn't have a proper reset at probe in Linux. So the reset patch didn't add the issue, the issue is here and we see it because we never rebooted before. 0 Quote
martinayotte Posted April 10, 2019 Author Posted April 10, 2019 22 minutes ago, froezus said: Ethernet is still working at first cold boot right ? Right ! 22 minutes ago, froezus said: the issue is here and we see it because we never rebooted before. It is just a pandora box been opened ... 0 Quote
@lex Posted April 10, 2019 Posted April 10, 2019 @froezus I don't see your u-boot patched , it is the only ATF that should be patched? 0 Quote
frozeus Posted April 10, 2019 Posted April 10, 2019 12 minutes ago, @lex said: @froezus I don't see your u-boot patched , it is the only ATF that should be patched? https://github.com/clementperon/u-boot/commits/beelink_gs1 "arm: sunxi: h6: fix reset using r_wdog" 0 Quote
martinayotte Posted April 10, 2019 Author Posted April 10, 2019 12 minutes ago, @lex said: it is the only ATF that should be patched? Those are 2 different things ... Here is what has been done into Armbian : ATF one is for "reboot" issue : https://github.com/armbian/build/blob/master/patch/atf/atf-sunxi64/0001-Fix-reset-issue-on-H6-by-using-R_WDOG.patch U-Boot one is for "reset" command issue : https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-sun50iw6/fix-u-boot-H6-reset.patch 0 Quote
frozeus Posted April 10, 2019 Posted April 10, 2019 19 minutes ago, martinayotte said: Right ! It is just a pandora box been opened ... We just discovered that : cold boot != warn boot 0 Quote
@lex Posted April 10, 2019 Posted April 10, 2019 I see now. Then "reset" is not working properly, i suppose. stmac did not reset. If someone can check, do a cold boot, do a reboot and do a reboot again and check eth0. 0 Quote
martinayotte Posted April 10, 2019 Author Posted April 10, 2019 25 minutes ago, @lex said: If someone can check, do a cold boot, do a reboot and do a reboot again and check eth0. I did it with both OPiOnePlus and OPi3, only cold boot have eth0. As said by @froezus, it is not an newly introduced bug, it was only hidden by the fact that we were forced to do cold boot every time before ... EDIT : I've just confirmed with PineH64, it was still using old u-boot, eth0 comes up every time, then updated with new u-boot, still eth0 comes up every time. But PineH64 was already react differently from OPis, even for the "reboot" issue ... 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.