Jump to content

H6 Famous Reboot problem


martinayotte

Recommended Posts

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.

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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...:D

Link to comment
Share on other sites

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  ....


 

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

@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

 

Link to comment
Share on other sites

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)

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 ...

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 ...

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines