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.
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:
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.
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.
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;
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.
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…
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:
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 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:
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.
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
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 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 announcedGoogle 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
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.
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,
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…
This website uses cookies to improve your experience. We'll assume you're ok with this, but if you don't like these, you can remove them AcceptRead more
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.
