MarkH

@Igor Thanks for adopting my suggestion. RK3328 is working great now. Yesterday, I finally migrated my house server from OPi PC to ROCK64/4GB. Got a RAID5 array of 4 WD Red HDDs via USB3 UASP adapters, providing around 390 MiB/s. Fantastic! @moso Just removed my above-mentioned fork, as Igor merged all relevant changes to the official tree.

@moso If you like, you can use my fork https://github.com/markh-de/armbian-rock64 [fork obsoleted, as all relevant changes have been merged into official tree], where I locked the rk3328 kernel upstream repo to an ayufan release tag, instead of a "living" branch. This way, things won't surprisingly break. Currently the used ayufan release provides 4.4.126, which is then patched up to 4.4.133. This image boots and works just fine (for me). @Igor Is locking to a certain upstream kernel source tag maybe generally a good idea for the "default" builds? The armbian kernel patch set depends on a certain kernel version anyway. Yes, you'd miss upstream fixes, but you'd gain stable builds. If builds fail, it's a little hard to go back in time (i.e. the armbian history) if the kernel source link points to a "living" branch (e.g. ayufan). I.e. an older revision of armbian will still fail building. Using tags would eliminate this issue and point to a fixed version supposed to be used with that version of armbian (and the provided set of kernel patches, etc.).

May I ask what your previous (the "solid") version of the kernel was? For me, 4.4.133 (from the 2018-05-30 nightly image) works very well. If I upgrade beyond this version (e.g. .135, .137, ...) things look OK at first sight (system runs fine, overnight test with "stress" works OK). But ... if I then try to install a new (or even the same as already installed) kernel package from such a newer kernel (> 4.4.133) running, then it crashes badly during creation of the initrd (at package setup stage of the linux-image-... package). I'm not talking about booting that newly installed kernel. It already crashes during installation of the new kernel (when installed inside a kernel > 4.4.133). I had stack smashing, segfaults, illegal instructions, ... all kind of weird errors. Each time the crash looked a bit different/random. Of course, each time after such a crash, the SD card was unbootable and I needed to dd a backup copy to it, before trying again. So ... I think I will stick to 4.4.133 for now and do an upgrade later. However, I'd like to share experience here about the latest version known to "work well" (I'll try to avoid the term "stable" as long as we're talking about nightlies).

Thomas, thanks for the detailed information. Don't get me wrong, I am very impressed by the great progress we see for H3 mainline support. Not long ago it seemed like OPi PC would never get a mainline kernel, so I am really amazed how well it already works by now! I just wanted to understand the supposed status, because you said that SMP worked since ages, but then again, we only saw only one CPU up. Just wanted to make sure that it's a known issue. Thanks again for your great support and effort!

At least in Balldir's dmesg output I see that SMP does not work there either. So do I understand that correctly: SMP does not work out-of-the box for latest sun8i-dev (OPi PC)? Because I happen to have the same issues here: Only CPU 0 online, 1-3 are offline. Apart from that (and from the missing Vbus on the OTG port), 4.6 seems to be "good enough" for a (at least my) headless server.