Archive

Posts Tagged ‘nanopi’

Armbian v5.35 Released with Linux 4.13, U-boot v2017.09, New Boards Support

November 27th, 2017 19 comments

Armbian v5.35 has been released last Friday as a major update that brings Linux mainline kernel to version 4.13, U-Boot mainline to version v2017.09, adds support for 7″ Raspberry Pi display, Realtek WiFi drivers (mainline), and new stable hardware support for NanoPi Duo, Pinebook, and Orange Pi R1.

Some other boards got experimental support, including Le Potato, NanoPi NEO 2, Orange Pi Zero Plus, Orange Pi Zero Plus 2 (H5). The desktop version of the images gets a full featured XFCE terminal, OpenVPN connector, a new wallpaper, and various other changes and fixes.

Armbian v5.35 on NanoPi NEO with Legacy Kernel

armbian-config is normally used to configure the board for example networking configuration, but the utility has become even more useful with support for Hotspot, Bluetooth, SSH server configuration, swtich between stable & beta builds and between kernel applications, adds the ability to start an RDP server, and install third party software such as SAMBA, OpenMediaVault, PiHole, Transmission BT, and so on.

If you have an existing installation, you can simply upgrade with the following commands, as I did for NanoPi NEO board above:

For a fresh installation, download the images from the download page instead.

TECHBASE ModBerry​ M300 Linux IoT Gateway ​is Powered by NanoPi NEO Board

November 15th, 2017 2 comments

We’ve previously covered TECHBASE Modberry industrial automation gateways based on popular development boards such as Raspberry Pi 3, NanoPi M1 Plus, and Intel Cherry Trail’s UP board, and designed for applications such as PLC controllers or MODBUS gateway / router.

The company has now launched a new version with Modberry M300 powered NanoPi NEO Allwinner H3 board.

ModBerry​ M300 gateway specifications:

  • SoC – Allwinner H3 quad core Cortex A7 @ 1.2 GHz with an ARM Mali-400MP2 GPU
  • System Memory – 512 MB DDR3 RAM
  • Storage – micro SDHC card slot
  • Connectivity
    • 10/100M Ethernet port
    • Optional Wi-Fi (IEEE 802.11 b/g/n, speed up to 150 Mbps, 64/128-bit WEP, WPA, WPA2), LTE/3G modem, GPS module, ZigBee, Bluetooth, LoRa, Wireless M-Bus, Nb-IoT
  • USB – 1x USB 2.0 host port, 2x USB 2.0 host header
  • Expansion I/Os
    • 2x DIO ports
    • 1x RS-232, 1x RS-485
    • 1x 2-pin mBus master for up to 10 slave devices
    • Optional up to 3 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, etc…
  • Misc – RTC with battery, watchdog timer
  • Power Supply – 9~30V DC up to 20Watts without modem; 40W with modems
  • Dimensions – 91 x 71 x 61 mm (ABS case with DIN rail mount)
  • Weight – 100 grams
  • Operating Conditions
    • Temperature –  Standard : 0 ~ 60°C; extended range: -40 ~ 70°C
    • Humidity – 5 ~ 95% RH (non-condensing)

Modberry M300 Features and Options – Click to Enlarge

The gateway can run Debian, or Ubuntu Core based on Linux 4.11.2+ and u-boot, as well as the company’s iMod software to handle various industrial or other protocols such as M-Bus, Modbus, SNMP, MQTT, etc…

Pricing is not available just like with other Modberry gateways, and you’ll find more details on the products page. Not directly related, but found in the same TECHBASE’s November 2017 newsletter, the company also mentions M-Bus/WM-Bus support for their Moduino ESP32 gateways.

Linux 4.14 Release – Main Changes, ARM & MIPS Architecture

November 13th, 2017 7 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-years of support, so it will be found in devices for the years to come. [Update: While Linux 4.4 will be supported for 6 years until February 2022, the plan is to support Linux 4.14 until January 2020, right from the horse’s mouth]

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.

NanoPi Fire2A & Fire3 Boards Released with Samsung/Nexell Quad & Octa Core Processors

November 12th, 2017 31 comments

FriendlyElec previously launched NanoPi 2 Fire board powered by Samsung (Nexell) S5P4418 quad core Cortex A9 SoC, mostly interesting because of its small form factor, camera and LCD interfaces.

The company has now launched two new boards based on S5Pxx18 processors, namely NanoPi Fire2A powered by S5P4418 SoC, and NanoPi Fire3 based on S5P6818 octa-core Cortex-A53 SoC. Both boards share the same form factor, which remains quite similar to the one of NanoPi 2 Fire, except the HDMI connector now makes place for a micro HDMI port, the USB 2.0 has moved into vertical position, and a few other tweaks have been made to positions of buttons and components.

NanoPi Fire2A / Fire3 specifications:

  • SoC
    • Fire2A – Samsung S5P4418 quad core Cortex A9 processor @ up to 1.4GHz, Mali-400MP GPU
    • Fire3 – Samsung S5P6818 octa core Cortex A53 processor @ up to 1.4 GHz, Mali-400MP GPU
  • System Memory
    • Fire2A – 512MB DDR3
    • Fire3 – 1GB DDR3
  • Storage – 1x Micro SD Slot
  • Connectivity – Gigabit Ethernet port
  • Video Output / Display I/F- 1x micro HDMI 1.4a port up to 1080p60, RGB LCD interface
  • Camera – 24-pin DVP interface; 0.5mm pitch
  • USB – 1x USB Host port; 1x micro USB 2.0 OTG port for power and data
  • Expansions Headers – 40-pin Raspberry Pi compatible header with UART, I2C, SPI, GPIOs…
  • Debugging – 4-pin header for serial console
  • Misc – Power and reset buttons, power and system LEDs, RTC battery header
  • Power Supply – 5V/2A via micro USB port; STM32F03 ARM Cortex M0 MCU for power handling (SW power off, sleep , and wakeup function)
  • Dimension: 75 x 40 mm

Other differences with the earlier model: AXP288 PMIC is gone, and replaced by an STM32 Cortex M0 MCU, and the company has now added mounting holes for a heatsink. The company provides FriendlyCore, and Debian firmware images for both hardware, and an extra Android image for Fire3 board. FriendlyCore is based on Ubuntu Core 16.04 with Linux 4.4, Qt 5.9 with OpenGL, and GStreams with VPU acceleration. The good news is the Linux kernel got an upgrade from Linux 3.4 to a more recent Linux 4.4 LTS kernel.

You’ll find download links and instructions to get starting in the Wiki pages here and there. NanoPi Fire2A is sold for $28 plus shipping, while NanoPi Fire3 goes for $35. You may also be interested in compatible accessories and external modules, including S430 4.3″ capacitive touch screen LCD display, X710 7.1″ capacitive touch screen LCD display, HD101 10.1″ touchscreen LCD display, CAM500B 5MP CMOS camera, Matrix GPS module, and others which you can find by browsing in the store.

NanoPi Fire2A/3 Connected to LCD430 Display (Left) and GPS Matrix Module (Right)

RetrOrangePi 4.0 Released

November 6th, 2017 9 comments

RetrOrangePi is a retro gaming & media center firmware based on Armbian Debian image and working on Allwinner H3/H2+ based Orange Pi boards, Banana Pi M2+, and NanoPi M1, as well as Beelink X2 TV Box.

Right at the end of last year, I reviewed RetrOrangePi 3.0 on Orange Pi One board to which I connected Mars G01 gamepad, and I could play some games like Wolfenstein 3D and Quake, and watch videos on OpenELEC/Kodi 16. The firmware also comes with various emulators, but you’d have to load the ROMs yourself due to intellectual property / license issues. The developers have now released RetrOrangePi 4.0.

RetrOrangePi 4.0 changelog:

  • Latest Armbian v5.32 (Debian Jessie kernel 3.4.113)
  • RetroPie-Setup v4.3.3 (unofficial fork, upgradeable)
  • New RetrOrangePi repository for easy updates and fixes
  • EmulationStation v2.6.5 with video and game collection support, Desktop/OpenELEC shorcuts from main menu
  • New ROPi “Attract-Mode”-like theme (based on Cosmos theme)
  • Retroarch 1.6.7 – Retroachievements tested
  • Kodi Krypton 17.4 (hardware acceleration provided by MPV + VDPAU): IPTVsimple included, quit button fixed
  • OpenELEC (Kodi Jarvis 16.1) with CEC support by Jernej Skrabec (optional installation)
  • Slim and Full versions for all compatible boards
  • All Libretro cores updated
  • All RetroPie themes available for installation
  • Experimental new libretro cores: DOSBox, MAME2014, VICE, X68000, Amiga PUAE
  • PPSSPP latest v1.42
  • Mupen64Plus standalone emulator (with hires textures support)
  • AdvanceMAME 3.5
  • AdvanceMENU frontend integrated
  • AdvanceMESS (support for ancient platforms, tested OK: Bally Astrocade, BBC Micro, Channel F, Colecovision etc.
  • New Quake 2 port (Yamagi Quake)
  • New Streets of Rage Remake port (needs BennuGD engine downloaded to home folder)
  • Improved Amiga emulation – fullscreen UAE4ARM with JIT support, optional WHDLoad
  • Hatari 2.0 (SDL2) – atariST emulator
  • Vice 3.1 (SDL2) – Commodore emulator
  • Boot selection – from Desktop (EmulationStation, Kodi, AdvanceMENU, RetroArch, Desktop)
  • Onscreen keyboard (Florence)
  • Overscan fix in AV outputs (Allwinner_TVOUT_manipulator)
  • New Desktop wallpaper, wifi config, ES, Kodi, Donate and Support icons
  • Customized Retroarch configuration (optimal settings, appearance tweaks, original aspect ratio)
  • New HDMI/Analog AV configuration tool (thanks Jose Rios) + our overscan fix
  • New exclusive ROPi Radio beta version
  • Scraper by Sselph update
  • Universal XML Scraper integration and tutorials
  • Binary cores updates
  • GPIO driver can be installed from driver section.
  • RetroPie services tested: USBROMSERVICE – create a retropie-mount folder in your FAT32 flash drive, Virtual gamepad
  • Custom ES splashscreen by Francois Lebel @MagicFranky – the number 4 was on us :p (great skills!)
  • Custom MOTD with ROPi invader + Armbian info
  • Improved filesystem support: FAT32 automount, ExFAT support

The full images are not yet available, but if you are an existing users with ROPi 3.0.1 instead, you can upgrade to version 4.0 by running ropi4.sh script in your board/device as pi user:

The images for new users will be coming later once one of the developers involved get more free time. In the meantime, you’d have to download & install RetroOrange Pi 3.0.1, and run the script to upgrade to 4.0.

You’ll find more details about the release in the forums, where you can also ask for support questions. The source code can be found on github.

Giveaway Week – NanoPi K2 Development Board

November 2nd, 2017 271 comments

NanoPi K2 development board is powered by Amlogic S905 processor coupled with 2GB RAM, and follows Raspberry Pi 3 form factor, and I’ve got a K2 multimedia kit to give away courtesy of FriendlyELEC who sent me one a few months ago.

Click to Enlarge

The kit includes the board, a quick start guide, a fansink, a USB cable for power, an acrylic case (not shown above), and an IR remote control. I got it when I asked for NanoPi NAS Kit, and sadly I did not find the time to test it, but the company provides both Android 5.1 and Ubuntu 16.04.2 images for the board, and Armbian also released an experimental Ubuntu server image with mainline kernel, and an Ubuntu desktop “testing” image with legacy Linux.

To enter the draw simply leave a comment below. Other rules are as follows:

  • Only one entry per contest. I will filter out entries with the same IP and/or email address.
  • Contests are open for 48 hours starting at 10am (Bangkok time) every day. Comments will be closed after 48 hours.
  • Winners will be selected with random.org, and announced in the comments section of each giveaway.
  • I’ll contact the winner by email, and I’ll expect an answer within 24 hours, or I’ll pick another winner.
  • Shipping
    • $10 for registered airmail small packet for oversea shipping payable via Paypal within 48 hours once the contest (for a given product) is complete.
    • If Paypal is not available in your country, you can still play, and I’ll cover the cost of sending the parcel by Sea and Land (SAL) without registration if you win.
  • I’ll post all 10 prizes at the same time, around the 8th of November
  • I’ll make sure we have 10 different winners, so if you have already won a device during this giveaway week, I’ll draw another person.

If you don’t end up being lucky, you could still get the board for $45 on FriendlyARM website.

NanoPi Duo Quick Start Guide – Ubuntu, Breadboard, Mini Shield & mSATA SSD

October 30th, 2017 12 comments

As far as I know NanoPi Duo is the only quad core ARM Linux development board that can fit on a breadboard. We’ve already seen it’s much smaller than Raspberry Pi Zero, and the company offer a mini shield exposing USB ports, Ethernet, a few I/Os, and an mSATA slot in in NanoPi Duo Starter Kit Review – Part 1: Unboxing and Assembly.

I’ve finally played with it this week-end, and will report what I had to do to blink a LED when connected to breadboard, and my experience using the mini shield with  an mSATA SSD, WiFi connectivity, and cooling under load.

Flashing Ubuntu 16.04.2 firmware image to NanoPi Duo

As with many other Allwinner development boards, you should first check if Armbian is available for the board. NanoPi Duo is not supported, but it’s said to work with Orange Pi Zero image minus support for WiFi. Since the latter is rather important if you’re going to use the board standalone, I instead went with FriendlyELEC’s Ubuntu Xenial image (nanopi-duo_ubuntu-core-xenial_4.11.2_20170908.img.zip) shared on the company’s Wiki.

I flashed the (compressed) image with Etcher – available for Windows, Linux, Mac OS, on a 8GB micro SD card (Sandisk Ultra).

Using NanoPi Duo as a Breadboard-friendly Development Board

Once this is done, insert the micro SD into the board, insert it into a breadboard, and connect your circuit (in my case a 5V LED connected to GPIOG11 via a transistor). Most other breadboard-friendly WiFi boards include either a USB to TLL chip allowing to access the board’ serial console over USB (e.g. ESP32 boards), or firmware that setups the board as an access point for initial configuration (e.g. LinkIt Smart 7688 Duo). So you just need to connect power and you’re good to go.

Click to Enlarge

But NanoPi Duo’s board has no serial to USB chip, and the current firmware does not setup an access point by default, so I’ll need to connect a USB to TLL debug board too, as shown above. I then started minicom with 115200 8N1 configuration, and connected the board to one of the USB port of my computer for power, and the boot worked just fine.  See complete boot log for reference:

The system will autologin, and show a welcome boot message similar to what is found in Armbian build.

Let’s check some of the relevant info:

The image is based on Ubuntu 16.04.2 with a recent Linux 4.11.2 although apparently not updated with the latest patchsets found in Linux 4.11.12. The rootfs has been automatically resized at boot time so I have 5.9GB free on the partition, and 497MB RAM is accessible from Linux.

There are some useful pre-loaded modules for WiFi, USB mass storage, and IPv6:

Most people will want to use WiFi in this configuration (breadboard use), and nmtui text user interface is normally recommended, but the UI was really messy in the serial console, so I reverted to use nmcli instead as explained in the Wiki. First let’s list the network devices:

WiFi is disabled, so we’ll enable it and scan nearby routers:

I repeated the last command three times, but my main (2.4 GHz) router was not listed. So let’s attach a u.FL antenna…

Click to Enlarge

… to see if I can get a stronger signal for the already detected access points, and find my main router (CNX-TRANSLATION):

Success! I can now see CNX-TRANSLATION SSID, and CNX-SOFTWARE SSID signal is much stronger. However, I lost sonoff-office (which I did not plan to use).  We can connect to the access point of your choice as follows:

Oops. I did not work out as expected. Listing the access points again:

That’s crazy… All my APs are gone! But after persevering a few more times, I was finally able to connect and get an IP address:

We can now update the system to make sure it has the latest packages:

The board could download all the ~150 packages without issues, so once the connection is up it looks fairly stable. The update will take a while, so you may want to try a few other features of the firmware. For example, the company pre-installed NanoPi-Monitor, a fork of RPi-monitor, which allows you to monitor CPU and memory usage, temperature, up time, etc.. directly from a web browser via http://board_IP:8888.

Click to Enlarge

I was also be able to connect via SSH using either pi/pi or root/fa username and password.

The last step of this section of our tutorial is to control GPIOs. Since the board runs Linux 4.11, we may have hoped the new GPIO subsystem might be implemented, but lsgpio is not installed, and instead the company recommends to use WiringNP, a fork a WiringPi. It’s pre-installed, so we can use it right away to list GPIOs:

I’ve connected the LED to GPIOG11 (mapped to pin 16 in WiringNP), and it’s on by default, so let’s pull it down:

The LED turns off, and we can turn it back on with:

Let’s write blink.c to blink our LED every 500 ms:

We can now build and run it, and the LED will blink as expected:

You need to run blink as root as it is required by wiringPiSetup() function: “wiringPiSetup: Must be root. (Did you forget sudo?)”, but there are workarounds roughly explained in the Wiki. The user key/switch on NanoPi Duo board is connected to “GPIOL3/K1” pin, but is not listed by gpio readall command, so this would have to be looked into.

Other modes such as PWM,  I2C, SPI, UART, PWM should also be supported, but out of the scope of this quick start guide.

Beside “GPIOs”, Ethernet, USB, composite video, and various audio signal are also exposed, so it can make for some very interesting DIY projects.

NanoPi Duo with mini Shield and SSD

I took out the micro SD card, and inserted in my other NanoPi Duo board connected to the mini shield with an mSATA SSD. This time I connected the board through a 5V/2A power supply, and added an Ethernet cable.

Getting started is much easier since we are using Ethernet here. Just find your board IP address in your router’s DHCP client list, or via tools like arp-scan, and connect over SSH with pi user:

We can see the SSD is detected (sda – 59GB):

but not mounted:

So I formatted the drive with EXT-4…

and mounted it in a temporary directory to check it out:

In theory the SSD should have much better performance than the micro SD card, even though it’;s connected through a USB to SATA chip. But let’s no assume anything, and first run iozone on the 8GB micro SD provided by FriendlyELEC:

and repeat the same test on the SSD:

We can see that both sequential performance, and especially random I/O are much better on the SSD drive, so it would make perfect sense to move the rootfs from the micro SD card to the SSD.

But before going there, I’ve been asked to check run smartctl on the drive:

There are many parameters reported, and one of them is the drive temperature which apparently went up to 52°C, and as low as 19°C. The latter could not have happened my location, since temperature never went below 24°C.

Time to move the rootfs to the SSD, and to do so I’ll adapt the instructions for CubieTruck, another Allwinner development board.

As we’ve seen above, the roofs is mounted to /dev/mmbblk0p2, so let’s mount it in another directory, and copy the content to the SSD:

We need to let the boot partition know our rootfs has moved. Let’s go to /boot directory, and edit boot.cmd text file (used to be uEnv.txt in CubieTruck) by changing root from /dev/mmcblk0p2 to /dev/sda in the bootargs with all other parameters unchanged:

The final step to create boot.scr binary file using the command below, and reboot.

After a few seconds, we should be able to use login and verify the rootfs has now moved to sda.

Success! The boot partition is still in the micro SD card since Allwinner platform can’t boot from USB. You can reclaim mmcblk0p2 partition on the SD card to do something else. Eventually we should be able to do away completely with the micro SD card by booting from the SPI flash in the board, but I think this is still work in progress (TBC).

Stress Testing & WiFi Performance

Such small board is not designed for heavy load, as even with an heatsink, heat dissipation does not work as well as on larger boards (with a large ground plane). To demonstrate that I ran stress on all 4 cores, and monitored temperature and CPU with NanoPi-Monitor.

Click to Enlarge

Stress was started at 19:32, on based on the chart above the CPU cores ran at 1008 MHz for about two minutes with the CPU temperature quickly increasing from around 50 to 70°C, and after the CPU frequency oscillates between 624 MHz and 1008 MHz to keep the temperature in check. Ticking “active CPUs” would show 4 cores are used at all times during stress. Performance does not completely collapses but the system cannot run at 1008 MHz at all times without additional cooling. Whether this is an issue or not depends on your specific load/use case.

NanoPi Duo relies on Allwinner XR819 WiFi module, and while it’s working decently on my Orange Pi Zero, I had reports of poor peformance and issues in the past, and as we’ve seen above I had some troubles finding and accessing my access points with NanoPi Duo. So it might be good to have a look at WiFi performance too.

As a side note, nmtui is usable while connecting via SSH instead of minicom / serial connection, so if you prefer a user interface you may want to use this tool instead of nmcli when using the mini shield.

That time I could also list all my local access points even with no external antenna attached:

But I could not ssh to the board via the WiFi interface (192.168.0.115) from my computer:

So I rebooted the board, and could login again. All good, so I ran iperf with chip antenna (only):

  • upload:

  • download:

The board was located in my usual (TV box, development board) test location about 4 meters from the router (+ wall), and results are rather poor, so I tried again with an external antenna:

  • upload:

  • download:

Not fantastic, but still about twice as fast, and with much better signal strength so loss of connection should be less likely improving reliability.

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.