Igor

Kernel for H5/A64 is (labeled as) experimental because there are many such small troubles. I am not aware of this particular one and dunno if it is already solved. You can try to upgrade to latest nightly DEV kernel/u-boot (from armbian-config) to see if this problem was fixed ... but this is not recommended for any kind of productive deployment. If you can afford to experiment and you know how to rescue the system in case it will not boot, then proceed, otherwise ... wait for next tested update.

https://docs.armbian.com/User-Guide_Armbian-Config/

Not sure. I also noticed this (only?) on Bionic version which has some other problems and it's still in testing/fixing phase. Thank you for the report. Next time supply logs with: armbianmonitor -u This way we can see more.

How is the situation with a legacy kernel? Is it good enough to rebuild images?

That happened on 4.17.y ... will check it later. Anyway, I need to rebuild images to support S model. Boot and flashing part is fully supported from: https://github.com/armbian/build/commit/bb2ce93795be48f414ff223b06ea2533bd2af5ab eMMC flashing from Windows/Linux via Etcher.

Fixed with this commit: https://github.com/armbian/build/commit/3d35e2edfcbdd8bdb7b511e9973e5d83b5fba7a9 Boot log: http://ix.io/1fmU from eMMC ... an image was written directly to eMMC. Side note: there are some issues with DRM video driver and systems boots very very slow when a monitor is attached.

Ahaa. Got it. I saw that patches but didn't know what is the purpose of having that information. They can also be added once.

Which Ubuntu? If Bionic, I don't care ATM, if Xenial, I will look at what can be wrong.

Don't know why GPIOs are not working. IMO they should. It's fixed here as well. Add: extraargs=cma=128 to your /boot/armbianEnv.txt and it will work.

Nothing. Tinkerboard S or eMMC support on Tinkerboard was not developed/adjusted yet. I got my S model earlier this week, but I am too busy even to open the package. The second problem is that stock kernel is (still?) a complete mess due to severe upstream changes. Support in a modern kernel might be even more difficult. Don't know much from a current perspective. It can be a simple way to fix this as well ... Boot and use a system from SD media until this is not fixed since it might take some time.

What are you running here? Jessie or Xenial? (armbianmonitor -u is always handy to see) Network manager is pretty buggy in Jessie, while on Xenial it somehow works. Stretch is better, but for that, a modern kernel is a must. I don't recall issues but I will check.

Wrong. You should edit sunxi-next.config ... sunxi-dev is attached to 4.17 True, but sun8i codename is used only for an old legacy kernel, modern is common for all sun5i, sun6i, sun8i, ...

Ubuntu Bionic (http://www.ubuntu.com) has plenty of bugs and you just find one. We fix some but we can't catch them all. Cubox is the only Bionic build where we forgot to add a label "Bionic is testing" What to do? Search around for generic Ubuntu fix for this or switch to Debian Stretch (where this function works normally)

Workaround. Manually download wget https://dl.armbian.com/_toolchains/gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux.tar.xz and unpack into cache/toolchains

None atm. except going back to Xenial. It should work all but build Bionic images. You will need to override host dependencies checking too. Well, we can't fix all Ubuntu bugs. That is their job. It's a multimillion corporation, while we are a few amateurs.

Sorry, no idea in detail but you will probably need to rebuild the kernel.

https://docs.armbian.com/User-Guide_Allwinner_overlays/ http://linux-sunxi.org/GPIO Not compatible/developed for the modern kernel.

All non-nightly versions are O.K. https://dl.armbian.com/rock64/archive/ 4.4.124 They are also not perfect but they work while nightly are not monitored. They are published automatically if build succeeds.

Strange. Never bumped into this. It has to be some XFCE startup ... you are missing the most important info to perhaps know more: armbianmonitor -u

I am doing some housecleaning on our meson64 family patches and configs, merging with C2 which is the primary goal and removing odroidc2 family at the end. Odroid C2 legacy kernel was also upgraded to 3.16.y, NEXT/DEV is 4.16.y, meson64 and odroidc2 (can) use the same config, (almost - packaging hacks) same kernel patch set. Boot commands: we have booti on C2 next, bootz on C2 default, booti on Meson64 old and bootm on Meson64 NEXT ... uImage, zImage, Image ... is there anything to have this under one simplified boot script? Any ideas in which direction to go would help! @Neil Armstrong You have any idea how to boot legacy 3.14/3.16 C2 kernel with a modern u-boot?

Without investigating. Kernels are usually from different eras and their configurations are also not unified. It's some work to get to such plug and play state. That would easily explain why you have problems.

That is expected. We use the same u-boot with the same settings on all releases. You have one of those boards, which can probably be booted only with a stock Allwinner bootloader, which we don't use for many reasons. What can you do to run a modern and supported OS? Play with u-boot settings (recompile and write u-boot to SD card), especially with a different DRAM speed. I have a pile of boards around and not a single is affected by this problem, but I saw a few people bump into this.

Our target for Allwinner is to get 4.18.y operational and 4.17.y servers only to prepare patches, as a temporal version.

My 5 cents. Not a single board ever broke and no DOA. Actually, I broke Helios4 the very first day of testing - SOM died and partially broke SD card slot on Orange PC2 if this is related to this topic at all. It still works, but you need to be creative when inserting SD. I also broke a dozen SD cards. They just stop working. No name and expensive ones.

As expected. 4.17.y don't have overlay support there ... and USB ports are disabled by default on this board. DEV is experimental/preparation build and many things might be broken. Unfortunately no. USB on C2 is much more problematic. It's enabled but sometimes doesn't work. Here at least we know why it doesn't We seek ZRAM related issues at this point. That is planned to go into stable builds - when it's working as expected or at least if we know what prevents that, while 4.17-18 is months away.