Hello there. I've got an Orange Pi PC+ SBC running desktop Armbian Xenial 5.38 kernel 3.4.113 from its eMMC that showed up pink screen after intermittent Power Up. I was using a 5V power adaptor that became faulty and intermittently became on and off.  After replacing the power adaptor and booting up my device to a HDMI monitor, I found out that it now displays nothing but pink screen!

 

Here's what I've done to no avail:

1. Turning on the HDMI monitor before and after I turn on the machine

2. SSHing from UART0 and suing command h3disp -m 5 (or 6 or 33 or 34...). No dice

3. Booting using the same Armbian OS but from SD card. SSH shows me the hostname is different(so same OS but boot from SD card ) but the display remains pink

4. Booting from Android SD card. The monitor works normally, showing the entire Android and all

5. Reflashed the eMMC inside the Orange Pi PC+ using the nand-sata-install from the Armbian SD card. After booting from eMMC the monitor is still pink!

 

I noticed that during bootup, the Uboot output is different compared to the UBoot output of normal images.

 

Normal Uboot utput:

 

Quote

U-Boot SPL 2017.09-armbian (Nov 22 2017 - 16:49:59)
DRAM: 1024 MiB
Trying to boot from MMC2

U-Boot 2017.09-armbian (Nov 22 2017 - 16:49:59 +0100) Allwinner Technology

CPU:   Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi PC Plus
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 1, SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   vidconsole
Err:   vidconsole
Net:   phy interface0
eth0: ethernet@1c30000
230454 bytes read in 182 ms (1.2 MiB/s)
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 1.00
USB3:   USB OHCI 1.0
USB4:   USB EHCI 1.00
USB5:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
scanning bus 4 for devices... 1 USB Device(s) found
scanning bus 1 for devices... 2 USB Device(s) found
scanning bus 3 for devices... 1 USB Device(s) found
scanning bus 5 for devices... 2 USB Device(s) found

 

Pink Monitor UBoot Output

Quote

U-Boot SPL 2017.09-armbian (Nov 22 2017 - 16:49:59)
DRAM: 1024 MiB
Trying to boot from MMC2

U-Boot 2017.09-armbian (Nov 22 2017 - 16:49:59 +0100) Allwinner Technology

CPU:   Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi PC Plus
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 1, SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   phy interface0
eth0: ethernet@1c30000
230454 bytes read in 182 ms (1.2 MiB/s)
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 1.00
USB3:   USB OHCI 1.0
USB4:   USB EHCI 1.00
USB5:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
scanning bus 4 for devices... 1 USB Device(s) found
scanning bus 1 for devices... 2 USB Device(s) found
scanning bus 3 for devices... 1 USB Device(s) found
scanning bus 5 for devices... 2 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found

 

Is this why the pink screen comes up, becauseUboot settings have been changed/corrupted somewhat during the intermittent power interrupt? How does the in, out and err defined? I've checked the files in /boot and couldn't find anywhere that refers to this.  I don't understand how the device uses the eMMC UBoot even when it is booting from SD card, and how the problem persists even after I run nand-sata-install. A different Orange PI image works, so is this an Armbian issue? Is there a hardware broken somewhere?

Edited June 28, 20188 yr by Sodrohu
Added more details on eMMC

Do you have a linux computer that has a SD port available

 

Put the card in it..run Gparted, scan and fix the sdcard partition, re-insert and fire up...should come up with no issues

 

For some reason...even with good cards, and good power...if I pull the power on my SBC's sometimes (not every time) it makes the sdcard flip out and not reboot anymore....after a scan and fix on another machine...it reboots just fine.

 

If it persists, you could have damaged the hardware with power spikes...SBC's are somewhat fragile and sensitive to power

 

14 hours ago, WarHawk_AVG said:

Do you have a linux computer that has a SD port available

 

Put the card in it..run Gparted, scan and fix the sdcard partition, re-insert and fire up...should come up with no issues

 

For some reason...even with good cards, and good power...if I pull the power on my SBC's sometimes (not every time) it makes the sdcard flip out and not reboot anymore....after a scan and fix on another machine...it reboots just fine.

 

If it persists, you could have damaged the hardware with power spikes...SBC's are somewhat fragile and sensitive to power

 

 

I forgot to clarify beforehand,  that this pink screen issue first happened when the Orange Pi PC+ was running with Armbian installed inside its eMMC, not from SD. Later when I tried to boot the Orange PI from SD, the pink screen persisted, but from SSH i know it was booting from the SD card.

oh...sorry

Alright, I've solved this problem. I didn't really find out what is the cause, but I got the Orange Pi working back.

 

From here: https://www.jeffgeerling.com/blog/2016/format-built-emmc-storage-on-orange-pi-plus, I did the part where:

Delete the existing partitions:

sudo fdisk /dev/mmcblk1

p to list all partitions, then d and a number to delete all existing partitions, then w to write the changes.

 

I booted from a SD card with Orange Pi Ubuntu LXDE installed, then executed this command.  Then I booted from Armbian SD card and run nand-sata-install.  I had to reinstall everything back but anyway, problem solved!

i have a Orange Pi Plus 2E board and i also encountered a very persistent pink screen no matter how many times rebooting the board.
Turns out it is caused by the HDMI cable. The same cable doesn't cause any issue to my OrangePi PC Plus board.

 

OrangePi PC Plus board
ARMBIAN 5.38 stable
Ubuntu 16.04.4 LTS

Linux orangepipcplus 3.4.113-sun8i #18 SMP PREEMPT Wed Jan 24 22:10:49 CET 2018 armv7l armv7l armv7l GNU/Linux

 

Orange Pi Plus 2E board

ARMBIAN 5.38 stable

Ubuntu 16.04.3 LTS

Linux orangepiplus2e 3.4.113-sun8i #18 SMP PREEMPT Wed Jan 24 22:10:49 CET 2018 armv7l armv7l armv7l GNU/Linux
 

Is the pink blank screen a known issue? If yes, would there be a fix?

Is there a temporary solution?

How to recover without rebooting?

 

Using:

1. ARMBIAN 5.38 stable

Ubuntu 16.04.4 LTS

Linux orangepipcplus 3.4.113-sun8i #18 SMP PREEMPT Wed Jan 24 22:10:49 CET 2018 armv7l armv7l armv7l GNU/Linux

 

2. ARMBIAN 5.38 stable

Ubuntu 16.04.3 LTS

Linux orangepiplus2e 3.4.113-sun8i #18 SMP PREEMPT Wed Jan 24 22:10:49 CET 2018 armv7l armv7l armv7l GNU/Linux

 

Affected boards:
OrangePi PC Plus, eMMC IC: KLM8G1WEPD-B031

OrangePi PC Plus, eMMC IC: KLM8G1GEME-B041

Orange Pi Plus 2E 

 

To trigger:
Reboot OrangePi when monitor is powered off/sleep or do not connect to a monitor

 

Symptoms:

Able to FTP, ssh, ping OrangePi

 

Random things i tried that doesn't work:
(Trying to recover without rebooting)

xset -display :0.0 dpms force off 
xset -display :0.0 dpms force on

xfwm --replace --display :0.0

xfce4-panel -r --display :0.0
 

Thanks for reading.

On 7/6/2018 at 1:27 PM, 062621AM said:

Is there a temporary solution?

How to recover without rebooting?

We stopped to deal with this kernel (3.4.y) a long time ago and you will not find many people around that still do something about it. We fixed a ton of issues but it's impossible to fix them all with resources that are around. Fixes that were discovered are usually implemented. That's what our project essentially do.

 

Virtually all devs are working only on a modern kernel, (4.17.y ->), which will soon cover most of the functionality. Actually, when video/3D acceleration is working, these old kernel images are going to be trashed. We keep them solo for multimedia capabilities.

 

This is an old issue which is gone from my head so rather try to do some search for a possible solution.

Thanks Igor for the reply.
First, i will try to use an older image for the legacy kernel. 
Then i will try a suggestion by a poster to disable monitor detection.
Finally i will install XFCE4 desktop in mainline kernel.

Quote

 

To trigger:
Reboot OrangePi when monitor is powered off/sleep or do not connect to a monitor

 

Just curious... why would you turn on/connect the HDMI monitor AFTER turning on the OPI? Why not turn on the monitor first? I also had the same bug,  but I didn't trigger it because I always make sure to turn on and connect the monitor first before booting up the OPI. 

17 hours ago, Sodrohu said:

 

Just curious... why would you turn on/connect the HDMI monitor AFTER turning on the OPI? Why not turn on the monitor first? I also had the same bug,  but I didn't trigger it because I always make sure to turn on and connect the monitor first before booting up the OPI. 

i modified my LG monitor adapter to power my OrangePi. unfortunately the monitor power on slower than the OrangePi.
The monitor model is 24MT48AF-PT. 

In the end i switched to another image.

Debian 9.3 (stretch) armv71 4.14.14-sunxi #8 SMP Jan 26 11:51:20 CET 2018

Noticed the following:
1. ifconfig not working
The command could not be located because '/sbin' is not included in the PATH environment variable.

https://askubuntu.com/questions/433092/the-command-could-not-be-located-because-sbin-is-not-included-in-the-path-env

ifconfig and sudo ip addr flush works only after adding /sbin to the PATH variable

2. sudo ip addr flush

previous ip set using /etc/network/interface remains after flush

sudo ip addr flush

ip addr show
ip1

ip2

ifconfig and sudo ip addr flush works only after adding /sbin to the PATH variable
3. Screen resolution will ignore the resolution set in Settings > Display if unplug-plug the HDMI cable several times or switch the display

4. Nautilus Run in terminal does not work.
If choose the option, Run, i can grep the name of the batch script (content of the script is sleep 60).
Unable the grep if choose Run in terminal. Suspect that the batch script does not run at all.