Posts Tagged ‘rock64’

Linux 4.14 Release – Main Changes, ARM & MIPS Architecture

November 13th, 2017 6 comments

Linus Torvalds has announced the release of Linux 4.14:

No surprises this week, although it is probably worth pointing out how the 0day robot has been getting even better (it was very useful before, but Fengguang has been working on making it even better, and reporting the problems it has found).

Sure, some of the new reports turned out to be just 0day doing things that just don’t work (ie KASAN with old gcc versions, but also doing things like loading old ISA drivers in situations that just don’t make sense – remember when you couldn’t even ask if the hardware existed or not, and just had to know), but even then it’s been all good.

The appended shortlog is obviously only for the (small) haul since rc8, and it really is tiny. Not very many commits, and they are small. The biggest thing that stands out in the diffstat is the “leaking_addresses” perl script, which is actually under active development, but I put the first version in for 4.14 just so that people could see that initial state and start looking at the end result and perhaps ask themselves “should my code make these kernel addresses visible to user space”.

The actual changes will hopefully start percolating into 4.15, with one notable likely early change (which has been discussed extensively on the list) being to just hash any “%p” addresses by default. We used to have strict modes that just zeroed the address out, but that was actually counter-productive, in that often people use the address as a “kernel object identity” for debugging (or for cross-correlation -think network sockets), and so just clearing the pointer value makes those kinds of uses pointless. But using a secure hash allows for those kinds of identity uses, while not actually leaking the address itself.

(Other situations where the actual address is relevant then need other approaches – we’ll be restricting /proc/kallsyms only to entities that actually need them etc etc).

Anyway, apart from that one script, the rest of it really is one-liners or “few-liners”.

The most noticeable last-minute change is probably that we had to revert the code that showed a good MHz value in /proc/cpuinfo even for the modern “CPU picks frequency dynamically” case. It worked fine, but it was much too expensive on machines with tens or hundreds of CPU cores. There’s a cunning plan, but it didn’t make 4.14, so we’ll get it working and then back-port.

Anything else is pretty esoteric, you can just read the changelog..

And with this, the merge window for 4.15 is obviously open. As mentioned in the late rc announcements, the extra week for rc8 means that now Thanksgiving week ends up happening during the second half of the merge window, and I’ll be off on a family vacation.

We’ll see how that goes.

I might decide that I’ll extend the merge window if I feel that I can’t be responsive enough.

Or maybe you guys won’t even notice, because I _will_ have my laptop and Internet access.

Or maybe I will just decide that 4.14 was a painful release, and any late stragglers for 4.15 are not worth _another_ painful release, and I’ll just say “tough luck, you were late to the merge window, and I felt more like being out in the sun than taking your second-week pull request”.

Because it really would be lovely to have a smaller and calmer release for 4.15.

Anyway, go out and test the new 4.14 release, that is slated to be the next LTS kernel – and start sending me pull request for the 4.15 merge window.

Linux 4.13 brought us new features such as support for non-blocking buffered I/O operations at the block level, AppArmor security module’s “domain labeling” code, kernel-based TLS implementation for better performance, and CIFS/SAMBA default change to v3.0 for better security, among many other changes.

Some newsworthy changes in Linux 4.14 include:

  • Bigger memory limits – x86-64 used to be limited by 4-level paging to 256 TiB of virtual address space and 64 TiB of physical address space. Some vendors already reached the limit with servers equipped with 64 TiB of memory, so support for 5-level paging has been introduced, increasing the limits to 128 PiB of virtual address space and 4 PiB of physical address space.
  • Added AMD Secure Memory Encryption – Secure Memory Encryption can be used to protect the contents of DRAM from physical attacks on the system. Read LWN article or AMD whitepaper for details.
  • Better kernel traces with the ORC unwinder – An “unwinder” is what prints the list of functions (aka. stack trace, callgraph, call stack…) that have been executed before reaching a determinate point of the code. The new unwinder is called ORC (Oops Rewind Capability), works more reliably than the current unwinder, and does not require adding code anywhere, hence having not effect on text size or runtime performance
  • Compression in Btrfs and Squashfszstd compresses at speeds close to lz4 at compression ratio comparable to lzma. Support for zstd compression had been added to both Btrfs and Squash. See benchmarks in commit messages for Btrsfs and Squashfs.
  • Zero-copy from user memory to sockets – The MSG_ZEROCOPY socket flag enables zero copy mechanism to common socket send calls. It is generally only effective at writes over around 10 KB. Checkout the documentation for more details.

Linux 4.14 will be a long term support kernel with 6-year of support, so it will be found in devices for the years to come.

The ARM architecture has gone through many changes as per usual. Here’s a non-exhaustive list of changes:

  • Allwinner:
    • Allwinner A10s – HDMI DDC I2C Adapter,HDMI CEC support
    • Allwinner A10/A20 – CCU Clock-ng support
    • Allwinner A64 – SRAM controller driver
    • Allwinner A83T –  SD/MMC support, AXP813 PMIC,USB support
    • Allwinner H3 – I2S support
    • Allwinner R40 –  CCU sunxi-ng style clock driver support,pinctrl support
  • Rockchip
    • Clock driver – Fixes for RK3128, added RK3126 support within RK3128 driver
    • Pinctrl – Rockchip RK3128 subdriver
    • Power domains for Rockchip RK3366
    • New power key driver for Rockchip RK805 PMIC
    • PCI driver – Added Rockchip per-lane PHY support for better power management
    • SPI driver – Explicit support for Rockchip RV1108
    • DRM driver – Added dw_hdmi support for RK3399
    • Added ROCK64 board, RK3399 Sapphire module on Excavator carrier-board, and Theobroma Systems RK3399-Q7 SoM
    • Device tree changes:
      • pinctrl typos
      • keep-power-in-suspend in non-sdio nodes
      • removal of the deprecated num-slots property from dwmmc nodes.
      • RK3328 – support for spdif, io-domains and usb (including enablement of usb on the evaluation board)
      • RK3368 – support for spdif.
      • RK3399 – pcie changes, support for the mali gpu, a new power-domain, sdmmc support on the firefly board and dynamic-power-coefficients.
      • Removal of the deprectated num-slots property from all Rockchip dw-mmc nodes
      • RV1108 – support for sd-cards on the evaluation board
      • RK3288 – EVB gains support saradc and the adc-key, mali gpu enabled in some boards (fennec, evb, tinker).
      • RK3228/RK3229 – Support for efuse, sdmmc, sdio, io-domans and spdif; separate rk3229.dtsi;  The evaluation board also gets regulators, io-domains, emmc, tsadc keys
  • Amlogic
    • Clock driver – Added gxbb CEC32 and sd_emmc clocks, meson8b reset controller
    • SoC info driver – “Amlogic SoCs have a SoC information register for SoC type, package type and revision information. This patchs adds support for this register decoding and exposing with the SoC bus infrastructure”
    • Added Amlogic Meson AO CEC Controller driver
    • Device tree changes:
      • Updates for new MMC driver features/fixes, support for high-speed modes
      • Clock updates
      • Add GPIO line names to a few boards
      • Update clock controler for use as reset controller
  • Samsung
    • Clock driver – suspend fix for Samsung Exynos SoCs where we need to keep clks on across suspend
    • Samsung Exynos5420/5422/5800 audio fixes
    • S3C24xx platform – Cleanup from non-existent CONFIG entries, fix unmet NET dependency when H1940 bluetooth chip is selected
    • Pinctrl driver – Fix NULL pointer dereference on S3C24XX, fix invalid register offset used for external interrupts on Exynos5433, consolidate between drivers and bindings the defines for pin mux functions, minor code improvements
    • Samsung DTS ARM64 changes
      • Remove deprecated and unneeded properties from Exynos boards.
      • Implement proper (working) support for USB On-The-Go on Exynos5433 TM2/TM2E boards.
    • Samsung defconfig changes
      • Enable some drivers useful on our boards (communication: Bluetooth, WiFi, NFC, USB; codepages and crypto algorithms).
      • Enable debugging and lock testing options.
  • Qualcomm
    • IPQ8074 – Added SoC & HK01 board support, PCI driver
    • APQ8016 – Force USB host mode; jack detection support in ASoC
    • MSM8916 – Updated coresight nodes, added GPU, IOMMU, Venus video codec, and CEC clock nodes
    • MSM8996 – Add  support for USB, PCIE phy, RPM/GLink, and modem SMP2P; SMMU clks
    • Pinctrl driver – Qualcomm APQ8064 can handle general purpose clock muxing
    • NAND driver – Various fixes
    • Qualcomm GLINK SMEM driver – Fix memory leak, and unlock  on error
    • V4l – Update the Qualcomm Camera Subsystem driver document with a media controller pipeline graph diagram, VFE scale and crop modules support, and PIX interface and format conversion support.
    • Added DB820c PM8994 regulator node
    • Add PMI8994 gpios
    • Device tree changes:
      • Fixup XO, timer nodes, and pinctrl on IPQ4019
      • Add IPQ4019 RNG and wifi blocks
      • Update MSM8974 coresight node
      • Add IPQ8074 bindings
  • Mediatek
    • Pinctrl driver – Mediatek MT7623 PCIe mux data fixed up.
    • PCI Driver – Added MediaTek MT2712 and MT7622 support
    • Thermal driver – Added Mediatek thermal driver for mt2712
    • Added support for MediaTek MT2712 SoC and avaluation board
    • New board – Mediatek mt7623-based Banana Pi R2
  • Other new ARM hardware platforms and SoCs:
    • Broadcom – Stingray communication processor, Raspberry Pi Zero W
    • Marvell – ARMADA 8080 SoC
    • Microchip/Atmel – SAMA5D28 SoM1 EK
    • NXP – Toradex Apalis module + Apalis and Ixora carrier boards, Engicam GEAM6UL Starter Kit, Beckhoff CX9020 Embedded PC (i.MX53)
    • Renesas – R-Car D3 board (R8A77995)
    • Storlink/Cortina –
    • Texas Instruments – TI DT76x, TI AM335x Moxa UC-8100-ME-T open platform, TI AM57xx Beaglebone X15 Rev C
    • Uniphier – PXs3 STB SoC and development board
    • ZTE – ZX296718 PCBOX Board

MIPS had a huge changelog this time, summarized below:

  • CM – Rename mips_cm_base to mips_gcr_base; Specify register size when generating accessors; Use BIT/GENMASK for register fields, order & drop shifts; Add cluster & block args to mips_cm_lock_other()
  • CPC – Use common CPS accessor generation macros; Use BIT/GENMASK for register fields, order & drop shifts; Introduce register modify (set/clear/change) ; Use change_*, set_* & clear_* where appropriate, etc…
  • CPS – Read GIC_VL_IDENT directly, not via irqchip driver
  • DMA – Consolidate coherent and non-coherent dma_alloc code, Don’t use dma_cache_sync to implement fd_cacheflush
  • FPU emulation / FP assist code – Corner cases fixes such as NaN propagation and other special input values; Zero bits 32-63 of the result for a CLASS.D instruction; enhanced statics via debugfs; do not use bools for arithmetic. GCC 7.1 moans about this; correct user fault_addr type
  • Generic MIPS
    • Enhancement of stack backtraces
    • Cleanup from non-existing options
    • Handle non word sized instructions when examining frame
    • Fix detection and decoding of ADDIUSP instruction
    • Fix decoding of SWSP16 instruction
    • Refactor handling of stack pointer in get_frame_info
    • Remove unreachable code from force_fcr31_sig()
    • Many more fixes and cleanups
  • GIC – Introduce asm/mips-gic.h with accessor functions; Use new GIC accessor functions in mips-gic-timer; Remove counter access functions from irq-mips-gic.c; Remove gic_read_local_vp_id() from irq-mips-gic.c, etc…
  • microMIPS – Fix microMIPS stack unwinding on big endian systems
  • MIPS-GIC – SYNC after enabling GIC region
  • NUMA – Remove the unused parent_node() macro
  • R6 – Constify r2_decoder_tables; add accessor & bit definitions for GlobalNumber
  • SMP – Constify smp ops, allow boot_secondary SMP op to return errors
  • VDSO – Drop gic_get_usm_range() usage, avoid use of linux/irqchip/mips-gic.h
  • Platform changes
    • Alchemy – Add devboard machine type to cpuinfo, update cpu feature overrides,threaded carddetect irqs for devboards
    • AR7 – allow NULL clock for clk_get_rate
    • BCM63xx – Fix ENETDMA_6345_MAXBURST_REG offset, allow NULL clock for clk_get_rate
    • CI20 – Enable GPIO and RTC drivers in defconfig; add ethernet and fixed-regulator nodes to DTS
    • Generic platform
      • Move Boston and NI 169445 FIT image source to their own files
      • Include asm/bootinfo.h for plat_fdt_relocated()
      • Include asm/time.h for get_c0_*_int()
      • Include asm/bootinfo.h for plat_fdt_relocated()
      • Include asm/time.h for get_c0_*_int()
      • Allow filtering enabled boards by requirements
      • Don’t explicitly disable CONFIG_USB_SUPPORT
      • Bump default NR_CPUS to 16
    • JZ4700 – Probe the jz4740-rtc driver from devicetree
    • Lantiq – Drop check of boot select from the spi-falcon and lantiq-flash MTD drivers, access boot cause register in the watchdog driver through regmap, add device tree binding documentation for the watchdog driver, add docs for the RCU DT bindings, etc…
    • Loongson 2F – Allow NULL clock for clk_get_rate
    • Malta – Use new GIC accessor functions
    • NI 169445 – Add support for NI 169445 board; only include in 32r2el kernels
    • Octeon – Add support for watchdog of 78XX SOCs, add support for watchdog of CN68XX SOCs, expose support for mips32r1, mips32r2 and mips64r1, enable more drivers in config file, etc…
    • Omega2+ – New board, add support and defconfig
    • Pistachio – Enable Root FS on NFS in defconfig
    • Mediatek/Ralink – Add Mediatek MT7628A SoC, allow NULL clock for clk_get_rate, explicitly request exclusive reset control in the pci-mt7620 PCI driver.
    • SEAD3 – Only include in 32 bit kernels by default
    • VoCore board – Add VoCore as a vendor t0 dt-bindings, add defconfig file

For the complete details, you could check out the full Linux 4.14 changelog – with comments only – generated using git log v4.13..v4.14 --stat, or – kinder to your eyes – read kernelnewsbies’s Linux 4.14 changelog.

ROCK64 Board Review – Part 2: Quick Start Guide with Ubuntu 16.04.3 MATE, Multimedia Features, Some Benchmarks

August 7th, 2017 15 comments

Pine64 ROCK64 is the first maker board based on Rockchip RK3328 processor, and is potentially interesting for various applications including network storage thanks to USB 3.0 and Gigabit Ethernet, multimedia applications with 4K HDR video support, as well as other applications requiring I/Os. I’ve already tested Rock64 board with Android 7.1 operating system, so today I’ll report by finding and experience with Ubuntu 16.04.3 with MATE desktop.

Selecting and Flashing a Linux Image

You’ll find several operating systems in the Wiki, but you’ll also find more cutting edge images in ayufan’s github. But first let me explain some vocabulary used for Pine64 firmware files:

  1. Engineering version – Becomes with release build based on the stock build develop by Pine64 and the SoC vendor. It’s supposed to be more stable, but get less updates
  2. Community versions (currently managed via ayufan) are more frequently updates, and comes with more recent features. You’ll find two categories
    1. Release builds – The current stable version released by the community
    2. Pre-release builds – Version under test to eventually become the release build

Currently, documentation is still work in progress for the board, so I spent some time on IRC #Rock64 chatting with the helpful community there, and I noticed most of them used the community builds. I’ve also been told there has not been that much work on the Desktop version right now, with most people focusing on NAS support with images such as Debian + OpenMediaVault. But since I wanted to test a desktop image I was recommended the Ubuntu Mate image, and download the pre-release 64-bit version: xenial-mate-rock64-0.4.17-85-arm64.img.xz.

If you’ve read the WIki, you’ll notice all those are “micro SD” images, so since I had a eMMC flash module, I was a little confused at the beginning, but since I have Hardkernel’s micro SD to  eMMC flash module adapter, installation was just the same as on a micro SD card with Etcher.

Top to Bottom: ROCK64’s 16GB eMMC flash Module, Hardkernel adapter, and micro SD card reader

But Pine64 does not sell such adapter, so how are you supposed to do with you bought an eMMC flash module? I’ve been explained you first need to flash a micro SD card with the image, and then interrupt the boot in u-boot (USB to TTL debug board required), remove the eMMC jumper, and continue the boot by typing “boot”. This has be to be done, or you won’t see the eMMC flash module, while booting from a micro SD card.

Now you can download, and flash the firmware to the eMMC flash module with curl:

Not the most user-friendly method, but it should work. If you don’t have a USB to TTL board, first you should really buy one, but for this specific case, you could remove the eMMC jumper about two seconds after applying power. In that case, your mileage may vary though… Pine64 is working on an easier method of installation to the eMMC flash module.

Rock64’s Ubuntu 16.04.3 MATE Boot, System Info, and Initial Setup

Since I want to get the boot log, I connected the USB to TTL board. There’s no dedicated UART connected on the board, so I download the GPIO pinout charts for Pi 2 Bus and Pi 5+ Bus from the Wiki, amd we’ll use it to test GPIOs later on.

Pi 2 Bus – Click to Enlarge


Pi 5+ Bus – Click to Enlarge

UART Tx and Rx can be found on respectively pin 8 and 10 of Pi 2 Bus header, so I connect the debug board accordingly, together with USB keyboard and mouse, a USB harddrive, Ethernet and HDMI cables.

Click to Enlarge

Finally I put the micro SD card into the board, applied powered, and after a few seconds, I got to the Ubuntu MATE desktop. however, I only got ribberish in the serial console, which was set to 115,200 8N1, the most common settings “in the universive”. There’s currently no info about serial console setting in the Wiki, but a web search lead me to the right settings: 1,500,000 8N1, which apparently is the default in Rockchip SDK.

This high bitrate may cause troubles with some serial adapter, but after changing minicom settings accordingly, I had no trouble with the serial console. That’s the complete boot log after a reboot:

We can now login with rock64/rock64 credentials in the desktop or the serial console:

I checkout some infor about CPU, storage, memory usage, and Linux & Ubuntu versions:

I have the 1GB version of the board, and the firmware is based on the latest Ubuntu 16.04.3 LTS release with a fairly recent Linux 4.4.70 kernel. However, we can see that with just 4.8GB capacity the rootfs partition has not been automatically resized during the first boot. So let’s run the relevant script, and check again:

All good, as we now have a 14GB rootfs partition. It’s worth noting the other scripts in /usr/local/sbin too:

Modules and GPIOs on Rock64

The next step was to check pre-loaded modules and GPIOs:

Only uas and usb_storage modules are loaded, which shows people are truly focusing on the NAS part right now, or some other drivers are directly built-into the kernel. GPIOs need to be exported manually, and a quick search lead me to that forum post (again no info in the Wiki right now).

You need to convert the gpio pin name as shown in the pinout diagram (e.g. GPIO3_A5) into a raw number using a formula combining bank number (3), pad name (A) and pad number (5). marcushh777, who is also a helpful member on IRC, wrote a Python script to do just that, and you may want to create that script in /usr/local/sbin/

The file is also on Github so you could use wget or curl instead:

We can now run the script with the GPIO we want to use…

… switch to root, then use sysfs to export the gpio number and set the direction, and switch the GPIO to high and low levels:

I connected a 5V LED to GPIO3_A5 pin via a transistor and could turn it on and off with the last two commands above.

Eventually, a PDF document will be uploaded to the Wiki, but it does not appear to be ready yet. I was unable to find info to use I2C or SPI at this stage.

GPU (OpenGL ES) and VPU (Video Decoding) Testing

GPU and VPU support are often problems in Linux on ARM, and while I had low expectation, I still tried those by installing the usual OpenGL ES demo to test Mali GPU support:

I ran es2info first, and Mali-450MP GPU support is indeed enabled:

That command ended in a segfault however. Not too reassuring.

So I ran es2gears demo, but could not take a screenshot, as all screenshots were black with only the mouse pointer showing up, so instead I some photos, and it works, but the transparent window is unlikely to be normal.

Performance does not appear to be optimal right now however with just around 35 fps.
glmark2-es2 demo started well too…

Click to Enlarge

… but some features are not supported (maybe normal), and it crashed at the end as shown in full log below:

The results are actually better than I expected, but there’s still some work.

I tried to play 1080p60 H.264 Big Buck Bunny video with VideoLAN (VLC) first, and all I got was the first frame with changing artifacts around the bufferfly, and I had somewhat better luck in SMPlayer with the video playing almost smoothly in windowed mode, and some saturated and accelerated audio. Switching to full screen mode would just show a black screen, until I was asked to signing again a few seconds later…

So video playback is basically unusable at this stage in the Ubuntu MATE image, and you’d better go with Android, or potentially LibreELEC currently released as alpha for ROCK64 board.  LongChair also told me in IRC that “we have ffmpeg / mpv working on rock64 … we need to do more testing and get a few bugs fixed by rockchip before I finally upstream that to ffmpeg / mpv”, so video support is definitely coming. It’s just not ready yet. Another person informed me that contrary to Amlogic, Rockchip does not use AFBC (ARM Frame Buffer Compression) natively, and the memory bandwidth is critical, 4K H.265 HDR videos may not always play that well in RK3328. I’ve been told it may take one to two more months for 4K support in Linux, and that 1080p is now supported but not released just yet in the Ubuntu image.

Storage and Networking Benchmarks

I’ll skip the Phoronix benchmarks in this review, as we’ve had so many ARM Cortex A53 platform the results won’t be much better, unless there’s a bug, which would eventually be fixed. Instead, I’ll focus on storage and network performance on Rock64, since it may vary between boards.

Those are the results for the 16GB eMMC flash module:

Up to ~115 MB/s read speed, and ~69 MB/s write speed, and good random I/O too. For reference, Ubuntu boots in 17 seconds from power on to the login screen.

I then tried to create the iozone test on the NTFS partition of my hardware, but it failed because NTFS is read-only.

That can happen because of file system error, or because the image using the NTFS kernel module that provides read-only access only. So I installed ntfs-3g instead:

and remounted the drive inside the file manager in the desktop.

You can see the type is now “fuseblk” instead of “ntfs” – meaning the userspace ntfs-3g driver is used – , and the partition mounted as read/write.  So I could run iozone on the NTFS partition:

Something is clearly wrong with the read speed: up 271 MB/S is not right, as it’s much higher than what my USB drive is capable of (~115 MB/s) on my main PC. That means caching must be involved here, so I’ve increased the file size to 500 MB in the test:

and the results are much more realistic, except for the random read with 16384 reclen. It shows up to 119 MB/s reads, and up to 92 MB/s writes, which means everything is working as expected. So I repeated the test with the EXT-4 partition:

The results are a bit lower at 96 MB/s read and 94 MB/s write, but still pretty good for a mechanical drive over USB 3.0.  It should be noted that performance decreases the closer you are from the center of the drive. The NTFS partition in the first quarter, and the EXT-4 in the second quarter of the drive, and I got 108 MB/s with the first partition (NTFS) and 96 MB/s with the second partition (EXT-4) using “Disks” utility in Ubuntu when I first bought the drive. Other people have reached close to 400 MB/s with SSDs over the USB 3.0 port of ROCK64 board, but for most people getting to around 100 MB/s should be enough for their data.

Finally I tested Gigabit Ethernet by doing the usual full duplex test with iperf:

That’s OK, but not overwhelming, maybe it will improve with a more recent kernel as with some other platforms. I also did a download-only test with iperf3, and it could do so at around 933 Mbps:

No problem here with very good performance.

Pine64 has started to ship the first batch of board, so there will soon be more feedback from users. From my experience with Linux, you should be good to go if you want to build a NAS for example with their Debian OpenMediaVault image with good performance for Ethernet and USB 3.0, and use GPIOs with sysfs. If your project requires I2C & SPI drivers you may want to wait, and for multimedia use in Linux, 1080p support should be mostly ready, but 4K videos support may need a few more weeks or months, and good OpenGL ES performance may take more time too. Documentation is also work in progress right now, as I had search quite a bit to find how to use various features of the board like the serial console and GPIOs, but you can help from the forums, and #Rock64 IRC channel (if you are using an IRC client, disable SSL). I’m expecting things to improve over time as more people get their hands on the boards.

You can purchase ROCK64 board with 1, 2 or 4 GB RAM for $25 and up, as well as accessories directly on Pine64 website. The second batch of board is scheduled to ship on August 30th.