• Content Count

  • Joined

  • Last visited

  1. I thought that this might be a device issue, since 1 device (and some other devices I tested) loads the correct resolution regardless of which OS it booted from. Only 1 OPIPC+ so far had this issue. If so, why then this one device displays proper on Debian, but had issues on Ubuntu? I suspect this is related to the pink screen issue but I've got no proof so far...
  2. I've installed a bootable Armbian Ubuntu on an SD card. I plan to copy the SD's OS into multiple OPI PC+ devices. The problem I found was that somehow the HDMI monitor displays a different max resolution depending on which OPI device I'm using. The armbianEnv.txt for the SD card: verbosity=1 logo=disabled console=both #disp_mode=1920x1080p60 disp_mode=1280x720p60 overlay_prefix=sun8i-h3 rootdev=UUID=8bc771e4-1c8a-4bd0-af02-00570c63c5c9 rootfstype=ext4 overlays=uart1 uart2 uart3 extraargs=drm_kms_helper.edid_firmware=edid/1280x720.bin usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u When I boot the SD card on the OPIPC+ displaying the correct max resolution (1920x 720) , these settings are: xrandr --props: Screen 0: minimum 320 x 200, current 1280 x 720, maximum 8192 x 8192 HDMI-1 connected 1280x720+0+0 (normal left inverted right x axis y axis) 333mm x 187mm EDID: 00ffffffffffff0031d8000000000000 051601036d211278ea5ec0a4594a9825 20505400000081c00101010101010101 010101010101011d008051d01c204080 35004dbb1000001e000000ff004c696e 75782023300a20202020000000fd003b 3d2b2d08000a202020202020000000fc 004c696e75782048440a202020200094 non-desktop: 0 range: (0, 1) link-status: Good supported: Good, Bad 1280x720 59.65*+ When I boot the SD card on the The OPIPC+ displaying the wrong max resolution (1024x 768) has these settings: xrandr --props: Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192 HDMI-1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm non-desktop: 0 range: (0, 1) link-status: Good supported: Good, Bad 1024x768 60.00* 800x600 60.32 56.25 848x480 60.00 640x480 59.94 uname -a: Linux orangepipcplus 4.17.14-sunxi #9 SMP Mon Aug 13 09:06:31 +08 2018 armv7l armv7l armv7l GNU/Linux The OPICP+ with the wrong max address also currently had a pink screen issue with legacy Armbian images. That's why I changed to the new mainline kernel; to enable HDMI output. On both OPIPC+ devices the EMMC is flashed with Armbian Debian stretch mainline. On both devices the Debian displays the resolution properly (1920x720). I am currently trying to get the Ubuntu OS to work as well.
  3. OK, I've managed to build my own Armbian image. However, understanding and changing anything on it are going to consume time and a effort that I can't spare right now, so I'll just KIV that part for now. What I need right now is a unique ID that will not change no matter what version of U-boot and kernel are being used. I plan to use it as an identifier for use in databases. You mentioned SID, which I can read from /proc/cpuinfo. However, I've checked that, for the same device, the SID of the legacy and mainline u-boot are also different! I'd rather not have to keep two SID records for each device in the databases.
  4. Is it possible to modify the U-boot to reuse back the old algorithms? Right now I can change the mac addresses by calling macchanger every time the machine boots, however, if using this method I'll have to make a list of custom MAC addresses. I'd rather have the machine generate the proper MAC addresses themselves. BTW where is the U-boot located? Is it in /boot?
  5. Previously I installed legacy Armbian to an Orange Pi PC Plus device and noted down its eth0 and wlan MAC addresses. Then I installed a Mainline Armbian server image to its EMMC, updated the armbian-config to enable the desktop manager. Now I checked the MAC addresses to be completely different. Why does this happen?
  6. 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.
  7. 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:, 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!
  8. To familiarise yourself with NWJS, I suggest you go get a Ubuntu PC first for testing. Follow this tutorial: and download the SDK at . The online docs are here: Users/Getting Started/ Play around with it first to see if it's what you need. However, if you plan to use NWJS on the Orange Pi, then you have to compile the SDK yourself because the NWJS team doesn't provide binaries for ARM7 architecture. You can attempt compilation yourself by following the steps here: Mind you, this is extremely difficult! I've forgotten the steps how but I remember how painful it was due to lack of documentation, so I gotta go thru trial and error. Just make sure you read carefully, and google anything you don;t understand.
  9. 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.
  10. I have used Node.js to control hardware, like communicating to serial ports. I haven't tried using Node.js to control GPIO pins on my Orange Pi device. However, I found this:, which may be able to do what you want to do. Of course, you can also call python scripts from your Javascript scripts, though IMHO that's too many hoops for me to jump through.
  11. You should use either NW.js or Electron. They're basically Desktop apps that run using the Google Chrome engine. So, like a web page that you can open from the desktop. I use NW.JS for work so I can vouch for it myself, but I dunno about Electron since I've never used it extensively (even though it seems a lot more popular). Both of them uses node.js and codes in Javascript. So if your background is in front-end website development, this will be easy to start up.
  12. 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: Pink Monitor UBoot Output 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?
  13. OK..somehow I didn't notice the link before. I'll play around with the mainline kernel, once I got the legacy Armbian working with my drivers...
  14. Wait, really? I thought the Mainline kernel doesn't support desktop since the Cubietruck download page only has Jessie server for mainline kernel. I'm interested to test mainline kernel, but I forgot to mention that the Armbian is supposed to replace the current Cubieez. I gotta make sure Armbian can support the various drivers I've developed on the Cubieez. So the legacy kernel is pretty much required since, according to the Cubietruck page, the GPIO number is already different for the mainline kernel, and I did use GPIOs with python drivers.
  15. I would rather use the mainline kernel, but I'm going to make a GUI application so a desktop-capable kernel is required, and only the legacy kernel is capable of that for now. Even so... I've managed to fix the overscan issue! As usual the inspiration comes from a topic from the Armbian forums: Basically run these three commands: a10disp changehdmimodeforce 5 fbset -xres 1240 fbset -yrex 720 a10disp changehdmimodeforce 5 - this command just change the hdmi mode from 4(1280x720p50) to 5(1280x720p60). I suppose if I modify the script.bin so it becomes 5 then there's no longer a need to call this command. fbset - this just sets the x and y resolution of the frame buffer. I did some trial and error and found out, for my screen size, this is the config that works best! I've put all three commands in /etc/rc.local so it always trigger on boot up! So far the Xenial seems to be holding up. I haven't tried installing everything yet, but I've got all the basics covered so there's that. Thanks for the help Igor!