Igor

First Pine H64/H6 mainline testing images based on @Icenowy patchset https://dl.armbian.com/pineh64/ Boot log: http://ix.io/18DU

First Pine H64/H6 mainline testing images based on @Icenowy patchset https://dl.armbian.com/pineh64/ Boot log: http://ix.io/18DU

Summary of diff between development and master + related from armbian-config. I left out some minor changes:
 
- Network manager is now by default except Espressobin which needs systemd network. Ifupdown can still be overridden if one wanted.
- upstream patches for many kernels ...
- Ubuntu Bionic target (under expert mode, fully functional testing version)
- RFC for firstrun config to set IP or connect to Wireless. Using Network manager method now.
- switched NEXT to 4.14.y on Odroid XU4
- kernel packaging support for 4.17.y
- RK3399 kernel upstream updates (can't produce bootable image yet)
- docker support for RK3328 DEV kernel
- sign "sha256sum.sha" instead of "armbian.txt"
- add missing dependency libpam-google-authenticator to armbian-config
- reworked SSHD management, kernels and nightly/stable switching with armbian-config
- added upgrade to desktop from armbian-config (only generic desktop)
- added CODA module on imx6 and upstream patches. Requirement for video acceleration but ... haven't got it working under mpv
- Olinuxino. Enabled USB within atf, sane RAM speed
- icon pack moved to our repository. (Note to myself: remove .deb from build script)
- created desktop package per release, architecture independent, could be installed on top of any Debian / Ubuntu base
- removed old way of making desktop
- moving Odroid away from their mainline sources with a patch
- added bionic to the beta repository, soon to main
- added Z28PRO to the RK3328 kernel source (tested, working everything but wifi)
- meson64 default becomes 4.14.y, next 4.16.y, DEV master
- sunxi-dev pinned to 4.16.y and u.boot to v2018.03, most of the patches were adjusted
- S56818 is breaking. pinned to last known working kernel 4.14.15
- fixed eMMC install on Rock64
- adding eMMC support for Neo and Neo2 to make images usable for Core / Core2
- added Odroid C1 mainline config (DEV, it should boot but it doesn't)
- removing GKSU and rework dependencies

Those are areas where we should be focusing. Some are important now, some later. I have done many tests but it's impossible to predict and catch everything. Latest changes will show up in tomorrow's beta repository update and those images which are enabled for the nightly remake. No larger moves until testing and the big merge from my side.
 
I haven't checked:
- how changes will affect firstrun and armhwinfo
- networking in general. I did only a few tests and notice at least one power management set to "on" ... I think on OPI Prime.
- haven't made OMV images

The only real difference is that nightly images are (usually) not tested. They are just built from upstream, normally every day ... in reality building can be on hold for a week or more until things, which break the compilation, gets fixed or are removed. And most of the images don't get daily images rebuild, but only packages. This means any existing image, stable or nightly, can be upgraded to the latest nightly. (armbian-config -> switch to nightly)
 
171217 = 17. December, 2017

Good news about the new webpage.
 
I also have some good news about RK3288 media implementation: I finally got rkmpp accelerated mpv to work. It works really well, better than Gstreamer, although only in fullscreen. It's a real "Armbian premiere", no other distro implements it so far, neither ASUS' nor Rockhip's own. In the next days, I'll try to put that with some other new goodies into a script, and keep it available there until it is possible to integrate it in the main build script.

Exactly. It's already problematic - information is scattered around a web page, documentation, Github and forum which is mainly community, self-organized. IMO adding yet another chunk of infrastructure (Wiki) can only make things worse. If we wanted to improve the current situation, we would need to assign a person(s), dedicated editor for keeping documentation well organized.  We can dupe docs as they are now and move them to the web page or to another form or engine ... but its a huge task/challenge.

We are releasing new webpage, which was quite a challenge, in a few weeks and with it, new features and possibilities are being unleashed. Its also a paradigm change - the current website was a single user renderer directly from build script config. With many dirty scripts and plugins. A future website should be a group, community managed with a simple but powerful backend. Most of the work was done to improve that management, previously controlled with configs. I will give rights to anyone who wants to participate as a board(s) maintainer. In a sense to set facts, collect relevant information, decide which download options should be exposed and adjust things, add warnings, etc. This task is not hard work but helps core crew to find some breath. It should be fun and it comes with some responsibility. More when it's out ...
 
Getting access there or rights for editing the documentation is liberal. Like Wiki. Anyone wants to edit textual data, ping me, you get instant commit access.
 
Back to the topic. I think we should keep those how-to's updated but implement features directly into Armbian. When things are matured and when core developers team finds the time. And then, they become irrelevant for the implementation part but still keep the educational role. For that purpose, it should remain in the right place. Subforum "Research and tutorials" is IMO right spot, it's indexed by the main search engine and it will be linked directly from our new web page. They are important.

This feature cost 30.000 EUR and will be implemented free of charge when it is delivered  You can find detail info on that page.

Thanks,
Tried everything, finnally I got a TP-LINK TL-WN725N which worked plug and play.
 
The DWA-131 got a rtl8192eu chip, tried almost all the drivers available on github, and also the ones for raspberry with no look.
I remember a lsusb throws 2001:3319 for the dlink
 
Will do the armbianmonitor-u when I get a chance.
 
Tks!

Noted.
 

True, there is no need to hurry but its more convenient to repair things on the way. As a side task. My intention was to bring it to the level, where one can build and test. We are there now. We can build, we have a network, a desktop is up, ... There are small known problems and probably many hidden. Some will be fixed upstream and some can be fixed by people interested to run Bionic ASAP. I will still fix things if I bump into them, but will not hunt them.

Yes. Changes to packaging method upstream. It is getting fixed. Check my last commits to developmebt branch for quick fix.

Wrote on mobile

https://github.com/armbian/upload/commit/1a63938c6eeb6226f7ffea46f77ba3629bd45c17
Kernel for Tinker was updated to 4.14.34
 
apt update & upgrade 

Hi there Board,
 
I have bought my Tinkerboard after some good research with my fellow techies at Red Hat and reading thoroughly that 19+pages Tinkerboard Thread.
 
After crafting a super lean/mean kernel (kconfig at https://gist.github.com/rfrht/5f0fa113f12fbacf832e57ff4967785a ), I got a stable and lightweight kernel configuration.
 
Things got a lot funnier when doing some compatibility tests with specific Asterisk versions, I was able to install and run cleanly a Raspi .DEB pkg. And that got me thinking.
 
I have now JUST replaced the Raspberry Pi with the Tinkerboard. And guess what: It was a _inplace_ upgrade! Using the same userland, same hard drive, same everything.
 
I just had to set the MMC card with Tinkerboard /boot stuffs, specified the USB root device using rootdev=<proper clause> (in my case, rootdev=LABEL=TinkerRoot), edited /etc/fstab accordingly and... It RAN!
 
Smoothly. Perfectly. My 120 Mbps from carrier being diligently delivered. My userspace apps running nicely.
 
Well, I would like to send my deep respect and special thanks to @TonyMac32 for exploring Tinkerboard and putting it to work nicely, and  @Igor for hosting the project.
 
We grow when we share! ;-)

Hmm. We had some urgent updates from development branch which is already at 5.42 Splitting master and development branch, in general, brought some confusion and this is a direct consequence. Not that critical but it shell be fixed soon.

Hi guys,
 
after some interesting weeks, I could successfully install eight Odroid C2 together with dedicated FPGA hardware now, and prepare them now for deep sea operation.
 
Just wanted to express a big "THANK YOU" to all here in the forum which were involved in helping me to get the beast working.
 
The boards operate now with patches inside Uboot (serial console 9600 8N1) and several small patches inside the kernel (device tree, PWM, ADCs, 1Wire), and a patch inside the rt8152 driver to switch off the LEDs in the USB ethernet dongle (PMTs don't like such bright light usually). 128GB eMMCs are working fine, thanks to the speed patch
 
The Armbian image does a great job, it's a pleasure to work with. At the moment I run it headless over some DSL connection, with a SSH tunnel and TigerVNC to remotely operate it and test under hard conditions
 
Again, thanks to all persons involved.
 
BTW, I'm open for ideas on how to save power on C2 during operation, as well as how to read CPU temperature remotely - we have 22W max power dissipation inside the Titanium shell... every Watt counts.
 
BTW2, how can I take the kernel image out of updates? I want to use apt-get for normal packages, but hands off the kernel
 
So far, Michael

Go for the legacy kernel. There is no MALI in a modern kernel .. yet.

Hi Igor
 
very nice: The new image worked perfectly and I am really impressed. When using the images for Raspbian or Debian, the screen ouput was very blurry using the converter. With armbian, it is razor sharp, right from the beginning. Wow.

 
@Igor zador is correct. Patches can be dropped only when 4.17 is released, so in about 2 months. However, there are many DRM changes in 4.16 so it may be better to backport patches from 4.17, but there are many, including in clocks subsystem. Maybe I can find time to look into that later this week.

Yes. I don't use a heat sink.

https://github.com/armbian/config/commit/2992430d263cad9ca18fb773127fb90d628e5ab8#diff-f31297ad208d45c13b6d3d24c66823cdR35

Ubuntu Bionic can be build ... but you need to kill man-db process which hangs during debootsrap process. I made a test image for Odroid XU4 but the network was not configured and probably other things need to be fixed. Addin Bionic remains a low priority and hidden under the expert switch.
 
armbian-config, network management needs further testing and fixing.
 
power management on wireless devices was enabled on some during my last test. IIRC brcmfmac / mainline / h3 

It looks like they fixed the bug.
As I was able to build the image and all work fine 
except It only work on ubuntu 18.04
so run NO_HOST_RELEASE_CHECK=yes ./compile.sh
 
It freeze on ubuntu 16.04 in regenerating man pages
 
I am looking that all work is done in development branch and I want to make pull request
 
some changes with ubuntu 18.04
ntpdate is not instaled by default and they changed ntp daemon so ntpdate return error
missing package rcconf  but armbian-conf depend on that
 
so temporary workaround just add 
PACKAGE_LIST_ADDITIONAL="${PACKAGE_LIST_ADDITIONAL/armbian-firmware/}"
PACKAGE_LIST="${PACKAGE_LIST/rcconf/}"
 

Hooray! I found the problem, I've had following line in /boot/armbianEnv.txt from some previous experiments:
 
machid=1029 All cores are detected correctly after removing it. @Igor thank you for support.

@igor same here, was able to boot, run apt updates, installed to emmc, wifi also works. thank you for help.

I am doing some more research on this topic ... I'll update images when done.

Orange Pi Mini 2 was never directly supported and yes, you probably can just use the image from Orange Pi 2. Disappeared boards appear here: https://www.armbian.com/deprecated/