Igor

Yes. We provide tools that anyone can build Armbian on their own. Usually with their own modifications.

Cool. For future instances, this was pushed to armbian-config and one can select the board he has to get optimized configuration ... which solves such problems.

There are a few options if something you need is missing from the kernel: send PR with changes to this file and wait for next nightly kernel rebuild. Run apt update & upgrade build your own kernel, install it and freeze kernel upgrades (armbian-config) to prevent overwriting your custom built kernel

Yes. Cubieboard 1 I am doing various testings on OS level to find bugs related to last changes and I wanted to see how current latest Armbian assembly works on an older, officially unsupported, board, which we usually don't use any more. Especially not for a desktop replacement. It's more like a joke but let's look how a single core single board computer from 2012 actually performs: Armbianmonitor: http://ix.io/18QM Booting full featured XFCE desktop: (real-time) Writing and printing a document (slow typing due to crippled keyboard) Chromium works .. but its very laggy, barely usable. Wireless network works superbly, roughly 50% faster than wired: Boot media performance (8G C1 eMMC with SD card adaptor): Installed packages: Download: https://dl.armbian.com/cubieboard/nightly/

You wanted to start with almost the most difficult problem which is hard even for a group of most experienced programmers In case you want to contribute to the project, there are plenty things to do for people who are not technically skilled. I already expose a few and yet another very specific one: Upgrade whatever build you have to the latest beta (rather few different version since the output is kernel and board dependent) and update the manual for armbian config. This way you help programmers which have to write this down: (and they usually hate doing it, while some people love this job) https://github.com/armbian/documentation/blob/master/docs/User-Guide_Armbian-Config.md (in case you are perhaps skilled video producer, do a video) How to edit: https://docs.armbian.com/Process_Contribute/

Thank you. Remember, donations are unconditional, like love. Well, we still need to find another 99.9% to get your wish funded or we do it virtually for free Since most of the work is done for free it is done when it is done. First build is months away from end users level and there is nothing I can do. Build targets are hidden to limit down wasteful support questions. If you are not a developer, there is a test build and that's about it. Remember, we don't provide any support for development versions since this is stupid, wasteful and expensive. Supporting development - teaching and explaining one to one (since they are unable to use search) to newbies - you need to double the expenses of the development. You are wasting time.

At this moment we don't support 32bit target for 64bit CPU's and we don't support this board either. Perhaps in a few weeks or months. If you want to get things done quicker, take over some work: https://forum.armbian.com/topic/6751-v543-desktop-on-top-of-cli-xu4-next-upgrade/ https://www.armbian.com/get-involved/ https://docs.armbian.com/Process_Contribute/ Even this was near to impossible. You need to stay with Allwinner stock 3.10.y kernel, which we will not touch, for next couple of weeks/months if you want to have X. According to my experiences, this kernel will remain labeled as development/testing at least by the end of this year. https://docs.armbian.com/Process_Contribute/ It is "simple": start porting video drivers (they are actually already developed but need to get matured) and push your solution to the build script.

Solution: adding this to /boot/boot.ini and by creating or adding to /boot/armbianEnv.txt this: board_name=hc1 It boots strait up.

Migration date is set to Monday, May 7th. - devices download pages were checked many times but still, there might be some wrong data. Since now anyone can quickly fix, this is not a problem. - FAQ is not finished at this moment and even it won't be ready for the release that this is not a big issue. - I am still working on a content of "contribute", "about", "kernel, ... pages. Worst case, if I won't' be able to make something, content will be copy/pasted from the old page.

sunxi-dev changes https://github.com/armbian/build/commit/7275cd23167e8d9b6997b35de9eb51a3ce3c5c64 Patches are now somehow better organized (still a lot of to check and adjust) Quick tests with 4.17.0 RC2: Network DVFS USB HDMI Cubietruck yes yes yes yes Opi Prime yes no yes u-boot only Pine H64 yes no yes(2.0) no Opi One no no yes u-boot only LimeA64 no no no u-boot only

I am sorry to hear you have had those problems. They are "OMG" ones. Unfortunately, we as Armbian, don't support 3rd party hardware in the board support section. That's why this topic was moved from that section and I hope moving this to the right place will not add to your overall frustration

Most likely USB0 is disabled by default or we have some other regression. If you don't need console via microUSB it's safe to ignore this.

True, I notice that USB3 port was not working. I was happy that it booted in the first place. I already merged into our main sunxi DEV branch (attached back to upstream master) and will try to remake this with a working USB3.

If you join as a maintainer, we could afford to provide yet another optimized desktop, but until then ... one optimised desktop is already hard to maintain. For a generic MATE install proceed this way: https://www.google.com/?q=MATE+desktop+debian+install Most if not all recipes should work, but there will be no HW acceleration or other "lousy" optimizations. I agree it's not the most beautiful and advanced, but a choice within necessary compromise due to limited resources. Beauty is subjective so it's pretty pointless to discuss which is nicer. IMO both are lousy.

No. This board lack hw part which is present on A10-A20-A64 ... a proper PMU (AXP chip) which can power on/off ... here this is done via special close sourced part of the H3 chip which can do some hybrid deep sleep/wakeup. Wrote on mobile

... which of course doesn't work.

Consider that it is still in an active development and we don't maintain it. The driver is better in advanced features and it also supports 8814 and 8811 chips which are n/a in the default driver ... which supports the one sold by Hardkernel. Yesterday I made another update (few bugs + code cleanup) to the patch and I can push everything but updating is another story. We already use upstream kernel sources + add-odroid-0ae2774.patch.patch for Odroid XU4. I already tried to port XU4 support to 4.16.y but get stuck. Too many changes in handling big/little for what I could understand.

This is known bug/regression on all mainlined H3/H5 and we are waiting for next/better implementation. Just check if there are any differences in the reference design. If we choose to keep them on a support list, then you need to define board config files (.wip) and add them to (next) web page. Not much hacking at this point.

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

https://dl.armbian.com/nanopik2/archive/ Look whatever under 5.42 ... it should work but this board is "work in progress". Random freezing is usually a sign of a bad power supply. Check that first. How do you power the board?

1. See /etc/update-motd.d/ or use armbian-config to enable/disable those items 2. https://www.google.com/search?q=debian+start+on+boot

Always start with the last image but if you need another kernel ... we have older kernels and u-boot packages in packages repository: apt.armbian.com ... use apt-get tool to install the desired version.

Nothing special. I encourage people to create a PR but since this is less work to just add then explaining to people what to do. I would propose to add this to new web page's FAQ, somewhere among medium important questions. Cleaning as https://github.com/rfrht made should be done on all kernels and if there is some request we usually translate it to other kernels ... but sometimes enabling on one might break compilation, while it will work on some other kernel.

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