Tido

Completely agree...
 
Etcher does a great job - and the verification ensures that one has a good write to the card...
 
When in doubt - one can use the SDCard Formatter Util (Win/Mac) to "refresh" the card prior to writing...
 
https://www.sdcard.org/downloads/formatter_4/
 
If it fails, then check either the card, or the reader...

There was never a formal team. More like a strong common passion and interest to do something valuable, to push things forward, to help, to show how things should look like. IMO it worked very well until the level of self-fulfillment and happines was high enough and a mountain of problems low enough. People perception on this is very colorful and even among inner circle, we have different views. No matter how good and super the project might be. We have more and more users, while most of them waste our time and energy, contribute nothing and ask for more. This is not sustainable.
 
Armbian might not need major build script or infrastructure development, but both need regular maintenance. We are short already for that. Not hardware, not software but responsibility.
 
If board support is extending and developing, then this will bring solving harder problems which are not possible to be solved by a few people in their free time. This calls for 20-30x size of the budget size. Where from?

On the other hand, people expect that "we will solve all the problems they find out". Reality is that our main workforce is basically offline due to overload, mounted problems, life, ... 
 
We can talk about how to reshape the project, but first, you need someone that will execute what we brained out. 
 
Personally, I need to look on a project from a distance and leave super (hardware) details behind. It might give me an opportunity to better see the problems we have. 

Hello,
 
Add latest U-boot support for BPI-R2 & BPI R64 (not yet)
 
Status:
I’ve already sent the first round patches for MT7623n,  and the most of the drivers are based on mainline Linux, like clock, timer, mmc, pinctrl, watchdog, power domain and DTS.
 
I will also upstream U-boot  and ATF for MT7622 (BPI-R64) in the future.
 
The following are the major differences between Linux and U-boot:
-Modify the driver interface to adapt the U-boot DM framework.
-Remove unneeded DT nodes as they don’t have proper drivers in U-boot yet.
-Just add the basic functions (step-by-step) so that we can monitor the size.
-Reuse UART driver ns16550.c but add a highspeed register for MediaTek chips.
 
The current progress for R2:
-Boot from eMMC or SD card.
-ROM -> MediaTek preloder -> U-boot -> Linux
 
Todo list:
-Ethernet driver
-Other peripheral drivers.
-U-boot for MT7622
-ATF (arm trusted firmware) for MT7622
 
The patch sets:
-https://patchwork.ozlabs.org/project/uboot/list/?series=68601
 
How to build:
-make mt7623n_bpir2_defconfig; make
 
Ryder

That output seems incomplete, something went wrong. In any case, make sure the output of 'uname -r' shows that you are using the Default (4.4.y) version of the kernel. Or maybe it is better to just wait two or three weeks, and I'll try to release the Bionic version by then.

Hehe... just wait for USB-C connectors on SBC's... that's going to be a mess with all the interesting options
 
(perhaps the reason why the folks over on Cupertino decided with their recent HW releases to keep their proprietary connection)

There are still (many)some (short and) long-term questions which are scattered on the forum and in our heads which we would need to discuss.
 
- release naming, 2018.10 or 18.04 + some RFC as shown on the pic,
- collecting wishes on a special web page or forum topic. When someone approaches with "I want to help" that it is appointed to 1. Check issues on GH, 2. Fixing sound ... 3. Creating this ...
- improving testing protocols, automating what is possible. I'm low on ideas what more is possible to do.
- what to add to »end of support«?
- secure project longterm survival, leverage maintenance costs to users or drastically limit down free support,
- enforce browser of choice for desktop images, Firefox and/or some lighter alternatives?
- fix Bluetooth on all Broadcom AP62xx devices. Its the same on most boards, but we have it working only on a Cubietruck IIRC
- sum most frequent problems under »The Ten Commandments« / FAQ and promote it as much as possible
 
- does forum need structure update?
- add/remove moderators? Disable rights if not moderating content in past 6months?
- enforce forum rules? Some very simple ones.
- users are still seeking for help without providing logs. What to do about?

Download UX:
- make a bigger diff between nightly and stable, desktop and CLI (Gorazd)
- add a warning when nightly is downloaded, (Gorazd)
- tested devices lead to their test page where exists instead of Amazon affiliate, (Gorazd)
- tested hardware have information to which kernel is attached to but not displayed, (Gorazd)
- check other download option still no visible enough, (Gorazd)
- add a support box with 1. Check common issues 2. Search for solution 3. Ask (with a link to the correct forum) (Gorazd)
- add a button »alternative builds« with a link to dl.armbian.com/DEVICE (Gorazd)
 
To keep things in place, I would like to ask @Tido and @chwe  to help keep this 2do list up2date according to with our decisions.

Anyone interested in RTD1295/RTD1296 platform would need to do something like this first
check out upstream mainline kernel at version 4.9.119 import changes from RealTek's kernel above (you then end up with one giant commit like this -- context) Now you can spend some days or weeks to have a look what's different, where security holes exist (remember Allwinner's 'rootmydevice'?) and what's not properly licensed If this step is skipped there exists no reason to trust into RealTek's 4.9 at all. Especially if this step is skipped it's impossible to start with Armbian support for RTD1295/RTD1295 devices since it would harm the project repeating mistakes like with Allwinner's H3 BSP kernel again (where something like rootmydevice was only discovered by accident).
 
We can't trust Android vendor's BSP kernels since those employees forced to hack driver support into something they're not interested in (the Linux kernel and its concepts) never worked with mechanisms like peer review or code quality control. If those employees would've started to submit patches upstream where all this stuff happens (Linux kernel community) then this would be something entirely different. But RealTek just like Allwinner and the majority of ARM SoC vendors has no interest in properly upstreaming their code so this code can't be trusted.
 
If their stuff is not properly licensed this will most likely prevent developing mainline drivers for the affected hardware (but I doubt anyone will do this anyway since so far only Suse's Andreas Färber worked on the platform -- tried to inform him via CNX but no idea whether he's aware that some RealTek kernel sources are now provided).
 
Having now sources does not mean everything's fine now. Next step is looking at the mess contained (if anyone wants to spend weeks of his life with something like this).
 
 

Of course it does NOT work which is a problem since BPi folks distribute all their software solely through their unprotected forum:
 
http://www.banana-pi.org/download.html (no HTTPS) --> http://www.banana-pi.org/downloadall.html (no HTTPS) --> http://forum.banana-pi.org/c/Banana-pi-BPI-W2/BPI-W2-image (no HTTPS)
 
For any serious or professional use cases it's impossible to continue since a MITM (man-in-the-middle) attacker would download an image from them, open/modify it adding some nice backdoors, then uploading it somewhere on Google Drive, setting up something that looks like a download page and then doing some DNS spoofing. Not very likely but software downloads in general that are not protected by at least HTTPS aren't trustworthy at all. Any potential professional customer like @botfap will immediately turn away when seeing stuff like this.
 
This was just another free community service for our beloved Banana folks which of course will result in @Lion Wang talking about some evil individual (me) constantly attacking him. 

Current proposal?
 
the FAT32 config partition is at the end of the disk image firstrun applies configuration changes config file is scrubbed via shred for security purposes fat32 part is destroyed rootfs expansion step proceeds as normal

I envisage it more as a troubleshooting tool at this point for headless boards but it could be used for a lot more I suppose
 
Initial version to test: https://github.com/botfap/armbian-image-config.git
 
Working for injecting hostname and wifi and ethernet network profiles. DHCP only for now but I will update it later
 

I don't have reference, but if you do in a terminal:
dpkg -l python3.*
you can see what version you have installed by looking for the 'ii'.
 
As @martinayotte, already wrote 2.x and 3.x is usually already installed. Depending on your 'project' the installed version is already sufficent for your needs and you can start programming :-)
 

*** This is educational material only concerning current limits and their effects on things like rise and fall times, and how they can theoretically impact SD cards.  The correlation with reality is purely theoretical and has not been empirically proven, the concept is correct but any specific values may be/ probably are off by some factor***
 
A lot of boards from various vendors inevitably have some difficulties with electrical signalling.  You see it in delay values, phase correction in software, etc.  The general prevailing theory is almost always "get it close and fix it in software".  But, the software team is not always clued in, or the physical reality is simply not able to be fixed that way.  Today I'll go into SD cards and the need for proper signal paths, limited capacitance along the way, and proper drive levels at the SoC.
 
This came to my attention while reviewing failures to boot on RK3328 devices, and while this particular issue may still be independent (no root cause confirmed as yet), I have a suspicion it is at least a contributing factor.
 
GPIO's on SoC's have, typically, current limiting on each pin or bank of pins.  For Rockchip, this limit defaults to 4mA, with 8 and 12 being available as optional settings.  This includes the SD card bus, clock, output, etc.  These current limits are exactly that, limits.  If the interface only needs 1 mA, it will only pull 1 mA, regardless of the GPIO drive setting.  if it needs more, however, it will only get what the drive setting allows.
 
SD card interface standards have 3 voltage signalling modes, SBC's only make use of 1 or 2 of them.  Many boards supply only 3.3V to the card, limiting to frequencies of 25 or 50 MHz.  Those that support UHS-I modes allow 1.8V signalling, and the range of speeds there include the original 25 and 50 MHz, but add higher speeds as well (100 and 208).  The higher speeds absolutely require the lower voltage, though the 25 and 50 Mhz speeds benefit from it as well due to improvements in rise/fall time with the smaller voltage transitions.
 
The SD standard requires a total line capacitance of 40 pF or less on each line, including the internals of the card.  I will simply assume 40 pF for the simulations, as it's likely few if any of these boards are "optimal" in that regard.
 
I'll be using LTSpice as an aid to show the effects of the current limitations, measuring voltage across the capacitance.  In reality there would be a complex impedance with the resistance I'm not modelling and the capacitance distributed throughout the system, which would cause some slightly different behavior.  This is mostly an educational introduction to the scary universe of high-frequency switching, so I'll skip the really gory details for the sake of readability.  In this circuit the LimiterDiode does exactly that, it limits current.
 

 
With a 4 mA limit into a 40 pF load at 3.3 Volts, 50 MHz, the signal is unusable.  Top in blue is the current sourced by the supply, stuck at the 4 mA limit at all times, below in red is the desired waveform, in green the result.
 

 
The board will crash if it attempts this.  Now, you might say, what if the board is extremely well made and the capacitance is lower?
 
Well, it looks like this (assuming 20 pF, which may not really be possible):
 

 
Still, no hope of operating properly.  Dropping to 25 MHz has roughly the same effect.  As I said, this is worst case, so don't jump down my throat about your board with the limits working at 4mA.  I am also assuming 4 mA source and sink limits, it may not be symmetrical, in which case the shape goes from triangle to shark fin.  Cutting the voltage almost in half by going to UHS-I signalling levels has the same effect (ratio wise vs the V_High value) as cutting the capacitance down.
 
On the ASUS tinker board this was discovered at some point, and the current limits increased to 8 mA.  I have not tried a card with no UHS support at 50 MHz (at least to my knowledge), the results at 3.3V/50MHz still look bad in my oversimplification, much like cutting voltage in half or capacitance or frequency, again, they all play into the same charge rate/time constant
 

 
At 25 MHz, however, 8 mA is far more reasonable:

 
Now to the big reason for 1.8 V signalling:

 
50 MHz, 1.8V, 40 pF, 8 mA drive.
 
Assumptions:  source/sink values both controlled.  It's possible this is not the case.  If there is no "sink" limit, or if you assume 20 mA sink limit:
 
 
3.3V signalling, 50 MHz, 40 pF load, 8 mA source, 20 mA sink:

 
Now, as a final bit, assume there were no current limits of any kind, and let's measure what the system would need to supply at 50 MHz 3.3V:

 
So 120 mA or so to create the exact waveform, assuming some sort of simulated resistance somewhere in the system (in reality there would be a measurable resistance and therefor a current lower than 120, but also a longer rise and fall time)  Needless to say, a lot more than 4.
 
This is mostly important for boards that do not implement the 1.8V signalling modes, but do have aggressive current limiting on the SD card I/O's.  50 MHz is a bad place to live at 3.3 volts given a mechanical connector with wide flat terminals, and routing that doesn't always get as much care as maybe it deserves.  RPI, a board with these issues, seems able to source/sink 16 mA, most likely accounting for it's ability (when not starving itself for power, cooking itself, etc) to be "overclocked" in highspeed 3.3V mode.  Rockchip can only push 12 mA, I haven't read up on Amlogic yet, so you can't expect to have the same performance if you're not willing to add the necessary support for 1.8V signalling.
 

I guess you came across his first post: https://forum.armbian.com/topic/2419-armbian-for-amlogic-s905-and-s905x/
Once you have multiboot, you can backup the eMMC (especially the dtb), then copy Balbes armbian on eMMC and now you can tweak it how you like it.
eMMC needs many partitions, I don't know why.
 

I don't know and don't care so much about the u-Boot as long as it works as expected.
Balbes images are based on armbian 5.59 and Kernel 4.18 https://yadi.sk/d/pHxaRAs-tZiei/5.59/20180829
And as I wrote before, with Multiboot you can boot from every source obviously which might be useful doing it the hardway ;-)
 

Have you got a tool to check the latency to compare USB2 and USB3? Or CPU usage when doing the same workload?
My understanding of the difference between USB2 and 3 is USB2 is polled, while USB3 is interrupt driven.
 
Assuming you haven't done something wrong and your numbers are an accurate representation, maybe at the hardware level USB3 requires more resources, all the interrupts could be causing excessive context switching. Or the drivers aren't as optimised yet.
would be interesting to compare between different hardware USB3 implementations.

I had the SSH session window still open and collected the relevant logging portions from 'iostat 1800' while running the test with USB3, USB2 and then again zram/lzo (which also surprisingly again outperformed lz4):
USB3: %user %nice %system %iowait %steal %idle 82.31 0.00 12.56 4.68 0.00 0.45 74.77 0.00 16.80 8.25 0.00 0.18 55.24 0.00 19.84 24.44 0.00 0.48 72.22 0.00 16.94 10.43 0.00 0.41 50.96 0.00 22.24 26.09 0.00 0.71 USB2: %user %nice %system %iowait %steal %idle 81.77 0.00 11.95 5.30 0.00 0.99 75.99 0.00 16.95 6.71 0.00 0.35 66.50 0.00 19.19 13.81 0.00 0.49 77.64 0.00 18.31 3.97 0.00 0.08 44.17 0.00 12.99 13.09 0.00 29.74 zram/lzo: %user %nice %system %iowait %steal %idle 84.83 0.00 14.68 0.01 0.00 0.48 82.94 0.00 17.06 0.00 0.00 0.00 81.51 0.00 18.49 0.00 0.00 0.00 78.33 0.00 21.66 0.00 0.00 0.01  
 
That's an interesting point and clearly something I forgot to check. But I was running with latest IRQ assignment settings (USB2 on CPU1 and USB3 on CPU2) so there shouldn't have been a problem with my crippled setup (hiding CPUs 4 and 5). But iostat output above reveals that %iowait with USB3 was much higher compared to USB2 so this is clearly something that needs more investigations.

Hallo Guido,  I just burned for the tinker board K4.14 and now K4.4, it works like a charm   it wrote that it writes with up to 34MB/second on the Samsung EVO Plus 32, can you ask for more?
As my device is 'young' compared to yours I already have the latest firmware on it.  Vielen Dank für den Tipp, Tido
 

OK, the audio confusion that was going on is, I think, resolved.  I cleaned up my pa configuration patching and added a udev rule so pulseaudio doesn't enumerate the device twice (which it was doing)
 
udev rule targets the specific VID:PID of the onboard ALC4040 so external USB cards still work (currently listening to a 2007 Creative Labs X-Mod)  <--  Card is crappier than I remember.  Maybe some caps are bad after 11 years of abuse/neglect, I hear audible noise in my headphones.
 
Build and test if you would, it will be in the next release.
 
[edit]   Kernel 4.18 is now bootable, but needs some love before it's ready for use:  http://ix.io/1lpi

Just a little bit list, more detail would be done on wiki soon.
1. NEO4 board size is 45 x 56mm, but M4 is 85 x 56mm
2. NEO4 has 1GB DDR3 RAM with single chanel, But M4 has two version 2GB DDR3 RAM/4G LPDDR3 RAM with Dual Chanel.
3. NEO4  will use AP6212 wireless module with single antenna , but M4 use AP6356S dual-band module, and use 2x2 MIMO and 2 real antennas. 
4. NEO4 has one MIPI-CSI, M4 has two MIPI-CSI
5. NEO4 has USB3.0  x1 & USB 2.0  x1, but M4 has USB 3.0 x4 behind a VL817 internal hub.
6. NEO4 use 1.27mm pitch SMD connector for GPIO-40 pinout,  M4 is same with RPi3 40pin GPIO.
 
Both have:
1. PCIe x2 pin-out
2. eMMC module connector
3. GigE port.
4. TypeC is for power supply and OTG.
5. HDMI-A & MicroSD slot.
6. Big CNC heat sink, with two side 1/4 screw hole

https://github.com/armbian/documentation/blob/master/docs/Release_Changelog.md (please add what you think I forgot and is relevant to mention, up to 6 months back)
all images were rebuilt, except boards which support ended, and with a few exceptions which are still in the works (Tinkerboard, MiQi and perhaps we can move T4/RockPRO to the stable) and will be added probably next week. I already test a few and so far I couldn't find troubles. I record them here: https://github.com/armbian/testings. The result is displayed in this https://beta.armbian.com/buildlogs/report.html table and when it is filled up, an update to the main repository on all images can be rolled out.

Cons: I never worked on ffmpeg source or V4L2, so there is large amount of code and documentation to research.
Pros: It is the best way to go on for Kodi. It wouldn't even need any change, while for current approach, it needs a patch, which has to be cared for (I''m not sure if approach taken in that patch would be acceptable for upstream Kodi). I think that other problems could also be avoided like excessive buffering...
 
Please don't take that for granted, I don't know ffmpeg well.

Direct access is a bit strong word. Technically, it means that VAAPI layer would be dropped and same interface as in https://github.com/bootlin/libva-v4l2-request would be used (V4L2 interface with new additions).
 
 
If I understand correctly, "untiling" research took a bit more time than anticipated. Please also note that request API patches (base for AW VPU driver) are at v18 (!) written by multiple people outside Bootlin. But now that V4L2 base (request API) and VPU driver base are more or less finished, it should be much easier to add support for other codecs.
 
BTW, you can actually watch movies with current H264 driver. It just doesn't cover all possible variants and from time to time you can see artifacts. Bigger problem is ffmpeg + VAAPI combination for H264, since you often run out of memory (note that VPU can address only 128 MB of memory and currently DT allocate even less). This problem is know and noted on cedrus wiki page. I hope that using more direct approach in ffmpeg this could be solved.
 
Contrary to you, I'm not disappointed, since the work needed to make stable base is enormous. Framework which support such driver (request API) is evolving along AW VPU driver and AW VPU driver will be it's first user.

MPEG2 is with latest version definitely production quality while H264 is not. You must understand that MPEG2 is very simple codec. It seems that focus shifted to H265 because Paul has a contract only until end of August. Fortunately, H264 and H265 share some common features, so work on H265 will definitely help with H264.
 
However, it turns out that ffmpeg + vaapi doesn't work well for some not so well formed MPEG2 files (same issues with Intel vaapi + ffmpeg), while purely SW ffmpeg decoding works well. I kinda started working on direct ffmpeg integration, but I'm not sure if I have enough motivation to actually finish it.

@dimraz you only do:
 
armbianmonitor -u
 
 

In the post above, I wrote about the full analogue of MVR9. Here are the specific links to this device. By the way, freaktab has several special themes for this model. For it released fresh firmware and Libreelec.
 
http://freaktab.com/forum/tv-player-support/rockchip-based-tv-players/rk3328-devices/653167-bqeel-mvr9-rk3328-quad-core-64bit-cortex-a53-android-7-2-16gb-2-4ghz-wifi-bt4
 
https://www.amazon.de/dp/B07FT2LH22/ref=psdc_189155031_t2_B076BGBV4Y
 
https://www.ebay.com/itm/Bqeel-MVR9-Android-TV-Box-Android-7-1-Supporta-Aggiornamenti-Firmware-2G-/282839333163?_ul=RU
 
http://freaktab.com/forum/tv-player-support/rockchip-based-tv-players/rk3328-devices/686375-mvr9-rk3328-nougat-rom-by-mo123
 
http://freaktab.com/forum/tv-player-support/rockchip-based-tv-players/rk3328-devices/712961-mvr9-rk3328-libreelec-release
 
 
I do not have RK hardware yet, so I will refrain from specific comments.