zador.blood.stained

Edit: Price seems to be $17.99
 
Just FYI: FriendlyARM is preparing another H3 board: NanoPi Air somehow related to NanoPI NEO (same low default DRAM clockspeed let me believe this). What we already know (by looking at Github commits):
onboard eMMC (no idea about the size) no HDMI no Ethernet AP6212 based WiFi+BT (connected through SDIO and UART) Personal assumptions:
most probably also just a single bank DRAM configuration most probably also a SD card slot maybe eMMC only an option and a basic version without eMMC available same 40 x 40 mm dimensions as NEO, eMMC on the lower PCB side next to H3, AP6212 on the upper (where the Ethernet Jack is located on the NEO -- assumption based on heatsink design for NEO) Therefore adding Armbian support for this board is pretty easy as soon as we're done with NanoPi NEO since it's then just combining settings for NanoPi NEO with Banana Pi M2+ (WiFi/BT).
 
No official announcement available yet and no traces in FA's wiki. But since the FriendlyARM folks follow the 'release often, release early' principle most information can be gathered from Github sources

This looks like an old Armbian version
 
 
 Exactly. This issue with firstrun script was fixed a long time ago. Please try more recent version (5.14 is available and it can be upgraded to 5.16)

OSD is available via software (pixman) on socs without G2D.The problem with Kodi is, that there is currently no prebuilt alternative to jernej ones. But this one uses Allwinner's code ... (<- as discussed on various other places).
Mosterta has done and is still trying (AFAIK) to do an implementation with using linux-sunxi.org/cedrus , the reverse engineered code from linux-sunxi community. More info about kodi story here: linux-sunxi.org/kodi (<- to be continued)
UI in kodi works through gles though which has to be implemented via Mali on sunxi. On both forks.
Rellla

I would guess no UI overlays (on video) and no subtitles (especially on H3 which doesn't have G2D)?

No, red LED is connected directly to 3.3v power, so it's a clear sign that PMU doesn't shut down correctly. I just tested my cubietruck, and there are no issues with shutdown (Debian Stretch, kernel 4.6.4, powered from barrel plug and battery)

There are some options that control this behavior: first, FORCE_CHECKOUT=no should disable overwriting modified source files, second, DEBUG_MODE=yes (it's a really non-descriptive name for this option that should be changed) allows creating patches based on your modifications to the sources.

I don't see any current limiters on BPro (compared, for example, with Orange Pi PC or Cubietruck schematics), so USB ports current limit is based on DC-DC converter current limit and voltage drops on PCB traces. Only OTG port is protected with SY6280 current limiter.
 
In addition to (or instead of) ordering cables you could order USB A and miniUSB/microUSB plugs and just solder any wires that would fit.
 
If you basically want USB power meter with external interface for reading measurements, you could combine some USB sockets/plugs, current sensor and ATtiny MCU programmed as I2C slave for reading internal ADC
 
Yes, but these pins may be used or not used on different boards, so amount of soldering and configuration steps may vary.

@wildcat_paris
 
You tested Banana Pi with mainline kernel, not H3 device with legacy kernel. I added some options to sun8i-default kernel config file, but didn't test yet if this fully solves the issue.

Yes, in igorpecovnik/lib master

Yes, in igorpecovnik/lib master

@wildcat_paris
 
You tested Banana Pi with mainline kernel, not H3 device with legacy kernel. I added some options to sun8i-default kernel config file, but didn't test yet if this fully solves the issue.

I'm not sure AXP209 is precise enough (well, datasheet doesn't provide ADC tolerance and current measurement path details) to use it for any absolute measurements, and you'll have to verify that it is linear enough to make relative measurements. If you want to use your board as a USB power meter - it may be possible. If you want to produce meaningful numbers - you better use something else. Speaking of meaningful numbers, Banana Pro generates 5V from IPSOUT voltage with DC-DC converter running (presumably) at 1MHz (yes, it has capacitors at input, but still), and, again, we don't know how well AXP209 handles measuring non-DC current.
 
Current shunts are usually designed for very small output voltage (i.e. 75mV at maximum current). A20 has only 8-bit Edit: 6-bit (!) LRADC (and doesn't have proper driver for reading it), and Arduino even at 3.3V reference will have input resolution of 3.2mV/bit, so with 5A 75mV shunt you will get resolution of 200mA/bit, which is bad. So either use shunt with special amplifier or buy a Hall effect current sensor.

It should work on kernel 4.4 with this patch (which is planned for 4.5).

I've been studying and working on Dynamic Device-Tree Overlays since awhile, but after hard work, I've finally got a working prototype using the work from Pantelis Antoniou.
 
During last few days, I was doing debugging to find out why it wasn't working, even if I got the ConfigFS working, it was refusing to grab my simple overlay test.
I've finally figured out this afternoon : the Root/Base DTB need also to be compiled with the "symbols" list generated with the Antoniou's version of "dtc".
 
So, I will probably prepare a patch soon and submit it thru a PR.
 

Yes, /etc/modules should support module parameters, but you can also put
gc2035 in /etc/modules without any arguments and put
options gc2035 hres=0 mclk=34 in /etc/modprobe.d/<some-file-name>.conf

Just tried a gpg --clearsign locally, so I can confirm that just the first of the two lines is required to get SHA512 signatures for --sign and --clearsign.
 
 
I think that no new GPG key is required this time. Using a specific algorithm for signing a message/file is completely independent from the key, so we can stick with the current key and just instruct gpg to use the right hashing.

You don't have to have a rootfs entry in fstab - just pass "rw" and "rootflags" to kernel command line to mount it from kernel
setenv bootargs "root=${uuid} rw rootflags=noatime,nodiratime ..." lime2-emmc is mainlined - separate DT file will be available in kernel 4.7

Overclocking H3 based boards is an option for users who believe in rationalism and not for users who believe in marketing bullshit. So @tkaiser simply protects this forum from users that would set their boards to 1.6GHz instead of 1.2GHz just because 1.6 is higher than 1.2, and then whine that "my board doesn't work anymore", "armbian is unstable" and "armbian sucks".

Overclocking H3 based boards is an option for users who believe in rationalism and not for users who believe in marketing bullshit. So @tkaiser simply protects this forum from users that would set their boards to 1.6GHz instead of 1.2GHz just because 1.6 is higher than 1.2, and then whine that "my board doesn't work anymore", "armbian is unstable" and "armbian sucks".

Overclocking H3 based boards is an option for users who believe in rationalism and not for users who believe in marketing bullshit. So @tkaiser simply protects this forum from users that would set their boards to 1.6GHz instead of 1.2GHz just because 1.6 is higher than 1.2, and then whine that "my board doesn't work anymore", "armbian is unstable" and "armbian sucks".

Well, if you use legacy image you have this driver already included and you don't have to do absolutely anything, except fix script.bin Unless you want to have it as a module, but this will give you just additional work without any benefit. Do you by any chance want to transfer this module to mainline kernel?

New u-boot issue will be fixed (or u-boot version will be reverted to v2016.05). Meanwhile you can try setting
BOOTBRANCH="v2016.05" in userpatches/lib.config
 
 
It can be done manually by disabling update procedures and building of additional applications and drivers.

Actually several tasks are executed at this point: 
Creating SSH keys Creating swap file Adjusting swap related parameters Tweaking ramlog if it is installed There should be some messages in /var/log/armhwinfo.log regarding some steps.
 
Are you sure that it completely hangs? Can you switch to other TTYs (i.e. to tty2 by pressing Ctrl-Alt-F2) and login from there if a prompt is available?

It was already fixed and an update will be issued ASAP to minimize the problem. This was simple overlooked so it could not appear in the changelog. We are overloaded. Sorry. 

Fixed, I only test for building.
https://github.com/igorpecovnik/lib/commit/98000d4021a5c4bc617fa9595685791db0cf3a01