botfap

I feel left out but it’s 2:30am and the fanciest action in my kitchen is a Molotov cocktail 
 

The armbian-image-config script is pretty much done, I'm about to push it to github but thought I best check a couple of things first with people who are more knowledgeable about Armbian than me
 
Apart from sudo netdev audio video dialout plugdev input bluetooth systemd-journal and ssh, are there any other groups that you want the user adding to? What files need deleting or modifying after initial setup but before 1st reboot? (/root/.not_logged_in_yet, ~/Xauthority) For debugging 1st reboot problems, is there any interesting info outside of /var/log? (assuming log2ram is disabled) I have only added support for WPA-PSK in the wifi setup. IS WPA-Enterprise or radius auth used enough to justify adding support for them? IPv6 support is currently DHCP or auto config only. Are there many people who use IPv6 ONLY, no IPv4, with static addressing?  
 
@lrrr I understand that. I like the idea, we do something similar in our production boxes. start the rootfs at an 8mb offset and embed a 4mb hidden, compressed fat partition between uboot and rootfs containing config information. We then have a windows GUI tool to manipulate the 3 files we store in there. I just dont think its suitable for Armbian, its adds a small level of complexity that is difficult for non tech users to troubleshoot. It also requires any minor tweaks, say a change of hostname, to have to repack and reinsert data to the disk image or SD Card. I could be wrong, feedback would be appreciated
 

Im not sure that 12mA was the only safe setting, it was the only setting that helped to stop sd corruption when using very low end or fake sd cards. 8mA was rock solid stable when using any normal sd card. Its also probably a better default for Armbian. If the users sd card wont work properly with 8mA of current then it has no place for sbc use I would have thought, the sd card is almost certain to cause other problems later on

Try pre configuring the image and network with a static IP before boot
 
There is a simple script in dev that will do that here: https://github.com/botfap/armbian-image-config
 
git clone https://github.com/botfap/armbian-image-config.git cd armbian-image-config For Ethernet:
sudo ./armbian-image-config armbian-image.img e|ethenet [dhcp|static] [ipaddr mask] [gw] [dns] e.g. sudo ./armbian-image-config armbian-image.img ethernet static 10.0.0.50 255.255.255.0 10.0.0.254 9.9.9.9 mynet.lan  
For Wifi:
sudo ./armbian-image-config armbian-image.img w|wifi [dhcp|static] ssid key [ipaddr mask] [gw] [dns] [search] e.g. sudo ./armbian-image-config armbian-image.img wifi static MyWifiAP MySecret 10.0.0.51 255.255.255.0 10.0.0.254 9.9.9.9 mynet.lan  
Obviously replace armbian-image.img with the path and name or your Armbian image file. Then write that file back to SD Card

Can you try setting the connection details and IP address manually in your image before boot? Does it still not connect?
 
If your device has been randomizing mac addresses, then your DHCP pool may have run out of addresses, even though it doesn't list them as used
 
If you run tcpdump on the dhcp box can you see any DHCP negotiation traffic?

You're not alone, many board makers have to sign NDA with chip vendors. For example, when Dragonboard 820c was under development, they signed NDA with Qualcomm, and they must get approval before releasing Qualcomm kernel/bootloader sources.
However before they got the approval to release kernel/bootloader source code, they didn't even release the board, nor any GPL-licensed binaries. You should follow the rules, too.

As for the armbian-image-config
 
https://github.com/botfap/armbian-image-config

Tool to pre-configure basic system settings on Armbian images. Each module can be used independently on an image but using the same module twice will overwrite not combine any changes. This tool needs superuser permissions to mount and write to system files on disk images, you will need to run it with sudo or in a root shell
armbian-image-config armbian-image.img module [options] modules: n|hostname [mynewhostname] e|ethernet [dhcp|static] [ipaddr mask] [gw] [dns] [search] w|wifi [dhcp|static] ssid key [ipaddr mask] [gw] [dns] [search] u|user [username] [password] l|log2ram [enabled|disabled] d|debug [enabled|disabled|save] r|remote [ssh|xrdp] [enabled|disabled] t|template [package|template.tgz] x|rootshell h|help  
Image Info
Image file can be any standard Armbian image (or ubuntu 18 / debian 9). Either self built or downloaded
Replace image name with keyword "template" to generate just the config files ready to make a template package
 
Module Help and Examples
hostname or n
Sets the system hostname for the image
armbian-image-config armbian-image.img h|hostname [mynewhostname] n|hostname name armbian-image-config armbian-image.img h myserver
ethernet or e
Sets up ethernet networking for the first detected card for either DHCP or static IP addressing
armbian-image-config armbian-image.img e|ethenet [dhcp|static] [ipaddr mask] [gw] [dns] e|ethernet d|dhcp s|static ipaddr mask [gw] [dns] [search] armbian-image-config armbian-image.img e d armbian-image-config armbian-image.img e s 10.0.0.50 255.255.255.0 10.0.0.254 9.9.9.9 mynet.lan wifi or w
Sets up wifi networking for the first detected card for either DHCP or static IP addressing
armbian-image-config armbian-image.img w|wifi [dhcp|static] ssid key [ipaddr mask] [gw] [dns] [search] w|wifi d|dhcp ssid key s|static ssid key ip mask [gw] [dns] [search] s6|staticipv6 ssid crypto key ip6 mask6 [gw6] [dns6] [search] armbian-image-config armbian-image.img w d MyWifiAP MySecret armbian-image-config armbian-image.img w s MyWifiAP MySecret 10.0.0.51 255.255.255.0 10.0.0.254 9.9.9.9 mynet.lan user or u
Sets the username and password of the primary system user
armbian-image-config armbian-image.img u [username] [password] log2ram or l
Enable or disable log2ram for troubleshooting startup issues
armbian-image-config armbian-image.img l [enabled|disabled] remote or r
Enable or disable remote access via ssh and rdp
armbian-image-config armbian-image.img r [ssh|xrdp] [enabled|disabled] debug or e
Sets the boot diagnostics to enabled / disabled or save logs from image to a local archive
armbian-image-config armbian-image.img d|debug [enabled|disabled|save] d|debug enabled disabled save e.g. armbian-image-config armbian-image.img d save rootshell or x
Mount the image and start a chroot shell
armbian-image-config armbian-image.img rootshell template or t
Inject a config template into the image. Can be any files in a compressed tar archive which is extracted at root (/) on the image root file system. See also Creating templates below
armbian-image-config armbian-image.img t|template [package|template.tgz] t|template package template.tgz e.g. armbian-image-config armbian-image.img t aic-template.tgz  
Creating templates
To create a config template, consisting of the config of 1 or more modules, use the keyword "template" instead of an image file name. This will populate the "tmproot" folder with the generated config files ready for packaging. To create a package use the command "armbian-image-config template package" and a config packaged named aic-template.tgz will be created
armbian-image-config template n tvbox armbian-image-config template w d MyWiFi wpa-psk MySecret armbian-image-config template package  
Development Status
Active
#### Module Progress
- hostname - done, needs testing
- ethernet - done, needs testing
- wifi - done, needs testing
- user #TODO
- log2ram - testing in botfap branch
- debug - testing in botfap branch
- template done, needs testing
- rootshell #TODO
- help - done, needs testing

I feel left out but it’s 2:30am and the fanciest action in my kitchen is a Molotov cocktail 
 

I feel left out but it’s 2:30am and the fanciest action in my kitchen is a Molotov cocktail 
 

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
 

You have a build framework that works pretty good, is it out of the question to have an extremely simple configuration framework? Maybe framework is more advanced than needed, probably just a script? 
 
It it doesn’t need to be part of the normal build process but could just simply inject a configuration profile into a completed rootfs, image or actual sd card
 
Just the basics:
Single network manager profile
hostname
default user and pass
serial console config 
log2ram status
remote login status (ssh, xrdp)
 
I don’t mind writing a simple v0.1 to get started 
 
 
 

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
 

Did some quick research after noticing your edit and wanting to verify my vector instruction suspicions. Neither lzo or lz4 use neon vector instructions on Arm7 or 8 which is very far from ideal and explains why the performance of lzo and lz4 is much better on Intel than on Arm
 
 

UK Server deployed. Details PM'd

Hi @TonyMac32
 
The HDMI script is very generic, I created it to handle most use cases for display output and is not SoC specific. I have an extended version that also covers LVDS and VGA output devices if you wanted to include a more generic version to cover all possible displays and SoC's for a generic Armbian script.
 
Im working with some students, teaching (and creating) an embedded systems course for my local tech college till the end of the year. We are using Tinkers and some RK3399 dev boards that I managed to pick up very cheaply. I have built them a minimalist OS (glibc, busybox, weston/wayland, gtk3: ~56MB image size, not debian/ubuntu based) to get started with and their project is to create working kernel images, bug fix, add features and build a simple cloud management solution. My next step was to get them to examine Armbian's kernels to use as a starting point, compare to RK-BSP and mainline and figure out how to package it in a single code base to work across multiple RK boards and generic armhf / aarch64 qemu targets. So I have 3 unskilled but willing students I can point to help on this if you like.

Not actual answers but:
 
70-80% of other Armbian users I have encountered (outside this forum) are only looking for 1 thing. Ubuntu desktop or server on their TV box or new SBC toy. Armbian just happens to be the easiest way for semi or non technical users. Usually they come looking for Armbian or something similar because of problems or limitations in the stock Ubuntu image offered by their ODM. I say Ubuntu because thats what most have them have heard of or run in a VM so thats what they ask for. Very few of them have even heard of Debian. These people are not interested in development or bug fixing or contributing. They will however spread the good (or bad) word depending on their experience, and that is very important for the long term viability of any project. While the individual opinion of anyone from this group is pretty much irrelevant to development process the collective opinion is valuable and should be listened too.
 
How do you keep these people out of developer discussions? New users dont get posting privileges to Developer support unless they contribute (code, docs, bug fix, cash donations, etc) and you expand peer to peer tech support.
 
1. What does Armbian bring to the SBC and its users that the Vendor does/can not?
2. What does the SBC, it's vendor, and its users bring to Armbian that would be a benefit to the community?
 
Im not sure what Armbian brings to a particular SBC is important. It may be, but from my commercial perspective SBC's come and go fast, SBC retailers come and go fast, users mostly have no loyalty to either, they just want an operating platform that consistent and usable across projects.
 
You mentioned the concept of an "Armbian Device" which I think is a great concept, hard to define right now, but the concept of an "Armbian Device" that just works with your project code, no changes, is a very powerful concept. In my experience thats what devs and aspiring devs are looking for. Thats why I suggested the standardised functionality in the meltdown/spectre post. That standardised functionality would also elevate Armbian's usefulness well above any stock distro or ODM image.
 
Users benefit a community. ALWAYS. Very few users follow specific SBC's, most of them are looking for an SBC to use with the operating platform they are familiar with. Only hardware tinkerers (which admittedly is the majority of the Armbian community) are interested in specific SBC's.
 
Also in general:
Most end users bring nothing of value to the table except testing, expecting end users to bring other value is unrealistic
Most board manufacturers bring very little value to the table, free boards are not a good reason to support a board
Users bring devs, devs dont bring users. This is critically important and I think overlooked by this community.
 
The bottom line: SBC manufacturers and boards come and go, the operating stack is way more important than the hardware. Armbian can be a much more important part of the ecosystem than any specific SBC stamper but in order to do that it has to define what it is. That may mean 2 different variants (its what we do in house), one to cater to the generic desktop / server type user and a variant specifically tailored to IoT single use devices.
 
This thread is not really the place but if @Igor, @tkaiser, @TonyMac32 wants to create a specific channel or thread to discuss this I would be happy to contribute in terms of ideas, infrastructure and code. Im also happy to contribute more servers for hosting and building and even funding if the development direction is clarified.

Big digression but:
 
In regards to @tkaiser negative and pessimistic suggestions to keep dropping board support for problem boards,  I think he is absolutely correct.
 
While Im not a big Armbian user (we have our own linux based OS stack that we created from scratch and an ubuntu 16.04 derivative we tailored), I do follow its progress quite closely and its clear that there isnt enough engineering resource to support the list of boards that you try to support. Thats not a criticism, its just the reality of any open project. Once you have a board up and running, even at just 25% of completion, every TV Box shitter and their dog wants it all working, right now, on mainline, with 8K support, running from a nokia 3210 charger, etc, etc.
 
There seems to be enough engineering resource to support about 10 major boards with minor variations. To my mind it would make much more sense and make Armbian a much more valuable project to support less boards to a higher level and to have fully standardised functionality across all "officially" supported boards. Officially supported boards get support for 3/4/5 years or whatever. You dont even try to support a board unless every critical dev on the project has at least one of them.
 
By standardised Armbian functionality, I mean things like:
standard Armbian GPIO (+i2c, spi, 1wire, etc) library (@Larry Bank already made a good start here) standard RTC interface, utils and device (we only support 3 RTC drivers) standard NAND interface, layout, device standard GSM interface, utils and device (we only support 5 drivers) standard and predictable network interface naming, handling and utils standard hardware / psu stress test standard sound and video in / out / process utils (standard interface is pretty difficult here I accept) standard remote access interface for cloud control standard config utility standard base OS. pick debian 9 or ubuntu 18.04 for future dev, stop trying to support both (my personal preference is debian but there are good commercial reasons to stick with ubuntu LTS) limited SD card support. dont support any re-badgers (Kingston, entry level sandisk, toshiba, etc ). we only use sandisk extreme plus and sandisk high endurance and have a failure rate of approx 2 in 1000  
That doesn't mean you cant have another 15 "community" supported boards, but with those there is no promise of full functionality and no official support offered. Those boards need to have community champions (individuals that want to help support specific boards, probably because they have them at home) and automated builds of community supported boards, its just means they dont get factored into long term development planning, support and testing.
 
What would you rather see from Armbian?
1) 30+ boards with levels of completion from 20%-95% and different functionality on each (think GPIO, NAND, RTC, GSM, etc)
2) 10 boards with 90%+ level completion and with standardised Armbian specific functionality across all of them? With 20 more community supported unofficial boards. 
 
Once you have structure 2 in place then you also have the correct structure to start making money from commercial support offerings. Think Armbian Gold / Pro whatever where you sell commercial support delivered via a cloud interface where the customers can manage all their devices (1-1M) from a web browser. This is what we do.
 
Controversial suggestion but you should support at least 1 variant of the RasPi. I know the hardware is shit and the RasPi foundation is full of shit but its also the most common SBC on the market. For that reason we do support the RasPi 3 only and while there are concessions to be made we also have roughly 6500 of them on support with our own OS stack at £5/€5 per month per device. We normally manage to get clients off them and onto something better at the next platform refresh.

Big digression but:
 
In regards to @tkaiser negative and pessimistic suggestions to keep dropping board support for problem boards,  I think he is absolutely correct.
 
While Im not a big Armbian user (we have our own linux based OS stack that we created from scratch and an ubuntu 16.04 derivative we tailored), I do follow its progress quite closely and its clear that there isnt enough engineering resource to support the list of boards that you try to support. Thats not a criticism, its just the reality of any open project. Once you have a board up and running, even at just 25% of completion, every TV Box shitter and their dog wants it all working, right now, on mainline, with 8K support, running from a nokia 3210 charger, etc, etc.
 
There seems to be enough engineering resource to support about 10 major boards with minor variations. To my mind it would make much more sense and make Armbian a much more valuable project to support less boards to a higher level and to have fully standardised functionality across all "officially" supported boards. Officially supported boards get support for 3/4/5 years or whatever. You dont even try to support a board unless every critical dev on the project has at least one of them.
 
By standardised Armbian functionality, I mean things like:
standard Armbian GPIO (+i2c, spi, 1wire, etc) library (@Larry Bank already made a good start here) standard RTC interface, utils and device (we only support 3 RTC drivers) standard NAND interface, layout, device standard GSM interface, utils and device (we only support 5 drivers) standard and predictable network interface naming, handling and utils standard hardware / psu stress test standard sound and video in / out / process utils (standard interface is pretty difficult here I accept) standard remote access interface for cloud control standard config utility standard base OS. pick debian 9 or ubuntu 18.04 for future dev, stop trying to support both (my personal preference is debian but there are good commercial reasons to stick with ubuntu LTS) limited SD card support. dont support any re-badgers (Kingston, entry level sandisk, toshiba, etc ). we only use sandisk extreme plus and sandisk high endurance and have a failure rate of approx 2 in 1000  
That doesn't mean you cant have another 15 "community" supported boards, but with those there is no promise of full functionality and no official support offered. Those boards need to have community champions (individuals that want to help support specific boards, probably because they have them at home) and automated builds of community supported boards, its just means they dont get factored into long term development planning, support and testing.
 
What would you rather see from Armbian?
1) 30+ boards with levels of completion from 20%-95% and different functionality on each (think GPIO, NAND, RTC, GSM, etc)
2) 10 boards with 90%+ level completion and with standardised Armbian specific functionality across all of them? With 20 more community supported unofficial boards. 
 
Once you have structure 2 in place then you also have the correct structure to start making money from commercial support offerings. Think Armbian Gold / Pro whatever where you sell commercial support delivered via a cloud interface where the customers can manage all their devices (1-1M) from a web browser. This is what we do.
 
Controversial suggestion but you should support at least 1 variant of the RasPi. I know the hardware is shit and the RasPi foundation is full of shit but its also the most common SBC on the market. For that reason we do support the RasPi 3 only and while there are concessions to be made we also have roughly 6500 of them on support with our own OS stack at £5/€5 per month per device. We normally manage to get clients off them and onto something better at the next platform refresh.

You sure about this?
 
One of our clients ordered 85K rk3288 boards to be designed and manufactured to rk-miniarm spec in August and they have contractual availability to buy upto 500K per year through till July 2021. Their OEM would have to hold a lot of rk3288 SoC stock to meet those obligations for a discontinued chip over 5 years.

You sure about this?
 
One of our clients ordered 85K rk3288 boards to be designed and manufactured to rk-miniarm spec in August and they have contractual availability to buy upto 500K per year through till July 2021. Their OEM would have to hold a lot of rk3288 SoC stock to meet those obligations for a discontinued chip over 5 years.

Its now set up on the UK server  for both dl and apt. Test it, if you visit from the US it redirects you to main. Clone the setup on to any webserver with the following patch against /etc/nginx. Add more regions in the map if needed and make sure the server name directive for each vhost contains all the regional host names. You will also need the max mind geoip database from here: http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz. Save it to /usr/share/GeoIP. It literally takes less than 2 mins per server then its done.
 
Dont fanny about with bad solutions when the proper solution is so easy.
 
diff -r bkp/etc/nginx/nginx.conf /etc/nginx/nginx.conf 60a61,64 > #Updated maxmind geoip data > geoip_country /usr/share/GeoIP/GeoIP.dat; > geoip_city /usr/share/GeoIP/GeoLiteCity.dat; > diff -r bkp/etc/nginx/sites-available/apt.uk.armbian.com /etc/nginx/sites-available/apt.uk.armbian.com 0a1,6 > map $geoip_city_continent_code $closest_server { > default apt.armbian.com; > EU apt.uk.armbian.com; > US apt.armbian.com; > } > 5c11 < server_name apt.uk.armbian.com; --- > server_name apt.uk.armbian.com apt.armbian.com; 7a14,18 > > #GeoIP redirect > #if ($closest_server != $host) { > # rewrite ^ $scheme://$closest_server$request_uri break; > #} diff -r bkp/etc/nginx/sites-available/dl.uk.armbian.com /etc/nginx/sites-available/dl.uk.armbian.com 26a27,32 > map $geoip_city_continent_code $closest_server { > default dl.armbian.com; > EU dl.uk.armbian.com; > US dl.armbian.com; > } > 31c37 < server_name dl.uk.armbian.com; --- > server_name dl.uk.armbian.com dl.armbian.com; 33a40,44 > > #GeoIP redirect > if ($closest_server != $host) { > rewrite ^ $scheme://$closest_server$request_uri break; > } If you need vpn's for testing I can give you and ipsec, l2tp or pptp vpn connection that terminates in the US, UK, Germany, Italy, France, Australia, Russia, Taiwan, Japan or Holland.

Thats what I would suggest, pretty much in the same way as that article. Its very simple and straight forward to set up and is very easy to adapt if you need to add / change servers.
 
Its more complicated to put in place simple redirects with nginx that to do proper geoip based distribution. To do simple random redirects you could use a combination of rewrite and random rules from the rewrite and misc nginx addons with region maps to achieve the simple solution, but its a lot more effort than doing it properly.

Its an arm7 / arm8 thing, anything after the Cortex-a15 ish supports HYP mode in hardware.
 
I have managed to get it working today but that was under a buildroot based system with legacy kernel not armbian, but it is possible. Something in Armbian's u-boot is ignoring or blocking the nonsec PL2/HYP boot mode. With a "clean" u-boot from rockchips github repo it works as expected after setting CONFIG_ARMV7_VIRT. I will compare the difference between the 2 when I get a chance.

UK Server deployed. Details PM'd

UK Server deployed. Details PM'd