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, but they replaced Allwinner R40 with an Allwinner V40 processor, removed some features, and used the 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 showed the Banana Pi BPI-M2 Berry board with Allwinner R40 instead of Allwinner V40.
Banana Pi BPI-M2 Berry
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.
Allwinner Business Units
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 a 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 your 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 works and releases its own SDK, and based on different Linux and Android versions for different SDKs, 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 from running. 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 complaint 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.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
