Archive

Posts Tagged ‘nanopi’

Linux 4.13 Release – Main Changes, ARM & MIPS Architectures

September 4th, 2017 6 comments

Linus Torvalds has just announced the release of Linux 4.13 and a kidney stone…:

So last week was actually somewhat eventful, but not enough to push me to delay 4.13.

Most of the changes since rc7 are actually networking fixes, the bulk of them to various drivers. With apologies to the authors of said patches, they don’t look all that interesting (which is definitely exactly what you want just before a release). Details in the appended shortlog.

Note that the shortlog below is obviously only since rc7 – the _full_4.13 log is much too big to post and nobody sane would read it. So if you’re interested in all the rest of it, get the git tree and limit the logs to the files you are interested in if you crave details.

No, the excitement was largely in the mmu notification layer, where we had a fairly last-minute regression and some discussion about the problem. Lots of kudos to Jérôme Glisse for jumping on it, and implementing the fix.

What’s nice to see is that the regression pointed out a nasty and not very well documented (or thought out) part of the mmu notifiers, and the fix not only fixed the problem, but did so by cleaning up and documenting what the right behavior should be, and furthermore did so by getting rid of the problematic notifier and actually removing almost two hundred lines in the process.

I love seeing those kinds of fixes. Better, smaller, code.

The other excitement this week was purely personal, consisting of seven hours of pure agony due to a kidney stone. I’m all good, but it sure _felt_ a lot longer than seven hours, and I don’t even want to imagine what it is for people that have had the experience drag out for longer. Ugh.

Anyway, on to actual 4.13 issues.

While we’ve had lots of changes all over (4.13 was not particularly big, but even a “solidly average” release is not exactly small), one very _small_ change merits some extra attention, because it’s one of those very rare changes where we change behavior due to security issues, and where people may need to be aware of that behavior change when upgrading.

This time it’s not really a kernel security issue, but a generic protocol security issue.

The change in question is simply changing the default cifs behavior: instead of defaulting to SMB 1.0 (which you really should not use: just google for “stop using SMB1” or similar), the default cifs mount now defaults to a rather more modern SMB 3.0.

Now, because you shouldn’t have been using SMB1 anyway, this shouldn’t affect anybody. But guess what? It almost certainly does affect some people, because they blithely continued using SMB1 without really thinking about it.

And you certainly _can_ continue to use SMB1, but due to the default change, now you need to be *aware* of it. You may need to add an explicit “vers=1.0” to your mount options in /etc/fstab or similar if you *really* want SMB1.

But if the new default of 3.0 doesn’t work (because you still use a pterodactyl as a windshield wiper), before you go all the way back to the bad old days and use that “vers=1.0”, you might want to try “vers=2.1”. Because let’s face it, SMB1 is just bad, bad, bad.

Anyway, most people won’t notice at all. And the ones that do notice can check their current situation (just look at the output of “mount” and see if you have any cifs things there), and you really should update from the default even if you are *not* upgrading kernels.

Ok, enough about that. It was literally a two-liner change top defaults – out of the million or so lines of the full 4.13 patch changing real code.

Go get the new kernel,

Linus

Two months ago, Linux 4.12 was released with initial support for AMD Radeon RX Vega GPU, BFQ (Budget Fair Queuing) and Kyber block I/O schedulers, AnalyzeBoot tool for the kernel, “hybrid consistency model” implementation for live kernel patching, but disabled the Open Sound System, and removed AVR32 support, among many other changes.

Some interesting changes in Linux 4.13 – mostly based on LWN 4.13 Merge Window part 1 & part 2 – include:

  • Support for non-blocking buffered I/O operations added at the block level, which should also improve asynchronous I/O support when used with buffered I/O.
  • AppArmor security module’s “domain labeling” code has been merged into the mainline. It was maintained by Ubuntu out of tree previously.
  • Kernel-based TLS implementation that should deliver better performance for HTTPS, and other protocol relying on TLS.
  • CIFS/SAMBA now defaults to v3.0 instead of v1.0 due to security issues
  • File System Changes – EXT-4: support for to ~2 billion files per directory with largedir option, extended attributes up to 64KB, new deduplication feature; f2fs: supports disk quotas; overlayfs union: new “index directory” feature that makes copy-up operations work without breaking hard links.

Changes specific to ARM include:

  • Rockchip:
    • Added support for RV1108 SoC for camera applications
    • Rockchip IOMMU driver is now available on ARM64
    • PCIe – configure Rockchip MPS and reorganize + use normal register bank
    • Clock driver for Rockchip RK3128 SoC
    • Rockchip pinctrl driver now supports iomux-route switching for RK3228, RK3328 and RK3399
    • Sound driver – Support for Rockchip PDM controllers
    • Device tree
      • Added RK3399-Firefly SBC
      • Added ARM Mali GPU
      • Added cru
      • Added sdmmc, sdio, emmc nodes for Rockchip RK3328
  • Amlogic
    • Updated CEC EE clock support
    • Enabled clock controller for 32-bit Meson8
    • Device tree changes
      • Meson UARTs
      • new SPI controller driver
      • HDMI & CVBS for multiple boards
      • new pinctrl pins for SPI, HDMI CEC, PWM
      • Ethernet Link and Activity LEDs pin nodes
      • SAR ADC support for Meson8 & Meson8b
    • Defconfig changes – Meson SPICC enabled as module; IR core, decoders and Meson IR device enabled;
    • New boards & devices: NanoPi K2, Libre Computer SBC, R-Box Pro
  • Samsung
    • Clock driver updated for Samsung Exynos 5420 audio clocks, and converted code to clk_hw registration APIs
    • Pinctrl drivers split per ARMv7 and ARMv8 since there’s no need to compile everything on each of them
    • ARM DT updates:
      • Add HDMI CEC to Exynos5 SoCs + needed property for CEC on Odroid U3
      • Fix reset GPIO polarity on Rinato
      • Minor cleanups and readability improvements.
    • ARM64 DT updates:
      • Remove unneeded TE interrupt gpio property
    • Defconfig changes – Some cleanups, enabled Exynos PRNG along with user-space crypto API.
  • Qualcomm
    • Clock & pinctrl drivers for Qualcomm IPQ8074
    • Add debug UART addresses for IPQ4019
    • Improve QCOM SMSM error handling
    • Defconfig
      • Enable HWSPINLOCK & RPMSG_QCOM_SMD to get some Qualcomm boards to work out of the box/again
      • Enable IPQ4019 clock and pinctrl
    • Mailbox – New controller driver for Qualcomm’s APCS IPC
    • RPMsg – Qualcomm GLINK protocol driver and DeviceTree-based modalias support, as well as a number of smaller fixes
    • Qualcomm Device Tree Changes
      • Fix IPQ4019 i2c0 node
      •  Add GSBI7 on IPQ8064
      • Add misc APQ8060 devices
      • Fixup USB related devices on APQ8064 and MSM8974
    • Qualcomm ARM64 Updates for v4.12
      • Fix APQ8016 SBC WLAN LED
      • Add MSM8996 CPU node
      • Add MSM8992 SMEM and fixed regulator
      • Fixup MSM8916 USB support
  • Mediatek
    • CPU clks for Mediatek MT8173/MT2701/MT7623 SoCs
    • Pinctrl – Serious code size cut for MT7623
    • Mediatek “scpsys” system controller support for MT6797
    • Device tree
      • Added support for MT6797 (Helio X20) mobile SoC and evaluation board
      • Extended MT7623 support significantly
      • Added MT2701 i2c device & JPEG decoder nodes
  • Other new ARM hardware platforms and SoCs:
    • STM32 – stm32h743-disco, stm32f746-disco, and stm32f769-disco boards; Drivers for digital audio interfaces, S/PDIF receiver, digital camera interfaces, HDMI CEC, watchdog timer
    • NXP – Gateworks Ventana GW5600 SBC;  Technexion Pico i.MX7D board; i.MX5/6 image processing units & camera sensor interfaces
    • Realtek – Initial support for Realtek RTD1295 SoC and Zidoo X9S set-top-box
    • Actions Semi – Initial support for Actions Semi S900 / S500, and corresponding LeMaker Guitar & Bubblegum-96 SBCs
    • Renesas – Salvator-XS and H3ULCB automotive development systems; GR-Peach board, iWave G20D-Q7 System-on-Module plus
    • Socionext- Support for Uniphier board support for LD11-global and LD20-global
    • Broadcom – Stingray communication processor and two reference boards;
    • Marvell – Linksys WRT3200ACM router
    • Texas Instruments – BeagleBone Blue
    • Microchip / Atmel – MMU-less ARM Cortex-M7 SoCs (SAME70/V71/S70/V70)

Some of the changes specific to MIPS include:

  • Boston platform support – Document DT bindings; Add CLK driver for board clocks
  • CM – Avoid per-core locking with CM3 & higher; WARN on attempt to lock invalid VP, not BUG
  • CPS – Select CONFIG_SYS_SUPPORTS_SCHED_SMT for MIPSr6; Prevent multi-core with dcache aliasing; Handle cores not powering down more gracefully; Handle spurious VP starts more gracefully
  • DSP – Add lwx & lhx missaligned access support
  • eBPF – Add MIPS support along with many supporting change to add the required infrastructure
  • Generic arch code:
    • Misc sysmips MIPS_ATOMIC_SET fixes
    • Drop duplicate HAVE_SYSCALL_TRACEPOINTS
    • Negate error syscall return in trace
    • Correct forced syscall errors
    • Traced negative syscalls should return -ENOSYS
    • Allow samples/bpf/tracex5 to access syscall arguments for sane
      traces
    • Cleanup from old Kconfig options in defconfigs
    • Fix PREF instruction usage by memcpy for MIPS R6
    • Fix various special cases in the FPU eulation
    • Fix some special cases in MIPS16e2 support
    • Fix MIPS I ISA /proc/cpuinfo reporting
    • Sort MIPS Kconfig alphabetically
    • Fix minimum alignment requirement of IRQ stack as required by ABI / GCC
    • Fix special cases in the module loader
    • Perform post-DMA cache flushes on systems with MAARs
    • Probe the I6500 CPU
    • Cleanup cmpxchg and add support for 1 and 2 byte operations
    • Use queued read/write locks (qrwlock)
    • Use queued spinlocks (qspinlock)
    • Add CPU shared FTLB feature detection
    • Handle tlbex-tlbp race condition
    • Allow storing pgd in C0_CONTEXT for MIPSr6
    • Use current_cpu_type() in m4kc_tlbp_war()
    • Support Boston in the generic kernel
  • Generic platform:
    • yamon-dt: Pull YAMON DT shim code out of SEAD-3 board;  Support > 256MB of RAM;  Use serial* rather than uart* aliases
    • Abstract FDT fixup application
    • Set RTC_ALWAYS_BCD to 0
    • Add a MAINTAINERS entry
  • core kernel – qspinlock.c: include linux/prefetch.h
  • Add support for Loongson 3
  • Perf – Add I6500 support
  • SEAD-3 – Remove GIC timer from DT; set interrupt-parent per-device, not at root node; fix GIC interrupt specifiers
  • SMP – Skip IPI setup if we only have a single CPU
  • VDSO – Make comment match reality; improvements to time code in VDSO”
  • Various fixes:
    • compressed boot: Ignore a generated .c file
    • VDSO: Fix a register clobber list
    • DECstation: Fix an int-handler.S CPU_DADDI_WORKAROUNDS regression
    • Octeon: Fix recent cleanups that cleaned away a bit too much thus breaking the arch side of the EDAC and USB drivers.
    • uasm: Fix duplicate const in “const struct foo const bar[]” which GCC 7.1 no longer accepts.
    • Fix race on setting and getting cpu_online_mask
    • Fix preemption issue. To do so cleanly introduce macro to get the size of L3 cache line.
    • Revert include cleanup that sometimes results in build error
    • MicroMIPS uses bit 0 of the PC to indicate microMIPS mode. Make sure this bit is set for kernel entry as well.
    • Prevent configuring the kernel for both microMIPS and MT. There are no such CPUs currently and thus the combination is unsupported and results in build errors.
    • ralink: mt7620: Add missing header

You can read the full Linux 4.13 changelog – with comments only – generated using git log v4.12..v4.13 --stat for the full details, and eventually kernelnewsbies’s Linux 4.13 changelog will be updated with an extensive list of chances.

$8 NanoPi Duo is a Tiny Breadboard Compatible Linux Board powered by Allwinner H2+ Quad Core SoC

August 29th, 2017 34 comments

It’s very easy to find breadboard compatible boards in the market with products based on Espressif chips such as NodeMCU or ESP32 boards, as well as OpenWrt board like Onion Omega2, or LinktIt 7688. However, it’s much more difficult to find powerful quad core boards in this form factor, but that’s exactly what FriendlyELEC has done with their NanoPi Duo board featuring an Allwinner H2+ quad core processor in a form factor slightly smaller than a Raspberry Pi Zero.

NanoPi Duo specifications:

  • SoC – Allwinner H2+ quad core Cortex A7 processor @ 1.2 GHz with Mali-400MP2 GPU @ 600 MHz
  • System Memory – 256 or 512 MB DDR3-1866 SDRAM
  • Storage – micro SD card slot, footprint for SPI flash
  • Connectivity – 802.11 b/g/n WiFi (Allwinner XR819 module) with chip antenna, and u.FL/IPEX connector for external antenna
  • USB – 1x micro USB OTG port
  • Expansion headers – 2x 16-pin breadboard compatible headers with 2x USB host ports, GPIO, UART, SPI, I2C, MIC, Line Out, CVBS (composite video), Ethernet, 5V, 3.3V, and GND
  • Misc – 1x key
  • Power Supply – 5V via micro USB port
  • Dimensions – 50 x 25.4 mm
  • Weight – 7.76 grams with headers
  • Temperature Range – -40°C to +80°C

An optional heatsink covering most of the board has also being designed in order to deliver optimal performance under load.

The company provides an image based on U-boot, Linux 4.11.2, and Ubuntu 16.04.2 Xenial for the board, which you can find in the Wiki, together with the rest of the software and hardware documentation including schematics (PDF) and mechanical design files.

NanoPi Duo Connected to Mini Shield

In order to experiment the I/Os on the board, FriendleELEC also provides what they call “NanoPi Duo mini Shield” exposing the following interfaces:

  • Storage – Half-size mSATA slot via JMS567 USB to SATA controller
  • Connectivity – 1x 10/100M Ethernet port
  • USB – 4x USB host port
  • Audio – Built-in microphone, and 3.5mm audio jack
  • Debugging – 4-pin connector for serial console
  • Expansion – 2x 9-pin GPIO header with I2C, SPI, UART, and GPIO; 6-pin SPI header
  • Misc – SSD and Power LEDs
  • Power Supply – 5V via micro USB port
  • Dimensions – 85 x 56 mm (Compatible with Raspberry Pi 3 cases)

Documentation for the mini shield is located in a separate wiki page.

NanoPi Duo sells for $7.99 with 256MB RAM, $11.99 with 512MB, plus shipping. You may consider adding the $2.99 option for the heatsink, and while you can also add the mini shield for $9.98, the “NanoPi Duo Starter Kit” may be a better option as it goes for $17.98 with all accessories you may need for a complete system.

Thanks to theguyuk for the tip.

NanoPi K2 Board Gets Ubuntu Core Firmware Image

July 19th, 2017 3 comments

FriendlyELEC NanoPi K2 is a board powered by Amlogic S905 processor, just like ODROID-C2 board, so while only the Android image was available at launch, it was expected to also support Ubuntu or other Linux distribution shortly after. This was put in doubt by comments on the company’s forums claiming the board would not get Debian images, and only Android was supported.

One alternative would be Armbian, but right now they only have ODROID-C2 images for download, no other Amlogic S905 hardware platform is supported either through stable or experimental builds. One user did manage to run Armbian on K2 with balbes150 help, but I’m not sure what’s the status of those firmware. Balbes150 also have a list of image for Amlogic platform in Github, which may be adapted to most hardware by using your board’s device tree binary (DTB) file.

The good news today is that FriendyELEC did not give up on Linux support for the board, as they’ve just released Ubuntu Core with Qt Embedded for NanoPi K2 (s905-ubuntu-core-qte-arm64-sd4g-20170718.img.zip), which you’ll find on mediafire with some changelog (currently in Chinese only) in the Wiki with translates to:

NanoPi-K2 Ubuntu Core system, including Qt-Embedded graphical interface library, the system features are as follows:

Supports HDMI output
Support WiFi connection
Supports Gigabit Ethernet
Support for Bluetooth transmission
Built-in Qt-Embedded

Thanks to the powerful performance of the A53 architecture processor, 2GB memory and Gigabit Ethernet, the NanoPi-K2 is ideal for use as an IoT server or DIY lightweight servers such as Nas.

That probably means they’ve not worked on 3D GPU acceleration, nor hardware video decoding support, or this would be proudly listed in the changelog… So if you’re interested in media playback in Linux this won’t be an option, and LibreELEC should work without too many modifications, maybe with just the right DTB file.

Thanks to boudyka for the tip.

ModBerry Industrial Automation Controllers Leverage Raspberry Pi, FriendlyELEC, and AAEON Boards and Modules

July 19th, 2017 1 comment

TECHBASE’s ModBerry Linux based industrial controllers have been around since 2014 with their first model being ModBerry 500 powered by a Raspberry Pi compute module. Over the years, the company has kept adding new ModBerry controllers with now an interesting choice of Raspberry Pi 3 board or compute module, FriendlyELEC’s NanoPi M1 Plus board, or Intel Atom x5 based AAEON’s UP board.

Click to Enlarge

All programmable automation controllers (PAC) runs Linux 4.0 or greater, with Debian or Ubuntu Core rootfs including ready tools and pre-compiled packs including C/C++, JAVA, SQL, PHP, SSH, and VPN support. The firmware is upgradeable over the air, and the controllers can run the company’s iMod control software and interface with iModCloud cloud computing service for telemetry, remote control and data sharing. Typical uses include C-L-V functions with conversion to collect and transmit data over communication interfaces, logging via iModCloud or a SCADA, and visualization via a web browser.

Click to Enlarge

All models share many of the same features, with some models having more I/Os beside the different board, but to get a better idea of the systems, I’ll have a look at ModBerry M700 specifications:

  • SoC – Allwinner H3 quad core Cortex A7 @ 1.2 GHz with an ARM Mali-400MP2 GPU
  • System Memory – 1GB DDR3
  • Storage – 8GB eMMC flash + micro SD card slot
  • Video & Audio Output – HDMI 1.4 and 3.5mm jack for CVBS (composite + stereo audio)
  • Connectivity

    ModBerry M700 – Click to Enlarge

    • Gigabit Ethernet
    • 802.11 b/g/n WiFi and Bluetooth 4.0 LE
    • Optional Zigbee, LTE/3G, GPS, WiFi, and Bluetooth cards
  • USB – 2x USB 2.0 host ports, 1x 4-pin USB 2.0 host header, 1x micro USB port (OTG/power)
  • Expansion I/Os
    • 4x digital inputs, 4x digital outputs up to 30V DC
    • 1x RS-232/RS-485
    • 1x PCIe slot
    • Optional 1-wire
    • Optional ExCard I/O modules for more RS-232/485 ports, Ethernet ports, PCIe slots, analog input and output, digital I/Os, relays, M-Bus interface, and more
  • Misc – RTC with battery, watchdog timer,
  • Power Supply – 7~30V DC up to 20-35W
  • Dimensions – 106 x 91 x 61 mm (ABS casing with DIN railin enclosure)
  • Weight – 300 grams
  • Operating Conditions – Temperature: -30 ~ 80°C; humidity: 5 ~ 95% RH (non-condensing)

The ExCard are DIN rail module that plugs into the ModBerry like LEGO’s, and up to 3 ExCard is supported per ModBerry.

Click to Enlarge

Applications for such systems include PLC, telemetry module with data logger, serial port server, protocol and interface converter, programmable controller, MODBUS Gateway/Router, SNMP Agent, Web server with PHP and SQL database support, SMS Gateway, LTE/3G/GPRS router and more.

TECHBase has not released pricing for the controllers, but you can find more details, including detailed PDF product briefs and links to purchase the controllers and expansions (you’ll still have to ask for the price), on the products page.

Via LinuxGizmos

NetBSD is Now Running on Allwinner H3 Boards

July 11th, 2017 7 comments

Most people will run Linux kernel on development boards because it does the job, and that’s usually the only option. But others have been working on NetBSD kernel for Allwinner H3 boards, and it’s now running on various H3 boards with serial console, USB, Ethernet, SD card, and eMMC flash working.


Jared McNeill explains they first had to deal with low-level code to initialize the CPU and MMU, before using a U-boot layer to disguise NetBSD as the Linux kernel in order to load kernel and device tree file. The code then jumps to the generic ARM FDT implementation of initarm to relocate DTB data and perform other steps, and finally they can enumerated devices. This is explained in greater details in the aforelinked blog post on NetBSD website.

Jared tested the implementation on NanoPi NEO and Orange Pi Plus 2E, but others have reported success on various hardware based on Allwinner H3 processor. Other ARM development boards have been supported since 2015 by NetBSD 7.0 and greater with Raspberry Pi 2, ODROID-C2, BegleBone Black. Allwinner A20/A31, and others, but the work done on Allwinner H3 is different, as it’s the first implementation to use device tree, and eventually it should be possible to ship a single GENERIC evbarm kernel for all boards.

Thanks to Geokon for the tip.

Linux 4.12 Release – Main Changes, ARM & MIPS Architectures

July 3rd, 2017 6 comments

Linus Torvalds has just released Linux 4.12:

Things were quite calm this week, so I really didn’t have any real reason to delay the 4.12 release.

As mentioned over the various rc announcements, 4.12 is one of the bigger releases historically, and I think only 4.9 ends up having had more commits. And 4.9 was big at least partly because Greg announced it was an LTS kernel. But 4.12 is just plain big.

There’s also nothing particularly odd going on in the tree – it’s all just normal development, just more of it that usual. The shortlog below is obviously just the minor changes since rc7 – the whole 4.12 shortlog is much too large to post.

In the diff department, 4.12 is also very big, although the reason there isn’t just that there’s a lot of development, we have the added bulk of a lot of new  header files for the AMD Vega support. That’s almost exactly half the bulk of the patch, in fact, and partly as a result of that the driver side dominates  everything else at 85+% of the release patch (it’s not all the AMD Vega headers – the Intel IPU driver in staging is big too, for example).

But aside from just being large, and a blip in size around rc5, the rc’s stabilized pretty nicely, so I think we’re all good to go.

Go out and use it.

Oh, and obviously this means that the merge window for 4.13 is thus open. You know the drill.

Linus

Linux 4.11 provided various improvements for Intel Bay Trail and Cherry Trail targets, OPAL drive support, pluggable IO schedulers framework, and plenty of ARM and MIPS changes.

Some of the most notable changes in Linux 4.12 include:

  • Initial AMD Radeon RX Vega GPU support
  • BFQ (Budget Fair Queuing) and Kyber block I/O schedulers have been merged, meaning the kernel now has two multiqueue I/O schedulers suitable for various use cases that should improve the responsiveness of systems.
  • Added AnalyzeBoot tool to create a timeline of the kernel’s bootstrap process in HTML format.
  • Implemented “hybrid consistency model” for live kernel patching in order to enable the applications patchsets that change function or data semantics. See here for details.
  • Build of Open Sound System (OSS) audio drivers has been disabled, and will likely be removed in future Linux releases
  • AVR32 support has been removed

Some of the bug fixes and improvements for the ARM architecture include:

  • Allwinner:
    • Allwinner H3 –  USB OTG support
    • Allwinner H5 – pinctrl driver, CCU (sunxi-ng) driver, USB OTG support
    • Allwinner A31/H3 SPI driver – Support transfers larger than 64 bytes
    • AXP PMICs – AXP803 basic support, ACIN Power Supply driver, ADC IIO driver, Battery Power Supply driver
    • Added support for: FriendlyARM NanoPi NEO Air, Xunlong Orange Pi PC 2
  • Rockchip:
    • Updates to Rockchip clock drivers
    • Modification for Rockchip PCI driver
    • RK3328 pinctrl driver
    • Sound support for Radxa Rock2
    • USB 3.0 controllers for RK3399
    • Various changes for RK3368 (dma, i2s, disable mailbox per default, mmc-resets)
    • Added Samsung Chromebook Plus (Kevin) and the other RK3399 “Gru family” of ChromeOS devices.
    • Added Rockchip RK3288 support for ASUS Tinker board, Phytec phyCORE-RK3288 SoM and RDK; added Rockchip RK3328 evaluation board
  • Amlogic
    • New clock drivers for I2S and SPDIF audio, and Mali GPU
    • DRM/HDMI support for Amlogic GX SoC
    • Add GPIO reset to Ethernet driver
    • Enable PWM LEDs and LEDs default-on trigger
    • New boards: Khadas VIM, HwaCom AmazeTV
  • Samsung
    • Split building of the PMU driver between ARMv7 and ARMv8
    • Various Samsung pincrl drivers updates
    • ARM DT updates:
      • Enhancements to PCIe nodes on Exynos5440.
      • Fix thermal values on some of Exynos5420 boards like Odroid XU3.
      • Add proper clock frequency properties to DSI nodes.
      • Fix watchdog reset on Exynos4412.
      • Fix watchdog infinite interrupt in soft mode on Exynos4210, Exynos5440, S3C64xx and S5Pv210.
      • Enable watchdog on Exynos4 and S3C SoCs.
      • Enable DYNAMIC_DEBUG because it is useful for debugging
      • Increase CMA memory region to allow handling H.264 1080p videos.
    • ARM64 DT updates:
      • Exynos power management drivers support now ARMv8 SoC – Exynos5433 – so select them in ARCH_EXYNOS
      • Enable few Exynos drivers (video, DRM and LPASS drivers) for supported ARMv8 SoCs (Exynos5433 and Exynos7)
      • Add IR, touchscreen and panel to TM2/TM2E boards
      • Add proper clock frequency properties to DSI nodes
  • Qualcomm
    • Enable options needed for QCom DB410c board in defconfig
    • Added new PHY driver for Qualcomm’s QMP PHY (used by PCIe, UFS and USB), and Qualcomm’s QUSB2 PHY
    • Qualcomm Device Tree Changes
      • Add Coresight components for MSM8974
      • Fixup MSM8974 ADSP XO clk and add RPMCC node
      • Fix typo in APQ8060
      • Add SDCs on MSM8660
      • Revert MSM8974 USB gadget change due to issues
      • Add SCM APIs for restore_sec_cfg and iommu secure page table
      • Enable QCOM remoteproc and related drivers
    • Qualcomm ARM64 Updates for v4.12
      • Fixup MSM8996 SMP2P and add ADSP PIL / SLPI SMP2P node
      • Replace PMU compatible w/ A53 specific one
      • Add APQ8016 ramoops
      • Update MSM8916 hexagon node
      • Add PM8994 RTC
  • Mediatek
    • New clock drivers for MT6797, and hi655x PMIC
    • Fix Mediatek SPI (flash) controller driver
    • Add DRM driver and thermal driver for Mediatek MT2701 SoC
    • Add support for MT8176 and MT817x to the Mediatek cpufreq driver
    • Add driver for hardware random generator on MT7623 SoC
    • Add DSA support to Mediatek MT7530 7-port GbE switch
    • Add v4l2 driver for Mediatek JPEG Decoder
  • Misc
    • Added ARM TEE framework to support trusted execution environments on processors with that capability (e.g. ARM CPUs with TrustZone)
    • ARM64 architecture now has kernel crash-dump functionality.
  • Other new ARM hardware platforms and SoCs:
    • NXP – NXP/Freescale LS2088A and LKS1088A SoC, I2SE’s i.MX28 Duckbill-2 boards, Gateworks Ventana i.MX6 GW5903/GW5904, Zodiac Inflight Innovations RDU2 board, Engicam i.CoreM6 Quad/Dual OpenFrame modules, Boundary Device i.MX6 Quad Plus SoM.
    • Nvidia – Expanded support for Tegra186 and Jetson TX2
    • Spreadtrum – Device tree for SP9860G
    • Marvell – Crypto engine for Armada 8040/7040
    • Hisilicon – Device tree bindings for Hi3798CV200 and Poplar board
    • Texas Instruments – Motorola Droid4 (OMAP processor)
    • ST Micro – STM32H743 Cortex-M7 MCU support
    • Various Linksys platforms,  Synology DS116

The MIPS architecture also had its share of changes:

  • Fix misordered instructions in assembly code making kenel startup via UHB unreliable.
  • Fix special case of MADDF and MADDF emulation.
  • Fix alignment issue in address calculation in pm-cps on 64 bit.
  • Fix IRQ tracing & lockdep when rescheduling
  • Systems with MAARs require post-DMA cache flushes.
  • Fix build with KVM, DYNAMIC_DEBUG and JUMP_LABEL
  • Three highmem fixes:
    • Fixed mapping initialization
    • Adjust the pkmap location
    • Ensure we use at most one page for PTEs
  • Fix makefile dependencies for .its targets to depend on vmlinux
  • Fix reversed condition in BNEZC and JIALC software branch emulation
  • Only flush initialized flush_insn_slot to avoid NULL pointer dereference
  • perf: Remove incorrect odd/even counter handling for I6400
  • ftrace: Fix init functions tracing
  • math-emu – Add missing clearing of BLTZALL and BGEZALL emulation counters; Fix BC1EQZ and BC1NEZ condition handling; Fix BLEZL and BGTZL identification
  • BPF – Add JIT support for SKF_AD_HATYPE;  use unsigned access for unsigned SKB fields; quit clobbering callee saved registers in JIT code; fix multiple problems in JIT skb access helpers
  • Loongson 3 – Select MIPS_L1_CACHE_SHIFT_6
  • Octeon – Remove vestiges of CONFIG_CAVIUM_OCTEON_2ND_KERNEL, as well as PCIERCX, L2C  & SLI types and macros;  Fix compile error when USB is not enabled; Clean up platform code.
  • SNI – Remove recursive include of cpu-feature-overrides.h
  • Sibyte – Export symbol periph_rev to sb1250-mac network driver; fix Kconfig warning.
  • Generic platform – Enable Root FS on NFS in generic_defconfig
  • SMP-MT – Use CPU interrupt controller IPI IRQ domain support
  • UASM – Add support for LHU for uasm; remove needless ISA abstraction
  • mm – Add 48-bit VA space and 4-level page tables for 4K pages.
  • PCI – Add controllers before the specified head
  • irqchip driver for MIPS CPU – Replace magic 0x100 with IE_SW0; prepare for non-legacy IRQ domains;  introduce IPI IRQ domain support
  • NET – sb1250-mac: Add missing MODULE_LICENSE()
  • CPUFREQ – Loongson2: drop set_cpus_allowed_ptr()
  • Other misc changes, and code cleanups…

For further details, you could read the full Linux 4.12 changelog – with comments only – generated using git log v4.11..v4.12 --stat. You may also want to ead kernelnewsbies’s Linux 4.12 changelog once it is up.

H3Droid Android Firmware is Designed for Allwinner H3 Boards & Devices

June 30th, 2017 4 comments

Allwinner H3 boards such as Orange Pi PC and NanoPi NEO are mostly interesting due to their ability to run Linux and control I/Os, and while they also support Android, most people wanting to run Android are better served with TV boxes instead, as they come with enclosure, power supply, HDMI cable, and an IR remote control. That does not mean there’s no use case for Android on development boards, and that’s why probably KotCzarny, and other developers, have decided to work on H3Droid project to provide better Android images for Allwinner H3 boards and devices than the firmware released by manufacturers.

Some of the improvements include “sane DRAM/CPU settings”, support for Custom recovery system, Google Play Store and more USB network adapters, as well as the removal of apps and feature unusable for people outside out China. You’ll also be able to access the board via SSH if you add your public key to the image. You’ll need a Linux computer (or board) to install the image, as it relies on an installer and there are a few steps to complete the installation on the SD card:

  1. Download image from one of the mirrors
  2. Extract the tar file (tar -xf filename.tar) in a folder with enough space to hold the contents (~450MB)
  3. Update 00_conf file to set OUTDEV variable. It should contain either device or plain file path (ex: OUTDEV=/dev/mmcblkX or OUTDEV=/dev/sdX or OUTDEV=/some/path/to/somefile.img)
  4. Copy your PUBLIC SSH key(s) to the install folder (Optional, but required to have root access via SSH) (ex: cp /root/.ssh/my_key.pub ./)
  5. Execute 10_init_new_card.sh to write image to your SDCard or somefile.img (in case of a file, you can use it later with dd/etcher/winimager to write to real device)
  6. Note: run only 10.. script, other files are meant to be called from it in order. (for example 20.. prepares partitions.dat used in 30..)

[Update: A Windows installer called H3ii is now available]

The FAQ indicates that the image has been tested on Orange Pi PC, Orange Pi Plus 2E, Orange Pi PC Plus, and Orange Pi Lite, but it should also work on other Allwinner H3 boards as long as you change the FEX file (script.bin). Also note that the first boot may take a while, and H3droid is still considered beta with for example Bluetooth, and power off not working yet, and a few other bugs still lingering. If you try the image on your board, you can provided feedback on #H3droid IRC channel on Freenode, or via the website. There’s also a forum thread on Orange Pi forums.

NanoPi NEO NAS Kit Review – Assembly, OpenMediaVault Installation & Setup, and Benchmarks

June 18th, 2017 68 comments

NAS Dock v1.2 for Nano Pi NEO / NEO 2 is, as the name implies, a complete mini NAS kit for 2.5″ drive for NanoPi NEO or NEO 2 board. The NEO 2 board is strongly recommended, since it’s not much more expensive, but should deliver much better results due to its Gigabit Ethernet interface. I’ve received two of those kits together with several other boards & accessories from FriendlyELEC, and today I’ll show how to assemble the kit, configure OpenMediaVault, and run some benchmarks.

NAS Kit V1.2 Assembly with NanoPi NEO 2 Board

The only extra tool you’ll need is a screwdriver, and potentially a soldering iron as we’ll see further below.
The metal box is stuff wih accessories so the first thing is to open one or two sides to take out the content. We have the mainboard, NanoPi NEO back plate, NanoPi NEO 2 back plater, a heatsink and thermal set, and a set of 5 screws to tighten the hard drive which mean there’s one extra screw. FriendlyELEC always adds extra screws, and I find it’s a nice touch, as it can be a real pain if you happen to lose one.

Click to Enlarge

Let’s have a closer look at the “1-bay NAS Dock v1.2 for NanoPi NEO/NEO2” board. We have a UAS capable USB 3.0 to SATA brige chip between the two header for NanoPi NEO board (note that the USB connection will be limited to USB 2.0 since the board only supports that), an LED, a USB 2.0 host port for a printer, WiFi dongle, or webcam, the power switch, the power jack, a 3-pin serial header, an I2C connector for Grove modules, and of course the SATA connector.

Click to Enlarge

There’s not much on the other side of the board, except a CR2032 battery slot for the RTC.

Before going further, you’ll need to go to the Wiki, and get the latest OpenMediaVault firmware, in my case nanopi-neo2_debian-nas-jessie_4.11.2_20170531.img.zip, which I then flashed with Ether program to a micro SD card..

Once this is done, install the heatsink and thermal to your NanoPi NEO 2 board, and insert the micro SD card into the board.

Notice that I also soldered the headers. While it would be obvious to people would have looked at the pinout diagram, I’ve read some people have justed connect the board using the (pre-soldered) 4-pin header, as they may have believed it was a USB header, but it’s just the serial console instead, and obviously the hard drive was not detected. If you don’t feel like soldering the headers to the board yourself, make sure you tick the option “with pin headers soldered” when ordering. It just costs $1 extra.

Now we can insert our board into the “1-bay NAS Dock” board, instead the hard drive, and optionally an I2C module. I connected an I2C OLED display i the picture below for illustrate, as using the display would require cutting out the case. Some people may want to connect an I2C temperature sensor instead.

Click to Enlarge

I used four screws to tighen the hard drive on the other side of the board, and install a CR2032 battery for the real-time clock.


Finally, you’ll need a 12V power supply with at least 1A, but I could not find any (safe) spare ones so I used Maxoak K2 power bank instead, since it can output 12V @ 2.5 A max.


OpenMediaVault Setup on NanoPi NEO 2 Board

So I connected everything, and applied power, but the board would not boot with the Ethernet Link LED blinking in a regular fashion, meaning something was very wrong. So I took out the board, and connected a serial debug board, connect to the console via minicom using 115200 8N1, and that’s what I got:

The boot was just stuck there. I re-inserted the micro SD in my PC, and I could see both boot and rootfs partitions, so everything looked good.
Then I powered the NanoPi NEO 2 board with a 5V/2A power supply only, and the boot succeeded:

Then I went back to the 12V power input on NAS Kit with the power bank and the boot succeeded. Very strange. It turns out the board would not boot most of the time, but the symptoms are not reproducible 100% of the time. This kind of random behavior is usually a timing or distorted signal issue. So I thought the micro SD card might not play well with the board, and the power bank signal might not be so clean. So I first flashed another micro SD card, but same results. I used another 12V/5A power supply, and it did not really help either. Finally, I used another NanoPi NEO 2 board and it appears to be stable.

You can find the board using FriendlyELEC.local if bonjour services are running in your computer:

Alternatively, you could check out the IP address in other ways. In my case, I just type friendlyelec.local in Firefox to access the web interface. The default username and password are admin and openmediavault.

Click to Enlarge

After login, you can access the dashboard showing system information, and which services are running. You may want to disable the services you don’t need.

Click to Enlarge

You can go to Storage->Physical Disks to check if your hard drive has been detected. No problem for me here with a 931.51 GiB drive detected.

Click to Enlarge

You may then want to setup a fix IP address. There are various ways to do this but I went to Network->Interfaces and set eth0 to a fixed IP address. You’ll be asked to apply the changes once it’s done.

Click to Enlarge

I also changed the hostname to CNX-NEO2-NAS in the General tab.

After that I decided to address some security issues. First by changing the administrator password in General Settings->Web Administrator Password.

I then went to Access Rights Management->User to find out there were two pre-configured users: pi and fa. I deleted fa user, changed pi’s user password, and added it to ssh group. It’s actually even probably better to just delete both user, and create your own.

The root user is not shown, but you’ll want to login as root through ssh first and change the password, as the default password is fa. Once it’s done, you’ll have better security, and your system should not be easily accessible via basic “hacks”. For more security, you’ll still want to install an RSA certificate. A self-signed one should do if you plan to use it only in the local network, but you may also consider a free Let’s Encrypt certificate instead.

We can now take care of the hard drive. I went to Storage->File Systems, and clicked on +Create file system which will let you choose between BTRFS, EXT3, EXT4, XFS, and JFS. I’ve gone with EXT4 first.

Click to Enlarge

After a few minutes you drive should be formatted, so we can configure network shares. I want to use SAMBA and SFTP to transfer files for the purpose of this review, so I went to Access Rights Management->Shared Folders to add a new share called HDD for the root of of hard drive. You may want to add multiple share if you plan to split videos, documents, music and so on.

Click to Enlarge

I clicked Save, and selected ACL to add permissions to pi and admin users. You can add whatever users you plan to use to access the share.

Click to Enlarge

That share3d folder can now be assigned to the services you plan to use. SFTP is enabled by default when SSH is running, so I create a SAMA/CIFS share by going to Services->SMB/CIFS->Shares to add the share.

Click to Enlarge

Browsing the Network with Nautilus would show both cnx-neo2-NAS – SMB.CIFS and cnx-neo2-nas – SSH (SFTP) shares.

Configuration is now complete. I have not find a clean way to power off the system, so I normally open a terminal session via ssh and run the shutdown now command. A software button to turn of the NAS would have been a nice features on the kit.

I also often encountered the error “Software Failure. Press left mouse button to continue. Session not authenticated.” before the session timeout is set to 5 minutes. If you prefer a longer timeout, you can change it in General Settings->Web Administration.

In case you want to use the RTC, you may first want to set the timezone:

Check the date is correct, and write it to the hardware clock:

before reading it back.

You can test it by rebooting the board without the Ethernet cable:

Perfect! You’d just have to make sure the “set” command is run automatically at boot time if the time in the RTC is set. It would be good if FriendlyELEC updated their image to do that automatically at boot time.

NAS Dock V1.2 + NanoPi NEO 2 Benchmarks

Since I can now copy files and folders over SAMBA and SFTP, we can start running some benchmarks to evaluate performance. I’ll use EXT-4, BTRFS, and XFS file systems on the hard drive, and run iozone to specicially test storage performance, following by copying large and small files over SAMBA or SFTP to test real-life NAS performance. For large file copy, I’ll use a folder with 7 large files totaling 6.5 GB, and for small files, I’ve done a fresh checkout of the Linux kernel in my computer:

and removed symlinks since they may cause issues during copy, as well as .git directory with a huge 1.8GB file:

The end result is a directory with 64,013 files totaling 748.6 MB.

Iozone results

EXT-4:

BTRFS:

XFS:

I’ve taken results with 16384kB reclen for read, write, random read and random write values to draw a chart, since most people are likely going to store large files in their NAS. The smaller reclen could be interesting if you plan to handle smaller files.

All three file systems have a very good read speed of around 40 MB/s, but BTRFS write appear to be the fastest among the three, with EXT-4 being the weakest at around 25 MB/s. But for some reasons, those results are useless in practice, as we’ll see below. Finding out the exact reason would possibly require studying and profiling iozone and the kernel source code which would be outside of the scope of this review.

File copy over SAMBA and SFTP

Results for large files in minutes and seconds.

File Copy  Large Files SMB SFTP
Write Read Write Read
EXT4 02:49.00 02:40.00 03:54.00 04:15.00
BTRFS 03:20.00 02:40.00 03:48.00 04:32.00
XFS 02:45.00 02:38.00 03:36.00 04:23.00

Chart converted to MB/s.

Read and Write Speeds in MB/s

First, we can see very good read performance from the NAS (NAS to my PC)  with 41 to 42 MB/s close to the theorethical limit of a USB 2.0 connection. Write speed is a a little different as the files were transferred more slowly with BTRS, and around 40MB/s with EXT-4 and XFS.  Since SFTP is encrypted the transfer speed is roughly the same for all three file systems. Overall the file system you choose does not really impact performance with large files.

Results for small files in minutes and seconds.

File Copy  Small Files SMB SFTP
Write Read Write Read
EXT4 15:26.00 18:34.00 09:02.00 12:48.00
BTRFS 18:48.00 18:02.00 10:30.00 11:30.00
XFS 17:33.00 18:22.00 09:18.00 12:35.00

Chart converted to MB/s.

Transferring a large number of small files over SAMBA is really slow, and barely faster over SFTP. Again,there aren’t any significant differences between file systems here.  If you are going to transfer a large number of small file over the network, you may want to either compress the files before transfer, or compress the files on the fly using the command line:

It took just 1 minute and 49 seconds to transfer all 64,013 files, or over five times faster than SFTP write to XFS, at around an effective 6.86 MB/s. So knowing your tools may matter as much as having the right hardware.

I was going to run a last part after enabling optimizations provided by tkaiser, but it turns out FriendELEC has already done that in their firmware image.

If you want to reproduce the setup above, you’ll need to purchase NAS Kit v1.2 for $12.99, and a NanoPi NEO 2 with soldered headers for $15.99. If you don’t have a 2.5″ hard drive, you’ll need to add this, as well as a 12V power supply which you could purchase locally, or on FriendlyELEC website for under $10. All in all that’s cheaper than a similar kit with a Raspberry Pi 3 board, and you’ll get close to four times the SAMBA performance for large files since RPi 3 will be limited to 10 to 12 MB/s due to the Fast Ethernet connection.