chwe

I've added RPi 7" DSI touchscreen support to the 4.4 kernel, I will work on patching it into mainline as well, but no guarantee, it is not the cleanest of drivers (requires modifying the dw-mipi-dsi.c file), and this patch is MiQi safe.
 
This would have been done earlier, but I had to make sure it would work by declaring the hardware in the device tree instead of explicitly in the kernel source. (and make sure it didn't break the MiQi)  As it turns out, I was incredibly overthinking the problem, cheers to the Linux kernel devs.
 
Tested OK with this configuration: 
Tinker with DSI Display Tinker with DSI Display and HDMI display (displays are "on top of each other" on first boot, drag the smaller display around in the desktop settings and you have an extended desktop) Touchscreen driver is not robust against this configuration.  It tries to cover the full extended desktop. Tinker with only HDMI (no ghost devices/errors/crashes. Tested to be sure the drivers could cope with not finding the hardware, as the device tree entries are still there) MiQi (as it does not have the DT entries, merely a test to make sure no source/driver interactions)  

We have search feature: "mali mainline" would give you something useful. I merged it with an existing topic.
https://www.armbian.com/search_gcse/
 

To develop, test and debug dependencies and finally implement this feature cost/would cost roughly 5.000 (depend from which perspective you look) volunteering working hours from experts in the field. I am always happy when we receive a donation since it is a rear event. Sometimes people donate a box of beer which makes my wife angry and sometimes pcs of hardware.

Donations are like love. Unconditional.

Hi there, this very short tutorial is a solution when you need to backup/clone/save as small *.img file as possible of your whole fully bootable system (e.g. you have 8GB card but you want to make smaller system image for 2GB card). And another reason why I created this tutorial - I need to burn the same image to many microsd cards.
 
I am using Windows (yup, hate me know)  and Debian in these steps:
Put your microsd card to Windows machine and make image of card with Win32diskimager. If your card is e.g. 8GB, you get *.img file with the same size (my name backup.img). Now in linux maxine (in my case Debian virtual machine) we are going to work with backup.img file. Run these commands in terminal (if you are not root use sudo at the start of each line) modprobe loop losetup -f losetup /dev/loop0 backup.img partprobe /dev/loop0  
Run gparted with this command and move slider of main partition to the left to make partition smaller (leave some space, e.g. I left 400MB free space)
gparted /dev/loop0 Click on Apply once you are happy with it.
We can unload loopback device now
losetup -d /dev/loop0  
With fdisk find out end of last block
fdisk -l backup.img   
 In my case last block is 3571711 so I run command 
truncate --size=$[(3571711+1)*512] backup.img  
Done! Size of your backup.img file should be now about 1.5GB.
 
 
You can burn this new backup.img file to another (or the same) card/s now. In my case I dramatically reduced time needed for burning data to many many cards (it saves hours/days when you need to burn a lot of microsd cards). Enjoy!
 
P.S. this can be done also with just Debian, so no need for Windows, in this case you just need to make first step with backup.img with linux command (e.g. dd). And of course you can set up a script on your newly burned card to expand system partition to the whole microsd size during first boot, if needed. 

which brands? models? Would be interesting so that others can try to reproduce your findings.

Hi, I'm leaving for a few days , so given parameters it might be someone needed. For these parameters, display works with 1280x800 , but I do not know if these values are optimum values. I'll do some more tests after returning, but but for now it works correctly     {HDMI1280x800_60, 0,83460000, 0, 1280, 800, 1680, 200, 64, 136, 828, 24, 1, 3, 1, 1, 0, 0, 0} {{Video ID  ,4 , 0, 96, 5, 3, 3,  1,   1, 0,  0,  0, 144, 64, 136, 32, 28, 1,  1 }} PLL_VIDEO 334

Problem is that there are at least 4 different RasPi PSU's that I have seen and not a single one of them is suitable for powering the tinkerboard which draws upto 3 x more current under load than any of the Pi models. The 2.5A Pi PSU we tested (comes with the Pi3 Kit) would only actually deliver ~1.4A reliably and when it gets hot it gets very unreliable. Thats why I asked  for the numbers off the PSU. The most power hungry PI model (3B) uses 30-40% of the total current than the tinkerboard at max load (see attached chart). Even if you connect the Pi PSU through the GPIO pins there still isnt enough current from any Pi branded PSU I have seen to power the tinkerboard reliably. As a general rule, RasPi accessories (like the boards) are made to very low standards and budgets and should be avoided.
 
If you can provide details for me to replicate your software, ramdisk, swap and workload I can have a look at reproducing the problem and finding a solution or at least a cause. The fact you have swap on SD make me shudder!
 
 

So, 8-12$ (depends if you calculate the price for an orange pi with or without shipping) is expensive? I do some testings with the opi pc+ in AP mode, but to be  honest I like the 'connecting sbc to access point wired, and connect nodes normally to this ap' approach more. It's less load on my SBC and capabilities of my AP are better (throughput, which is of no interest in your case but ping seems also to be better).
 
Just have a look with the google search engine here if you find something that fulfills your needs. It's a bit out of my knowledge cause my sbcs are mostly wired.  
https://www.armbian.com/search_gcse/

When you started with a freshly burned SD-Card running mainline something like this should appear within your first login.

 
If you did it via armbian-config, something like this appears:

or this (if you moved to nightly):

And if you had a brief look on armbian download page you would see something like this:

and this:

 
I can't repeat your experiment, booted a 4.11.7 image (wifi was visible, cause not deactivated on this image), followed by booting a 3.4.113 image and wifi worked, without any issues (no long-term test!!).. So it might be hard to figure out why wifi on your board is broken now. If you look around here, you'll see that wifi on this board is somehow questionable (just an example, you'll find multiple threads about this issue).
A personal opinion: Using a older nightly with 4.11.7 just cause wifi wasn't deactivated by default isn't really smart (you got maybe wifi, but cause you've to freeze kernel and board upgrades, you'll miss all the improvements on board support). It seems that the wifi driver for XR819 is in such a bad shape that nobody wants (or is able) to work on it. If I would need wifi on one of my opi0, I'd go for a usb wifi stick. If I would need wifi permanently, I'd go for another board with better wifi support.
 

I havent tried Armbian yet but I had the same problem when I created a buildroot based firmware using eudev.
 
I added a new udev rule:
SUBSYSTEM=="drm", ACTION=="change", RUN+="/usr/local/bin/hdmi-toggle" in a new file (hdmi.rules) in /etc/udev/rules.d
 
Then save the bash script below to /usr/local/bin/ which will be triggered by the udev rule and toggle the display
#!/usr/bin/env bash USER="$(who | grep :0\) | cut -f 1 -d ' ')" export XAUTHORITY=/home/$USER/.Xauthority export DISPLAY=:0 ########### Settings ########### # Use 'xrandr' to find these DP="DP-1" VGA="VGA-1" HDMI="HDMI-1" INTERNAL_DISPLAY="LVDS-1" # Check /sys/class/drm for the exact location DP_STATUS="$(cat /sys/class/drm/card0-DP-1/status)" VGA_STATUS="$(cat /sys/class/drm/card0-VGA-1/status)" HDMI_STATUS="$(cat /sys/class/drm/card0-HDMI-A-1/status)" # Do no change! EXTERNAL_DISPLAY="" # Check to see if the external display is connected if [ "${DP_STATUS}" = connected ]; then EXTERNAL_DISPLAY=$DP fi if [ "${VGA_STATUS}" = connected ]; then EXTERNAL_DISPLAY=$VGA fi if [ "${HDMI_STATUS}" = connected ]; then EXTERNAL_DISPLAY=$HDMI fi # The external display is connected if [ "$EXTERNAL_DISPLAY" != "" ]; then # Set the display settings xrandr xrandr --output HDMI-1 --auto else # Restore to single display xrandr --output HDMI-1 --off fi exit 0  

legacy
 
For everything inside a case I can't give you an answer, my OPi laying somewhere around. But as bozen mentioned, this boards aren't running stable inside a case and I think he tested it more than once. At the moment I wouldn't recommend this board for high load use cases. Seems that rev. 1.4 is somehow a design failure. I have one running since ~20d stable (without case, last reboot was due to updates not crash, legacy) with node-red on it over ETH without problems. You can try with a heat sink and set max_freq with h3consumption to 912MHz (this should aviod feeding the CPU with 1.3V) but I'm not sure if this is enough to avoid overheating. 

8812au ... and also anything that has Ralink RT5572 or RT3572. Those are not AC but are at least dual band up to 2T2R with good Linux support. I am working on to setup proper testing environment. The current problem is the other side. My router is just 10cm away and I will need to set up another AP. 2.4 band performance is pretty irrelevant in an urban area but our apartment condo has a lot of steel inside walls and it actually works quite well. Except Xradio
 
I have 13 wireless adaptors in a dedicated USB3.0 hub and two more are on the way. The plan is to make some scripts and update the database compatibility/kernel properties. All this setup is early WIP.

Completely forgot this stock androids on eMMC... It's not that uncommon..  
 
There's a reason why we push people to the usb-ttl.  
Even if it's not solved everything yet, you see now what's going on during boot. 

Alright, I think I got something working !
 
MPV using MPP seems to work and is able to read a 1080p WebM file and output a very fluid image !
However, I only tested this with 1m30s sample files so I'll have to test this more seriously.
 
Still, having the VPU driver works on 4.13 kernels is nice ! Now, I'll need testers !
 
So here's a patched kernel build, including the VPU driver in it :
https://github.com/Miouyouyou/RockMyy-Build/releases/tag/v4.13-VPU-Test
 
This build include patches that makes logging VERY NOISY when playing files. If everything works nicely, I'll remove the noise.
 
Here's the repository containing the patches applied :
https://github.com/Miouyouyou/RockMyy/tree/VPU_Work_tests
 
And here's the patch itself :
https://github.com/Miouyouyou/RockMyy/blob/VPU_Work_tests/patches/kernel/v4.13/0012-Slight-butchering-to-test-the-VPU-driver.patch
 
Here's the repository containing the working VPU code :
https://github.com/Miouyouyou/rockchip-vcodec/tree/retry
 
 
 
Testing the VPU
 
Now, in order to test the VPU driver, you'll need something that work with it !
I tested it with MPP and MPV. So if you want to test it like I did, you'll have to recompile MPP and MPV, and also know how to download and use ARM Mali user-space binary drivers and make them work through the DRM interface.
https://github.com/rockchip-linux/mpp
https://github.com/LongChair/mpv
https://github.com/rockchip-linux/libmali/
 
Have fun !
 
Whether everything works or you got a crash, don't hesitate to reply on this thread.
If you something went wrong, please provide any crash message that might appear in dmesg !

Hmm your 'wishlist' isn't that small.  To my knowledge there's no 'modern' SBC with open source GPU drivers. I think, you have to live with it. Most of these boards have a Mali GPU, so legacy instead of mainline seems to be a better choice for your use case. 
My personal favourite would be the Orange Pi PC Plus for these reasons:
You get it for ~35$ with a case and barrel plug powersource (3 Amp @ 5V). It have 3 native USB plus the otg micro USB. So you solve two problems at once.  Firstly you can be sure that no one uses a not appropriate micro usb cable for mobile phone charger to power this board and you have the otg still available if you need it somehow. armbian runs smoothly on it to my knowledge there's no big issue with this board. Maybe someone like @martinayotte can give you more insights cause he owns more than one. I don't know how good it is with your 3D stuff cause mine run as a headless server and I never tried it (don't have any HDMI monitor free to test these things ).  Maybe you have to buy one first for evaluation before you decide if it's a good board for these stuff or look at google if somebody did these. There's a connection for cameras and there are cameras available on their aliexpress online store (~6$). There's an onboard 'sound card', if you don't do really fancy stuff this one should work, so you don't need any USB sound cards (to be honest, I never tested mine). 8GB onboard eMMC, so you don't have to buy a reliable SD-Card for each board. Buy one for each class, with everything installed and configured, run nand-sata-install before give the SBC to the kids and let them play with it. If they damage something on software side, you can simply insert your "back up" SD-Card and re-run nand-sata-install again and they can start do brick it again.   Most of these arduinos and other small 'thingies' can be programmed via serial. There's one on your pin header so you would save one USB.  IR receiver and microphone on board. So two more things to play around for the kids.   As you can read in various threads here, all these cheap SBC haven't that an exciting wifi performance. To my knowledge the wifi chip on the OPI plus PC isn't the worst one soldered on such a board. 

You could do locally on your own tree by editing the config/boards/orangepilite.conf file, and change the line below :
KERNEL_TARGET="default,next,dev"  

For those of you who're interested in running a CMS on Armbian I've a small tutorial how to get django CMS working. If you're not interested in the 'story' just want a step by step installation guide, scroll to the end of this post, there you find it. 
 
Story:
Following their installation guide it fails during creation of a django project with 'djangocms -f -p . mysite'.
 The error looks something like:
After a brief google search I found that other also had similar problems. It seemed that pillow is the problem while the whole installation failed. Unfortunately pip pillow also failed, and this one helped me to install pillow. After installation of libpq-dev python-dev  libjpeg8-dev,  pillow could be installed without any issues and 'djangocms -f -p . mysite' too. Starting the CMS with 'python manage.py runserver' worked too but unfortunately wasn't accessible over local network (since all of my armbian devices are running headless, I need access over network to the CMS). Inspired by a next google result, I found out that I should run the CMS on the SBCs network IP not on localhost by using 'python manage.py runserver 192.168.0.44:8000'. Which led in a next error.  
... DisallowedHost: Invalid HTTP_HOST header: '192.168.x.xx:8000'. You may need to add u'192.168.x.xx' to ALLOWED_HOSTS. Some housekeeping in the settings.py and restart of the CMS led than to a working system.
# SECURITY WARNING: don't run with debug turned on in production! DEBUG = True ALLOWED_HOSTS = ['192.168.x:xx'] Lessons learned:
Even if you're not a dev and your background is limited, it is possible to get something like this CMS to work if you're able to use google. By reading through google results and have a look on the output errors during installation you learn much more about your project/SBC than just following the step by step procedure I'll show at the end of this post.  The 'tarzan approach' - Tarzan/me swings from tree/error to tree/error holding on to elastic lianas/error logs works but it makes sense to repeat this installation after get a straight forward approach for the next time you'll use it.  
Step by step procedure:
Installing package dependencies sudo apt-get install libpq-dev python-dev virtualenv libjpeg8-dev
Make your virtualenv folder for all your CMS projects (since django cms is capable to run multiple cms at once it might make sense to have a 'parent folder' where all of them are placed): mkdir CMS --> cd CMS
Create and activate a virtual env: virtualenv env --> source env/bin/activate
Update pip: pip install --upgrade pip
Use the django CMS installer: pip install djangocms-installer
Create a new directory to work in: mkdir tutorial-project --> cd tutorial-project
Run it to create a new Django project: djangocms -f -p . mysite
Setup for access via LAN: nano mysite/settings.py  --> ALLOWED_HOSTS = ['192.168.x:xx'] (IP of yor SBC)
Start up the runserver: python manage.py runserver 192.168.x.xx:8000
Your CMS will be accessible via browser on your SBCs IP port 8000.
 
Tested on:
OPi 0: ARMBIAN 5.31 stable Ubuntu 16.04.2 LTS 3.4.113-sun8i Odroid HC1: ARMBIAN 5.33 user-built Debian GNU/Linux 8 (jessie) 4.9.46-odroidxu4 

For those of you who're interested in running a CMS on Armbian I've a small tutorial how to get django CMS working. If you're not interested in the 'story' just want a step by step installation guide, scroll to the end of this post, there you find it. 
 
Story:
Following their installation guide it fails during creation of a django project with 'djangocms -f -p . mysite'.
 The error looks something like:
After a brief google search I found that other also had similar problems. It seemed that pillow is the problem while the whole installation failed. Unfortunately pip pillow also failed, and this one helped me to install pillow. After installation of libpq-dev python-dev  libjpeg8-dev,  pillow could be installed without any issues and 'djangocms -f -p . mysite' too. Starting the CMS with 'python manage.py runserver' worked too but unfortunately wasn't accessible over local network (since all of my armbian devices are running headless, I need access over network to the CMS). Inspired by a next google result, I found out that I should run the CMS on the SBCs network IP not on localhost by using 'python manage.py runserver 192.168.0.44:8000'. Which led in a next error.  
... DisallowedHost: Invalid HTTP_HOST header: '192.168.x.xx:8000'. You may need to add u'192.168.x.xx' to ALLOWED_HOSTS. Some housekeeping in the settings.py and restart of the CMS led than to a working system.
# SECURITY WARNING: don't run with debug turned on in production! DEBUG = True ALLOWED_HOSTS = ['192.168.x:xx'] Lessons learned:
Even if you're not a dev and your background is limited, it is possible to get something like this CMS to work if you're able to use google. By reading through google results and have a look on the output errors during installation you learn much more about your project/SBC than just following the step by step procedure I'll show at the end of this post.  The 'tarzan approach' - Tarzan/me swings from tree/error to tree/error holding on to elastic lianas/error logs works but it makes sense to repeat this installation after get a straight forward approach for the next time you'll use it.  
Step by step procedure:
Installing package dependencies sudo apt-get install libpq-dev python-dev virtualenv libjpeg8-dev
Make your virtualenv folder for all your CMS projects (since django cms is capable to run multiple cms at once it might make sense to have a 'parent folder' where all of them are placed): mkdir CMS --> cd CMS
Create and activate a virtual env: virtualenv env --> source env/bin/activate
Update pip: pip install --upgrade pip
Use the django CMS installer: pip install djangocms-installer
Create a new directory to work in: mkdir tutorial-project --> cd tutorial-project
Run it to create a new Django project: djangocms -f -p . mysite
Setup for access via LAN: nano mysite/settings.py  --> ALLOWED_HOSTS = ['192.168.x:xx'] (IP of yor SBC)
Start up the runserver: python manage.py runserver 192.168.x.xx:8000
Your CMS will be accessible via browser on your SBCs IP port 8000.
 
Tested on:
OPi 0: ARMBIAN 5.31 stable Ubuntu 16.04.2 LTS 3.4.113-sun8i Odroid HC1: ARMBIAN 5.33 user-built Debian GNU/Linux 8 (jessie) 4.9.46-odroidxu4 

Since 'benchmarking gone wrong': https://www.cnx-software.com/2017/06/18/nanopi-neo-nas-kit-review-assembly-openmediavault-installation-setup-and-benchmarks/#comment-543160 (btrfs and iozone's 'direct IO' mode don't match so you get numbers without meaning since not 'disk' performance is measured but mostly filesystem performance due to buffering)

Kernel 4.4 does support bluetooth.  If you look at the original post you'll see a status for the different kernels, a link, and a command that must be run at boot.  A program "rtk_hciattach" is necessary to make the bluetooth stack talk to the bluetooth hardware.
 

Try to borrow a USB-TTL Serial from a friend ...

Only 'ETH leds on' is a not so uncommon behaviour when SD-Card is not there or not recognized.
4gb? Seems that you use a really outdated SD-Card, did you tested it with an other one? As @martinayotte suggested, best way to debug is an USB-TTL. But I would additionally keep an eye on your SD-Card.

If anyone is still following this then adding a command to rc.local isn't a complete fix. I left the unit running for 7 days without doing anything to it and power management has re-enabled itself again. This would explain why other distros have bodged in cron jobs to periodically disable power management. There must be some re-initialisation mechanism somewhere I presume. 

Armbian server image is ~1.5GB, since the smallest reliable SD-Cards for SBCs are 8GB. But it confuses me that you bought a SBC without HDMI for gui programs (Lazarus). So, did you buy the OPi Zero or the OPi Zero Plus2? If it is the original OPi Zero this might be a bad decision for your use case: no HDMI and a questionable wifi (XR819). You might think about a OPi One/Lite/Pc/PcPlus (3 UART on Pinheader, without using the seperated debug UART)?

Do I understand you right? Your CHG340 is connected to your computer, thats were your COM3 comes from, so it might be a Windows machine and you try to connect with this serial to usb adapter to get access to your orange pi zero? Baud Rate is correctly? Should be 115200. You use the 3 pin header to get access? (ground, RX & TX @ 3.3V). 
 
RX -->TX and TX-->RX connected?
My CHG 340 changes sometime COM address on windows machine (don't know why) just to make sure you don't 'ride a dead horse'..  

After a longer break, the dogafu experiment was online again. Since rev. 1.4 of the OPi0 is prone to overheat I tried some possibilites to avoid these situations. Cause thermal throttling leds normally to a CPU frequency of 768MHz, it's obvious that no throttling should occur as long as your max cpu freg. is sett to 768MHz.  stress -c 4 ran smoothly without any issues for more than one hour.  Wifi seems to be still unstable. Ping is horrible high (iwconfig showed that power management is off). Normally I lose connection after 5-12 hours (I'll test it now with power management on). Sometimes crashing of wifi leads to crash the whole system so no connection via serial console possible.
Compared to Igor, I'm not 100% convinced that thermal readings on the SoC are false. The temperature difference between DS18b20 and internal temperature could also come from 'point of measurement'. Measurements outside from a liquid are always hard. There are so many possibilities that the measured temperatures are too low (e.g. contact surface, insulation/heat spreading between cpu and SoC surface). I need a rev. 1.1 board to log SoC temperature with the same setup. Since I don't own such a board, I've no possibility to do this.  Maybe I test temperature on my OPi pc plus to get a 'feeling' of the temperature readings from DS18b20 compared to internal readings. 
I also tested if they broke something to feed the CPU. Measurements on the SY8113B showed that the CPU is mostly fed with 1.14V idle and 1.37V if I run stress -c 4. So it seems that this is not the case. I also noticed that the SoC temperature is 2-3°C higher when wifi is running. It might be that the thermal design of the rev. 1.4 board is worse compared to the rev. 1.1 board.
All the data is logged with a second OPi 0 connected via ETH to the the network with node-red. This one runs now since 18d without any issues (last reboot wasn't cause it crashed ). But node-red isn't such a high load for this board...