Igor

Awesome! Well, option 2. is also a logical next step to make sure you don't lose your changes upon a next kernel upgrade - custom kernel is replaced by default. And ... sharing is caring

Then perhaps this way: https://github.com/armbian/config/commit/16c96c975b6d29bc80ca9d6184a3448c135b5689

OK. Than some safer approach. Pack boot scripts separate and install them where it's needed?

I fixed one thing but ... kernel switch works, but the board does not boot. Boot scripts are different on the legacy "pine64" kernel vs. next "sunxi64". If we add boot.cmd and its creation to either boot loader package or BSP? @zador.blood.stained Any objections?

Perhaps with one of this way: 1. Compile kernel on your own: https://docs.armbian.com/Developer-Guide_Build-Preparation/ 2. Send pull request with changes to this file and make use of nightly rebuild version of a kernel

By reverting this: https://github.com/ayufan-rock64/linux-kernel/commit/232b62b4bd69db6e9f074afc710f2c1c00b668df ?

All boards compile the same way: https://docs.armbian.com/Developer-Guide_Build-Preparation/ For this one, you need to use additional parameter EXPERT="yes" to see those which are not supported/untested. The building might work or not. If not, you are on your own to fix the configuration. Our resources are underpowered to take care for all boards that are out there

You can ignore that ... What happens after this part: Starting kernel ... Loading, please wait... starting version 232 Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems done. Begin: Waiting for root file system ... Begin: Running /scripts/local-block ... done.

None. This is first preview version and only a few things works. IMO at least 6-12months or even more to match the legacy kernel and be ready for some production. deployment This estimation is pure speculation so don't hold it.

Nope, AFAIK it works (don't have any Pine64 except Pinebook) on 100Mbit only like with Orangepi Win, Lime A64, ...

Good. This is a bug ... we need to add yet another exception: https://github.com/armbian/config/blob/development/debian-config-submenu#L368-L383

Do you have those two things enabled? CONFIG_FW_LOADER_USER_HELPER=y CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y

https://github.com/armbian/build/commit/b15bb76a35e6f94868dbc8539e52a5102670be42 Have you tried powered USB hub? Plugged at boot time?

When we have at least mainline u-boot support ... it's not near to copy/paste operation. Modern kernel support is in a very infant state. https://groups.google.com/forum/#!topic/linux-sunxi/6StQyINyin8

I would propose to add this: start with oldest from download, switch to beta and upgrade. The rest is ok - special things, new features can go into highlighted.

Try this utility. It works out of the box on a legacy kernel, while on mainline you need to secure boot. h3fakeoff.gz

http://linux-sunxi.org/File:ORANGE_PI-ZERO-PLUS2_V1_0.pdf

Serial console log would be very useful in this case.

Indeed. One year ago we started with first organized testing. We cover all boards except clones. We used project management application, set milestones from "feature freeze, beta testing, bug fixing, writing release information, launch". A new cycle starts with "feature development" and last for 3-4 months and we have 1-2month for freeze-fix-launch phase. We made this with 9 people involved and the first time it went fairly o.k., second time badly ... and third time we didn't try. There are many reasons why even the way and technology is set up perfectly. A tester is responsible for a single task (board) and he gets email: "We are testing, please check what works and what not, write comments". Like this: Exactly. We didn't get here in the first place since our first testing cycle went fine, while second failed. And since I am not sure what is the best way to conduct the testing its hard to pass on. This is good enough if testing process is done properly. At least as we did it the first time. Then it could be also divided into userspace - which should be hardware independent - testing and low-level stuff. IMO, we need a project manager for this testing which can't be me. Organizing testing means some communication but I am in general already up to two weeks behind with my email and other private comm. I can't lead this.

Mainline kernel for H3, H5, and A64 hasn't reached stable yet. They are in experimental/testing phase. 4.14.y will hopefully be the first one. For some people, some cases, they are fine for some time ...

It is labeled testing for this reason ... no warranty for this kernel - if you have some production stuff, rather freeze kernel update (armbian-config -> system), update other userspace packages normally with apt update and upgrade, and wait for a stable version. IMO this is ATM the best way to go.

So you mean you have a boot cycle ... than kernel must crash for some reason. This mainline is not bulletproof yet Try to get some more info why it crashes. Worse case you will need to go back to older version of the kernel.

That looks fine, but why a screen goes off its hard to say without more detailed inspection - serial console logs. Have you tried booting board only? If there is a power restraint, HDMI is shut off.

That's ok. This is latest in the stable repository ... if you need more recent, you need to switch to (warranty free) beta.armbian.com

https://docs.armbian.com/Developer-Guide_Build-Preparation/ We already have support for Rock64 and this board is similar so IMO only minor adjustments are needed.