Igor

Probably best is to reach out to community for help in such cases. Pinned topic with a very brief description why and what kind of help is needed. If there is nobody in a week ... we tried. Dropping a board is not a critical task. It's just a name and status change while dropping sources and patches is a bit more complicated and we could actually leave them for a while with additional pop-up inside build script "scheduled for removal" where its noted what will happen and how to prevent that? Important, but need some study and can be done later. In a separate PR. Thank you. Applied.

Proper communication can help that. If there is none, it's hard to change things. Communicate services as such: search function, documentation, ... Most of marketing is done by the happy users which means we have very little to do with this. Why should we care about? It is our time which is getting wasted on support. When we decide it's time to go, we drop the board and voila. My proposition is to write a clear conditions under which a board can come back. To the community supported configuration. This means we will update images, but that's all what can be done.

A few things was already solved and a few things can be pushed forward: release naming 2018.10 is ready for last inspection: https://github.com/armbian/build/pull/1129/files What was done: u-boot package gets frozen by default (armbian-config need adjustment after that to handle »update u-boot«). Bootscripts and their handling were moved to u-boot package. MOTD will look like this: Before: Version number 2018.10 is shown only when stable image was update with official update else commit is shown and such image doesn’t receive official support. Other concerns, which were expressed in that PR (and are off topic) such as package rebuild policy shall be done separately. It also look a bit complicated. Adjusted to: _ _ _ __ __ _ _ | \ | | __ _ _ __ ___ _ __ (_) | \/ | || | | \| |/ _` | '_ \ / _ \| '_ \| | | |\/| | || |_ | |\ | (_| | | | | (_) | |_) | | | | | |__ _| |_| \_|\__,_|_| |_|\___/| .__/|_| |_| |_| |_| |_| Welcome to Ubuntu Xenial with Armbian Linux 4.4.161-rk3399 Where are no concerns for moving to CSC/drop: Kernels: - cubox 3.14.y and Udoo, - meson 3.10.y default, - sP6818-default 4.4.y, - odroid-c2 3.1x kernel Boards to CSC, build script and download page: Olimex Lime2 NAND Olimex Micro Orangepi Pi2 Orangepi+ Nanopi M1 MiQi NanopiM1+ Odroid C1 General concerns which we can also carry on concern free: - project is operating on too big scale -> focus back on the essentials. - reduce attention to the project to reduce pressure on the development. - rethink if we need to implement some sort of project management/ticketing system. - where and how to move things that important but get lost on the forum - fine tune recently created documents: forum rules, guidelines and Contribute. - add moderator duties short list to the forum rules and refresh moderator crew.

We do and others who play with it or do the low level software support. Latest hackers board were not meant to be used for the projects. Some needs months, some years to get to that level. Some never came. Main problem here is marketing which is in general a mixture of lies. They communicate OS support: Android, Debian, Ubuntu ... which is ofc only half true but since all makers repeat this it become a true. They give you some kind of operating system but this is Linux. It can be good or trash. Legally you can't do anything except asking for a refund without a reason. But you have 90 days on Aliexpress for that IIRC? After that, you can forget about. You learned something.

But you should be if you want that "all hardware work properly". That is your best chance, perhaps the only one but sadly this board is not supported by Armbian. Board makers Android based Linux backed by a few inexperienced engineers is usually a little further then proof of concept. Getting from proof of concept to rock stable Linux cost thousands of hours/people/money and you are clearly not willing to pay for that. You expect that hardware maker will do the job of community of pro's? You can only rant about that they fool you and that you failed to do the homework prior to purchase. That's all. This board is not as simple as proprietary device/toy backed with huge community (Raspberry Pi). One more to think which might open your mind: we provide much better software support but without rights to complain. Linux support comes always as is or you have to pay for it.

Implemented: https://forum.armbian.com/terms/ https://forum.armbian.com/privacy/ https://forum.armbian.com/guidelines/ Native speakers, please some assistance.

This utility might work. h3fakeoff.zip

Document from 2016 might not be useful. Script.bin is proprietary Allwinner way of describing hardware configuration. This is EOL and is not used in mainline kernel which we use here. Here, we have https://en.wikipedia.org/wiki/Device_tree Support for eMMC in u-boot is not enabled or does not exists at all. Check those patches to get an idea how to enable eMMC: https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-sunxi/add-nanopi-air-emmc.patch https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-sun50iw2/add-a64-olinuxino-emmc-support.patch Than just use nand-sata-install.

Add your ideas to the list "Download UX". Then it might not get lost. https://forum.armbian.com/topic/6281-board-support-general-discussion-project-aims/?do=findComment&comment=64049 Safe to ignore. They are mostly not even errors.

Knows, but it is expensive and virtually impossible to answer all questions and explain what those specifics kernel "errors" means. Over and over again. H5/A64 section is deliberately left out from forum support section since at least support remains limited. Mostly because of A64 which is staying behind H5. SUPPORTED devices are tested and they work apart from known issues and missing features. Which is true. Known issues info adds an information that there might be unknown issues. WIP goes mainly for boards based on new chips, where we are in the process of knowing things (RK3399) or where we know vital things are broken (A64) and needs longer time to fix. It's complicated. This support is as is. "we" are no obligated to answer on anything.

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/