Igor

We have a few problems here. First is that sunxi64-next branch was reverted back to 4.14.y since 4.18.y just not ready yet ... in 4.14.y there is no support for H6 ... I can only switch to sunx64-dev, where the board boots, but without http://ix.io/1nK7 HDMI, WiFi and USB3 seem also not to function properly. @martinayotte Should I apply this? diff --git a/config/sources/sun50iw6.conf b/config/sources/sun50iw6.conf index 16834529..692bb292 100644 --- a/config/sources/sun50iw6.conf +++ b/config/sources/sun50iw6.conf @@ -31,6 +31,13 @@ case $BRANCH in KERNELDIR=$MAINLINE_KERNEL_DIR KERNEL_USE_GCC='> 7.0' KERNELPATCHDIR='sunxi-dev-h6' + + KERNELSOURCE=$MAINLINE_KERNEL_SOURCE + KERNELBRANCH='branch:linux-4.18.y' + KERNELDIR=$MAINLINE_KERNEL_DIR + KERNEL_USE_GCC='> 7.0' + KERNELPATCHDIR='sunxi-dev' + ;; esac diff --git a/patch/kernel/sunxi-dev/p-board-h6-add-THS.patch b/patch/kernel/sunxi-dev/p-board-h6-add-THS.patch index 8d59cca2..631a40f8 100644 --- a/patch/kernel/sunxi-dev/p-board-h6-add-THS.patch +++ b/patch/kernel/sunxi-dev/p-board-h6-add-THS.patch @@ -1012,7 +1012,7 @@ diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/ index 000a681fb515..bec8c4a46ec7 100644 --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi -@@ -41,6 +41,32 @@ +@@ -41,6 +41,30 @@ opp-microvolt = <880000>; clock-latency-ns = <244144>; /* 8 32k periods */ };

It's there for months: https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-rockchip/board_tinkerboard/0049-added-timeout-when-force-entering-UMS-mode.patch

Fex editor is not there if there are no sunxi-tools installed or if you are running a mainline kernel ... or there is a bug, your system is broken somehow. If GUI is not operational, there is always a manual way: bin2fex and fex2bin tools. If not, you install them, eventually compile from sources.

armbian-config -> system -> install desktop ... do that on a clean image. But its officially untested on Oranepi Zero. Here the problem is probably because HDMI is disabled by default (need to be enabled in boot/script.bin|fex). Probably the same on a mainline kernel. Since it's not there.

Possible. Let me check this during the day.

Network troubles were in the past while (non-critical) USB hotplugging is still present. As you can see I manually tested most of the boards and already that was on the edge what I can do "by the way". I am not sure I will do that ever again and certainly not within the next 6 months. It's painful, time wasteful and it goes by completely unnoticed. I didn't expect that it will break and my C2 works also when updated to latest nightly. Here https://github.com/armbian/testings everything looks fine -> From the information that I have its safe to update.

My C2 is working without any issues: http://ix.io/1nGc

A network was working OK for some time and at the time of testing but it is possible that one wrong patch finds its way upstream. Obviously ... while USB is a bit problematic. Hotplugging sometimes still doesn't work. If you boot with an attached device, it works. I need to see if I can recreate this.

This should be done automatically. Please provide logs with: armbianmonitor -u

If the image boots, it should work out of the box.

This is a bit strange but OK. You can find old u-boot packages in our repository. http://apt.armbian.com/pool/main/l default=3.4.y next=4.14.y dev=4.18.y ->

I'll try to bring it up in 4.19.y ... some basic support is getting mainlined and it will be less troublesome. I hope.

We use that for years now in all modern kernels, Hardkernel uses something else.

Probably because it is still .wip and packages are made only for .conf ... not 100% sure but possible.

I personally don't need it and have no time - it will be donated directly to one of the project volunteers (living in US or Canada). Will send you info ASAP. Thanks.

For what we already do for you? Deal.

With the latest update, it should be 5.60 ... but perhaps after reboot/logout/login? Well, perhaps it's time to enforce some already proposed naming for a version of Armbian and use this numbering only for our internal process. Armbian 2018.10 Armbian 18.04 Armbian Some_Generic_Names Let's make a separate topic or attach to existing for those changes.

Perhaps apt purge armbian-RELEASE-desktop ? You can also just temporally disable it in the armbian-config.

Yes -> "... I can clean up armbian-config" We don't need to have so many functions doing the same thing.

@lanefu self-assigned this 7 days ago. I need to recharge.

Just use armbian-config for changing kernel which will remove old kernel and prevent troubles on update. Symlink is made on package install ... Wrote on mobile

Try blacklisting wireless (xradio) and set lower max CPU frequency (/etc/default/cpufrequtils). Some revisions of this board have overheating issues ... which are a possible cause for troubles. Where does it hang?

According to our testings, there is no bug: https://github.com/armbian/testings On some boards, it can take a little longer that networks get initialized. Your logs show expected entry: [ 13.398258] rk_gmac-dwmac ff540000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off

The problem is exactly as predicted. You need to update a boot script as described a few posts back: Since this only happens when booting from eMMC, fixing is super easy. Boot from SD card and copy /boot/boot.* to eMMC's /boot/ directory. You only need to mount eMMC before.

We were off topic all the time so I did change the name of it. Regressions happen and will happen in the future. https://www.google.com/search?q=how+many+people+work+on+the+kernel "There are over 13,500 developers working on the Linux kernel, most of them will know the general workings of the kernel. No one knows the exact details of what every line of code does in the monster kernel. Even Linus Torvalds himself does not know every detail of the kernel, it's not the pet project he started in 1991 anymore" There are tens of thousands of Tinkerboard users and since it only bricked a few of your boards (a problem with some of your monitors, cablings, DVI adaptors), the issue is not critical. That changes a view on the problem for 360. If you want us or me to solve your problem, its possible, but our resources are so tiny that waiting time is currently measured in years. If donations bump for 100x, I will hire a few professionals to help out. Until we have to earn money elsewhere to keep this project running ... this remains as is. There are many kernel hackers out there who are fixing problems for money. You can also just switch faulty hardware. It's your call.