Sodrohu

OK..so I've succeeded in creating an image with the following partitions: 1) Bootloader 2) 1st OS server partition, 3) 2nd OS desktop partition, 4) unallocated free space How I did it: 1. Have an Orange PI PC+ device with OS in EMMC as development/test device 2. Compile full server image from armbian/build (legacy image). Burn in SD card A 3. Compile basic desktop image from armbian/build (legacy image). Put in SD card B 4. Boot OPI device from EMMC. insert SD card A in SD card slot. Insert SD card B from USB card reader 5. FIre up Gparted. Check OS file partition sizes of both SD cards A and B. Make sure Boot partition A + OS file partition A + OS partition B < SD card A total size. if not, use Grapted to reduce partition size. 6. Copy OS partition B into SD card A. Let Gparted run. after done, check if all looks OK 7. If no errors, you should turn off the device,take out all SD cards, then turn on again. The device should boot into 1st server partition. Now the problem I'm having is how to boot the 2nd OS partition. fdisk output sayas: 1st partition /dev/mmcblk0p1 2nd partition /dev/mmcblk0p2 I've tried changing the boot.cm in first partition's /boot/boot.cmd to call this command: setenv rootdev /dev/mmcblk0p2 and called mkimage to generate new boot.scr (original boot.cmd and scr renamed for backup purposes) rebooting the device, I see my changes are used ( there are some echo cmds I put to make sure it's running my changes), but the device still boot from the 1st partition. how do I make it so it points to the 2nd partition?

I've been reading on the forums on the possibility of having multiple OSes inside 1 EMMC for the Opi PC+. From what I understand, inside a typical EMMC installation, it has 3 partitions: 1) Bootloader partition, which runs first and starts the main partition 2) main partition, contains OS files 3) unallocated free space suppose I have 2 devices: 1. Armbian Jammy Server 2. Armbian Jammy Desktop Now I want to make another device that has 2 OS partitions, like so: 1) Bootloader 2) 1st OS main partition, 3) 2nd OS main partition, 4) unallocated free space I'm thinking of using DD to extract the image out from 1 OS and dd it back into the other (booting the devices using another OS from SD card). I'm guess taking out the desktop image and put it inside the server device... If this is done, how do I make it so that the 2nd OS is bootable? It can be like this: 1) Select which OS to boot on startup ala GRUB 2) Boot into 1st OS, then boot into 2nd OS from 1st OS. I want to make this as a way to make the 2nd OS robust. 2nd OS is the work OS, 1st OS is diagnostics OS. The idea is to make the 1st OS able to fsck/remote rsync the 2nd OS OS in case the 2nd OS corrupts/needs updates.

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

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.

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.

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?

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?

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.

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!

To familiarise yourself with NWJS, I suggest you go get a Ubuntu PC first for testing. Follow this tutorial: https://www.sitepoint.com/cross-platform-desktop-app-nw-js/ and download the SDK at https://nwjs.io/downloads/ . The online docs are here: http://docs.nwjs.io/en/latest/For 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: https://github.com/LeonardLaszlo/nw.js-armv7-binaries 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.

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.

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: https://www.npmjs.com/package/orange-pi-gpio, 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.

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.

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?

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

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.

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!

Thanks Igor! I did like what you told me to do and it worked! I extracted the u-boot-sunxi-with-spl.bin from the deb file, booted from SD card and run these commands: dd if=/dev/zero of=/dev/mmcblk0 bs=1k count=1023 seek=1 status=noxfer dd if=/boot/u-boot-sunxi-with-spl.bin of=/dev/mmcblk0 bs=1k count=1023 seek=1 status=noxfer Turning off the CT, taking off the SD, I can now boot from the TSD! However, There is still the monitor misalignment issue. Here's the pic: https://drive.google.com/open?id=0B5XGa48DW48qZzF0OWZ4Y1lZRk0 So far I've tried: 1. Modifying the /boot/armbianEnv.txt. Only managed to change the resolution 2. MOdified the boot.scr by replacing "setenv disp_mode "1280x720p60"" with "setenv disp.screen0_output_mode "1280x720p60"". No change 3. Running "a10disp changehdmimodeforce 4" and toher numbers according to https://docs.armbian.com/User-Guide_Fine-Tuning/ the commands work from number 4-5 I noticed that, when the armbian boots up, at the first 3 seconds when the monitor displays the armbian logo along with the serial console, the alignment is correct! Later the screen goes blue, and when Ubuntu is finally loaded it becomes misaligned! I checked the serial console line and found this: HDMI connected: Setting up a 1366x768 hdmi console (overscan 0x0) Does this line point to the problem?

OK some updates. Previously, I’ve tried to change the /dev/mmcblkxx settings at /boot/armbianEnv.txt, boot.cmd, boot.scr (from mkimage command), and even /etc/fstab. However, regardless of the values, the SD card always show up as /dev/mmcblk1p1, and TSD as a removable device at /dev/mmcblk0p1. Df –h always show the /dev/mmcblk1p1 mounted on /. However, I noticed that an hour after I started this topic, one of the armbian maintainters, zador, updated the github repo for u-boot cubietruck. https://github.com/armbian/build/blob/0d6757eee7c5c8d1336e325bc6cbeee39df9d6a9/patch/u-boot/u-boot-sunxi/add-cubietruck-emmc.patch Specifically a new patch that affected this line: CONFIG_MMC_SUNXI_SLOT_EXTRA=2 From what I understand, this line is required in order for the machine to recognise other MMCs apart from the SD card. This is the conclusion I got from reading these topics: https://forum.armbian.com/index.php?/topic/2974-boot-from-sdusb-to-emmc/ https://forum.armbian.com/index.php?/topic/4169-help-my-allwinner-box-cannot-boot-anymore/ https://forum.armbian.com/index.php?/topic/4789-problem-with-nand-sata-install/ https://forum.armbian.com/index.php?/topic/3895-cubieboard2-nand-vs-tsd/ I guess he saw my topic after all… Anyway I ran apt-get update/upgrade and booted the CT. On start, I realised the CT booted from TSD since the username is different. Previously, after running nand-sata-install on the TSD, I reflashed the SD card and set it up again with a new username. TSD seems to function and behave just like SD, which is good. It even has the same monitor misalignment problem, which is…not so good. Anyway, I turned off the CT, took out the SD, turned it on again, only to see the serial console output the same exact error: U-Boot SPL 2017.05-armbian (Jun 15 2017 - 02:37:55) DRAM: 2048 MiB CPU: 912000000Hz, AXI/AHB/APB: 3/2/2 Trying to boot from MMC2 MMC Device 1 not found spl: could not find mmc device. error: -19 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### I also found out that the CT requires the SD card in order to boot from TSD. Weird huh? Without SD, CT will not boot. With SD, it boots from TSD instead. The same previous issue with /dev/mmcblk remains, except now it mounts the TSD to root instead of the SD, and now Sd behaves as a removable device. Also, if I change the TSD to /dev/mmcbk1p1 at /boot/armbianEnv.txt, boot.cmd, boot.scr (from mkimage command), and even /etc/fstab, the SD card no longer shows up in df –h and as removable device. It still shows up in ls /dev though. I’m happy that the TSD works proper. However, this recent development is still far from what I need to achieve. I’ll just do some trial and error until I got something.

Hello and hi everyone. So I've got a Cubietruck with the NAND replaced by TSD eMMC. The TSD behaves like an SD card, and previously tested to run OK using Cubieez-TSD. However, I need to run Node.JS on the Truck, and the Cubieez Debian Wheezy Node.JS support stops at v6 (now we're at NodeJS v8). Ubuntu Xenial will still have NodeJS v8 support, so it's good excuse to change to a new OS. I'm using this image to successfully flash my SD card: Armbian_5.31_Cubietruck_Ubuntu_xenial_default_3.4.113_desktop. First time booting the CT from SD, I got the usual prompt, then the desktop loaded. First problem: The screen is misaligned. https://drive.google.com/open?id=0B5XGa48DW48qZzF0OWZ4Y1lZRk0 I opened /boot/armbianEnv.txt and changed the "disp_mode" to "1280x768p60". After reboot, the problem persists, albeit at lower resolution. I figured out the problem can be solved later, so I checked if the TSD is detected or not. Obviously it wasn't: https://drive.google.com/open?id=0B5XGa48DW48qNWVjcllVV2ZzbGM console output: ls dev: mmcblk0 mmcblk0p1 df -h: Filesystem Mounted on /dev/mmcblk0p1 / I modified the script.bin file in /boot. Here's the part that I modified: The important bits were the nand and mmc, although I included (most of) the modifications for reference. With that, I put the new script.bin in /boot (with the original script.bin renamed), and rebooted the CT. Here's the result: https://drive.google.com/open?id=0B5XGa48DW48qQlRlRFFCUGRLVzQ So it detects! Here's the serial console message I got when booting the CT: I fired up nand-sata-install from /usr/sbin/, went thru the menu, choose "install to eMMC(cant remember full text)", with ext4, waithed about 1 hour, then turned off the CT, removed the SD card, then booted the CT. Second problem: Cubietruck failed to boot by itself. The good thing is that the CT can still boot from SD card. Here's the bootup sequence when booting from TSD: I'm guessing I'm guonna need to recompile the u-boot now. Here's the mmcinfo I got from the bootup sequence when booting from SD card: Looks like it only detects the SD card, not the TSD. Based on this topic here: https://forum.armbian.com/index.php?/topic/3895-cubieboard2-nand-vs-tsd/ I guess I need to recompile the u-boot for the TSD. Have no idea how to do it though. Have gone through the current wiki but still trying to get the idea how to do it.