Igor

IMO, minimizing complexity and subsequently saving energy should be a recurrent activity. Its so simple to get lost in a pile of code, projects and tasks. Few of people, including myself, are too involved and sometimes is getting too much. I don’t want to get depressed or disabled by stress, so more tasks should be redistributed or cut. It's not just about board support count. When a board can come to a support list: - if there are not a lot of problems and most of the stuff already work. At least: network, (HDMI), thermal protection, to run as a server. - if there is at least one stable kernel, - if we got minimum of two boards/persons to cover, except special cases, where one board is stripped version of the one we already support - [new] if we have chosen a responsible person(s), not necessarily a developer, for editing board status and to join perhaps with personal motives and spread responsibility. Technical part of editing is under rework and will be done in some simple manner within a Wordpress only (no more WP + github .conf + github. Putting to other words – if we, as a community, wanted to have longer support for certain boards or their less aggressive moving to »deprecated« section, we need people to take a part in this maintainer/tester role - to take responsibility. BTW: last week I throw out some obvious deprecated candidates, while I still have some left: Odroid C1, Bananapi+, Beelink X2, Lime1. From a kernel perspective: sun4i, sun7i, odroid1 - what else? From this perspective, H3 NEXT images should now get a support status. Should they? Shell we merge forums into one? Its yet another decision to make? Should I just do it or shell we spent "long hours on meetings"? BTW. There was an idea by @Tido that we should start to use some VOIP solution (https://wiki.mumble.info) to regularly, better and faster clear out opened questions. If this helps save energy, I fully support the initiative. Then, there is a question how a board becomes a WIP and why it is not just CSC? How is this path from nothing to WIP, something like »Board bring up« / »Support proposal«? It seems like a good idea, but the very first proposed board, Rock64, proved to be a hard nut or it is simply too early to do anything with? There are many uncertainties and it’s a hit and miss game per se. Or rather push here and there – only our initiative is anyway not enough – and move the board among supported, when we have enough "ifs" on the table? In essence is all about a kernel, not boards. I would rather start talking from there, always. And what @zador.blood.stained already exposed - there is usually a personal motive to work on some board or type of problems and we have to consider that, when doing some plans or talking and organising the work around the project, but certain things, those which might not require a lot of time and energy, could be agreed upon. Reasonable minimal OS images, exactly. Perhaps we have to look on this more from the user side. But we face a big variety, from »I am new to Linux« down to kernel hackers. Well, first ones take a lot of time and ask stupid questions, while others don’t ask much, but when they do, sometimes is not possible to answer – because of quantity, complexity or we simply don’t know the answers. Cleaning is a very good idea but its some work. Yes, this is a good description, but how users see this? Each Linux distribution is nothing but a mix of just some packages. Some only mix and add a stamp, others do big changes. Nevertheless, how big changes are, we have to tell people, where we can help and for what we ask people that is better to use a Google or ask elsewhere. This makes me think to do some changes to a forum (at once) and remove »Common issues« since they are nothing but a generic Debian/Ubuntu problems (which should not be our problem) and merge them with »Peer to peer«. There we add a sticky where and how to search. Also move all nontechnical stuff from »General chit chat« as well. I hardly catch up on topics and can't moderate forum content. If this is too much for current moderator team, it should expand. New WEB is under construction and the person who is doing the actual work - from UX and design perspective - is doing this on biased limited input. Old WEB, the way it looks now, is a patch over patch over patch. Affiliate Amazon links are added value content, but since it’s tied to a kernel only, it might not show up completely correctly. This problem is being considered in the new database design. Current WEB is not a representation of what I or what we wanted to show. That’s the reason something is going on in this field. A basic logical concept of WEB is already standing, without any content. It's possible to add direct comments and check actual navigations - currently, only me and Tido were added comments and if anyone wants to participate in the process, send me a PM and we will ger credentials. Currently, we have a basic frame, UX is getting better and database/web management is designing from scratch. It's a stereotype which won't just go away. We can only send those who come up with such questions to the place where all those common things, like power supply, SD cards, ... essentially to the "Getting started"/"welcome to forum" and simply stating that Armbian is a generic Linux distribution and we don’t cover such special cases. KODI might work, but most likely won't and you better look after a special multimedia distributions like Openelec, Librelec, … In any case, users must be aware how to find such information from a very first page. Such questions are considered in a UX redesign over and over again.

Without logs, no. A problem does not exist. armbianmonitor -u If this does not work, then run this: dpkg -l | egrep "openmediavault|armbian| linux-"

Which kernel? NEXT 4.y is still experimental/testing. Edit: I just checked DT bits for Zero - SPI is disabled. /* Disable SPI NOR by default: it optional on Orange Pi Zero boards */

Tested also: Nanopi Air NEXT Orangepi Zero NEXT

You can log in via microUSB serial. Just plug it to your USB port and a serial device will pop up on your host computer. It's not serial at boot time but you can log in when a system is up. Enabled by default. Just grab latest images from here: https://dl.armbian.com/nanopiair/archive/ For having a different UART during boot time it might be a little more complex job.

Majority of problems mentioned in this topic, those possible to fix, were fixed and images have been rebuild. They are not linked yet to the download pages since not all are tested, but those are: Banananpi Cubietruck Banananpi M2 Beelink X2 Helios4 Nanopim3/fire3 Orangepi Win Odroid C2 NEXT XU4 NEXT = 4.14 Orangepi PC NEXT Tinkerboard Udoo H3/H5 NEXT/mainline support remain experimental/testing so I didn't bother for in-deep testing at this stage. You can find 5.38 images under dl.armbian.com/$boardname/archive Perhaps this way of testing will be better also for a major update? Few more test would help, but since this is more or less a bugfix update, things should just work.

Great job that you tried to do this. As you can see there are still a lot of obvious problems and mainline is not yet useful on this board. Not even for simple cases since its lack of network support. Wens made progress on this, so you can try even more complex job by adding few of those patches to userpatches/kernel/sunxi-next and recompile the kernel. Monitor debug/patching, adjust patches if necessary ... Patch is downloaded from Github by adding .patch to the commit URL, for example: https://github.com/wens/linux/commit/48f1bef6c0b43defca07edd4d6e1962f272fe9d6.patch Have fun!

Kernel 3.4.y is too old for (proper) Debian Stretch functioning. With mainline kernel, 4.14.y, yes. It is currently under testing, so you are welcome to test it. There is no video 3D/acceleration yet while the rest/in general it should work. A testing image might contain unknown bugs, could crash and is coming without end-user support.

Early versions of or nand-install script had this value too low (32M) ... but it's doubled since some time. You must have been using some very old build: https://github.com/armbian/build/blob/master/packages/bsp/common/usr/sbin/nand-sata-install#L333 I am not sure you can change this on the fly.

I tried now once again with brcm40183-patch ... and it works We don't need to change a method, just make it more resilient? hci0: Type: BR/EDR Bus: UART BD Address: 43:29:B1:55:01:01 ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING PSCAN RX bytes:728 acl:0 sco:0 events:49 errors:0 TX bytes:4205 acl:0 sco:0 commands:49 errors:0 Scan also work.

If you create a new file, no.

No, nothing. That's a problem.

Push it here: https://github.com/armbian/firmware/tree/master/ap6212 I just tested and hci device is up but it doesn't work Strange. Don't have more time today ...

Those scripts go to armbian-tools package, which is by default installed from apt.armbian.com. After this commit, it should work ... just trying out.

You mean self-made or the one from the download? I will look more into this. Edit: Problem found. Repository needs a small update.

That is certainly not our problem. We don't host Debian packages. only those which come from apt.armbian.com (I hope that works for you well). It is most likely random temporally issue. There aren't any differences between Ubuntu or Debian at this level. I mean, it should not be. This wifi chip is very basic and also not very quality one. Get Realtek 8812AU which performs very well, also in 5G AC mode, with speed up to 200Mbit/s. You are welcome

And few network tests with Tinkerboard Ubuntu Xenial desktop 4.14.14, logs: http://ix.io/EHC Connected with onboard wireless: after connecting a wired network

Try this build: https://dl.armbian.com/orangepipc/archive/Armbian_5.38_Orangepipc_Debian_stretch_next_4.14.14_desktop.7z Still testing.

I made a test install on 5.35 (which is currently the latest on a download page), install on SATA. Apt update and the upgrade went fine. From our perspective, everything looks fine. Here are logs: http://ix.io/EHu I see you made some modifications? In this case its hard to tell. What did you change?

Not correct. I close it - check docs and try again.

It is the same problem:

https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boot-2017.03-armada-17.06/doc/mvebu/uart_boot.txt According to Marvell engineers, it is "Not the funniest process, but you still will not need to setup JTAG session."

Or there is something wrong with your network? Are you try to use the wireless network for this?? Please check/provide: 1. Is your server already downloading something 2. Did you notice this right after install? We are downloading package base updates in the background in the first run 3. Results of network testings. Remember that you are using a mainline (NEXT) kernel which does not have all functions yet. If you want them, you need to use a default/stock kernel, found in Android or TinkerOS, which is anyway not recommended for this case. And for many others as well. You can switch kernels back and forth in armbian-config menu.

Check this section: https://docs.armbian.com/Hardware_Allwinner/#how-to-reconfigure-video-output

Perhaps this is related? https://github.com/armbian/build/commit/1599e074fbd5a5851a6384cb4f619c63dcdb70e3 Build passes - need testing.