Igor

Now I did. K4.4 until mainline is not sorted out. Better!

Yes, a kernel only, briefly. It works but booting took very long time for unknown reasons, some strange errors in the logs, ... Haven't got time for debugging yet.

The answer is written on the download page https://www.armbian.com/orange-pi-lite-2/ with the purpose to save precious resources - time. In any case, we don't support this board yet and with 3rd party hardware, you are on your own. Images are suitable for testing, as noted, while problems are observed and collected at this stage. Wait for HDMI video drivers to arrive in the kernel? Dig into the kernel and port/make the touch driver? Perhaps it already exists? Absolutely no idea. Perhaps hire people who know?

It doesn't help. It's even slower on 4.18 http://ix.io/1jXb

Samsung OEM SM961 512GB, new or used is also good enough for such use, 150-100USD? Yes, works well. Some small things, overclock, @JMCC media scripting, ...

@martinayotte @hjc Successfully merged. https://github.com/armbian/build/commit/6d82a8974872ee261006d2cdf6726b7d13df5032

I made a few tests and you can see below that USB is working all the time. [ 3.810953] scsi 0:0:0:0: Direct-Access Multiple Card Reader 1.00 PQ: 0 ANSI: 0 [ 4.015361] random: crng init done [ 4.015376] random: 7 urandom warning(s) missed due to ratelimiting [ 4.366231] sd 0:0:0:0: [sda] 15269888 512-byte logical blocks: (7.82 GB/7.28 GiB) [ 4.367109] sd 0:0:0:0: [sda] Write Protect is off [ 4.367148] sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00 [ 4.367938] sd 0:0:0:0: [sda] No Caching mode page found [ 4.367962] sd 0:0:0:0: [sda] Assuming drive cache: write through [ 4.374477] sda: sda1 Nightly builds upgrade testing: Odroid C2 http://ix.io/1jU0 Odroid XU4, started with oldest Ubuntu Xenial, kernel 3.10.y -> NEXT -> DEV -> DEFAULT -> NEXT http://ix.io/1jU1 XU4 ran from eMMC I found few problems which needs to be fixed before sending out a new update ...

Supported board vs. unsupported boards is exactly this. I can only confirm that there is no overlay support for this board/chip and no plan nor resources to add it. You can should be able to enable I2C manually by editing device tree blob. Edit: solution can be probably reached by reading this: https://github.com/armbian/sunxi-DT-overlays then testing, implementing and sending a PR: https://docs.armbian.com/Process_Contribute/

Comparing experimental mainline support on certain cheap ARM hardware vs. mainstream x86 is pointless. ARM boards are chosen by a use case in first place. If you want a modern kernel, certain things will simply not work. USB must work and it should. This (and usually network) is a minimum level that we start to provide test support. For certain uses cases, this is already good enough. Since ATM I can't check if the latest update actually broke USB I can't argue about. USB used to work on a modern kernel with a few limitations ... ARM corp. only creates a design which is licensed to chip makers. Chip on C2 was made in Amlogic corp., which helps the community develop mainline kernel support via this project http://linux-meson.com/doku.php I hope they(Amlogic) are not underestimating the scale of this process ... which takes months to years per chip family. We are more on the implementation, testing and maintenance side in this process.

USB generally works but sometimes hotplugging doesn't work. Reboot helps and latest changes regarding USB are probably not in the stable repo ... they are for sure in beta/nightly.

Getting to the main repository needs general testing. It's not the only thing that has been changed. Until we are running this project on a hobby level ... it has to wait. Barbecue has higher priority

This problem was fixed with this commit but haven't got its way to the repository yet.

IMO rather get a large (perhaps official) heatsink. Stock XU4S , which is the exact same board, comes without fan by default.

- this method works on clean builds. If you didn't break anything, - problems might arise when you upgrade from a very very old image, the one from early days. - if you upgrade from an old legacy kernel (3.4.y), you need to remove all its package or just use armbian-config method of kernel switching

Yes. This solution just works as expected and it remembers the password. On both kernels ... but driver quality can make some troubles and in some cases, old style networking might show better results.

Are you sure? The network needs a few moments to back to life. Can you attach a serial console when doing those experiments? But it is possible. Not many wireless drivers are good quality.

We proceeded to 3.16.y kernel as did the Hardkernel. Nothing interesting in the kernel commit logs: https://github.com/hardkernel/linux/commits/odroidc2-v3.16.y our build is very recent so it is virtually the same. Can you check 4.14.y/4.17.y kernels? For that, you need to change u-boot and boot scripts. They are getting to that state, where we could just forget about old legacy kernels. Soon. What is your use case?

I didn't know for which device this was about until now. (that's why we urge people to ALWAYS submit logs with armbianmonitor -u before opening an issue topic). I could just make images, but: - current kernel is 4.17.y and I would need to check if overlays are working fine. The problem which you have. - I don't have this dock board to check if everything else there is working. A few weeks ago @5kft added a separate configuration for this board. I just made an image which needs to be tested: https://dl.armbian.com/nanopineocore2/Debian_stretch_next.7z If things works, I'll made a switch on the download page.

You are using nightly development build which is not supported. For a reason ... which is writen in red at first login. Get non nightly image or switch to stable from armbian-config. Than this should work. Wrote on mobile

1. Serial console 2. MicroUSB serial console 3. Solder USB and attach USB keyboard

Yes. It looks like a random issue. I did a few tests on PineH6 and two strange things happened. First, ASM2115 works in fast mode but it doesn't complete the test. It hangs somewhere in the middle. Next test is with 152d:1562 JMicron Technology Corp. and M2 128GB Transcend MTS: PineH6, 4.18.y Reference: Intel Xeon 2GHz, 4.9.y via very good HUB Edit: All images for H6 boards have been updated!

Desktop console usage is defacto unsecured - give me access to hardware and you don't need to give me any passwords Perhaps using armbian-config to switch on / off? Most of our interest lies far below the desktop and we have no means nor people that would mess around the Desktop UX. I can only agree it's not the most modern and since most of the boards are anyway barely usable with a desktop, we don't focus into this area much. If you or anyone wish to tweak the desktop, welcome to join. You need to start here: https://github.com/armbian/build/blob/master/lib/desktop.sh and here: https://docs.armbian.com/Process_Contribute/ I think this part is already on the users' side. Nothing that we need to worry about. I am not aware that XFCE has such limits. In any case, you need to talk to them. We have no means nor resources to make our own desktop or provide a selection of them. Only slight cosmetic fixes at most. Unfortunately, there is little we can do about Thanks for the tip. For those who want's to use Firefox.

ASM2115 SATA 6Gb/s bridge and Samsung 850 PRO 256GB USB3 port at OrangePi Lite2, 1.5Ghz, 4.17.y http://ix.io/1jHP iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 random random kB reclen write rewrite read reread read write 102400 4 14794 15914 15837 15583 11989 15921 102400 16 28337 29333 29288 30406 26548 29360 102400 512 40902 41017 40852 41017 40007 41121 102400 1024 41129 41316 41116 41317 40152 41333 102400 16384 40305 41491 41212 41382 41319 41384

Patch applied but we need to look elsewhere. 1.8Ghz doesn't show up. I need to sort out a lot of things until sending up sources. Until then, the image is here: https://dl.armbian.com/pineh64/Debian_stretch_dev_nightly.7z Logs: http://ix.io/1jE5

Fixed now. All is working.