Igor

No, we don't. Current Allwinner next branch has yet another problem. sun8i support was merged into sunxi and now it is a bit difficult to go back until upstream gets solved. The idea is to stay still on 4.14.y and apply bugfix patches only. OK, but unfortunately there is a mess outside our power atm and we will probably need to jump further when the time is right. Regarding u-boot I vote for a conservative approach. We don't update it unless it's tested very well or necessary. This will require switching repository upgrading to semi-manual mode. I picked two boards (C2 and Opi 2e), where I will do all possible upgrade scenarios together with new/changed features part. This is manageable but I didn't cover all problems this way, well at least most of the userspace ones. Even we don't have dedicated testers I hope someone will join at least testing part to find problems.

If some urgent kernel update is needed, we do it directly from development branch? ... and/or completely merge development to master when new features are thoughtfully tested? I am currently finishing a desktop packaging and networking cleanup. Starting with debugging.

I assume you want to use on your x86 desktop? Just go with stock Debian or Ubuntu under KVM/some virtualization for testing the bash install scripts. I do it this way and its fast, convenient and 100% compatible. If you need to talk deeply with hardware in this process you will need to boot real hardware anyway.

https://docs.armbian.com/Developer-Guide_User-Configurations/#user-provided-image-customization-script

Hmm, strange. I'll try to replicate - I suspect network failed to initialize but why ... what about with a default or DEV kernel? Can you try to power cycle this 4.9.86 build?

If you are creating kernel on your own, two things matters for this case: use branch NEXT (DEV is deprecated) if you need headers within your image, build with INSTALL_HEADERS="yes" If you only need to install headers, install them from armbian-config -> software -> headers

This one was tested yesterday and if it does not work, check the hardware. I used first option - an ext4 rootfs partition.

The biggest problem is not creating a script but its maintaining. Such scripts might work fine now, for few months ... and once they break. We can only accept zero maintenance work or work that comes with a maintenance. Next, scripts also have to be as generic as possible. Starting with a most recent clean image + your software and data deployment script is the best way if you do it for you only. If you need to distribute images than you need to build them with your modifications.

Try most recent "NEXT" image and use armbian-config to create an AP for you .... and when reporting a problem remember to provide logs: armbianmonitor -u Wrote on mobile

Armbian-config - alternative kernels -dev ... but procedure for this upgrade is untested. Wrote on mobile

It looks everything kernel wise is enabled https://github.com/armbian/build/blob/master/config/kernel/linux-odroidxu4-next.config#L5220-L5226 I don't recall we need anything else. Unfortunately, I don't have any CD rom device around to test

I made a self-build and it works normally. http://ix.io/UpD Try this one: https://dl.armbian.com/odroidxu4/Debian_jessie_next.7z I hope you are not removing SD card after the process is finished? The bootloader can only be loaded from SD card.

Mainline kernel is not quite finished and is not recommended to use in production. ATM it is somewhere in a testing/bug hunting stage. A month. Few months.

By who? This year? Today? What for? Have you noticed this?

It was right now. In case of emergency: 1. Upload files here: https://github.com/armbian/upload/tree/master/debs and into appropriate subdirectories if applicable 2. Wait for cron to kick in / me run the script

It doesn't appear to be Armbian related.

If you mean testing repository. Well, we do have it -> beta.arnbian.com ... I understand the previous hint as a build engine branch and then we do it this way: https://github.com/armbian/build -b stable -> apt.armbian.com https://github.com/armbian/build -b development -> beta.armbian.com This will solve some problems, but not all and I am not sure if we can set some strict merging policy on this schema. If we are ok with proposed, development continues from there, current master is only getting bugfixes from development branch and other branches are duped?

Back in the days, I made many many many tests to secure that, but in today's perspective, this is not possible. The answer to this is - try to: limit board count, enlarge team, enforce better organization. All at once. Until we don't have help (more people for covering at least board statuses) or do it radically different (and risk opening a pandora box of currently unknown troubles), nothing will change. Automated testings are one thing, but still, we need truly dedicated persons who would have an eye on this and that board - the new webpage is being designed with this in mind. ... of a build engine which is grabbing sources from elsewhere? Hmm. If we move to a development branch (perhaps even to start with a clean fork as Zador proposed not long ago), someone needs to maintain the old one. Can we afford to maintain both ATM? The last upgrade was a bit messy, yes. I wasn't expecting that much problems from upstream. Prevention would be possible only with extensive testing which would provide a more accurate big picture before putting anything out. We still have an unfinished task: recruiting and manage testers. I tried but failed. Writing announcement or pleads helps absolutely nothing.

Try to imagine how to enforce policies to volunteer developers. Do count them and then proceed to this question. Of course not. I don't pay much attention to stuff which is CSC and since you discovered a potential bug which is actually not working ... why do we waste time discussing this? Remove it. Our work is somewhere in between as you can see mainline support is months behind and some features might never get there. I don't see this as a problem.

This board is CSC and is not related to board bring up. Ignore the fact its there or remove it. I don't care.

Espressobin bin is not yet supported since there are some rough edges and bugs. To be able to boot you need to update u-boot, located on SPI flash - instructions are at the download page and apparently you need to recreate (and save) boot environment which seeks for boot script on SD card or USB. We don't support this board also because we are out of resources.

Yes, if you have a driver for DVFS ... this is not existing yet or not working properly yet in a mainline kernel for A64/H5 boards. This is not as simple as enabling MIDI.

You are wasting time to compare all this. A modern kernel support for Allwinner is basically written from scratch (by a community) and DVFS part will be completely reworked I heard. There is no solution at the moment - you already find a workaround and that's it. A few months ago there was no DVFS, no video output, no ... and few months will pass that these things actually reach upstream kernel builds and become stable. We don't support H5 since it's still labeled development. Supporting things in motion is not possible/stupid/extremely costly.

Do you have any powered USB gub laying around? Try with it. And try modern kernel.

You made a typo. That's why id doesn't work. systemctl start NetworkManager.servce systemctl start NetworkManager.service