chwe

http://bfy.tw/HIy8

Okay, this script is confirmed to work in a XU4  image with desktop and kernel NEXT 4.14.29 nightly:
 
#!/bin/bash if [ $EUID != 0 ]; then sudo "$0" "$@" exit $? fi # User setup grep -q odroid /etc/passwd || adduser --no-create-home --disabled-login --disabled-password --gecos "" odroid usermod -aG video $(getent passwd 1000 | cut -f1 -d:) # Package installation wget http://deb.odroid.in/5422-s/pool/main/m/mali-x11/mali-x11_20170718-r17p0-20503ff-3_armhf.deb dpkg -i mali-x11_20170718-r17p0-20503ff-3_armhf.deb rm mali-x11_20170718-r17p0-20503ff-3_armhf.deb wget http://deb.odroid.in/5422-s/pool/main/x/xf86-video-armsoc/xserver-xorg-video-armsoc-exynos_1.4.1-0ubuntu4_armhf.deb dpkg -i xserver-xorg-video-armsoc-exynos_1.4.1-0ubuntu4_armhf.deb rm xserver-xorg-video-armsoc-exynos_1.4.1-0ubuntu4_armhf.deb wget http://deb.odroid.in/5422-s/pool/main/x/xf86-video-armsoc/xserver-xorg-video-armsoc_1.4.1-0ubuntu6_armhf.deb dpkg -i xserver-xorg-video-armsoc_1.4.1-0ubuntu6_armhf.deb rm xserver-xorg-video-armsoc_1.4.1-0ubuntu6_armhf.deb wget http://deb.odroid.in/5422-s/pool/main/libs/libsdl2/libsdl2-2.0-0_2.0.4%2bdfsg1-2ubuntu3_armhf.deb dpkg -i libsdl2-2.0-0_2.0.4+dfsg1-2ubuntu3_armhf.deb rm libsdl2-2.0-0_2.0.4+dfsg1-2ubuntu3_armhf.deb wget http://deb.odroid.in/5422-s/pool/main/p/pixman/libpixman-1-0_0.34.0-1hk3_armhf.deb dpkg -i libpixman-1-0_0.34.0-1hk3_armhf.deb rm libpixman-1-0_0.34.0-1hk3_armhf.deb apt -y install libdrm-exynos1 # Udev rules echo 'KERNEL=="mali0",SUBSYSTEM=="misc",MODE="0777" KERNEL=="CEC", MODE="0777" KERNEL=="cec*", MODE="0777"' > /etc/udev/rules.d/10-odroid.rules # Xorg config sudo rm /etc/X11/xorg.conf.d/* echo 'Section "Device" Identifier "Mali-Fbdev" Driver "armsoc" Option "fbdev" "/dev/fb0" Option "Debug" "false" Option "DPMS" "false" Option "NoFlip" "true" Option "NoHardwareMouse" "true" EndSection Section "ServerLayout" Identifier "Default Layout" Option "BlankTime" "0" Option "StandbyTime" "0" Option "SuspendTime" "0" Option "OffTime" "0" EndSection Section "DRI" Mode 0666 EndSection Section "Extensions" Option "Composite" "Disable" Option "RENDER" "Disable" EndSection ' > /etc/X11/xorg.conf.d/01-armbian-defaults.conf # Chromium config echo '# Default settings for chromium-browser. This file is sourced by /bin/sh from # /usr/bin/chromium-browser # Options to pass to chromium-browser CHROMIUM_FLAGS=" --disable-namespace-sandbox --use-gl=egl --ignore-gpu-blacklist --disable-accelerated-2d-canvas --num-raster-threads=2" ' > /etc/chromium-browser/default [ -e /usr/lib/chromium-browser/libEGL.so ] && mv /usr/lib/chromium-browser/libEGL.so /usr/lib/chromium-browser/libEGL.so.org [ -e /usr/lib/chromium-browser/libGLESv2.so ] && mv /usr/lib/chromium-browser/libGLESv2.so /usr/lib/chromium-browser/libGLESv2.so.org ln -s /usr/lib/arm-linux-gnueabihf/mali-egl/libmali.so /usr/lib/chromium-browser/libEGL.so ln -s /usr/lib/arm-linux-gnueabihf/mali-egl/libmali.so /usr/lib/chromium-browser/libGLESv2.so echo ' *********************************** * Configuration complete. * * PLEASE REBOOT * *********************************** ' exit 0 Notes:
You must disable window compositing, or performance will be awful The problem is that, without compositing, some elements of the Xfce UI became invisible, the most annoying being the tray notification icons. I have checked, and it also happens in the Hardkernel image, but it is not a problem for them since they use Mate as default DE. We'll need to find a way to work around this.

Just ordered an ov5647 camera to join the party. Will take a few days to ship from China, though

I'm building an image with their buildscript right now.  In case this doesn't work I'll open an issue on their github repo (and as a side note that they should rename their rootfs name on gdrive: rootfs-debian-20171225(fix a stupid mistake, affect performance since 20170901).tar.gz  it's nasty to work with such names from console... ).
 
Another side note: 
RK suggests to use gcc <6:
 
Whereas we use gcc7, I tested it with:
case $BRANCH in default) KERNELSOURCE='https://github.com/rockchip-linux/kernel.git' KERNELBRANCH='branch:release-4.4' KERNELDIR='linux-rockchip' KERNEL_USE_GCC='< 6.0' it built without issues but the kernel failed also to boot... Can this have an effect? I'm not that motivated to test all possible configurations with gcc<6...  
 
Update:
At least it boots...   but dmesg shows:
linaro@linaro-alip:/usr/local/bin$ dmesg | grep ov56 [ 3.664487] OF: graph: no port node found in /i2c@ff660000/ov5647@36 [ 3.677146] ov5647 2-0036: DT parsing error: -22 [ 3.687968] ov5647: probe of 2-0036 failed with error -22 and therefore as expected their camera test fails too:
linaro@linaro-alip:/usr/local/bin$ sudo ./test_camera.sh Start MIPI CSI Camera Preview! ./test_camera.sh: 9: ./test_camera.sh: cannot create /sys/module/video_rkisp1/parameters/rkisp1_debug: Permission denied Setting pipeline to PAUSED ... ERROR: Pipeline doesn't want to pause. ERROR: from element /GstPipeline:pipeline0/GstRkXImageSink:rkximagesink0: GStreamer error: state change failed and some element failed to post a proper error message with the reason for the failure. Additional debug info: gstbasesink.c(5184): gst_base_sink_change_state (): /GstPipeline:pipeline0/GstRkXImageSink:rkximagesink0: Failed to start Setting pipeline to NULL ... Freeing pipeline ... I'll open an issue...  Seems that the camera is powered during boot (red LED on camera board shines up for a short time before it turns off). 
 
Update II:
issue is open and I hope we get some respond:
https://github.com/rockchip-linux/kernel/issues/72
 

I just released a new C library for communicating with those inexpensive 4-digit 7-segment LED displays:
 
https://github.com/bitbank2/tm1637
 
They can run on 3.3V or 5V and draw between 1 and 15mA depending on the brightness setting. I purchased mine from an AliExpress vendor for 68 cents each with free shipping.
They use a custom 2-wire communications protocol and must be "bit-banged" from 2 GPIO pins. In my demo, I assign pins 38 and 40 on my Orange Pi Lite.
 

Best nights I don't remember.  The stuff was illegal in the United States for a long time...

I've never tested it. From the original dts, it's properly described (whereas the OV5647 misses the port description as described in the github issue you see in the other thread). So building a new image with the needed drivers, replace our dts (create patch = yes) which has some adjustments and build an Image could be worth to test. In case this doesn't work set GCC to <= 6 in the buildscript (cause RK described it somewhere in their documentation that they build with gcc <= 6 and we use a newer gcc for our builds).  This breaks for sure some functionality, e.g. DSI related stuff, eMMC for the tinker S, probably wifi and maybe some stuff I didn't think about yet.  In case this doesn't work you should have a look our config and the config which RK uses with their linaro.. Or you build a linaro first an look if it works there... 
The IMX219 arrived some days ago but I didn't spent that much attention to it at the moment..  I suggest you describe your findings in the other thread cause it is related to the new ISP driver. 

there you go..  
 
to keep it short.. at the moment it doesn't boot and we're still not sure what it breaks.. I think it's DTS related, or we miss something in the configs, or one of our patches breaks it... We also tried the asus way of implementing camera support via isp10 (the old deprecated isp driver from rockchip and this seems to be not practicable)... I built more than 20 (I really don't remember how many SD cards I flashed...) images trying to bring up the camera. So feel free to join the party..  I decided that I need a break from the tinkercam... 

I think this is mostly related to this stuff here...
http://www.lavrsen.dk/foswiki/bin/view/Motion/ConfigOptionFfmpegVideoCodec
 
There's a lot of enhancement for the cameradriver and I think @@lex did some stuff there and maybe you get better performance with the cedrus ffmpeg stuff..
 
I never paid that much attention to see if this can help for motion... 

http://linux-sunxi.org/Mainlining_Effort#Status_Matrix
As it can be seen here...  
 
There is progress in mainlining the camera interface see here (mostly for the V3s):
https://groups.google.com/forum/#!forum/linux-sunxi
 
It's not trivial and might need a lot of work before we see a mainlined CSI interface. 
 
Do you get acceptable framerates with a USB webcam with motionEye? I only played a bit with it months ago and I had terrible slow framerates (6-7 fps).. To be honest, I used the cheapest usb cam from Aliexpress and never paid attention if this was a camera or settings related issue.

;-) A joke of course. I do not mind some German, of course I can read it, so that makes it less distracting.

Sent from my Pixel using Tapatalk

Thanks for mentioning that @Igor, I share a lot of code, but rarely get any feedback that people are using it.

Yes, put
/bin/bash into your customize-image.sh to launch a shell from the customization script, do what you want and then exit the shell to continue the build process. Don't forget to kill any running services or background processes if you start any otherwise you may get unexpected issues later.
 
It uses qemu-user emulation to execute binaries for the different architecture.
 
This is responsible for building additional packages, outside the normal image creation process.

Since there are a lot of issiues with underpowered boards, this ‘White Paper’ should explain why it’s recommendet to think about the powering situation of your board (especially if it’s powered throught micro USB).
Basics:
It’s all about Ohm’s Law (eq. 1), your SBC needs a defined voltage (U) and current (I). So the only variable that we can influence is the resistance (R)!

The micro USB cable which powers our board acts as resistor between the output of the power source and the input of our board. For the moment, let’s assume our power source delivers a stable Voltage (what isn’t true, depends on current needed) and our cable has fixed resistance (what’s more or less correct). It’s clear that the more current is needed, the more drops the voltage (fig. 1).

Figure 1: Voltage droping (cable ressistance was assumed to 0.5 Ohm)
Depending on your SBC, it’s more or less tolerant to such a voltage drop. But the result is mostly the same à software instability.
How can we influence the resistance of our cable, this is simple à Use the thickest and shortest cable that you can find. The resistance of a round coper wire is defined by eq. 2.

Cause ρ is a material constant, only length and thickness could be changed. The length can easily be checked. Whereas for the thickness you have to cut the cable and check it, or trust the vendor that he doesn't cheat you (the more copper inside a cable, the higher the production cost). The American wire gauge (AWG) classifys the thickness of your copper wires inside your cable. Its often written on your cable. Micro USB cables have mostly a AWG number between 30 (d=0.255mm) to 20 (d=0.812mm) for realy good ones (Illustration 1).

Illustration 1: AWG print on cable
Example:
If we assume that there’s no voltage drop from the connector (which is not true) and the power source has an output of 5.1 V @ 2.0 A and our SBC needs >4.8 V to run properly*. How long can a copper-cable with a defined diameter be before the SBC crashes?
*this numbers are chosen randomly, since I don’t have any validatet numbers when a specific board runs into instability.
 
Using eq. 2 for cables between EWG 20 and EWG 30 gives us the following results (fig. 2).

Figure 2: Voltage drop of a copper cable at various thiknesses
If we only had a voltage drop due to the cable length (no resistance from the USB connectors nor inside the SBC) we could have cable lenghts between 40cm (AWG30) up to 4.8m (AWG 20). But that’s not the reallity! To illustrate this, some measurements on a real issue were done.
 
Case Study:
Three different USB-Chargers and four different micro USB cables were used to charge a ‘xtorm’ powerbank (from the powerbank spec, it should be possible to charge it with 2.0A @5V). This powerbank has to possibilities for charging. With the ‘onboard’ USB-cable or with a micro-USB input. With a ‘Keweisi’ USB-Powermeter on one side and a multimeter on the other side current, and voltage drop during charging was measured (Illustration 2).

Illustration 2: Setup vor measurement
FYI: These measurements weren't made under laboratory conditions nor with high precision equipment. All chargers are listed in Table 1.
Table 1: Specification of the tested chargers

Table 2 displays the tested micro-USB cables, they came mostly from buyed usb devices and were not especially buyed to power a SBC!
Table 2: Tested micro USB cables

Results:
After all this theory, lets have a look how much the voltage drops at delivered current. All resulsts are sumarized in Fig. 3.

Figure 3: Voltage drop at delivered current of all chargers
Firstly, we see that the noname USB charger from aliexpress couldn’t deliver the claimed 2A, it seems like that it is more or less a 1A charger sold as 2A charger. The short USB-cable and the one deliverd to power a tablet (cable 1&2) performe well, with only a small voltage drop and the highest current. Even at arround 1A the thin cables (cable 3&4) have a realy hight voltage drop of around 0.5-0.7V! This is similar on the iPhone charger.  If we go to high current, the situation becomes interesting. Even if the charger can deliver such a high current (cable 1&2), thin long cables (cable 3&4) can't deliver it and the voltage drops more than 0.8V! That’s definitely not a recommended setting for a SBC.
All these chargers are a little bit above the 5.0V at its output so no problem, right? ‘If I use a short cable this small voltage-drop of around 0.3-0.5V wouldn’t be a problem. That’s not true! As soon as the charger must deliver higher current the voltage drops at its output (Fig 4)

Figure 4: Voltage without load, with load and on output and @powerbank
.
Worst in class here to is also the noname cell phone charger. It delivers around 4.1V on the powerbank side.  The iPhone charger doesn’t perfome much better. Even the Trekstore charger, which is able to deliver 2.0A couldn’t do this at 5V. With a short cable, it’s around 4.6V. I wouldn’t recommend one of these chargers to power a SBC with some peripherals attached to it.
Conclusion:
What's next? Should we never buy again a micro USB powered SBC?  IMO no! A micro USB powered board is not a no go. But we should keep the powering situation in mind when we have such a device. Long thin cables are definitely not recommended for powering such a device. Even short cables with a bad power source will end in touble. It stands and falls with your setup (e. g. powerconsumption of your SBC, perepherials attachted to it) and the choosing of the right charger. For example, I use a charger (2A @5V) with a fix attached AWG 22 cable (Ill. 2). Doing the same test with it (current and voltage under load at its output could not been mesured since there is no USB for the powermeter) showed 4.84V on the output of the powerbank and 5.20V without load.  Which is about 0.2V more than the Trekstore charger with the best cable attached to it. Spend a little bit more money on your powersource and you eliminate one of the possibilities to frustrate you!

Illustration 3: Recommended powersource
 
 

was onboard here from the start that was a couple of years ago was around pre apt repository even  been happy with the support only had one hickup and that was the last couple of pushes the latest kernel works just fine but thats just it staying on the same kernel isnt good in the long run.
 
i care less about write speed aslong as im getting sata support and about the same speeds as i get from the cubieboard 2 im good  
 
again my hat goes off to @Igor and the rest of the crew for the years of support. 
 
and ill certainly check out any board that has the qualities that im looking for.

If I'm not wrong, that error is due to Mali not supporting OpenGL, but only OpenGL ES. In other words: there is no rockchip_dri.so, it just doesn't exist anywhere, and I don't think it will exist.
 
Rockchip provides a tweaked X server that gives you glamor acceleration through OpenGL ES, but it only works for mali midgard  (RK3288 and 3399). However, you can get 3D acceleration for your RK 3288 3328 (sorry, typo) through the armsoc driver. If you are interested, I can give you more info on it.

Development branch https://github.com/armbian/build/tree/development/packages/bsp/common/etc/network is moving completely towards Network manager, 1st boot setup with it was successfully tested. Worked with wireless and ethernet, with normal and predicted interfaces. It can be further expanded to the hidden network connection ..., but problems are expected on Jessie due to an old version of NM.
 
The main problem with this topics issue is that wifi drivers for Tinker's onboard wifi are not in the best shape and if you want to use wpasuppliant to connect, you need to tell network manager to unmanage that particular wifi interface.
 
@bulletim3 Checking this part of the script might give you some clues.

I have three of the V3s based LicheePi Zero's and they work ok, V3s mainline u-boot and 4.16.x Linux work out of the box... you can still buy those at the taobao shop page Zepan set up...

So, design-off, guys?  First one to boot Armbian on their own V3s board wins?

I have a HC1 (a kind of a headless XU4), so I can't test WebGL. It should work if you install these two packages:
http://deb.odroid.in/5422-s/pool/main/m/mali-x11/mali-x11_20170718-r17p0-20503ff-3_armhf.deb
http://deb.odroid.in/5422-s/pool/main/x/xf86-video-armsoc/xserver-xorg-video-armsoc-exynos_1.4.1-0ubuntu4_armhf.deb
 
And then replace /etc/X11/xorg.conf.d/(whatever-is-the-name-of-the-conf-file) with the following:
Section "Device" Identifier "Mali FBDEV" Driver "armsoc" Option "fbdev" "/dev/fb0" Option "Fimg2DExa" "false" Option "DRI2" "true" Option "DRI2_PAGE_FLIP" "false" Option "DRI2_WAIT_VSYNC" "true" # Option "Fimg2DExaSolid" "false" # Option "Fimg2DExaCopy" "false" # Option "Fimg2DExaComposite" "false" Option "SWcursorLCD" "false" EndSection Section "Screen" Identifier "DefaultScreen" Device "Mali FBDEV" DefaultDepth 24 EndSection Maybe you can play with the commented-out lines, and see how it affects performance. Let us know whether it works.

Armbian doesn't support this board. It's .csc (community support configuration). 
according to:
https://github.com/armbian/build/blob/347a1699944b15a74ec39b5fa0014781fbf20177/config/kernel/linux-rda8810-default.config#L2318
# CONFIG_USB_SERIAL_PL2303 is not set so you might need to rebuild a kernel with the driver activated.. But no guarantee that it works.  

I will try building it without any extra patches to see if it works that way.  If not I will reach out to Rockchip concerning the issue.

I think I'd probably get a stomach ulcer in fear of screwing it up...  ?

Please be careful since this is an entirely different workload compared to 'using SD cards for the rootfs' since storing images and video is more ore less only sequential IO coming with a write amplification close to the optimum: 1. This means that the amount of data written at the filesystem layer, the block device layer and the flash layer are almost identical.
 
With our use cases when running a Linux installation on the SD card this looks totally different since the majoritiy of writes are of very small sizes and write amplification with such small chunks of data is way higher which can result in 1 byte changed at the filesystem or block device layer generating a whole 8K write at the flash layer (so we have a worst case 1:8192 ratio of 'data that has changed' vs. 'real writes to flash cells')
 
Please see here for the full details why this is important, how it matters and what it affects: https://en.wikipedia.org/wiki/Write_amplification
 
Our most basic take on that in Armbian happens at the filesystem layer due to mount options since we use 'noatime,nodiratime,commit=600' by default. What do they do?
noatime prevents the filesystem generating writes when data is only accessed (default is that access times are logged in filesystem metadata which leads to updated filesystem structures and therefore unnecessary writes all the time filesystem objects are only read) nodiratime is the same for directories (not that relevant though) commit=600 is the most important one since this tells the filesystem to flush changes back to disk/card only every 600 seconds (10 min) Increasing the commit interval from the default 5 to 600 seconds results in the majority of writes waiting in DRAM to be flushed to disk only every 10 minutes. Those changes sit in the Page Cache (see here for the basics) and add as so called 'dirty pages'. So the amount of dirty pages increases every 10 minutes to be set to 0 after flushing the changes to disk. Can be watched nicely with monitoring tools or something simple as:
watch -n 5 grep Dirty /proc/meminfo While @Fourdee tries to explain 'dirty pages' would be something bad or even an indication for degraded performance it's exactly the opposite and just how Linux basics work with a tunable set for a specific use case (rootfs on SD card). To elaborate on the effect: let's think about small changes affecting only 20 byte of change every minute. With filesystem defaults (commit interval = 5 seconds) this will result in 80KB written within 10 minutes (each write affects at least a whole flash page and that's AFAIK 8K or 16K on most cards so at least 8K * 10) while with a 10 minute commit interval only 8KB will be written. Ten times less wear.
 
But unfortunately it's even worse with installations where users run off low capacity SD cards. To my knowledge in Linux we still have no TRIM functionality with MMC storage (SD cards, eMMC) so once the total amount of data written to the card exceeds its native capacity the card controller has no clue how to distinguish between free and occupied space and has therefore to start to delete (there's no overwrite with flash storage, see for example this explanation). So all new writes now might even affect not just pages but whole so called 'Erase Blocks' that might be much larger (4MB or 16MB for example on all the cards I use). This is for example explained here.
 
In such a case (amount of writes exceed card's native capacity) we're now talking about writes affecting Erase Blocks that might be 4MB in size. With the above example of changing 20 bytes every minute with the default commit interval of 5 seconds at the flash layer now even 40 MB would be written while with a 10 min commit interval it's 4MB (all with just 200 bytes having changed in reality).
 
So if you really care about the longevity of your card you buy good cards with capacities much 'larger than needed', clone them from time to time to another card and now perform a TRIM operation manually by using your PC or Mac and SD Association's 'SD Formatter' to do a quick erase there. This will send ERASE (CMD38) for all flash pages to the card's controller which now treats all pages as really empty so new writes to the card from now on do NOT generate handling of whole Erase Blocks but happen at the page size level again (until the card's capacity is fully used, then you would need to repeat the process).
 
There's a downside with an increased commit interval as usual and that affects unsafe power-offs / crashes. Everything that sits in the Page Cache and is not already flushed back to disk/card is lost in case a power loss occurs or something similar. On the bright side this higher commit interval makes it less likely that you run into filesystem corruption since filesystem structures are updated on disk also only every 10 minutes.
 
Besides that we try to cache other stuff in RAM as much as possible (eg. browser caches and user profiles using 'profile sync daemon') and same goes for log files which are amongst those candidates that show worst write amplification possible when allowing to update logs every few seconds on 'disk' (unfortunately we can't throw logs just away as for example DietPi does it by default so we have to fiddle around with stuff like our log2ram implementation showing lots of room for improvements) 

When you read the comment from @Igor a few days before it should be clear that this doesn't happen that fast..  
 
Translation: Probably no Dev has an interest to clean up the BSP kernel to make it useful for an Armbian based images (similar to the H5 where armbian also doesn't provide BSP kernel based Images).
 
Doesn't need a translation... Too early says everything....
 
You can follow http://linux-sunxi.org/Mainlining_Effort#Status_Matrix to get an idea about how far away this SoC is. You can follow @Icenowy, she's to my knowledge the most active one in getting it mainlined  or you're following the sunxi mailing list.... http://linux-sunxi.org/Mailing_list
 
The small OPi H6 boards do not have unique features which makes them interesting (there's nothing wrong about this boards, but you get alternatives for the same job which have a better support on software side), even for the pine H64 there are alternatives where armbian provides images  - maybe not (yet) labeled 'stable'... 
Early adopters pay always I price - in the SBC world it's mostly the lack of software support..