pfeerick

Hi to all!
 

 
A wallpaper i named "projection". (if one find better name for this i dont mind renaming it)
And thank's to all!
https://www.dropbox.com/s/xensyaed07nbr59/projection_1920x1080.png?dl=0
 
zip https://www.dropbox.com/s/t26y1a1pfuok1ah/projection.zip?dl=0
 
Edited by admin (added image to the post)

Edit: Light versions added
 
Whipped up a couple more this evening. Any feedback would be greatly appreciated. Really cool stuff everyone is making. I really like the logo/typography Miike. Good stuff. Anyway I can get the dark version with just a charcoal grey instead of the gradient? I'd like to use it for my wallpaper. Again these are at the highest resolution asked for. They can easily be scaled down if anyone is interested.
 
H-Town

 
H-town - Light

 
CPU Magenta

 
CPU Magenta - Light

 
Micro SD

 
Micro SD - Light

Hi to all! I'm just here to say thanks for your work with armbian and contribute with some wallpapers. 
 
Pd. Do you think in armbian logo redesign? 
 

Armbian microprocessor die


 
 
 
 

 
 




Remix from Wikimedia Commons Image, ARM chip under microscope, CC BY-SA 3.0 :
https://commons.wikimedia.org/wiki/File:PHILIPS_ARM_VY22549A6_N48752.00_04_kSG0631-1825-0172.jpg


 

Edit: I didn't realize the type had shifted when i centered everything. I'll fix and reupload this evening.
Edit 2: Light version added
 
Here is another one.
 
Large typography

 
 
Large typography - light

Edit: Light version added
 
Hey guys,
Great work you're doing with armbian. Just created an account to post a couple of ideas I came up with. I've only got the largest resolution right now, but if you like any of them I can easily save out others.
  Linen - Dark   Linen - Light   Vertical blur   Vertical blur - Light

Armbian Glacier

Heres my try. Instead of one fixed colorset I chose some different colors too, can be used for alfa-beta-stable, release versions etc.
 

 
Recreation of Tux is under Public Commons.
 
RGB codes for different colors are included. Can be used for branding in general.
 
https://dl.dropboxusercontent.com/u/49778084/armbian.zip

I came up with this. I hope you like it Leave a like if you do, i accept criticism.
 

 
Download a whole .zip with all resolutions: https://drive.google.com/open?id=0B5goNLARJa4fSFdscnkyVDhnRUE
 
I used Blender to make Tux (no, i didnt steal it from anywhere) and Cycles render to render it.

armbian 2017
 
#nologo #nolight #nofuture

In my case, Fast Ethernet works as usual and a very basic analysis on GbE issue suggest RX does not work most of the times. And i can't say it is a faulty chip or poor soldering even looking at it.

Meanwhile in Pine64 land: http://forum.pine64.org/showthread.php?tid=1166&pid=21382#pid21382
 
HW accelerated video decoding is available since this commit (2D acceleration works also since half a year) but one moderator still denies that 'HW acceleration' would be available. If you're a Pine64 user and rely on the forum over there you're still simply lost
 
(but maybe the Mali hype just caused serious brain-damage?)
 
BTW: first question was about HW accelerated video encoding. @lex, one of our great community members, provides this here: http://forum.armbian.com/index.php/topic/1855-ffmpeg-with-cedrus-h264-hw-encoder-a64-cmos-camera/

The problem is that the 'moderator elite' over there (a couple of them at least) created their own micro reality not taking into account that A64 is one of many tablet SoCs from the same vendor called Allwinner. Using Allwinner's BSP (board support package, an awful mix of Linux and Android sources and ugly scripts to combine everything to a smelly 'LiveSuit image' with broken partition map) with A64 is nearly the same as with A83T or A20 or A10 and of course LCD configuration is also the same (look at the timestamps here -- if anyone ever wants to use a different LCD with Pine64 there you get the idea how to calculate values).
 
With A64 BSP Allwinner still supported defining everything in fex files (I put an example online when the first A64 BSP variant was leaked 10 months ago) but since they're using kernel 3.10 starting with A64 they alternatively allow also defining all this stuff as DT (device tree). Logic/behaviour is the same as known since ages. Why shouldn't a tablet SoC not be able to use a f*cking LCD?! It's made for no other reason!
 
Longsleep was the first who tried to get this horrible BSP stuff working with 'generic Linux' and for obvious reasons he chose to get rid of the fex stuff right away. But LCDs connected to Pine64 can be used with BSP kernel since he published his first simpleimage approaches (and that means almost half a year ago). By defining parameters as it has been done from day one (nothing has changed here since 2013).
 
BTW: At the same time longsleep also looked into HDMI situation and decided to develop sunxi-disp-tool for A64 to switch between different HDMI modes on the fly. Thankfully he also added a mode to configure HDMI resolution as it is done on the older sunxi SoCs (A10, A20). By adding disp.screen0_output_mode and/or disp.screen1_output_mode (most Allwinner tablet SoCs support more than 1 display) to kernel cmdline and calling sunxi-disp-tool in the boot process which reads /proc/cmdline and then sets HDMI resolution before a desktop environment would be started.
 
What happened with this knowledge? It's gone since the way to adjust HDMI resolution is mentioned in longsleep's description for his own original Ubuntu image but missing in every other 3rd party image or the crappy ones made available through wiki.pine64.org. Supressing documentation means destroying developer's work. And this happened with every OS image available on wiki.pine64.org or pine64.pro (see also the bottom of this rant)
 
And now people think they have to get rid off sunxi-disp-tool to be able to use an LCD instead of using the tool correctly (defining the LCD as display 0 in .dtb and optionally use HDMI as display 1 -- simply remove/adjust disp.screenX_output_mode in uEnv.txt or boot.scr and you're done). The whole 'history' of dealing with simple 'problems' is just absurd when looking over at pine64.org due to lack of documentation, clean instructions and allowing strange people to spread BS all the time while also allowing them to censor others posts (especially those mentioning that these guys are part of if not the problem).
 
Why did they provide crappy Linux images and still do not even mention longsleep's original Ubuntu image? Why do they provide so called 'DD images' for RemixOS/Android in several sizes (all too large since they don't fit on every SD card of the specific size) instead of providing small Android/RemixOS images that expand their data partition on first boot (as the community Android 7.0 implements it now -- these guys are great!). Why do they provide different Android images for HDMI and LCD? It's just adding a TS driver and adjusting settings! And checking for the I2C connected touchscreen controller in u-boot and then use this or that .dtb afterwards like it's already done depending on DRAM size and choosing the correct .dtb for Pine64 or Pine64+ (different Ethernet config).
 
I would love to know the answer.
 
Anyway: If there's some progress regarding HDMI (we still have to deal with the libhdmi blob here!) we will think about A64 HDMI situation with Armbian (maybe using Simon's sunxi-disp-tool in exactly the same way -- then on H3 too where it should work with minor tweaks -- and then on all supported sunxi SoCs display resolution can be defined in a consistent way again). But at the moment Pine64+ is clearly a headless device for us (and there it can really shine if you're not unfortunate enough to got a broken board suffering from the GbE issue)

In the meantime the 'breaking news' that using an LCD together with an Allwinner device requires defining how to use it the usual way also arrived at Pine64 forum (really great news since just a few weeks ago they've been told by the 'moderator elite' to get the LCD working first 'the Mali' would be needed and it would take at least 2 weeks of hard work and other BS).
 
I added some suggestions: https://github.com/MackPI/Pine64LinuxLCD/issues/1

Please get back to TL Lim and ask what to do. I can send you one of the working boards but need it here for some time to do a few tests before.
 
They really should start with a quick QA round at least for the replacement boards (they sent 4 boards out to us and 2 are defective -- huh?). But it seems they really don't care that much about what's happening...
 
BTW: Had a short look into pine64 forums after weeks. Unbelievable that a specific person is still moderator and now tries to tell @ssvb about Mali -- too funny (if I would ever have a question regarding Mali I would always ask Siarhei first)

Nice, just discovered the Azpen Hybrx A64 laptop starting at $69: http://hybrxpc.com/about-hybrx/(combining an A64 board with cheap and most probably ultra glossy 1366x768 LCD and starting with 1 GB DRAM and 16 GB flash). In case it's eMMC it should be possible to flash Armbian to it through USB/FEL...
 
LOL, the same person (Charbax) showcases Allwinner's reference design and 5 months later the very same device in pink (known as Azpen Hybrx now).

Yes, we could (formally) engage more people into developing process as testers. It could be helpful and we would be little relieved.
 
Perhaps we start to seek & assign few testers / maintainer for each board? We can provide access to daily upgrades to make things easy on technical level. I can provide extra repository (aptdev.armbian.com) with daily updated deb packages, while creating images takes way too much time for daily builds. I am already working on this for some time and it's not far away from running it daily.
 
Subforum "Development" is not that busy, so we can have those things here.

Well, it has been already known that Pine64+ is capable of exceeding 80 MB/s based on 'raw' iperf3 numbers (only one person needed to be convinced, thanks for doing the job). It would be great if you could grab 'Helios LanTest' (available at http://webshare.helios.de user 'tools', pwd 'tools') and run each 3 times with the settings for 'Very fast' and 'Enterprise' networks.
 
And while this sort of test using btrfs compression is somewhat useless since it only demonstrates what's possible if storage isn't the bottleneck (but most of the time disk IO will be the bottleneck since we're limited by USB 2.0) it gives also a nice preview of what will be possible later when mainline kernel is ready (and EMAC driver further improves) or when Pine64+ runs completely from fast network storage (since GbE is the fastest interface available on A64 this makes perfectly sense)

So, I know it isn't comparing apples with apples, but I just have to post this as it shows the GbE on the pine64 can indeed move when it wants too... 
 
I finally reformatted my USB flash drive as btrfs, and made a zeroed 1G file as you suggested earlier (with compression on). I'd started armbian up again a youtube upload for tonight, so thought I'd make that file first,and then see what the transfer speed was like. I'm copying to the same desktop computer as before, but it's booted in to windows (I know, you won't like it) this time (dual-boot), and it was... fast... damn near missed getting the screenshot! 
 

 
 

Well, let's stop speculating about motives and focus on the real problem again (him being a huge part of though). He closed the thread, censored the advise to measure voltages away and even discourages users to do so ('I have proven that the VDD33 voltage is not the problem').
 
So all we have now are Zador's measurements on his board where no problem occurs, we have @androsch's board where I can not measure since I sent it back to @androsch yesterday before new schematic release and Zador came up with the PHY_VDD33 suggestion and we now have to rely on others taking notice (quite unlikely given the weird situation in pine64 forum). So let's see what happens when @-L0thar-'s gear arrives and he's able to compare his two boards.

Emphasis by me. This is just an assumption and hoping that more expensive equipment cures a problem that needs detailed attention. As an example: when @androsch's board arrived the day before yesterday I used an 5V/2A USB PSU with a well known 'crap cable' (tiny wires, resistance high, the only reason I have this cable in the drawer is to demonstrate how shitty Micro USB is). Crappy cable + crappy connector --> resistance way too high --> voltage way below 5V:

 
I replaced this with a dual voltage PSU connecting the 5V rail to Euler pins and GbE problems in TX direction disappeared almost immediately (that's the difference the powering method made). But this stable PSU provides only constant 4.97V on idle and 4.95 under load (and only voltage on the 12V rail can be adjusted). So this stable PSU didn't help in RX direction even if it's stable.
 
Since I found my barrel plug to Micro USB adapters I could try two different PSUs now connecting to the Micro USB port using the adapter. With the one providing 5.0V RX throughput was in the range of Kbits/sec, with the one providing 5.2V it was at Mbits/sec (nearly 500 times more 'performance' -- but since I was not able to repeat this with the new bench PSU I bought yesterday there must be different other influences also). So the assumption that a higher rated PSU will behave better is just that: an assumption not backed by anything.
 
I did also some tests yesterday with a USB disk connected (higher consumption --> voltage drops). Without USB disk I measured 5.23V on the RPi header, with disk connected 5.17V. Iperf3 numbers varied reproduceable between 300 and just 100 Mbits/sec in RX direction. So these minimal differences are important. By believing in a 5V/5A brick you don't get even close to this since maybe this brick starts at 5.05V idle and then drops down to just 5.02V under load (both values being too low at least for @androsch's affected board).
 
BTW: Software matters. With mainline kernel on @androsch's board when using the 5.0V PSU the kernel driver did not even find the RTL8211E PHY. Shutting then the board down, replacing the PSU with the 5.2V one and I 'got the PHY back': https://irclog.whitequark.org/linux-sunxi/2016-09-09#17505156;
 
And now the most funny part: the AXP803 PMIC present on each A64 device is measuring voltages and current all the time since it takes decisions based on that (eg compensating from undervoltage on mains by using a connected battery). So instead of relying on assumptions a responsible vendor would have added readouts to sysfs so every user can easily monitor whether he uses an insufficient powering method or not. And I write about powering method and not PSU since this is important. The average user has not the slightest idea that the main problem is the cable between PSU and the crap connector (called Micro USB). The average USB cable is crap and responsible for insane voltage drops! It makes absolutely no difference whether you use a 5V/10A PSU or a 5V/2A PSU if the cable between PSU and board is crap since here the more severe voltage drop happens since the cable (and the tiny contacts inside the crap connector) act like a resistor.
 
Regarding test points and QC: No idea, there are a bunch of test points on the lower PCB side... but without any description they're at least useless for us users. At least TL Lim promised to release schematics for the 2GB model soon.

If you provide power through Micro USB you can measure at Euler pins 4 and 6 (5V/GND) or also at the USB ports (the outer contacts carry power, the inner data) with jumper set to 5VDC (since otherwise the AXP803 PMIC provides stable 5V there). The reason I ask for this measurements is that I really don't understand how it's possible on my (@androsch's) board that I feed 5.1V through Euler pins but get then only 4.6V on the USB ports while I get there a higher voltage when using Micro USB for DC-IN (and Micro USB is known for severe voltage drops caused by cable and contact resistance, it's also limiting maximum current so any advises to use a PSU capable of more than 2A are BS).
 
Here's a picture of 'my' 1st Pine64+ dev sample (now at Zador's place): http://linux-sunxi.org/File:Pine64_Powered_through_Euler_Connector.jpg (red is 5V, black is GND)
 
 
A comparison with the good board would help. Using same PSU and measuring there too. Both at USB ports and Euler pins 4/6. Just to get the idea whether voltage drop behaviour differs between good and bad board and we find an easy correlation. But even if not: the board @androsch sent to me clearly has a power problem if voltage between Euler pins and USB port drops by 0.5V (idle) and just 0.7V with 'stress -c 4'.
 
To measure the influence of voltage drops you could use 'stress' (contained in Armbian for exactly this reason). A 'stress -c 2' is pretty lightweight, a 'stress -c 4 -m 2' for example will lead to higher voltage drops (that's the problem with these drops, they depend on the amperage needed by the board so they increase under load or when bus-powered USB peripherals are connected).
 
BTW: These measurements in 'stab in the dark mode' are of course somewhat stupid since if we would have a test point to check voltage provided to RTL8211E this would make much more sense. But at least on androsch's board behaviour of GbE performance depends on input voltage (see the 5.0V vs. 5.2V experiment) and the voltage readout on the USB ports simply feels wrong. So IMO it's a good idea to check these voltages to help pine64 folks identify the root cause (now that hopefully other reasons for bad network performance -- the OS images using ondemand cpufreq governor for example -- are identified and able to be ruled out by switching to good OS images or better settings). In the meantime TL Lim promised releasing schematics of the 2GB Pine64+ this weekend. Let's wait and see.

Thanks for the feedback. I don't think 'higher ratings' will help that much but it would be interesting if you could measure voltage provided on Pine64's USB ports when the jumper is in 5VDC position (just to get the idea whether a voltage drop here correlates with the GbE issue). And it would also be interesting if you've a bench PSU able to provide more than 5.2V to fed to either the Micro USB jack or Euler pins (the behaviour on @androsch's board is somewhat strange since when powering through Euler pins the voltage on the USB ports drops down more than using Micro USB).
 
Anyway: 4.6V on the USB ports dropping down to 4.4V with some load on androsch's board is a sign for me that's something wrong (disclaimer: I'm an absolute NOOB regarding electronics, I just had to learn the hard way that insufficient power supply can cause many issues) so even if higher DC-IN voltage might 'resolve' the issue I would still have doubts regarding reliability (in other words: the reason for these voltage drops has to be found)

Now a real world example showing where you end up with the usual 'benchmarking gone wrong' approach. Imagine you need to set up a web server for static contents only. 100 GB of pure text files (not that realistic but just to show you how important it is to look closer). The server will be behind a leased line limited to 100 Mbits/sec. Which SBC to choose?
 
The usual benchmark approaches tell you to measure sequential transfer speeds and nothing else (which is OK for streaming use cases when DVD images several GB each in size are provided but which is absolutely useless when we're talking about accessing 100 GB of small files in a random fashion -- the 'web server use case'). Then the usual benchmark tells you to measure throughput with iperf (web serving small files is about latency, that's quite the opposite) and some silly moronic stuff to measure how fast your web server is using the loopback interface of your server and test tool on the same machine not testing network at all (how does that translate to any real world web server usage? Exactly: not at all).
 
If we rely on the passive benchmarking numbers and have in mind that we have to serve 100 GB at a reasonable cost we end up thinking about an externally connected HDD and a board with GbE (since iperf numbers look many times faster than Fast Ethernet) and a board that shows the highest page request numbers testing on the local machine (when the whole 'benchmark' turns into a multi-threaded CPU test and has nothing to do with web serving at all). Please don't laugh, but that's how usual SBC comparisons deal with this.
 
So you choose from the list above as storage implementation an external 500 GB HDD since USB performance looks ok-ish with all boards  (+30 MB/s), and NanoPi M3 since iperf numbers look nice (GbE) and most importantly it will perform the best on the loopback interface since it has the most and the fastest CPU cores.
 
This way you end up with a really slow implementation since accessing files is more or less only random IO. The usual 2.5" notebook HDD you use on the USB port achieves less than 100 IOPS (see above result for USB HDD on Banana Pro with UASP incapable enclosure). By looking at iperf performance on the GbE interface you also overlooked that your web server is bottlenecked by the leased line to 100 Mbits/sec anyway.
 
What to do? Use HTTP transport stream compression since text documents show a compression ratio of more than 1:3, many even 1:10, (every modern web server and most browsers support this). With this activated NanoPi now reads the text documents from disk and compresses it on the fly and based on a 1:3 compression ratio we can stream 300 Mbits/sec through our 100 Mbits/sec line. Initially accessing files is still slow as hell (lowest random IO performance possible by choosing USB HDD) but at least once the file has been read from disk it can saturate the leased line.
 
So relying on passive benchmarking we chose a combination of devices (NanoPi M3 + 500 GB HDD) that costs +100$ considering also shipping/taxes and is slow as hell for the use case in question.
 
If we stop relying on passive benchmarking, really look at our use case and switch on our brain we can not only save a lots of money but also improve performance by magnitudes. With an active benchmarking approach we identify the bottlenecks first:
Leased line with 100 Mbits/sec only: we need to use HTTP content-stream compression to overcome this limitation Random access to many files: we need to take care of random IO more than sequential transfer speeds We need to tune our network settings to make the most out of the sitiuation. Being able to use the most recent kernel version is important! We're on a SBC and have to take care of CPU ressources: so we use a web server with minimum ressources and should find a way to avoid reading uncompressed contents from disk to immediately compress it on the fly since this wastes CPU ressources So let's take an approach that would look horribly slow in the usual benchmarks but improves performance a lot: An Orange Pi One together with a Samsung EVO 64 GB as hardware, mainline kernel + btrfs + nginx + gzip_static configuration. Why and how does this work?
Orange Pi One has only Fast Ethernet and not GbE. Does this matter? Nope, since our leased line is limited to 100 Mbits/sec anyway we know that the cheap EVO/EVO+ with 32/64 GB perform excellent when it's about random reads. At 4K we get 875 IOPS (3500 KB/s, see comparison of results), that's 8 times faster than using an external USB HDD we use pre-compressed contents: that means a cron job compresses each and every of our static files and creates a compressed version with .gz suffix, if nginx communicates with browsers capable of that it delivers the already compressed contents directly (no CPU cylces wasted, if we configure nginx with sendfile option not even time in userspace wasted since the kernel shoves the file directly to the network interface!). Combine the sequential read limitation of SD cards on most boards (~23MB/s) with an 1:3 compression ratio and you end up at ~70MB/s with this trick. Twice as fast as uncompressed contents on an USB disk unfortunately we would also need the uncompressed data on disk since some browsers (behind proxies) do not support content compression. How to deal with that? Using mainline kernel, btrfs and btrfs' own transparent file compression. So the 'uncompressed' files are also compressed but at a lower layer and while we now have each and every file twice on disk (SD card in fact) we only need 50 GB storage capacity for 100 GB original contents based on an 1:3 compression ratio. The increase in sequential read performance is still twice as fast since decompression happens on the fly. Not directly related to the filesystem but by tweaking network settings for low latency and many concurrent connections we might be able to improve requests per seconds when many clients access in parallel also by factor 2 compared to an old smelly Android 3.x kernel we still have to use on many SBC (relationship with storage: If we do tune network settings this way we need storage with high IOPS even more) An Orange Pi One together with an EVO 64GB costs a fraction of NanoPi M3 + USB HDD, consumes nearly nothing while being magnitudes faster for the 'static files web server' use case if set up correctly. While the usual moronic benchmarks testing CPU horsepower, GbE throughput and sequential speeds would show exactly the opposite.
 
And you get this reduction in costs and this increase in performance just by stopping to believe in all these 'benchmarking gone wrong' numbers spread everywhere and switching to active benchmarking: testing the stuff that really matters, checking how that correlates with reality (your use case and the average workload) and then setting up things the right way.
 
Final note: Of course an Orange Pi One is not the perfect web server due to low amount of DRAM. The best way to overcome slow storage is to avoid access to it. As soon as files are in Linux' filesystem cache the speed of the storage implementation doesn't matter any more.
 
So having our web server use case in mind: If we do further active benchmarking and identify a set of files that are accessed most frequently we could add another Orange Pi One and a Pine64+ with 2GB. The new OPi One acts as load balancer and SSL accelerator for the second OPi One, the Pine64+ does SSL encryption on his own and holds the most frequently accessed 1.7 GB in RAM ('grep -r foobar /var/www' at startup in the background -- please keep in mind that it's still +5 GB in reality if we're talking about a 1:3 compression ratio. Simply by switching on our brain we get 5GB contents cached in memory on a device that features only 2 GB physical RAM!). And the best: both new boards do not even need local storage since they can be FEL booted from our first OPi One.

The Pine64+ I had here (sent to @androsch a few days ago) with Armbian / Xenial (Xenial matters, I explain above why using Xenial vs. Jessie makes a difference if anyone relies on iperf/iperf3 numbers) has not the slighest problem to saturate its GbE interface. We also know that the USB 2.0 implementation of A64 is limited to ~35MB/s with BSP kernel (if you measure higher numbers you measured fs buffers). We also know that Samba without extensive tuning on SBCs doesn't perform very well. We also know that copying a bunch of small files takes longer than 1 large file over Samba since both Explorer and Samba do a great job in slowing things down.
 
That being said with good Samba settings you could expect ~30MB/s in both directions with large files.
 
If @androsch's Pine64 arrives here and I find the time I'll set up a RAID-0 with a bus-powered 2.5" disk (setting the DC5V/BAT jumper to power the disk from Euler pins) and a 3.5" disk and test throughput (my dev sample does not have this jumper and due to the Pine64 design flaws reliable operation with a bus powered disk is not possible). Apart from that: This here is Armbian, Pine64 is just one of over +40 boards we support, there exist a lot of better choices for NAS use cases: http://linux-sunxi.org/Sunxi_devices_as_NAS