Search the Community

I tested it by myself while making a Rock64 configuration for Armbian. I'm still not sure why cryptsetup shows much higher numbers than openssl (and so I decided to not post them right away without making some real world tests with cryptsetup on a real storage, but even if I had a spare SSD to make a benchmark, I broke the USB3 port while desoldering the protection diodes) Yes, and a relatively fast DRAM. So just by numbers Rock64 (4.4 kernel, performance governor) is more or less twice as fast as the Pinebook (3.10 kernel, performance governor, A64 has AES instructions too) and more or less 4 times as fast as Armada A388 with CESA. AFAIK A53 cores in H5 don't have AES support? Can you post contents of /proc/cpuinfo ?

Thank you for the test. Wrt Ethernet I was thinking about adding the USB Ethernet dongle that came with the Pinebook (RTL8152) since this works out of the box with the network config we use on the OPi Zero image (zero contents and therefore interfaces under NM control). So most probably an own download page pointing to OPi Zero images and mentioning sed -i 's/xradio_wlan\ g_serial\ xradio_wlan/8189es g_serial/' /etc/modules && reboot is enough. Dealing with up to 4 interfaces here (USB Ethernet gadget, Wi-Fi and two times Fast Ethernet) would also be a nice opportunity to write up an article dealing with OPi R1 but more generally explaining how to configure networking here (and focus on common mistakes like connecting more than one interface to the same network and then wondering why eg Wi-Fi stops working after the Ethernet cable is disconnected )

(IMO) There is no point on switching to 4.12 since Icenowy just made a first 4.13 branch: https://github.com/Icenowy/linux/tree/sunxi64-4.13-rc5 While it doesn't have some features that could be added (I can already hear "there is no DVFS! let's use Megous' branch instead") it's still a good candidate for a development branch since it has a WIP DRM display driver, support for the Pinebook, and the SoPine. if/when she posts a 4.13.y branch (for a stable kernel version, not a release candidate) we can try switching sun50i-dev to that branch, but we still need to update the u-boot (ideally to v2017.09).

Well, from a technical point of view it's just an OPi Zero with an USB-Ethernet dongle attached to the USB port in a much nicer form factor. Software development efforts needed: close to zero since the only two things that are interesting is whether the used Ethernet chip is supported by legacy kernel and runs stable (testing efforts hardware vendors usually skip) and same for Wi-Fi (since it's RTL8189ETV an /etc/modules modification should do the trick). If Armbian wants to support this board IMO we should focus on providing a single OS image for both H2+ OPi Zero variants. But let's wait until schematics are released or at least real information is available (especiall type of Ethernet chip -- if it's RTL8152 then we could at least test a bit with legacy kernel since Pinebook shipped with such a dongle) Well, it can always grow to one side without affecting mechanical compatibility to add-on boards.

While it's far from "supported", HDMI output should work via simplefb enabled by u-boot, but I don't think that anybody tried to enable the DSI output in mainline (though Icenowy was able to use the RGB output on the Pinebook which should use pretty much the same display pipeline if I understand it correctly). By "mostly useless" I mean mostly useless for an average user that wants to use a desktop environment (X11 or Wayland). Without a matching binary userspace driver (and by "matching" I mean architecture (armhf vs arm64), API (Wayland, X11, framebuffer) and hardware (Mali400 and matching revision)) you won't be able to use it, and it's not like ARM or Allwinner are willing to provide a full set of these blobs. Well, if you call r3p0 UMP version "support", then maybe. AFAIK r5p0 was tested on mainline H3 and H5 too, but again it is limited by the availability of a matching userspace binary and a proper DRM display driver.

Update. Pinebook was my Beachbook for some time. I used it for email, browsing, IRC and terminal. It proved to be sufficient while once it didn't start charging (from 5%) even plugged to charger - unplug / plug back solved that - and "heavy" Chromium usage ate all resources. I think we need to check Chromium caching - when using let's say about 10 tabs for some time - RAM is going down, swap is not getting used and system just become extremely slow / unresponsive. My environment did not provide enough motives for exploring the problem deeper

What about to provide a separate pinebook-hdmi dtb file? I already searched to understand how to enable hdmi but not found. OK, will RFC. Loaction of this file https://github.com/armbian/build/blob/master/config/50-pine64-pinebook-touchpad.conf is also not very logical. Where should we collect such things?

Release candidate latest fixes + this regarding audio on resume, touch pad and kernel upgraded with upstream patches. Download: (touch pad fix not included) https://dl.armbian.com/pinebook-a64/Ubuntu_xenial_default_desktop.7z What about HDMI out - how to use it?

All those listed long ago for a reason in the very same thread: https://forum.armbian.com/index.php?/topic/4133-quick-pinebook-preview-review/&do=findComment&comment=31463

I was using Pinebook for a week and it's performing ... good as a light browsing and remote terminal console work - any objections to move it from WIP section? Any idea why audio stopped to work? IIRC we fixed that.

[Disclaimer on] This is the try to play through some sort of an approval process contuining discussion from here and there -- maybe move @hmartin's last post to the latter thread? IMO we need a transparent process to decide whether to support new devices or not weighing pros/cons for both developers and users and estimate efforts especially if it's a new platform. Even if hardware vendors send out free dev samples we should not automatically start with new boards but discuss and evaluate first since we already deal with way too much boards with a crew just too small. I would believe @Igorhas now every new Olimex device and TL Lim said he sent out 3 ROCK64 boards to various Armbian devs me being amongst... I think that's an opportunity to start to establish such a process now? Since I've thought about this issue for a few days and came to no conclusion (Github issue or not or discussion in forum and so on) I'm now just naively start with a new thread regarding this RK3328 device and maybe we find out collectively how to define a process based on this? [Disclaimer off] Let me introduce ROCK64: RK3328 SoC: feature list ROCK64 schematic (preliminary since vendor promised to accept last minute changes/suggestions within the 2 next weeks) Board layout picture (same form factor as Raspberries, pre-production samples do not fit exactly in RPi enclosures, final design should fit) 1GB, 2GB or 4GB PC-18666 LPDDR3 eMMC has higher boot priority than SD card (but eMMC can be disabled via jumper) socketed eMMC modules are the same as on Pinebook and SoPine (and compatible to older ODROIDs and their SD card adapter) 128Mb SPI NOR flash (16MB) on future board revisions (to directly boot from USB[3] storage, network or whatever) RK3328 should be interesting for media center purposes (4K support, video codedcs, somewhat decent GPU, high memory bandwidth) Due to USB3, GbE and additional Fast Ethernet also interesting for NAS/server use cases (TBC, both USB3 and GbE performance needs to be checked) I2S exposed and compatible to some early RPi DACs, a lot more GPIOs exposed as usual (see picture above and this) Pricing will be competitive (can't share details yet but it's based on amount of DRAM and tries to match Pine64 costs but since DRAM prices increased a lot the last months it might be slightly more. Prices will be announced publicly within the next 2 weeks) Pros: board vendor actively participates (listens to community, provides information including schematic and cares about correctness, tries to bridge developer community and chip vendor) board vendor provides dev samples and documents problems devs might run into (see below) chip vendor actively supports mainline Linux and u-boot chip vendor is said to focus on ROCK64 as currently best supported RK3328 device to spread market adoption (TBC) SDK/BSP not horribly outdated (RK relies currently on 4.4) almost all Armbian target audiences might benefit from RK3328 support (desktop replacement, NAS/server, audiophiles + IoT use cases due to exposed GPIOs/interfaces) No unreliable shitty Micro USB for DC-IN but sane 3.5/1.35mm barrel plug to be combined with 5V/3A PSU Pine Inc already sells together with Pinebook Icenowy already received a dev sample Cons: new platform (Rockchip 64-bit) needing more initial work Did anyone of you received shipping confirmation with tracking number already? @jernej? Unfortunately I get a dev sample with unusable USB3 (some components need to be desoldered which is a pity since I'm not good in soldering at all) My next steps planned: Boot the board with what's provided within one week (TL Lim mentioned a 'Debian based 4.4 BSP, later Yocto' and said RK would be ready with a mainline variant within the next weeks) Test GbE speeds, memory throughput and the usual Armbian tunables (IRQ distribution) ask @Xaliusfor USB3 numbers (his dev sample was shipped out later and doesn't need soldering) Present results to continue discussion

What is way more important is to understand how the physical environment affects thermal readouts especially in the Pinebook. There PMIC and SoC are both attached with thermal pads to a metal plate. When the Pinebook charges, the PMIC gets very hot and transfers this heat over to the SoC, so SoC temperatures seem to increase for no reason and people are scared. In general it's the old story about data vs information. People love numbers (since easy to compare), love graphs (since nice looking) but don't like information (need to switch on the brain). So what does monitoring provides? Data but no information. You need to have some knowledge to make use of it, in this case about PMIC+SoC placement. This RPi-Monitor stuff is great for developing good settings (as we did last year for H3 and A64 devices, this year it was just a quick check if we can throw Allwinner's Pinebook settings away and replace with the way better Pine64 settings community developed last year) but once this is done it's not that useful anymore unless you want to experiement yourself (testing out different heatsinks or cooling solutions for an enclosure for example) BTW: position of the CPU cores matters wrt temperature sensor: https://forum.armbian.com/index.php?/topic/1614-running-h3-boards-with-minimal-consumption/&do=findComment&comment=12525 (A64 is more or less a H3 with exchanged CPU cores and crippled USB) This is not related to GPU/Mali400 (this Mali crap is useless with A64 anyway). Allwinner's video engine is doing this stuff, we can use HW accelerated video decoding on A64 since March 2016 (even if over in Pine64 land still some believe they need 'the Mali' for that), we were able to use hardware accelerated video encoding a few months later. Temperatures increase just by a few degree: https://forum.armbian.com/index.php?/topic/789-breaking-news-choosing-armbian-speeds-up-your-orange-pi-multiple-times/&do=findComment&comment=6005 (video engine in H3 and A64 is exactly the same, at the top of that thread you also find a nice example why Allwinner's defaults are so shitty and why it matters to replace them with community settings)

There was none since with Armbian it's just a simple 'armbianmonitor -r' to get RPi-Monitor installed. But currently only for one single platform the templates will be adjusted so you end up with default templates on all other platforms and have to exchange them yourself. On A64 platforms using legacy kernel (that applies to you) the most simply thing is to use this script: https://github.com/ayufan-pine64/linux-build/blob/master/package/root/usr/local/sbin/install_rpi_monitor.sh (it's bundled in most recent ayufan builds for Pine64 and Pinebook). All currently available RPi-Monitor templates here: https://github.com/armbian/build/tree/master/scripts/armbianmonitor/templates (even for shitty devices like Banana Pi M3 Armbian hopefully never will support). I never touched or even looked at those templates for memory or swap since useless anyway (it's fine having no 'free memory': http://www.linuxatemyram.com)

On the Pinebook or SOPine having the eMMC installed changes the device numbering and needs handling in boot.cmd, not sure how the RK u-boot config handles that atm...

As per this post and the downloads section of the Armbian site, some boards have been moved to WIP (Work In Progress) or EOS (End of Support). The only specific H5s I'm aware of, the Orange Pi Zero 2+ H5 and the Orange Pi PC2 are both WIP boards (although from a second glance at the downloads page, it looks like all but the pinebook are H5 boards), so post this commit from 28 days ago, you'll need to set the EXPERT flag to YES in order to show WIP boards. This was done to reduce the number of support requests when people have self-built WIP board images or downloaded the nightlies and subsequently complained that it didn't work properly, which is exactly the reason why it is a WIP!!!

Current situation with WIP/EOS boards: ➜ armbian % find lib/config/boards -name '*.wip' -o -name '*.eos' | xargs grep BETA_TARGET | grep -v '\"\"' lib/config/boards/orangepiprime.wip:CLI_BETA_TARGET="xenial:dev" lib/config/boards/orangepiprime.wip:DESKTOP_BETA_TARGET="xenial:dev" lib/config/boards/orangepipc2.wip:CLI_BETA_TARGET="xenial:dev" lib/config/boards/orangepipc2.wip:DESKTOP_BETA_TARGET="xenial:dev" lib/config/boards/lamobo-r1.eos:CLI_BETA_TARGET="xenial:next" lib/config/boards/nanopineo2.wip:CLI_BETA_TARGET="xenial:dev" lib/config/boards/orangepizeroplus2-h5.wip:CLI_BETA_TARGET="xenial:dev" lib/config/boards/orangepiwin.wip:CLI_BETA_TARGET="xenial:dev" lib/config/boards/orangepiwin.wip:DESKTOP_BETA_TARGET="xenial:dev" ➜ armbian % As proposed in the discussion thread, we should think about disabling prebuilt nightlies for configurations that we won't support, so I propose disabling them for all boards listed here. Current situation with "supported" boards: ➜ armbian % find lib/config/boards -name '*.conf' | xargs grep BETA_TARGET | grep -v '\"\"' lib/config/boards/orangepizero.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/miqi.conf:DESKTOP_BETA_TARGET="xenial:dev" lib/config/boards/cubieboard2.conf:DESKTOP_BETA_TARGET="xenial:default,next" lib/config/boards/pine64.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/pine64.conf:DESKTOP_BETA_TARGET="xenial:default" lib/config/boards/odroidc1.conf:DESKTOP_BETA_TARGET="xenial:default" lib/config/boards/cubox-i.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/cubox-i.conf:DESKTOP_BETA_TARGET="xenial:next" lib/config/boards/odroidxu4.conf:DESKTOP_BETA_TARGET="xenial:next" lib/config/boards/orangepilite.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/pine64so.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/pinebook-a64.conf:DESKTOP_BETA_TARGET="xenial:default" lib/config/boards/orangepiplus2e.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/cubietruck.conf:CLI_BETA_TARGET="xenial:next" lib/config/boards/nanopineo.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/clearfogbase.conf:CLI_BETA_TARGET="xenial:default" lib/config/boards/orangepione.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/nanopiair.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/tinkerboard.conf:DESKTOP_BETA_TARGET="xenial:dev" lib/config/boards/bananapi.conf:CLI_BETA_TARGET="xenial:next" lib/config/boards/orangepizeroplus2-h3.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/orangepipc.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/bananapim2plus.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/beelinkx2.conf:DESKTOP_BETA_TARGET="xenial:default" lib/config/boards/orangepipcplus.conf:CLI_BETA_TARGET="xenial:dev" lib/config/boards/clearfogpro.conf:CLI_BETA_TARGET="xenial:default" lib/config/boards/lime2.conf:CLI_BETA_TARGET="xenial:next" lib/config/boards/odroidc2.conf:CLI_BETA_TARGET="xenial:next" lib/config/boards/odroidc2.conf:DESKTOP_BETA_TARGET="xenial:next" ➜ armbian % In my opinion this is too much, so we should disable some nightlies fron this list too.

While I am pretty content now with the performance of Chromium after all the tweaks that were applied, I never heard of qupzilla before and am testdriving that on my Pinebook atm. It seems a bit more capable compared to the other lightweight options like Midori.

Nope, I only know I'm on the list since I received an email from him (which I responded to somewhat off-topic collecting a lot of weird proposals for a potential next Pine design). While I think Pine folks have no objections sending out few more dev samples IMO we should try to focus on what 'we' want: board bring up adventures or focus again on what Armbian has been in the past: a reliable distro with secure and optimized defaults (so me receiving an early pre-production sample is already somewhat wrong since I'm too stupid to read schematics or fix USB3 issues on my prototype with solder iron...) Not really but by looking at Pine64 price-list you get the idea (maybe already add a few bucks more since DRAM prices increased a lot and I don't think Pine Inc does any good selling a loss-leader). They'll decide within next 2 weeks and then I'll believe information will be leaked anyway even if official ROCK64 announcement will be delayed a bit. But from an end user perspective shipping costs are also important so let's wait and see with what they come up. Wrt availability: Currently Pine Inc gets some bad press regarding 11" Pinebook shipments due to display shortage (BTW: I would fully understand if that's no real display shortage since I can't imagine how they make any money with the $89 variant since they defined prices long ago and both DRAM and eMMC increased BOM costs a lot in the meantime) but I don't think that will be an issue with ROCK64. TBC. I'll only do some initial testing and maybe attend improving settings but I neither have the time nor skills/patience to add a new $LINUXFAMILY so someone else is needed as maintainer if we want to add this board to Armbian. Benchmarks are always a problem. Simple example: https://forum.armbian.com/index.php?/topic/1285-nanopi-m3-cheap-8-core-35/&do=findComment&comment=14623 (you need to understand relationship between cpufreq behaviour and numbers, then need to tweak settings so benchmark scores look better but in reality that's not important at all!). Network benchmarks on slow ARM devices are currently more or less benchmarks for cpufreq scaling and compiler settings (a lot is CPU bound even with appropriate settings) and the same is true for storage --> choose wrong cpufreq settings and storage performance sucks: https://tinkerboarding.co.uk/forum/thread-310.html If we want to behave like IT protozoons just collecting numbers without meaning it's easy (passive benchmarking, that's what Phoronix is about) but if we want to do benchmarking to improve things it gets complicated since then benchmarking is not a process of collecting numbers but improving them with focus on real world workloads and NOT synthetic benchmarks. In other words: Not that easy to come up with some sort of standard tests since on those low performing ARM devices with settings optimized for totally different use cases the most important thing is to identify and understand all the various bottlenecks to get the idea where to improve stuff.

Yes, no locker for now is the way to go, though Pinebook is exactly a kind of device which may benefit from password protection in login manager and locking support in the future.

Regarding backlight control issues: Jun 06 15:41:31 pinebook pkexec[3562]: zador: Error executing command as another user: Not authorized [USER=root] [TTY=unknown] [CWD=/] [COMMAND=/usr/sbin/xfpm-power-backlight-helper --set-brightness 51]

A10-OLinuXino-Lime (Allwinner A10) A20-OLinuXino-Lime2 (Allwinner A20) Banana Pi (Allwinner A20) Banana Pi M2+ (Allwinner H3) Banana Pi M3 (Allwinner A83T) Banana Pro (Allwinner A20) Beelink Mini MX (Amlogic S905) Beelink X2 (Allwinner H3) Clearfog Pro (Marvell Armada 385) Cubietruck (Allwinner A20) Lamobo R1 (Allwinner A20) NanoPi M1 (Allwinner H3) NanoPi NEO (Allwinner H3) NanoPi NEO Air (Allwinner H3) ODROID-C1+ (Amlogic S805) ODROIC-C2 (Amlogic S905) ODROID-XU4 (Samsung Exynos 5422) Orange Pi Lite (Allwinner H3) Orange Pi One (Allwinner H3) Orange Pi PC (Allwinner H3) Orange Pi PC Plus (Allwinner H3) Orange Pi Plus 2E (Allwinner H3) Orange Pi Win (Allwinner A64) Orange Pi Zero (Allwinner H2+) Orange Pi Zero Plus (Allwinner H3) Orange Pi Zero Plus (Allwinner H5) pcDuino3 Nano (Allwinner A20) Pine64+ (Allwinner A64) Pinebook (Allwinner A64) Roseapple Pi (Actions Semi S500) Wandboard Quad (NXP i.MX6) (useless list since as Zador and me already explained it's more related to software/settings: high commit interval, reducing permanent writes, ability to do a fsck at boot)

Tested without issues on 14" Pinebook, PR merged already. Do we need a patch for the same set of changes for u-boot too?

Ok, I can also confirm on my 11" pinebook that changing reduces the tearing and gets rid of the bottom row of dots... it isn't interlaced like it was before, but I think it is still there a bit, but that may be a artefact of XFCE not liking window contents being shown when dragged (easiest way to spot) and not knowing how much we can push the lcd_dclk_freq without something going pop. Interestingly enough the reported screen refresh rate jumps from 60hz to 64 hz. Changing the lcd_ht and lcd_vt then drops it back to 56hz like we usually see on ayufans mate images 2180c2249 < lcd_dclk_freq = <0x48>; longsleep --- > lcd_dclk_freq = <0x4d>; ayufan 2187c2256 < lcd_ht = <0x5dc>; longsleep --- > lcd_ht = <0x640>; ayufan 2190c2259 < lcd_vt = <0x320>; longsleep --- > lcd_vt = <0x35c>; ayufan

You need latest u-boot with @zador.blood.stained's patches: linux-u-boot-pinebook-a64_5.27_arm64.deb.gz

Just the optical size (I've not touched Pinebook for a week and when booting it again I had the chance to look at it from an 'average user' perspective). Feel free to replace bootlogo with it.