Archive

Posts Tagged ‘banana pi’

Banana Pi M2 Magic Board Now Sold with Allwinner A33 Processor for $23

October 20th, 2017 13 comments

Banana Pi M2 Magic development board was first unveiled in February of this year with an Allwinner R16 SoC, 512 MB RAM, and 8GB eMMC flash, and its main selling points were support for MIPI DSI LCD displays, CSI cameras, and 3.7V LiPo batteries. AFAIK SinoVoIP never sold that version of the board, at least on Aliexpress.

Possibly due to the intricacies of Allwinner business units, the company has now officially launched Banana Pi M2 Magic (aka BPI M2M), but replaced Allwinner R16 by the similar Allwinner A33 processor, and removed the 8GB eMMC flash to bring the price down to $23 plus shipping. The “old” Allwinner R16 based Banana Pi M2 Magic board will apparently be sold as M2 Magic Plus soon.

Banana Pi BPI-M2 Magic (A33) specifications:

  • SoC – Allwinner A33 quad core ARM Cortex-A7 processor with ARM Mali 400 MP2 GPU
  • System Memory – 512MB DDR3
  • Storage – micro SD slot
  • Display Interface – 4-lane MIPI DSI connector
  • Camera Interface – CSI connector supporting up to 5MP sensor, 1080p30 H.265 video capture (OV5640 module)
  • Video Decoder – Multi-format FHD video decoding, including Mpeg1/2, Mpeg4, H.263, H.264, etc H.264 high profile [email protected]
  • Audio – On-board microphone
  • Connectivity – Wifi 802.11 b/g/n, Bluetooth 4.0 LE (AP6212) with u.FL antenna connector
  • USB – 1x USB 2.0 host, 1x micro USB 2.0 OTG port
  • Expansion – 40-pin header with GPIOs, UART, I2C, SPI, PWM…
  • Misc – Reset & power buttons, LEDs,
  • Power Supply
    • 5V/2A via DC power barrel
    • 3.7V Lithium battery support via 6-pin header
    • AXP223 PMIC
  • Dimensions – 51 x 51 mm
  • Weight – 40 grams

The Wiki indicates the board support Android and Linux, and provides some further information about the interface. Bear in mind SinoVoIP is often not quite fully correct, so make sure to double check if one of the feature is important to you.

Industrial Shields Industrial Panel PCs are Based on Raspberry Pi, Banana Pi, or HummingBoard

October 10th, 2017 4 comments

Boot&Work Corp., S.L. is a company based in Catalonia that sells industrial automation electronic devices under “Industrial Shields” brand. What makes their product noticeable is that they all appear to be based on maker boards such as Arduino or Raspberry Pi.

The company offers various Arduino based PLC modules with or without Ethernet that can be controlled with 10.1″ industrial grade panel PCs based on ARM Linux development boards.

Click to Enlarge

Currently three sub-families are available:

  • HummTOUCH powered by Solidrun HummingBoard-i2 NXP i.MX 6Dual Lite board
  • BANANATOUCH with either Banana Pi M64 (Allwinner A64 quad core Cortex A53) or Banana Pi M3 (Allwinner A83T octa core Cortex A7)
  • TOUCHBERRY with Raspberry Pi model B or Raspberry Pi 3 model B

Beside the different processors, the 10.1″ Panel PCs share some of the same specifications:

Industrial Shields Arduino PLC – Click to Enlarge

  • Display – 10.1″ resistive multitouch LVDS, 315 nits, 170° viewing angle, 1280×720 resolution
  • Video Input – MIPI CSI connector (HummTouch only)
  • System Memory – 512MB to
    • HummTOUCH – 1 GB RAM
    • BANANATOUCH – 2GB RAM
    • BERRYTOUCH – 512MB RAM or 1GB LPDDR2
  • Storage
    • All – micro SD slot
    • BANANATOUCH – 8GB eMMC flash (16, 32, 64 GB optional)
  • Connectivity
    • Fast or Gigabit Ethernet depending on model
    • BANANATOUCH and BERRYTOUCH 3 – 802.11 b/g/n WiFi, Bluetooth 4.0
  • USB – 2x to 3x USB ports
  • I/O Expansion – 8x GPIO, SPI, I2C, UART
  • Power Supply – 12V DC; supports 7 – 18V DC input up to 1.5A
  • Dimensions – 325.5 x 195.6 x 95 mm
  • Compliance – CE

The user manual lists further details about environmental conditions, for example for HummTOUCH models:

  • Temperature Range – Operating: 0 to 45°C; storage: -20 to 60 C
  • Humidity – 10% to 90% (no condensation)
  • Ambient Environment – With no corrosive gas
  • Shock resistance – 80m/s2 in the X, Y and Z direction 2 times each.

There’s no information about Ingress Protection (IP) ratings, so it’s safe to assume those have not been tested for dust- and waterproofness.

Back of BANANATOUCH M3 Panel PC

The company also have smaller 3.5″ and 3.7″ model based on Raspberry Pi 3 board only. HummTOUCH models are available with either Linux or Android, BANANATOUCH and BERRYTOUCH models are only sold with Linux (Raspbian),  but Ubuntu, Android and Windows 10 IoT are options if they are supported by the respective board.

The 10.1″ panel PCs are sold for 375 to 460 Euros, and the Arduino based PLCs start at 135 Euros. Documentation and purchase links can all be found on Industrial Shields website.

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.

Fedora 26 Supports Single “Unified” OS Images for Multiple ARM Platforms

August 14th, 2017 29 comments

The decision to use device tree in Linux occurred several years ago, after Linus Torvalds complained that Linux on ARM was a mess, with the ultimate goal of providing a unified ARM kernel for all hardware. Most machine specific board files in arch/arm/mach-xxx/ are now gone from the Linux kernel, being replaced by device tree files, and in many case you simply need to replace the DTB (Device Tree Binary) file from an operating system to run on different hardware platforms. However, this is not always that easy as U-boot still often differ between boards / devices, so it’s quite frequent to distribute different firmware / OS images per board. Fedora has taken another approach, as the developers are instead distributing a single Fedora 26 OS ARMv7 image, together with an installation script.

Images for 64-bit ARM (Aarch64) are a little different since they are designed for SBSA compliant servers, so a single image will work on any server leveraging UEFI / ACPI implementation on the hardware. So what follows is specific to ARMv7 hard-float images as explained in the Wiki.

You’ll need to install Fedora Arm installer after downloading one of the Fedora 26 images. This requires an Fedora machine, and since I’m running Ubuntu 16.04, and don’t want to setup a Fedora virtual machine in Virtualbox, I used docker instead right inside Ubuntu as it’s much faster to do:

The last line requires some explanation. /media/hdd is the mount point of the storage device on the host where I download the Fedora image and that will be accessible through /mnt in docker, /dev/sdd is my micro SD card device, while /dev/sdd3 will be the rootfs partition.Note that it took me a while to get that right, and I’m not sure it works for all targets (other other /dev/sddx are also needed), so using an actual Fedora 26 installation would be easier. The rest of the instructions below are not specific to docker.

I could then install the Fedora ARM Installer and the required xz & file packages…

…and check the usage:

Let’s see how many boards are supported in /usr/share/doc/fedora-arm-installer/SUPPORTED-BOARDS file:

AllWinner Devices:
A10-OLinuXino-Lime A10s-OLinuXino-M A13-OLinuXino A13-OLinuXinoM
A20-OLinuXino-Lime A20-OLinuXino-Lime2 A20-OLinuXino_MICRO
A20-Olimex-SOM-EVB Ampe_A76 Auxtek-T003 Auxtek-T004 Bananapi Bananapro CHIP
CSQ_CS908 Chuwi_V7_CW0825 Colombus Cubieboard Cubieboard2 Cubietruck
Cubietruck_plus Hummingbird_A31 Hyundai_A7HD Itead_Ibox_A20 Lamobo_R1
Linksprite_pcDuino Linksprite_pcDuino3 Linksprite_pcDuino3_Nano MK808C
MSI_Primo73 MSI_Primo81 Marsboard_A10 Mele_A1000 Mele_A1000G_quad Mele_I7
Mele_M3 Mele_M5 Mele_M9 Mini-X Orangepi Orangepi_mini Sinlinx_SinA31s
UTOO_P66 Wexler_TAB7200 Wits_Pro_A20_DKT Yones_Toptech_BS1078_V2 ba10_tv_box
colorfly_e708_q1 difrnce_dit4350 dserve_dsrv9703c i12-tvbox iNet_86VS
icnova-a20-swac inet86dz jesurun_q5 mk802 mk802_a10s mk802ii orangepi_2
orangepi_lite orangepi_pc orangepi_plus polaroid_mid2809pxe04
pov_protab2_ips9 q8_a13_tablet q8_a23_tablet_800x480 q8_a33_tablet_1024x600
q8_a33_tablet_800x480 r7-tv-dongle sunxi_Gemei_G9

MX6 Devices:
cm_fx6 mx6cuboxi novena riotboard wandboard

OMAP Devices:
am335x_boneblack am57xx_evm kc1 omap3_beagle omap4_panda omap5_uevm

MVEBU Devices:
clearfog

ST Devices:
stih410-b2260

Other Devices:
jetson-tk1 rpi2 rpi3 trimslice

So we’ve got a list of device to choose from. For example, if you wanted to install Fedora 26 server in a micro SD card for Raspberry Pi 3, you’d run something like:

You’ll then be ask to confirm:

The full process will take several minutes, and at the end you’ll get “_/” rootfs partition, “_/boot ” partition, and a “30 MB volume” with u-boot, config,etc…


I did not try the micro SD card in Raspberry Pi 3 board myself, because Geek Till It Hertz has already done it successfully on both RPi 3 and Banana Pi boards as shown in the video below.

He also showed the boards run Linux 4.11.8 version, but that can be upgraded with dnf update to Linux 4.11.11, just as on his Fedora 26 installation on a x86-64  computer.

Banana Pi BPI-R2’s U-boot & Linux 4.4 Source Code & MediaTek MT7623N Datasheet Released

June 28th, 2017 39 comments

Banana Pi BPI-R2 is a multimedia router board powered by MediaTek MT7623N quad core processor with 2GB RAM, 5 Gigabit Ethernet ports, up to two SATA ports, two USB 3.0 ports, HDMI output, and I/O headers. The board is not for sale yet, but the company has recently released the source code with U-boot and Linux 4.4.70, as well as a datasheet for MediaTek MT7623N processor.

The source code can be found on Github, so let’s see if we can build it:

After a couple of minutes, the build would end with:

For the very last step, it asks you to login as root / sudoer, which it should not do… But we end up with the images, so at least it builds:

MediaTek has also been active by committing patchsets for MT7623 to the Linux Kernel Mailing List, so mainline Linux is an eventual possibility for BPI-R2 board. We just don’t have a clear view of what works and what doesn’t with mainline.

Mediatek MT7623N PCIe Subsystem Block Diagram

The datasheet is a 1,235-page document, but the name “MT7623N Datasheet for Development Board” implies that it may actually be a subset of another larger and more complete datasheet. Nevertheless, it looks to have enough information to control peripherals like GPIOs, I2C, PWM, UART, timers, GMAC, USB, etc… You’ll also find BPI-R2 schematics (PDF only) in the board’s Wiki.

Banana Pi BPI-M2 Berry Allwinner V40 Development Board, Allwinner Business Units & SDK/Software Management

May 29th, 2017 55 comments

SinoVoIP has unveiled yet another new board with Banana Pi BPI-M2 Berry this week-end. It’s actually quite similar to Banana Pi BPI-M2 Ultra board, by they replaced Allwinner R40 with Allwinner V40 processor, removed some features, and use Raspberry Pi 3 form factor. If we look at Allwinner V40 product brief we can see the specifications look almost identical, with V40 potentially exposing an extra CAN bus. The company’s announcement was very confusing since they show Banana Pi BPI-M2 Berry board with Allwinner R40 instead of Allwinner V40.

Banana Pi BPI-M2 Berry specifications:

  • SoC – Allwinner V40 quad Core ARM Cortex A7 processor with ARM Mali-400MP2 GPU
  • System Memory – 1G DDR3 SDRAM
  • Storage – micro SD slot, SATA interface
  • Connectivity – 1x Gigabit Ethernet port, 802.11 b/g/n WiFi and Bluetooth 4.0 (AP6212 module)
  • Video Output – HDMI 1.4 port up to 1080p60, 4-lane MIPI DSI display connector
  • Audio I/O – HDMI, 3.5mm headphone jack, built-in microphone
  • USB – 4x USB 2.0 host ports, 1x micro USB OTG port
  • Camera – CSI camera connector
  • Expansion – 40-pin Raspberry Pi compatible header with GPIOs, I2C, SPI, UART, ID EEPROM, 5V, 3.3V, GND signals.
  • Debugging – 3-pin UART for serial console
  • Misc – Reset, power, and u-boot buttons
  • Power Supply – 5V via micro USB port; AXP221s PMIC
  • Dimensions – 85mm x 56mm

The Wiki is also shared for BPI-M 2 Ultra/Berry boards. The company also showed a picture of BPI-M2 Ultra with Allwinner V40 confirming both processors are  pin-to-pin-compatible.

BPI-M2 Ultra Board with Allwinner V40 Processor

So why bother doing different processors since they are so similar? Last time, we were told Allwinner A64 and R18 had different SDKs, so it should be the same for R40 and V40. Allwinner has different family of processors dedicated to different market segments: A-series are application processors, H-series are for home entertainment, R-series for the IoT, and V-Series for video camera applications. In some ways, it makes sense to have different business units that specialize in specific market segments. If you customer wants to make an action camera redirect him to the V-series guys, a TV box that’s for H-series, and so on.

There’s been a long-ish discussion about Allwinner business units on CNX Software. What has apparently been happening is that some processors can be used across market segments, so they have duplicates (or close to it) with for example Allwinner A64/R18 that’s just the same chip but assigned to a different business unit. Each business unit work and release their own SDK, and based on different Linux and Android version for different SDK, there does not seem common work across business units, and they appear to have separate software teams.  The processors are differentiated by “CHIP ID”, and by default you can’t run firmware generated by R18 SDK on A64, and vice-versa, since the bootloader will detect the ID and prevent the software to run.  That also looks like a bad idea, since for example a software bug fixed on Allwinner R18 SDK, may go unnoticed on Allwinner A64 for years etc… So ideally all business units should get their software from a single team taking care of low level software (bootloader/kernel/drivers), middleware (Android/rootfs), while software developers’ part of a given business unit may work on the market specific software.

Jon had more insights on this business organization:

The R group is releasing a different SDK for the R18. They are not using the A64 one. That strongly suggests to me two sets of software people. A single software group would have simply added the R18 extras into the A64 SDK.

You want a centralized Linux and Android group. Then inside that group you develop specialists. For example the DMA person, the UART person, the Ethernet person, etc. That person is responsible for driver support over all of the CPUs Allwinner makes. They become experts on this piece of the SOC. The output of this group is a single SDK that supports all Allwinner processors. Like what mainline Linux is doing for Allwinner SOC currently. Not the single CPU kernels that AW keeps releasing.

Then you can give this central software group two instructions:
1) Add a new SOC to the existing base. Each specialist will extend their existing driver to add support for the new SOC. Not cut and paste then edit to make a new driver! That happens with separate groups.
2) Add support for a new kernel or Android release. Everyone in the group works together to bring all of the SOC support up to this new release. This is not that hard now since each expert in their niche will know exactly what the issues are.

The central group allows these vertical specialists to exist. Having the chip groups do it results in a lot of copy/paste/edit (which we see in spades) and many bugs because the work is having to be done by generalist assigned to the group. When the programmers belong to the hardware groups Allwinner is creating “port and forget” specialists.

and also mentioned it’s been tried before, and failed:

This awful management style was practiced by most of the US semiconductor industry in the 1990’s. Most have discovered that it was a really bad way to do things and have reorganized.

This management style occurs when chip people end up in top management at these SOC companies. They treat everything like a chip and software is definitely not a chip. But these “chip heads” don’t know much about software so they can’t see how bad this organization design is for long term support. You can’t blame the “chip heads” for acting this way, it is the only area they have worked in. What they are doing is the correct model for making chips.

Now I don’t have detailed internal org charts for Allwinner. But I used to work for US companies that had this exact management structure before realizing how messed up it was. Only after a couple of very expensive failed launches of new chips because the software supporting them didn’t work did management change.

Another not-directly related complain is that Allwinner will also release the source code as tarballs, and they don’t have a git (or other revision control system) repository accessible to customers, for example like Amlogic or Rockchip already do. Instead they release those large tarballs, and then linux-sunxi community may import the u-boot/Linux kernel part to github, and work on them, although those days, they may prefer to focus on mainline rather than on Allwinner SDK releases.

Banana Pi BPI-M64 Board Gets Allwinner R18 Processor with Google Cloud IoT Core Support

May 18th, 2017 30 comments

Banana Pi BPI-M64 board was launched with Allwinner A64 processor, but a few days ago, I noticed the board got an option for Allwinner R18. Both processors are likely very similar since they are pin-to-pin compatible, and Pine64 was first seen with Allwinner R18, so I did not really feel it was newsworthy. But today, Google announced Google Cloud IoT Core cloud service working with a few app partners such as Helium and Losant, as well as several device partners including ARM, Marvell, Microchip, Mongoose OS, NXP… and Allwinner, having just announced the release of an Allwinner R18 SDK with libraries supporting Google Cloud IoT Core.

Let’s go through the board specifications first which are exactly the same as for the original BPI-M64 board, except for the processor:

  • SoC – Allwinner R18 quad core ARM Cortex A53 processor with Mali-400MP2 GPU
  • System Memory – 2GB DDR3
  • Storage – 8GB eMMC flash (16, 32 and 64GB options), micro SD slot up to 256 GB
  • Video Output / Display interface – HDMI 1.4 up to 4K resolution @ 30 Hz, MIPI DSI interface
  • Audio – HDMI, 3.5 mm headphone jack, built-in microphone
  • Connectivity – Gigabit Ethernet + 802.11 b/g/n WiFi & Bluetooth 4.0 (AP6212)
  • USB – 2x USB 2.0 host ports, 1x micro USB OTG port
  • Camera – MIPI CSI interface (which I guess you support parallel cameras via some kind of bridge)
  • Security – Hardware security enables ARM TrustZone, Digital Rights Management (DRM), information encryption/decryption, secure boot, secure JTAG and secure efuse
  • Expansion – 40-pin Raspberry Pi 2 somewhat-compatible header
  • Debugging – 3-pin UART header
  • Misc – IR receiver; U-boot, reset and power buttons;
  • Power – 5V via power barrel; 3.7V Lithium battery header; AXP803 PMIC

So from hardware perspective, there’s no advantage of getting the board with the new R18 processor. But the SDKs are somehow different, and based on Allwinner’s press release, only R18 processor gets Google Cloud IoT Core support.

Cloud IoT Core Overview

Some of the key benefits of Cloud IoT Core include:

  • End-to-end security – Enable end-to-end security using certificate-based authentication and TLS; devices running Android Things or ones supporting the Cloud IoT Core security requirements can deliver full stack security.
  • Out-of-box data Insights – Use downstream analytic systems by integrating with Google Big Data Analytics and ML services.
  • Serverless infrastructure: Scale instantly without limits using horizontal scaling on Google’s serverless platform.
  • Role-level data control – Apply IAM roles to devices to control access to devices and data.
  • Automatic device deployment – Use REST APIs to automatically manage the registration, deployment and operation of devices at scale.

Both Foxconn/SinoVoIP and Pine64 can offer Allwinner R18 platforms compatible with Google Cloud IoT Core via their Banana Pi BPI-M64 and Pine A64+ boards respectively.

SinoVoIP Releases $35 Banana Pi BPI-M2+ Board with Allwinner H2+ Processor

May 4th, 2017 10 comments

Banana Pi BPI M2+ board was first released with Allwinner H3 processor, but the same PCB can also be used with Allwinner H2+ and H5 processors since the processors are pin-to-pin compatible, and SinoVoIP intends to release three version of the board, and just launched BPI M2+ (aka BPI H2+) with Allwinner H2+ processor for $34.50 + shipping, $1.5 cheaper than the H3 version also listed on Aliexpress. If you shop around, and don’t order on the official SinoVoIP store, you may find cheaper price for the boards. As expected, the specifications have not changed apart from the processor:

  • SoC – Allwinner H2+ quad core Cortex A7 @ 1.2 GHz with an ARM Mali-400MP2 GPU up to 600 MHz
  • System Memory – 1GB DDR3
  • Storage – 8GB eMMC flash, micro SD card slot up to 64GB,
  • Video & Audio Output – HDMI with CEC support
  • Connectivity – Gigabit Ethernet, 802.11 b/g/n WiFi + Bluetooth 4.0 (AP6212)
  • USB – 2x USB 2.0 host ports, 1x micro USB OTG port
  • Camera – CSI Interface for 8-bit YUV42 CMOS sensor up to 1080p30
  • Expansions – 40-pin Raspberry Pi compatible header
  • Debugging – 3-pin UART header for serial console
  • Misc – Power, recovery, and u-boot buttons; Power and status LEDs, IR receiver
  • Power Supply – 5V/2A via power barrel (micro USB OTG port does not support power input)
  • Dimensions – 65mm × 65mm
  • Weight – 48 grams

The processors are not that different either, with Allwinner H3 supporting 4K video decoding and output up to 30 Hz, while H2+ is limited to 1080p60. The rest of the features look exactly the same. The company’s BPI M2+ page is all about the H3 version but most parts should be identical for the new boards. Supported operating systems include Android 4.4, Ubuntu 16.04 (Mate), Kano, Raspbian, Debian 8 and more according to the Download page, but none of them are likely to be working perfectly, and I’m not 100% sure they are working on the new H2+ board since they were all released last year, except Android 4.4 (Jan 2017). It might just be a case of updating the Device Tree (DTB) file however. [Update: I forgot the images are based on an ancient Linux 3.4 kernel, so not device tree here].

You may also wonder why Orange Pi Zero board with the same H2 processor sells for $7, while that new board goes for about $35… One of the reasons is that Banana Pi boards are  generally more expensive, but the price gap is mostly due to vastly different hardware specifications: 256 to 512MB DDR3, no eMMC flash, no HDMI output, Fast Ethernet, no camera support, smaller board, etc…