Archive

Posts Tagged ‘github’
Orange Pi Development Boards

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.

Official Rockchip Github Account and Wiki Launched

August 11th, 2016 6 comments

Following the popularity of RK3066 and RK3188 processors in 2013, a community of developers for Rockchip Linux and Android development was created with corresponding linux-rockchip github account, mailing list and #linux-rockchip IRC channel, and now most of the information can be gathered from development board manufacturers like Firefly. However, I’ve just been pointed out to some VA-API driver for Rockchip RK32xx processor, on rockchip-linux (not linux-rockhip) github account, with the following tagline:

An open source software for Rockchip SoCs, This site maintained by Rockchip

rockchip_githubThe only person currently registered to this account, Jacob Chen (陈豪), is a software engineer working for Rockchip, so it does indeed look to be official.

The github account also links to rockchip.wikidot.com with links to communication channels established by linux-rockchip community, and lots of entries about Linux, Android, U-boot, and so on, most of which are currently placeholders. So it still looks like work in progress, but maybe something to follow.

Github Releases GitHub for Windows Client

May 23rd, 2012 No comments

Github Windows IconGithub has announced the release of Github for Windows, a client that makes it easy to use Github in Windows XP, Vista, 7 and the upcoming Windows 8.

To get started, download GitHub for Windows. After the first part of the installation procedure, it will go through 2 eye raising steps: 1- Restart your computer, 2- Start Internet Explorer automatically (to complete the installation). Then you’ll just need to enter our credentials (or register) to get started with Github. It will automatically scan your local git repositories and ask you if you want to add then to Github. It will also show your Github repository as shown below.

If you want to clone other people Github repositories, you’ll need to go to github.com, select a repository and click on “Clone in Windows” button (See below)

Clone Github in WindowsThis will start cloning the repo in C:\Documents and Settings\User\My Documents\GitHub directory (default) and show the progress in Github Windows client.

Once a repository is cloned, you can check the history and status for each file in a user friendly way as well as commit changes and find, checkout, create and publish branches.

Github Changelog / History in WindowsThat’s a good start for a first version, but it would be interesting to see issue tracker integration and possibly access to the wiki and graphs.

Importing Source Code to Github

May 7th, 2012 4 comments

Github is a hosting service for software development projects using the Git revision control system. GitHub offers free accounts for open source projects (public repositories) and commercial plans for private repositories.

I’ve been using github for a while to clone source code, but I had never imported existing source code to github.

Here are the steps to follow:

  1. If you don’t have an account yet, sign-up for github.
  2. Setup github for Linux, Windows or Mac OS X.
  3. Create a repository as shown as explained here. You should now have a URL in github, something like [email protected]:user/repo_name.git, which we’ll use below.
  4. Go to the directory with your existing source code and create a local repo:
  5. Finally, type the commands below to add your code to your new repository:

That’s it, anybody should now be able to clone you code as follows:

NB: If your existing source code (or part of it) comes from a git repository, you need to delete existing .git* files and directory first:

or you won’t be able able to import your existing project to github and it will just upload an empty directory without source code.

Sources:

  1. http://stackoverflow.com/questions/2866872/how-to-upload-fresh-code-at-github
  2. http://stackoverflow.com/questions/4658606/import-existing-source-code-to-github