Build: M2+ doesn't boot with >5.20

Created on 26 Nov 2016 · 35Comments · Source: armbian/build

I tried to compile and boot from sdcard on bump versions >5.20, none are booting / working. Latest commit (#3bcc3c2) is recognizing M2+ as Xunlong Orange Pi PC, giving CRC errors...

Any insights?

bug

Source

Grabber

All 35 comments

@jadr2ddude, yes.

I compiled it from git source: "Armbian_5.24_Bananapimp2plus_Ubuntu_trusty_3.4.112.img"

Grabber on 26 Nov 2016

@jadr2ddude, as I told on the first post... I found the issues directly from cloning and compiling the sources (sudo ./compile.sh)

Check the strange error: https://www.youtube.com/watch?v=9Tg_U7ZUtQ8&feature=youtu.be

Grabber on 26 Nov 2016

@jadr2ddude, it is not booting from SD. I have 50 M2+ boards in my hands now... this one that I recorded the video has a previous / old Armbian version installed on eMMC. So it started booting from sdcard and switched to eMMC, never seen this behavior before. Look at the error on framebuffer... look at the wrong detection of the board... there is something wrong with newer Armbian commits. On other M2+ without anything on eMMC, screen go black and board keep rebooting after some minutes.

Grabber on 26 Nov 2016

Yes, it is hanging at "booting kernel..." can you provide more details about your image?

Grabber on 26 Nov 2016

Out of curiosity, how boards are powered ? I observed similar hang if board powered over barrel jack. If power provided via USB, board boots correctly.

kad on 26 Nov 2016

Latest commit (#3bcc3c2) is recognizing M2+ as Xunlong Orange Pi PC, giving CRC errors...

This is not an issue. There is no M2+ configuration in u-boot, so we are using one for OPi PC.

Overall booting issue was confirmed some time ago (https://forum.armbian.com/index.php/topic/2882-banana-pi-m2-does-not-boot-after-power-cycle/), no solution yet, but I would guess that something in FEX file causes this problem.

zador-blood-stained on 26 Nov 2016

👍1

@jadr2ddude please try to stay on-topic (legacy kernel issue).

@Grabber I second @zador-blood-stained's idea to check fex settings: https://github.com/igorpecovnik/lib/commits/master/config/fex/bananapim2plus.fex (simply start with latest version known to work and iterate through until the problem occurs). I can confirm the booting problem but can't do much about it since my BPi M2+ sits unaccessible at a remote location now (stuck at booting).

ThomasKaiser on 26 Nov 2016

@Grabber Perhaps this is related to broken sunxi tools in our repository? Check if script.bin o.k. in first place.

igorpecovnik on 26 Nov 2016

@kad, only powered over barrel plug.

Grabber on 26 Nov 2016

@igorpecovnik If I boot from sdcard, write to nand with 5.20 (both prebuilt or compiled from source) and last update to 5.23 with apt-get upgrade it works.

Grabber on 26 Nov 2016

Anyone with new idea? Not advancing here...

Grabber on 2 Dec 2016

This SinoVoip image seems to be booting perfectly, not presenting the same bug as found on Armbian.

Linux bpi-iot-ros 3.4.112-sun8i #2 SMP PREEMPT....

dmesg & script.fex:
https://gist.github.com/Grabber/80758fc9f65afc144c961af58ffec861

image download:
http://forum.banana-pi.org/t/bpi-m2-new-image-ubuntu-16-04-xenial-minimal-preview-bpi-m2p-img-2016-07-10/1989

I'm investigating...

Grabber on 2 Dec 2016

If this script.fex is from this image, then they used another board as a reference:

[product]
version = "100"
machine = "orangepi-plus"

zador-blood-stained on 2 Dec 2016

@zador-blood-stained

Armbian 5.20 / compile from sources

[product]
version = "100"
machine = "Banana Pi BPI-M2-Plus"

SinoVoip / 2016-07-10-ubuntu-16.04-xenial-minimal-preview-bpi-m2p.img

[product]
version = "100"
machine = "orangepi-plus"

Are you saying that by just changing machine param value it can work?

Grabber on 2 Dec 2016

No, I'm saying that we need to test current Armbian images with this script.fex, and if it boots, check the differences between fex files.

zador-blood-stained on 2 Dec 2016

@zador-blood-stained, it did this test now. I compiled Armbian 5.20 from sources, burnt to sdcard and the problem is happening. Last I replaced the script.fex from Armbian with SinoVoip version found on the .img I mentioned on previous link. It is now working! There several differences, do you have a hint on what fex section look first?

Grabber on 2 Dec 2016

@zador-blood-stained, please check both script.fex for comparison.

https://gist.github.com/Grabber/67214110d1aec17fb749a2e06c4e9e96

Grabber on 2 Dec 2016

Replacing Armbian fex with Sinovoip fex is resulting in "gmac0 gmac0: eth0: Initialize hardware error" message.

After a while waiting to boot... it boots, without networking.

Grabber on 2 Dec 2016

It seems that if you not plug HDMI cable and power up fist, the problem is gone.

Grabber on 3 Dec 2016

It seems that if you boot the M2+ without HDMI cable connected it always work with Armbian 5.20 and fex from lib repo. Same behavior with 5.20 upgrade to 5.23 via apt upgrade.

Grabber on 3 Dec 2016

Replacing Armbian fex with Sinovoip fex is resulting in "gmac0 gmac0: eth0: Initialize hardware error" message.

gmac_phy_power_en in [gmac_phy_power] section GPIO values are different

It seems that if you boot the M2+ without HDMI cable connected it always work with Armbian 5.20 and fex from lib repo. Same behavior with 5.20 upgrade to 5.23 via apt upgrade.

Apart from different display resolution (720p60 vs 1080p60) display settings look identical.

zador-blood-stained on 3 Dec 2016

@zador-blood-stained, power up the M2+ without HDMI connected is working, no more issues. Tried to find the root cause, no success, no more ideas.

Grabber on 9 Dec 2016

Apart from different display resolution (720p60 vs 1080p60) display settings look identical.

@Grabber
I know it's stupid but since it's related to HDMI somehow ... if you change screen resolution to match stock Sinovoip?

igorpecovnik on 9 Dec 2016

It is not stupid, but in my logic it would make sense if Armbian > SinoVoip resolution.

Grabber on 9 Dec 2016

@igorpecovnik and @zador-blood-stained, do you know about any bug on ethernet? It appears that when ethernet cable is connected it works.

Grabber on 13 Dec 2016

Working fine on latest nighty build so we can close this.

igorpecovnik on 13 Dec 2016

It is not solved.

Grabber on 24 Dec 2016

@igorpecovnik, please reopen it. If you unplug boards and plug power after some hours... the boot is stuck after Armbian logo.

Grabber on 24 Dec 2016

This is also the only board which has such weird problems and it also causes kernel crash on current mainline kernel on shutdown. All other H3 boards act fine in the same scenario. What is fundamentally different is U-boot (mainline vs stock allwinner) and I would start findind problems there.

igorpecovnik on 25 Dec 2016

Is M2+ using different u-boot from other boards?

Grabber on 25 Dec 2016

Sinovoip images are using legacy u-boot (most likely) and different partitioning scheme.
Mainline u-boot works fine on all other H3 devices, so even in case boot troubles are related to the mainline u-boot, it is not Armbian problem. It is most likely related to kernel and u-boot configuration, which is based on documentation provided by vendor.

zador-blood-stained on 25 Dec 2016