zador.blood.stained

.asc file is a digital signature for .raw image (maybe you confused it with a public key), it is generated for each file individually after building, and it can be used to verify both file integrity and origin. You may want to read something like this and this to understand it better.

1) use https://github.com/rellla/softhddevice-openglosd/tree/glesas source for the softhddevice plugin
2) compile it with "GLES2=1 make"
Glut is needed for the opengl version. We are on arm, we don't have that.
And be aware: it's WIP!
Didn't I say that already ?

âžœ ~ % apt-file search glu.pc libglu1-mesa-dev: /usr/lib/arm-linux-gnueabihf/pkgconfig/glu.pc So you probably need to install libglu1-mesa-dev package

Either eMMC or NAND can be enabled by default since they share pins.
Enabling eMMC in u-boot (via patch) should be safe, this is needed to boot from eMMC. Enabling eMMC in fex files by default can be done only for boards that don't have NAND variant. This is needed to see eMMC in OS. For mainline there will be separate DT file for Lime2-eMMC board.

Non-free firmware package was removed from Xenial due to license issues. Since it doesn't have any dependencies, you can manually install package, for example, for Wily.
 
For build-dep you have to uncomment or add deb-src entries for each deb entry, check this for example. 
 
SHA1 is considered "not secure enough" currently, new APT keys should use more secure hashing algorithms. It is just a warning though, it should not affect anything.

OK, let's use Github wiki as a base. I already done some rework. First part is more or less done, now going to script part and fine tuning on the top of it.
 
https://github.com/igorpecovnik/lib/wiki

The one problem I had with a github wiki was how to access the raw contents? But as usual it's quite easy. Editing wiki pages creates revisions and raw .md can be obtained in an automated fashion:
 
The latest revision of https://github.com/ThomasKaiser/lib/wiki/01-User-documentation for example is always accessible as: https://raw.github.com/wiki/ThomasKaiser/lib/01-User-documentation.md
 
The whole wiki is just a git repo in itself so cloning it locally is also possible: https://github.com/ThomasKaiser/lib.wiki.git

Minor detail - let user pick their favorite editor, "edit file /etc/exports" should be simple enough.
 
They are insecure anyway since you don't configure authentication or access limiting 
 
fsid=num|root|uuid NFS needs to be able to identify each filesystem that it exports. Normally it will use a UUID for the filesystem (if the filesystem has such a thing) or the device number of the device holding the filesystem (if the filesystem is stored on the device). As not all filesystems are stored on devices, and not all filesystems have UUIDs, it is sometimes necessary to explicitly tell NFS how to identify a filesystem. This is done with the fsid= option. For NFSv4, there is a distinguished filesystem which is the root of all exported filesystem. This is specified with fsid=root or fsid=0 both of which mean exactly the same thing. Other filesystems can be identified with a small integer, or a UUID which should contain 32 hex digits and arbitrary punctua†tion. Linux kernels version 2.6.20 and earlier do not understand the UUID setting so a small integer must be used if an fsid option needs to be set for such kernels. Setting both a small number and a UUID is supported so the same configuration can be made to work on old and new kernels alike. TL;DR from my experience - explicit fsid parameter is needed when underlying filesystem doesn't support UUID (i.e. tmpfs)
Edit: I mean for non fsid=0/fsid=root shares.
 
       nohide This option is based on the option of the same name provided  in               IRIX  NFS.  Normally, if a server exports two filesystems one of               which is mounted on the other, then  the  client  will  have  to               mount  both filesystems explicitly to get access to them.  If it               just mounts the parent, it will see an empty  directory  at  the               place where the other filesystem is mounted.  That filesystem is               "hidden".               The  nohide  option  is  currently only effective on single host               exports.  It does not work reliably with  netgroup,  subnet,  or               wildcard exports. User ID Mapping nfsd bases its access control to files on the server machine on the uid and gid provided in each NFS RPC request. The normal behavior a user would expect is that she can access her files on the server just as she would on a normal file system. This requires that the same uids and gids are used on the client and the server machine. This is not always true, nor is it always desirable. Very often, it is not desirable that the root user on a client machine is also treated as root when accessing files on the NFS server. To this end, uid 0 is normally mapped to a different id: the so-called anony†mous or nobody uid. This mode of operation (called `root squashing') is the default, and can be turned off with no_root_squash. By default, exportfs chooses a uid and gid of 65534 for squashed access. These values can also be overridden by the anonuid and anongid options. Finally, you can map all user requests to the anonymous uid by specifying the all_squash option. Here's the complete list of mapping options: root_squash Map requests from uid/gid 0 to the anonymous uid/gid. Note that this does not apply to any other uids or gids that might be equally sensitive, such as user bin or group staff. no_root_squash Turn off root squashing. This option is mainly useful for disk†less clients.        -a     Export or unexport all directories.        -r     Reexport all directories, synchronizing  /var/lib/nfs/etab  with               /etc/exports   and  files  under  /etc/exports.d.   This  option               removes entries in /var/lib/nfs/etab  which  have  been  deleted               from /etc/exports or files under /etc/exports.d, and removes any               entries from the kernel export table which are no longer valid.   "exportfs -ra" is enough to apply any changes made in /etc/exports
Restarting nfs-kernel-server may be needed to apply changes made in /etc/default/nfs-kernel-server or to disconnect already connected clients
 
Not exactly. This is not documented well, but I meant building image with "ROOTFS_TYPE=nfs" option, which creates small SD card image and rootfs archive. Edit boot script on SD, deploy and export rootfs on a server and you are done.

Minor detail - let user pick their favorite editor, "edit file /etc/exports" should be simple enough.
 
They are insecure anyway since you don't configure authentication or access limiting 
 
fsid=num|root|uuid NFS needs to be able to identify each filesystem that it exports. Normally it will use a UUID for the filesystem (if the filesystem has such a thing) or the device number of the device holding the filesystem (if the filesystem is stored on the device). As not all filesystems are stored on devices, and not all filesystems have UUIDs, it is sometimes necessary to explicitly tell NFS how to identify a filesystem. This is done with the fsid= option. For NFSv4, there is a distinguished filesystem which is the root of all exported filesystem. This is specified with fsid=root or fsid=0 both of which mean exactly the same thing. Other filesystems can be identified with a small integer, or a UUID which should contain 32 hex digits and arbitrary punctua†tion. Linux kernels version 2.6.20 and earlier do not understand the UUID setting so a small integer must be used if an fsid option needs to be set for such kernels. Setting both a small number and a UUID is supported so the same configuration can be made to work on old and new kernels alike. TL;DR from my experience - explicit fsid parameter is needed when underlying filesystem doesn't support UUID (i.e. tmpfs)
Edit: I mean for non fsid=0/fsid=root shares.
 
       nohide This option is based on the option of the same name provided  in               IRIX  NFS.  Normally, if a server exports two filesystems one of               which is mounted on the other, then  the  client  will  have  to               mount  both filesystems explicitly to get access to them.  If it               just mounts the parent, it will see an empty  directory  at  the               place where the other filesystem is mounted.  That filesystem is               "hidden".               The  nohide  option  is  currently only effective on single host               exports.  It does not work reliably with  netgroup,  subnet,  or               wildcard exports. User ID Mapping nfsd bases its access control to files on the server machine on the uid and gid provided in each NFS RPC request. The normal behavior a user would expect is that she can access her files on the server just as she would on a normal file system. This requires that the same uids and gids are used on the client and the server machine. This is not always true, nor is it always desirable. Very often, it is not desirable that the root user on a client machine is also treated as root when accessing files on the NFS server. To this end, uid 0 is normally mapped to a different id: the so-called anony†mous or nobody uid. This mode of operation (called `root squashing') is the default, and can be turned off with no_root_squash. By default, exportfs chooses a uid and gid of 65534 for squashed access. These values can also be overridden by the anonuid and anongid options. Finally, you can map all user requests to the anonymous uid by specifying the all_squash option. Here's the complete list of mapping options: root_squash Map requests from uid/gid 0 to the anonymous uid/gid. Note that this does not apply to any other uids or gids that might be equally sensitive, such as user bin or group staff. no_root_squash Turn off root squashing. This option is mainly useful for disk†less clients.        -a     Export or unexport all directories.        -r     Reexport all directories, synchronizing  /var/lib/nfs/etab  with               /etc/exports   and  files  under  /etc/exports.d.   This  option               removes entries in /var/lib/nfs/etab  which  have  been  deleted               from /etc/exports or files under /etc/exports.d, and removes any               entries from the kernel export table which are no longer valid.   "exportfs -ra" is enough to apply any changes made in /etc/exports
Restarting nfs-kernel-server may be needed to apply changes made in /etc/default/nfs-kernel-server or to disconnect already connected clients
 
Not exactly. This is not documented well, but I meant building image with "ROOTFS_TYPE=nfs" option, which creates small SD card image and rootfs archive. Edit boot script on SD, deploy and export rootfs on a server and you are done.

Noticed following problems:
Links need some work Inline code (`code`) needs another color for highlighting Youtube video block needs to be removed or converted to link Line wraps in code blocks are not perfect Whole document needs index (hope this tool does support that) Page numbers may be good too

-22 is -EINVAL error. One of possible reasons may be transfer size limitation here: https://github.com/torvalds/linux/blob/master/drivers/spi/spi-sun4i.c#L178
This patch removes this limit http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/363074.html
but I don't have proper hardware to test it.

done.
apt-get update apt-get install rpimonitor

Building https://github.com/avafinger/guvcview with "debianization" overlay from Ubuntu resulted in these packages.

BTW, there is an alternative to this - hosting this deb file on apt.armbian.com

Downloading and installing .deb file manually (with all dependencies) without setting up repository?
Depends: perl, librrds-perl, libhttp-daemon-perl (>= 6.0.0) | libwww-perl (<< 6.0.0), libjson-perl, libipc-sharelite-perl, libfile-which-perl, aptitude apt-get install perl librrds-perl libhttp-daemon-perl libwww-perl libjson-perl libipc-sharelite-perl libfile-which-perl wget -O rpimonitor_2.10-1_all.deb https://github.com/XavierBerger/RPi-Monitor-deb/blob/master/packages/rpimonitor_2.10-1_all.deb?raw=true dpkg -i rpimonitor_2.10-1_all.deb

I've been working on the rtl8189fs patches for Mainline.
 
Althouth the source code change between Legacy and Mainline is pretty trivial, preparing good and nice patches becomes a tedious task :
 
- First, the original patch in Legacy contains tons of DOS file formatted (strange for a Linux driver, shame on Realtek) and even dos2unix failed on some files because of binaries character (probably Chinese), I had to edit many files because I wouldn't "signed-off" such ugly thing. (btw, maybe that dos2unix job should be done one Legacy to make it cleaner)
 
- It is a quick big patch, but about the same size as the one in Legacy, about 10MB of text file.
 
- Even after applying the patch, we still need to have some other patches, one for DefConfig in Igor's lib/config and one for DTS which I will work on tomorrow ...
 
- Then, lots of testing need to be done, especially that I need to figured out that everything is working in the fresh build environment, then a PR will be sent to Igor.

It's not a "live system" exactly, it is "root on NFS" started from FEL: https://github.com/igorpecovnik/lib/blob/master/documentation/fel-boot.md
 
Setting up RAM only system is not wise because FEL transfer speed is too slow (less than 1 MB/s) to load anything close to full OS. If you don't want to use NFS at all, you can try to pack busybox and rsync into initrd and don't use rootfs at all.

What do you need to solve here? The "universal" part? If you prepare u-boot images and .bin files (H3) and .dtb file (A10/A20) for all available boards and give user a selection menu, this part is solved. The only requirements are
a ) Linux host (another SBC will work)
b ) network connection (wired Ethetnet or g_ether will work, wireless is significantly harder AFAIK due to shared libraries dependencies for wpasupplicant).

If CONFIG_CMA is not set, you have to set sunxi_ve_mem_reserve. 150+ would be a good value. In Armbian default it is not set.
If CONFIG_CMA is set, sunxi_ve_mem_reserve= is ignored. By default, the CMA memory is hardcoded to 80MB.
 
So, if no patch activates CMA, you don't have to care about that, but just set sunxi_ve_mem_reserve. In this case, you also don't need libump and must not compile libcedrus with USE_UMP=1.
To let Mali and the VE use the same memory area for zerocopy features in the future (for the upcoming vdpau_gles_interop feature e.g.) you need to use UMP with CMA memory as backend. And then you have to increase the hardcoded 80MB depending on how much surfaces etc. your app uses.
 
I hope, this was kind of understandable
 
Regards
rellla

You can specify VID and PID as  module parameters to g_ether - check
sudo modinfo g_ether BTW. Did you try to force standart Microsoft RNDIS driver or it's impossible on Win10 x64?

@Gravelrash
 
Please take a look at updated hostapd compilation script for example.
 
Directory structure is easy to fix afterwards, but if you want to do it right from the start, here is recommended setup:
If package can be cross-compiled, it's better to put in into "$SOURCES/<package_name>" directory and compile & pack it in-place.
If package needs to be compiled in chroot, put in into "$CACHEDIR/sdcard/root/<package_name>", so you can access it in chroot in "/root/<package_name>". Don't forget to remove this directory after you successfully built the package.
After building a package copy it to "$DEST/debs"
 
If there are no dependencies between packages, create new script in "extras" for each package. If some packages needs to be built in specific order, you can build several packages in one script.

There needs to be an udev rule overriding this behavior. I'll add this to board support package later.
 
 
% dpkg -S $(which free) procps: /usr/bin/free

It will be enabled by default in new Armbian releases

linux-sun7i-default.config: CONFIG_QUOTA=y
linux-sunxi-next.config: # CONFIG_QUOTA is not set

Short changelog:
Removed autodetection for H3 boards, changed DVFS and thermal settings Repackaged tools, hostapd and firmware (may require manual installation of packages) Odroid C2: Fixed headers packaging script, updated kernel configuration, updated boot script Added back watchdog to sun7i-default kernel Purging and reinstalling "unattended-upgrades" package should be recommended in changelog Script "40-updates" update logic was changed; script was switched to python3 since Xenial doesn't use python2 by default. Installing "python3-apt" should be recommended in changelog. Reworked initrd images handling on kernel upgrade ... (to be added) Other fixes and enhancements  
Release 5.15 closes following issues: #285, #345, #362 (closed), #337 (closed)
 
I would propose some changes in this release:
 
1. Change "auto eth0" to "allow-hotplug eth0" and "auto wlan0" to "allow-hotplug wlan0" (uncommented) for all distributions except Wheezy, pack new interfaces files to board support packages;
 
2. Reduce number of preinstalled packages. In my opinion, default package list is rather big and some software can be removed from prebuilt images, especially if:
We don't provide any custom configuration for the package It can be used only with addidional hardware or is rather useless in default CLI images Is not required for any preinstalled scripts and required packages So I propose removing these packages:
libmtp-runtime mtp-tools bluez (but add "bluetooth" metapackage to desktop list?) ir-keytable weather-util weather-util-data dvb-apps libbluetooth-dev libbluetooth3 subversion iptables thin-provisioning-tools Any additions, thoughts or suggestions?
 
Edit: added thin-provisioning-tools