Igor

There was a lot of testings but they sadly didn't discover this problem. You can improve this by joining and help testing + improve protocols + developing the project in general https://www.armbian.com/get-involved or by sponsoring https://www.armbian.com/donate and we will hire professionals (few hundred hours/release) to conduct profound testings. Nothing comes out of thin air.

Yep. Instead of colouring or transferring to xls/md, @chwe at least move tasks out to a clean b/w list of items which is more or less agreed upon and below a list where someone expressed concerns. Nothing else. KISS. What about keeping this here https://docs.armbian.com/Release_Changelog/ when the time comes and some text remained on the specific download pages? It can be done generally inside some reddish box -> if BOARD=EOS; then echo "We don't support this board any more which means blablabla and if YOU want to take care of the board DO THIS. In this case, board can be moved to CSC, which means it will remain in the system but will not be officially supported" ? When this is done, forum announcement can follow. Good. I will check them and make a TL;DR; version at the beginning of the document and you check my babbling? -> a general join/contribute documentation: https://www.armbian.com/get-involved/ It's WIP and a current templates should be somehow incorporated. Then we again need a TL; DR; version at the beginning of the document following by a proper placement & linking.

System is running, desktop too but nothing is on the screen ... but after a while [ 453.624128] random: crng init done [ 453.624143] random: 7 urandom warning(s) missed due to ratelimiting [ 454.842413] fuse init (API version 7.27) screen is back. while Debian based desktop works just fine. It looks like upstream troubles.

... and I have build it and pushed to Armbian stable repository (Stretch, Xenial and Bionic; armhf+arm64). First boot scripts also creates CPUfreq config based on CPU count. More can be added if there is an interest ... Package can be installed via apt update and upgrade while auto config feature will work only on self made images.

This sounds better to me + link to some better explanation if one can be found quickly.

It works but a chip quality and speed is bad. Put GL830 into a search box above. It is noted hardware (quality) issue which has nothing to do with out work. All images and kernels share this problem. Perhaps we would need to use different wording to make this more clear.

This is the first time someone stated that port on this board doesn't work. It worked all the time AFAIK. Boot any 4.14.y image and go to armbian-config -> system -> hardware configuration and enable all USB ports. Perhaps that is the problem.

First two download options (Armbian Bionic and Armbian Stretch) comes with a kernel 4.14.y and they should support SATA. However chip for USB2SATA bridge is crap and is to avoid.

We can/could merge Nanopi M4/T4/Neo4 under one image, which share boot loader and kernel family rk3399. We wanted to add Rock64 and Rock64PRO to one common rockchip64 family. To maintain one kernel source ... but its sadly way too much work and this is postponed to the future. Since we have two legacy kernels for RK3399 and since boot loaders are different, we can't provide one image.

If there was some corruption or unclean first run, do this: https://www.cyberciti.biz/faq/howto-regenerate-openssh-host-keys/

There is no diff between OdroidC2 NEXT and meson64 next since the last update. Known problems: USB hot plugging and network initialisation on some C2 boards. I don't know if this latter happens on a stock 3.x kernel too. XU4 default 3.10.y could be also added to the EOS list. Maturity is unknown to me as well. Back then I did a basic adjustment and made few tests. Known problems and shortcomings: no HDMI, no DVFS, halt on reboot, ... modern u-boot support? Not sure if this will change anytime soon. We can drop 3.x and wait with mainline for a few months else drop C1 completely? Allwinner 3.4 and 3.10/Pinebook should stay in the system. There are many users and projects such as H3Droid and Retroorangepi are dependent from it. Even there is no more development and support. Even code quality is so so ... Since we started to talk about changing u-boot update from auto to manual, which should have bigger impact on support pressure, we can lower threshold for EOS on only most obvious ones.

https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md As you can see it is quite a diff.

Correct, latest version is broken. Perhaps this is fixed now ... it shall be tested.

Last u-boot builds should have support for Macronix OOTB, right?

Where did you get that u-boot? It doesn't look ours. You need to start here: https://www.armbian.com/espressobin/