zador.blood.stained

No, even if we tag the build script we are almost always using branches and not tags for upstream sources (kernel, u-boot, ATF), so it is possible that things would get changed and broken over time.
 
 LIB_TAG should be changed in the configuration file, it cannot be set via command line.

And also https://linux-sunxi.org/Linux_mainlining_effort for the A83T mainlining status and progress (we are not touching the BSP for this SoC).
 

Or it could be pushed into a separate branch, stay there while it needs testing, and then squashed into one commit and merged to master. While master is currently set to protected so it is not possible to change existing commits,  commits in other branches may be rebased, squashed or amended if necessary.
 
We could still create temporary topic branches on demand (i.e. sunxi-next-4.17) for large change sets.

Then it should be called "DFS" instead 
And yes, frequency switching should work on those images, as I remember the main problem was with the regulators (the "V" part in DVFS), and since AW refuse to provide the ARISC firmware sources it was never fixed.

I would prefer to do it correctly: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892768
 
And IMO there's no need to hurry and I honestly do not understand the bunch of hacks recently added to get 18.04 built now...

I believe there is a simple command line player (c2play) that makes use of the VPU (similar to omxplayer on RPIs). Of course this does not integrate with FFmpeg/gstreamer and other applications that may want to use HW video decoding.
These libraries can be used to integrate with different apps like Kodi.

Well, if Xunlong didn't change any markings on the board (especially the revision number) then it gets pretty nasty
 
Compile the list of affected devices first (i.e. by contacting Steven), then put the notice regarding possible instability for newer boards on board download pages. After that there are different ways to limit the top CPU frequency, but there are multiple things to check and change - default in-kernel governor, OPPs in FEX and DT, /etc/default/cpufrequtils

I recently purchased a number of Orange Pi and Nano Pi boards, and discovered the awesome work of the Armbian team :-)  The Orange Pi Plus2 H5 is a rather nice board - built in eMMC, H5, etc.  (I wish it had 1GB of RAM but that's a different subject.)  I'd love to use these boards for a number of projects.
 
As a test, I modified the DTS for the board (mainline kernel) to enable support for the 1.1v/1.3v switch for VDD-CPUX using the SY8113B on the board.  I also enabled the allowed clock changes to 1.2GHz for cpufreq.  All of this worked great, but the board was very unstable at anything over 1GHz, which seemed strange, given that the CPU voltage should be switching to 1.3v.
 
I found that when measuring the voltage of the "1V2C" testpoint on the board that VDD-CPUX was always at 1.1v - it never switched to 1.3v.  I did some further examination of the board, and I was surprised to find that the "Q5" BSN20 MOSFET was not populated on the board!  I checked all of the other passives and they are present - it is like Xunlong simply decided not to stuff this part when they built the board.
 
So, as a test, I desoldered this part from my Orange Pi Zero rev 1.4 board and soldered it in the missing "Q5" spot on my Orange Pi Zero Plus2 board.  And now it works great!  VDD-CPUX properly switches between 1.1v/1.3v (measured at the "1V2C" TP), and I can clock the board to 1.296GHz without any problems.
 
Would anyone have an idea why Xunlong doesn't solder this part on the board by default?  They include all the other parts in this part of the power circuit, just not this MOSFET.  I was going to buy a few more of these boards, and I'd like to be able to clock them up.  Perhaps I should just order a set of these BSN20 MOSFETs and solder them on myself when I receive the boards...?
 
Or perhaps I should just forget Xunlong/Orange Pi and use Nano Pis?  My Nano Pi Neo Plus2 has been working perfectly since I powered it up (I enabled clocking to 1.296GHz by default as well in the DTS).  By the way, I did some extensive tests and it looks like with both of these boards DVFS and thermal throttling works fine - the clock throttles back properly at the different temperature thresholds.
 
Thank you!
 

Not for the legacy kernel

It's much easier to make some "reference pictures" using this kind of board as a base than an SBC board.

Still not nearly as impressive as the new GPU solutions for Pine64, for people who don't like the Mali 400:


 

Still not nearly as impressive as the new GPU solutions for Pine64, for people who don't like the Mali 400:


 

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.

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.

I'm starting to regret that we added it in the past, and we need something that works reliably regardless of the daily log size. I have some thoughts, but different ideas have different requirements and expected reliability issues, and anything requires extensive tests.

I'm starting to regret that we added it in the past, and we need something that works reliably regardless of the daily log size. I have some thoughts, but different ideas have different requirements and expected reliability issues, and anything requires extensive tests.

I'm starting to regret that we added it in the past, and we need something that works reliably regardless of the daily log size. I have some thoughts, but different ideas have different requirements and expected reliability issues, and anything requires extensive tests.

I have to note that dietpi.com front page claims optimizations towards disk space, memory consumption and CPU usage by the OS, not overall CPU, network and I/O performance in real world scenarios which you are interested the most. While it's easy to show that counting processes or checking RAM usage produces numbers without meaning, I don't think we should focus on that (arguing related activities).

Symptoms:
Board does not boot Armbian from inserted SD card, but may boot other distributions (based on old/legacy u-boot).
Following or similar output can be grabbed from the serial console:
U-Boot SPL 2017.01-armbian (Feb 02 2017 - 03:04:04) DRAM: 2048 MiB Trying to boot from MMC1MMC: no card present spl: mmc init failed with error: -123 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### The key message here is "MMC: no card present"
 
Most likely cause:
Malfunctioning microSD slot card detect switch.
It can be verified either visually (with a magnifying glass) or electronically (with a multimeter) - at least in the slots used on Orange Pi boards and on Pine64 the pin near the switch should be shorted to the ground (i.e. SD slot casing) when card is inserted.
 
Illustration (example) of a working switch:

 
Verification (with a multimeter):
Probe 1 - slot pin near the switch (may be different for different slot types, but at least true for Oranges and Pine64)
Probe 2 - microSD slot casing or other parts connected to GND (not shown on the photo)
No card - circuit is open
Card inserted - circuit is shorted
 
Photos - card is not inseted on the left and is fully inserted on the right:
Orange Pi
 
Pine64 (switch is more visible)
 
Can it be fixed?
Yes if the switch is not broken completely, by carefully adjusting (bending) the stationary contact (left on the pictures and photos, it usually is a part of the SD slot casing) i.e using a needle so it touches the moving contact (mostly hidden inside the slot on the photos) when card is inserted and not touching it when it is not inserted.

- device tree compiler (dtc) should be recent enough - either compile from here or use one from kernel headers
- you need to tell dtc that you are compiling an overlay (add -@ command line parameter)

I think the issue here is an overall frustration by the core team due to many factors: stress, update failures (including ones that happened due to human mistakes), trying to support too many boards and too many features at once, failed expectations of users, board vendors and upstream developers. And this frustration exits randomly in random places, which definitely should not happen in public, especially for a relatively big and popular project.
 
(off-topic) Unfortunately a lot of both kernel and non-kernel issues are out of our control too. And there will be those issues when dealing with cheap and popular low-end devices (like OPi Zero) that have close to zero software support from vendor (well, cheap things are usually cheaper than other similar things for a reason).

Today A83T HDMI driver was merged Now to the H3/H5 driver, which should be more straightforward for mainlining. Seems like with 4.17 there will be no need for DRM patches, except maybe for A64 (depends when Icenowy can get DE2 clocks & SRAM patches merged).

According to my tests this will be fixed in 4.16. Or it can be fixed right now by removing NM and using a different way for configuring networking (ifupdown, systemd-networkd)
 
Edit: Though I don't have the Pro model so not sure if DSA will still be an issue with NM.

From Armbian documentation (https://docs.armbian.com/User-Guide_Allwinner_overlays/)
 
Most in-circuit and GPIO based interfaces (SPI, I2C, I2S, …) don’t have a mechanism for detecting and identifying devices connected to the bus, so Linux kernel has to be told explicitly about the device and its configuration details.
 
While Device Tree is a way of describing hardware configuration to the kernel, Device Tree overlays are a way for modifying the DT in order to provide the kernel and kernel drivers with details about external devices or to activate interfaces disabled by default.
 
What do we want?
 
We want to add Device Tree overlays for the onboard interfaces and tested external devices so that they appear in future mainline Armbian images. This means that activating this type of hardware will not require recompiling the Device Tree or will require compiling just the overlay file which will be compatible with future kernel updates.
 
What kind of help do we expect?
 
We want people to participate in making and testing overlays for the hardware that they have.
Participation requirements:
An A10, A20 or H3 board that can boot the current mainline kernel Serial console adapter for getting the u-boot logs if they are needed Extra SD card to use for booting the nightly/beta images I2C, SPI or I2S (only A10 and A20 based boards since I2S driver is not present on H3 yet) device that you can connect to the board and that requires either generic driver (like SPIdev) or a special driver (available in the mainline kernel), with an exception of custom built boards that don't have commercially available compatible alternatives and devices that don't have in-tree kernel drivers. Some generic Linux knowledge (i.e. how to obtain a dmesg log, how to check file contents) At least a basic understanding of the hardware that you have and how does it integrate into Linux. For example I have no idea how to calibrate a resistive touch screen even if I can write a DT overlay for it. Please note that some hardware limitations (i.e. number of SPI chip selects, missing SPI DMA support) may affect possibility of supporting some devices  
What overlays are already available?
 
Please check the README in the subdirectory for your SoC in the overlays repository: https://github.com/zador-blood-stained/sunxi-DT-overlays-armbian

You are trying to solve a problem that doesn't exist in a first place - OPi Plus2 works with existing OPi Plus configuration - DRAM size is autodetected by the u-boot/SPL and eMMC size is not hardcoded anywhere too.
 
I case you still want to go your way you need to add the missing DT file to the kernel too, if you provided a text boot log instead of pictures I'd copy the relevant part from it.