Igor

@data tnx I made an image and WiFi seems to work just fine (with disabled power management of course): wlan0 IEEE 802.11 ESSID:"XXX" Mode:Managed Frequency:5.18 GHz Access Point: 00:XX:XX:XX:XX:XX Bit Rate=135 Mb/s Tx-Power=31 dBm Retry short limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality=69/70 Signal level=-41 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0

I think its safe to have it generally. This is overlay https://github.com/armbian/build/tree/master/packages/bsp/common https://docs.armbian.com/Process_Contribute/

Change this: https://github.com/armbian/build/blob/master/config/kernel/linux-sun8i-default.config#L1221

We have to get to some action plan on a broader scale. Not going too much into the details. That should be done elsewhere. 1. Shall we switch to minor version? Any concerns? 2. Dropping Allwinner default is still questionable. There are still many users of it for various reasons. Not just video acceleration. I would rather proceed with switching NEXT and DEV as it was already made, but too soon. AW support in 4.14.y is far from the best and is not getting any improvements. Beside upstream changes unrelated to Allwinner support. 3. Collecting wishes on a special web page or forum topic. This is a very important issue. Whenever we talk about that we don't have people. Yes, we don't have. I can only work less in the future since I have family duties and plenty of other things to do. If there will be just a few random people fixing/hacking things here and there, you can forget to plan any topic related to development. We don't have developers and until this point is not improved, we can stop talking about what to do. Planning and organizing included. Let's focus on how to attract people, how some random person with know-how and wish to help can start working on. He needs guides or personal assistance. Remember that I more often don't have time even to reply to their emails and opportunities go to /dev/null. It already happened a few times. 4. Improving testing protocols should be a guide backed with additional automation. A manual how to and how not to start with testings to get things done. Summary of what we learn so far. We need to find a way to eliminate border cases as such? This means pushing thing to another level. I think we simply lack resources. 5. What to add to »end of support«? My proposition: Olimex Lime2 NAND, Bananapi PRO, Olimex Micro, Orangepi Pi2, Orangepi+, Nanopi M1, MiQi, NanopiM1+ Any concerns? Another idea to add here. Instead of moving to EOS, we could put a counter. "3 months until going to EOS. Seeking for maintainer". In case someone steps up, a board is getting CSC status. We need a person to communicate this and that will not be me. 6. Secure project longterm survival is not a technical question but ... what if major project contributors leave the project, completely lost interest or is run by a bus. A project is developed openly, but infrastructure is not. It is scattered all around. Valid at least by the end of this year: Pine64 3.10.y is not ready to be dropped. RK3288 ??? 3328 and 3399 is not ready to be dropped, cubox 3.14.y and Udoo can be dropped, Meson 3.10.y default ??? SP6818-default 4.4.y was never finished and nobody works on it and can be dropped, This raises a question to provide 32bit userland as a matter of choice. This is especially needed for 64bit boards and not much memory. It would be nice to have but I really don't know how much work will this bring. Since the desktop upgrade is now simple and functional, providing desktop images is IMO not critical. But we lack the promotion (=repeating things over and over) that this is possible. That a desktop image is exactly the same as CLI + armbian-config way of setting the desktop. With one exception. Legacy desktop builds which have video acceleration support. This part was not implemented and not sure if it will be in the state. They have to meet one crucial rule: KISS Not the best way to welcome people You don't need to be a technical person to answer to such post. This should be one of the top 5 moderator duties. With exception of @tido, all can make use of ready-made templates for a topic answer: "Please provide this because... " People test and play with them, sometimes we don't. Some people are interested in those boards, other doesn't even try to look. Because we have different interest, no time or simply because support is not matured enough for any real-world usage. But they will eventually become usable. H6 has potential in the (biggest) cheap section. Another unwritten rule is that test/beta/nightly downloads starts when basic board functions work. This exists. Download page should only tell them what to expect and inform them with a support status. t is also a possible window to welcome new developers if done properly. Don't know. We can find that out by pinging them.

Try this This talks to AR100

And ZRAM fine-tuning is coming with future updates. No need to open a new topic. Here:

It was not properly fixed. Now is.

It can be time-consuming, yes. Now you know how my days look like Negative. linux-rockchip64-default.config

I am not sure such how-to or tool exists. Fex is nonstandard Allwinner way of defining hw while DT is version dependent. Wrote on mobile

Bionic and Stretch share kernel. Try to compare working (rock64) with nonworking configuration ... perhaps some other config option is needed or there is a bug in Odroid USB stack. You can also switch between different kernels for XU4 if that helps ... Wrote on mobile

An update is out on a stable branch.

There are still (many)some (short and) long-term questions which are scattered on the forum and in our heads which we would need to discuss. - release naming, 2018.10 or 18.04 + some RFC as shown on the pic, - collecting wishes on a special web page or forum topic. When someone approaches with "I want to help" that it is appointed to 1. Check issues on GH, 2. Fixing sound ... 3. Creating this ... - improving testing protocols, automating what is possible. I'm low on ideas what more is possible to do. - what to add to »end of support«? - secure project longterm survival, leverage maintenance costs to users or drastically limit down free support, - enforce browser of choice for desktop images, Firefox and/or some lighter alternatives? - fix Bluetooth on all Broadcom AP62xx devices. Its the same on most boards, but we have it working only on a Cubietruck IIRC - sum most frequent problems under »The Ten Commandments« / FAQ and promote it as much as possible - does forum need structure update? - add/remove moderators? Disable rights if not moderating content in past 6months? - enforce forum rules? Some very simple ones. - users are still seeking for help without providing logs. What to do about? Download UX: - make a bigger diff between nightly and stable, desktop and CLI (Gorazd) - add a warning when nightly is downloaded, (Gorazd) - tested devices lead to their test page where exists instead of Amazon affiliate, (Gorazd) - tested hardware have information to which kernel is attached to but not displayed, (Gorazd) - check other download option still no visible enough, (Gorazd) - add a support box with 1. Check common issues 2. Search for solution 3. Ask (with a link to the correct forum) (Gorazd) - add a button »alternative builds« with a link to dl.armbian.com/DEVICE (Gorazd) To keep things in place, I would like to ask @Tido and @chwe to help keep this 2do list up2date according to with our decisions.

Here we are getting off topic. Ubuntu Bionic is different enough to cause you troubles. In case you don't want to deal with the diff ... Debian TVhead installation has also been solved. I will push the update when finishing some other fixes.

Consider that images are tested and many people already download and use those images. How much time did you wait? (first boot needs several minutes) If this is not the case, some hardware trouble - power supply, bad or badly written SD card can be involved. Bionic and Stretch build have the same u-boot and same kernel. If one is broken, then the other must be broken too.

Temp diff can be explained with using proper regulator bits ... but since there seem to be many different board revisions, it's a mess. This would be the first case, that some other kernel runs cooler than Armbian :) And it can also be false readings. Did you measure temps? DVFS is n/a in upstream 4.14.y kernel. FA took https://github.com/megous/linux/tree/orange-pi-4.14 as a base ... where DVFS is already implemented. They only added their board's settings and some board recognition to that fork. If boards heat powered down, there is not AR100 involved.

Stock kernel for Tinkerboard was messed up upstream, by Rockchip developers. We are still working on to fix it. Older kernel versions are avaliable here: http://apt.armbian.com/pool/main/l/linux-4.4.120-rockchip/

If there is no Ubuntu version like here, you need/can build one: https://github.com/armbian ... I made you one Ubuntu Bionic build, but it is untested: https://dl.armbian.com/odroidc2/Ubuntu_bionic_next.7z I will try to fix this install in armbian-config asap. Edit: fixed

It is but on Ubuntu only.

Because someone needs to implement and test. We seriously lack "someones".

I actually build and boot Opi Lite 2, but before adding this https://github.com/armbian/build/commit/9fcb58b8f17b128dc305d76264830140d5a80c62

Reverted. Let's see.

It should work. https://github.com/armbian/build/commit/9fcb58b8f17b128dc305d76264830140d5a80c62 Someone needs to test this.

Already reported: https://github.com/armbian/build/issues/1094

Try with reserveing more memory. Add extraargs=cma=256M to /boot/armbianEnv.txt ... also try higher values.

Because that branch is temporarily development branch with a purpose to develop a few things. We only have two choices here - switch to current 4.18.y, say goodbye to HDMI for a while and fix other things, wifi perhaps ... or wait until HDMI is not mainlined. Other options are too expensive. I have to remind you that this board is under development and regressions are possible. Some are intended, some not.