OldBikerPete

I have built a small UPS to provide 5V to an Orange Pi PC Plus, currently running Armbian 5.1. My interface Pi <> UPS is a few digital pins and the control of the UPS is an ATtiny84 14-pin ARM IC. On the Pi side, I'm using a CPP program and the WiringOP library. I have no trouble detecting a low battery and issuing a 'shutdown now' command but I need to monitor the shutdown process and issue an 'ack' signal to the UPS so that it can shut itself down completely once the PI has shut down fully. At the moment I'm issuing the 'ack' at the same time as the 'shutdown now' command and the UPS is programmed to wait 20 seconds before shutting down. This seems a bit hit and miss to me and I'd like to be able to detect closer to when the Pi has actually shut down. Does anyone have any clues for me? Peter

Just a suggestion that may save others from suffering from this problem in the first place. I have been developing a garden watering system for my family's households. It consists of an 'engine' written in 'C' which uses the Wiring OP library to turn on valves and is programmed using text configuration files. These files are created. modified and managed by a web server using python scripts. The web server is accessed using any web browser such as on a smart phone via WiFi. A major design goal achieved has been that the smartphone or other device does not require assist software such as javascript. I made the mistake of moving the system under development from the SD card onto the EMMC early on, then continuing development. DON'T DO THIS. Save moving the system until a stable system is ready for deployment, it's much easier to back up an SD card. I haven't tackled updating an EMMC memory with a later version yet, that is an adventure yet to be enjoyed(?). Peter

I have put together an answer that worked for me. No, I don't want to fund Armbian developers to write SATISFACTORY backup program/s. Firstly, very capable multi-purpose backup program suites already exist for Linux and secondly, this particular backup problem is too deep in the bits and bytes - especially given the clues you have given me. To produce the micro SD card I have described there are a number of simple steps, all executed from the command line interface. The following is quite wordy and tries to be appropriate for users who are not familiar with Linux command line and its suite of utilities. 1. Find or produce an at-least-minimally-set-up appropriate Armbian system on a micro SD card, preferably the same version of Armbian that you are running on your EMMC memory. We are going to extract the bootloader off this SD card and it needs to be appropriate to the Armbian on the EMMC. Alternatively, you may be able to download a binary image, if so, skip steps 3 and 4. 2. Log in as root (for preference) on a command-line terminal to your EMMC-centred PC+ by some means. If you do not log in as root, you will have to preface most (all) of the typed commands given below with 'sudo' and re-enter your password several times. 3. Insert this SD card into the OrangePi PC Plus that you wish to clone the Armbian from. Wait a few seconds for Armbian to recognise it then type 'ls /dev/mmcblk*' Armbian should respond with something like: /dev/mmcblk0 /dev/mmcblk1 /dev/mmcblkboot1 /dev/mmcblk0p1 /dev/mmvblk1boot0 /dev/mmcblk1p1 mmcblk0 is the SD card and mmcblk1 is the EMMC memory. 4. Plug a USB stick into one of the USB2 ports on the board. Armbian will recognise this as /dev/sda with a file system in /dev/sda1 and mount it at /media/<USERNAME> where <USERNAME> is some username that you were logged in as the last time you plugged in a USB stick. 5. Type the command 'dd count=8192 if=/dev/mmcblk0 of=/media/<USERNAME>/bootloader.img (do not add any spaces around the equals signs) and the bootloader binary image will be copied off the SD card onto the USB stick in less than a minute. 6. Having a copy of the required bootloader on the USB stick, if you do not wish to over-write the contents of the SD card, replace it with one at least as large as the EMMC memory. Type the command 'fdisk /dev/mmcblk1' then press 'p' and 'Enter' then 'q' and 'Enter'. Be very careful to not do anything else here because this program CAN destroy your EMMC system if mishandled. Armbian on my PC+ displayed: Device Boot Start End Sectors Size Id Type /dev/mmcblk1p1 8192 15117183 15108992 7.2G 83 Linux 7. Using 'End' sector number, now over-write the SD card with command: 'dd count=15117183 if=/dev/mmcblk1 of=/dev/mmcblk0' Note that we are copying the file system plus the first 8192 sectors which contains the bootloader and the master boot record (MBR). We are going to write the bootloader we saved earlier into that low space and need to leave room. 8. Copy the bootloader obtained earlier into that space of 8192 sectors at the start of the SD card: type 'dd count=8192 if=/media/<USERNAME>/bootloader.img' In the process we will over-write the first sector on the SD card which contains MBR and the partition table with the MBR from from the earlier SD card which will contain data almost certainly irrelevant to the file structure we originally copied from the EMMC. 9. The next step is to again copy data from the EMMC to the new SD card, limiting the copy to just the first sector, restoring the MBR and partition table data to correctly duplicate that structure to be relevant to the partition we earlier copied from the EMMC. type 'dd count=1 if=/dev/mmcblk1 of=/dev/mmcblk0' 10. The final step is to mount the newly prepared SD card and edit the UUID in its Boot folder. type 'mount /dev/mmcblk0p1 /mnt' This attaches the SD partion to the /mnt folder. type 'cd /mnt/boot' make our area of work the default. type 'blkid | grep mmcblk0p1 >newUUID.txt' This saves the UUID we must use into the file /mnt/boot/armbianEnv.txt 'cat newUUID.txt' will show the saved UUID and more eg: /dev/mmcblk0p1: UUID="48a407c4-ca6e-4a21-ac94-71a9eac17295" TYPE="ext4" PARTUUID="709ff8b6-01" You must now edit the file ./armbianEnv.txt with an editor such as 'nano' (I prefer joe) and replace the UUID in the line such as the following with the one obtained by the above method. rootdev=UUID=828b3b50-226d-4f90-b607-2bccb4031c24 All done. I suggest that the next operation should be to save an image of the SD card just created onto the USB stick, eg: dd count=15117183 if=/dev/mmcblk0 of=/media/<USERNAME>/ArmbianSystem.img unmount the USB stick eg: umount /dev/sda1 and the new SD card eg: umount /dev/mmcblk0p1 then make a backup copy of that image by your usual file backup procedures. If you have another Orange Pi PCplus, you should plug the new SD card in and test it before packing up and opening a well-earned beer. Peter. PS. The above assumes an 8192-sector-sized bootloader at the start of the EMMC and SD cards. I have seen some SD cards formatted by Windows for which this is not the case. You should check for this using fdisk before proceeding.

NOTE: Despite similar topic names, a search did not find a topic which even remotely addressed my topic on this site. I have an OrangePi Pcplus on which I have successfully transferred my working system from SD card to the on-board EMMC. Now, on the assumption that the EMMC may eventually become corrupted or the board dies. (Hey, __it happens!) I need to create, from the currently running system, an SD card which I can plug into a brand new Orange Pi PCplus and have it boot from that card the system I was was running on the old board at the time I made the backup - which I can then transfer to the new board's EMMC. Obviously, this same SD card image would be very useful for making multiple systems. At present, the only VERY UNSATISFACTORY procedure that seems to be available is to tar the entire EMMC, make an SD card from the same image I originally used to build the original system and untar the whole lot over the top which may or may not work at all, I haven't tried that and I am very skeptical that it would work without a lot of editing. Can anyone shed some (lucid) light on this problem? Peter.

Hello forumees. I am running as root on an OrangePI Zero+ which uses a H2 processor running a CL version of arrmbian 3.4.113 which works fine. I have recently obtained a SimCom SIM7600CE GSM/GPS module which has only a USB interface. I tracked down drivers for it but the Linux version must be compiled to a module which I have managed (with a number of warnings) after a couple of hiccups. Now trying to install the compiled module is resulting in error messages. I think the problem is compatability with armbian which is beyond my expertise, so I am asking for help. Below is the CL dialog of my attempts to install the module. ```````````````` root@gpsControl:/usr/src/SIM7600LinuxDriver/GobiSerial# insmod GobiSerial.ko insmod: ERROR: could not insert module GobiSerial.ko: Unknown symbol in module ############ root@gpsControl:/usr/src/SIM7600LinuxDriver/GobiSerial# cd /lib/modules/3.4.113-sun8i root@gpsControl:/lib/modules/3.4.113-sun8i# ls build modules.alias modules.builtin.bin modules.devname modules.symbols GobiSerial.ko modules.alias.bin modules.dep modules.order modules.symbols.bin kernel modules.builtin modules.dep.bin modules.softdep ########### root@gpsControl:/lib/modules/3.4.113-sun8i# modinfo GobiSerial.ko filename: /lib/modules/3.4.113-sun8i/GobiSerial.ko license: Dual BSD/GPL description: GobiSerial author: Qualcomm Innovation Center version: 2011-07-29-1026 srcversion: 09B011938149D9A32402EAF alias: usb:v1E0Ep9001d*dc*dsc*dp*ic*isc*ip* alias: usb:v05C6p9000d*dc*dsc*dp*ic*isc*ip* alias: usb:v05C6p9046d*dc*dsc*dp*ic*isc*ip* alias: usb:v05C6p1E0Ed*dc*dsc*dp*ic*isc*ip* alias: usb:v05C6p920Dd*dc*dsc*dp*ic*isc*ip* alias: usb:v05C6p920Cd*dc*dsc*dp*ic*isc*ip* depends: usbserial vermagic: 3.4.113-sun8i SMP preempt mod_unload modversions ARMv7 p2v8 parm: debug:Debug enabled or not (bool) ################# root@gpsControl:/lib/modules/3.4.113-sun8i# depmod GobiSerial.ko depmod: ERROR: Bad version passed GobiSerial.ko root@gpsControl:/lib/modules/3.4.113-sun8i# ```````````````````````````````` I have attached the source of the module, the Makefile and a full log of the 'make all' Makefile GobiSerial.c make.log

Thank you for this pointer. I'll find one and buy it.

Thank you for the tip Igor - even if I've settled on a config now - maybe I'll implement it in a lter project. Thank you also for the pointer to SD card performance. Useful. Since the card writer is plugged into an Intel I7 CPU system running at 4GHz, I might even be able to go a little faster than those benchmarks.

It's on a USB 2.0 port. Bought the card from Australia POST, so I doubt that it's a brummy one.

The card is a SanDisk Ultra SD, sadly the SD writer is USB 2.0 and a slow one at that (1MB/sec flat out). Recommendations for a fast writer gratefully received.

The image I used was "Armbian_5.30_Orangepipcplus_Ubuntu_xenial_default_3.4.113.7z" on the OrangePi PC Plus. I immediately ran 'apt update' followed by 'apt upgrade' and then started trying to get an access point started. I tried Lim Han Yang's instructions then create_ap and finally ‘armbian_config’. It's probably not surprising that armbian_config didn't produce a result after those two prior attempts messed with settings. In any case at that point I decided to do it my way rather than search through config files and learn about unfamiliar drivers to find where I needed to make changes. I used "Armbian_5.35_Orangepizero_Ubuntu_xenial_default_3.4.113.7z" on the OpiZ. My SD card writer is terribly slow (hours to write an image) so I don't plan to install a fresh image and produce a link for you at this time.

I have been searching the net trying to find out how to set up the WiFi interface on an Orange Pi or a Raspberry Pi 3B as an access point. I have to have an access point for a project I have in hand. I found the instructions by Lim Han Yang but they just failed entirely on two out of three candidate boards with the third, an Orange Pi PC Plus, producing a point that is visible to an Android tablet but refused to authenticate. I tried the create_ap procedure from github but that crashed on all three boards when dnsmasq hung. I tried ‘armbian_config’ on the Orange Pi PC Plus which was running the appropriate Armbian image. That didn’t do anything usable. Reasoning that the distributed software assumes that the board will always be used as a WiFi client and that a lot of the setup and software aimed at that would interfere with setting WiFi up to be an access point, I decided to strip away all of the networking software and rebuild it using related versions of programs that have worked for me on desktop linux machines. I tried this on the Orange Pi PC plus first - AND IT WORKED. I tried it again on an Orange Pi Zero, which is the platform I want to use for my project – AND IT WORKED. Here is how I did it. My aim in doing this is to have just a WiFi access point without connection to anywhere else for a project that may be solar-powered a few hundred klicks into the outback and just as far from an internet connection. The boards I am looking at also have a CAT5 connection but my only interest in that is maintenance and software updates, so any possibility of bridging between the two is viciously suppressed. If I were trying to set up a bridged connection, I would use ‘iptables’ to create the appropriate routing. The Wifi is set up with a static IP and a dhcp server to provide connecting clients with an IP address and the hostapd binary to manage connection and WPA2 authentication. The CAT5 point is set up as a dhcp client, although that could have been given a static address also and may get one if remote-area maintenance with a laptop requires it. Install an Armbian image on your platform of choice. Other distros may work but I haven’t used them as I want a simple CLI linux. Assuming that your board automatically connects to the internet, do ‘apt upgrade’ to bring everything up to date. If your board’s internet connection and console access is through WiFi then things may get sticky for you. I used either an SSH connection through CAT5 wiring or the Orange Pi boards debug serial interface at 115200 baud via a 3.3Volt (5Volt WILL destroy the board!) TTL serial to USB interface for console access during these modifications. Login as the default user and if it is not root, do ‘sudo passwd root’ and create a password for root. This will enable you to log in as root and remove the need to use sudo (which I forget to do half the time – annoying). Either delete or ‘chmod a-x’ the wpa_supplicant, dhclient and dnsmasq (if installed) binaries. The scripts which invoke these will still be active and will fail – an untidy situation but I don’t care. Use whereis to find them. Do ‘apt install dhcpcd5 udhcpd hostapd’ (apt-get may work too). You may want to ‘apt install’ a text editor at this point, ‘nano’ is a good choice but I prefer ‘joe’ as I’ve been using it for years. ‘vi’ is long overdue for relegation to the deepest pits of hell. cd to ‘/etc/default’ and edit ‘hostapd’ to add DAEMON_CONF="/etc/hostapd/hostapd.conf" edit ‘udhcpcd’ to read: DHCPD_ENABLED="yes" DHCPD_OPTS="-S" remove dnsmasq if it exists. cd to ‘/etc/network’ and make ‘interfaces’ , ‘interfaces.hostapd’, ‘ interfaces.r1’, ‘interfaces.r1router’ and ‘interfaces.r1switch’ as in the attachments. Bear in mind that IP numbers, net masks etc. in these files are chosen to suit my preferences, your mileage may differ. cd to ‘/etc’ , do ‘rm –r dnsmasq.d’ and ‘rm –r dhcp’ and create or modify dhcpcd.conf and udhcpd.conf to be as in the attachments. Once again, IP numbers etc. are my preferences. This might be a good time to edit ‘hostname’ to be something you want it to be. cd to ‘/etc/hostapd’ and create ‘hostapd.conf’ as in the attachments. You may want to add telnet capabilities, in which case do ‘apt install inetd telnet’ then ‘update-inetd –-enable telnet’ then if you want to login as ‘root’ over telnet, edit ‘/etc/securetty’ to include ‘pts/0’ and ‘pts/1’ etc. . NOTE THAT TELNET IS AN INSECURE COMMUNICATION METHOD but it suits my purposes. The above setup has been running reliably for a couple of months now and (touch wood) I see no reason other than hardware failure that would change that. ConfigurationFiles.zip

Sorry about the long delay. I've had issues! Installed I2C-tools and ran i2cdetect on an Orange Pi PC plus and an Orange Pi Zero - both running the same Armbian distro. The results are below. /dev/i2c-0 detected a non-existent (as far as I know) device at 0x48 and the /dev/i2c-1 device detected nothing at all. In the interval since my first post on this subject, I wrote a bit-bashing library for the I2C bus on connector pins 3 and 5 and this works a treat with a DS3231 clock chip located at address 0x68 on the I2C bus on both CPUs using the gpio pin part of the WiringOP library to access the bits and a microsecond delay routine. Note that i2cdetect did not find my clock chip on the bus. root@orangepizero:~# i2cdetect 0 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0. I will probe address range 0x03-0x77. Continue? [Y/n] y 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- root@orangepizero:~# i2cdetect 1 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-1. I will probe address range 0x03-0x77. Continue? [Y/n] y 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- Peter. Note that I'm investigating a message that flashes by at boot-up on the debug serial port. 'FAILURE: Linux Kernel modules failed to load'

I've installed this library on an Orange Pi PC Plus running 'Armbian 5.31 stable Ubuntu 16.04.3 LTS 3.4.113-sun8i' with all updates and I would like to use wiringPiI2C but it doesn't work with either /dev/i2c-0 or /dev/i2c-1. My USB storage CRO device shows no output at all when I attempt a write to an I2C device on connector pins 3 and 5 (BCM pins 2 & 3). the 'gpio' app and 'blink' example apps that come with the library wiggles these and other pins as outputs, no trouble at all. I'm porting a library that interfaces to a DS3232 or DS3231 real-time-clock chip from Arduino and have used the initialisation sequence from the example in the WiringOP library as below. 　 static int sfd; 　 void DS323xRTC(bool *retVal) { wiringPiSetup(); if((sfd = wiringPiI2CSetupInterface("/dev/i2c-1", DS323x_I2C_ID)) < 0) { *retVal = false return; } // Control reg All disabled, EOSC low = oscillator enabled. wiringPiWriteReg8(sfd, CONTROL_REG, 0x00); wiringPiWrite(sfd, 0x08); // Status/Control reg, Enable 32kHz output *retVal = true; } 　 I note that the I2C examples that come with this library drive an I2C device via software bit-bashing. 　 Has anybody been able to use from C++ the I2C interface built into the H3 chip? If so, how did you get it working? 　 Peter. 　

Thank you, thank you. Now all good. Thank you also for fixing the upgrade problem.