Bananapi BPI-P2 Zero New Image Release Armbian Bullseye

BPI-P2 Zero

This release is for bananapi P2 Zero development board which is based on Allwinner H3.

When starting the image file for the first time, you need to register a user and set the language and time zone to ensure that the graphical interface can be accessed properly.

%E5%BE%AE%E4%BF%A1%E5%9B%BE%E7%89%87_20221012164210

Graphical interfaces

image-20221012143208455

About this release

Startup Video

1 Like

Thanks. Is there a server version of this OS?

1 Like

I just ran a quick test and it works well! Bravo! Tested: Ethernet, USB Keyboard and a 800x480x60p Waveshare 7" HDMI Touchscreen display. I will run more tests over the weekend.

I would like to customize this build, I’d like to preseed settings, drop the desktop and preinstall some software. Sorry I’m new to Armbian, which branch do I need to check out in order to build this myself? Has this been built under Debian (which I prefer) or Ubuntu (which I assume)?

Anyways, thanks a bunch for this upload (I actually received my first eval board yesterday), looks really promising.

1 Like

I ran further tests, mounted the eMMC (but didn’t do anything with it), and tested 11 of the GPIOs (the internal logical numbering of the physical GPIO pins differs from the Raspberry Pi’s numbering, but I was able to map them myself using the schematics). I tested two of my applications, one is a unmodifed binary (built for the Raspi) and another is a python3 application using pygame (based on SDL2) and pyserial. Both work, but I mention SDL2/pygame because the kernel is missing CONFIG_INPUT_MOUSEDEV option (thus /dev/input/mice is missing) which slightly breaks SDL2 and anything that’s built upon it (workaround is to set environment variable SDL_NOMOUSE=1).

I evaluated Armbian enough to know that I will not be using it, even though it is a very nice distribution. For example, I need the two-partition split with a small FAT32 boot partition. I would like to build u-boot, kernel and device tree myself (which I have done several years ago for an Olimex A13-OLinuXino, I have experience in this field), I have a whole build script using Debian’s multistrap ready to go which builds my custom SD card images.

Again I kindly ask for config files (kernel and u-boot) and device tree source files, and for directions to the sources used (repositories and branches). Also if there is anything special to know how to build these components, please document them or point me to where it is documented. At this point I believe U-Boot sources are most important, I do not believe that /usr/lib/u-boot/bananapi_m2_zero_defconfig is the correct config, and I’m not sure whether /usr/lib/linux-u-boot-edge-bananapim2zero_22.11.0-trunk_armhf/u-boot-sunxi-with-spl.bin is the U-Boot image that was used to build this Armbian release (first tests failed, but I might be wrong).

Thanks for any help on this.

According to your response, you failed to see both, basic and core advantages. Perhaps sales team is not doing it right, but in technical sense it does exactly what you want.

Armbian started 10 years ago as a simple debootstrap script, but today its a serious build system with which you can build your image, your kernel, your u-boot, your desktop or a whole distribution. With customisation on all levels. Positioning here.

And why is that a problem? Build image with fat boot partition, ext4 boot parition, root with f2fs, btrfs, … You didn’t get to manuals? https://docs.armbian.com/Developer-Guide_Build-Options/

Image here is just a demonstration of hardware functionality, while Armbian is a build system that can build many things.

Armbian was designed to provide this in as simple as possible manner. How you could miss that?

But since there is no official Armbian for P2 Zero, only Sinovoip can help you with details regarding this particular hardware. They / you will need to push it upstream that it could work as expected.

I’m sorry, I did not intend to sound critical or disrespectful regarding Armbian, in fact I have the greatest respect for your work.

I will evaluate Armbian deeper, but here is my current situation. I started my build script 4 years ago with an Armadillo board, then added support for A13-Olinuxino, then for the RaspberryPi 3B+/Zero-2W and now I have to decide whether to add support for this BananaPi or to switch over to Armbian.

For a build, each of my “boards” can be combined with one of our “projects” which we distrubute this way, the script creates bootable images, all settings preseeed such that the only thing left on first boot is to expand the rootfs, no user interaction (our products don’t have a keyboard or mouse).

Rootfs is created with Debian multistrap from jessy up to bullseye, the script can configure, patch (as needed) and compile both kernel and u-boot, everything is 100% automated to create reproducible builds, however I based it on a Amd64 Debian host VM, not Ubuntu.

My script also builds 32- and 64-bit Windows executables of Python projects by invoking PyInstaller via wine.

Armbian was designed to provide this in as simple as possible manner. How you could miss that?

No, I didn’t miss that. I had created an Ubuntu VM, installed Armbian and ran a test build for another BananaPi (bananapim2zero/edge/bullseye). I read through the Armbian sources to understand customize-image.sh and the hook pre_customize_image right before that (outside the chroot) as I can do much of what I need at these two points.

But then I couldn’t figure out where to call debconf-set-selections for preseeding apt packages dash, locales, keyboard-configuration and console-setup, I had the wrong impression that Armbian was single-partition rootfs+bootfs (sorry for missing that), and I simply thought the whole Armbian boot sequence (which is excellent for the general purpose case) deviates too much from my needs, and this is where I stopped evaluating, prematurely as it seems.

Having said all that, please understand that it still appears to be less work to just build bootloader and kernel myself (as I have done previously for the A13-Olinuxino) and integrate it into my own rather than to migrate over to Armbian.

Didn’t take it that way. I am trying to understand how and where you could have issues.

For non user interaction is again everything prepared. But by default it generates image for humans.

Ofc. The idea we have here is that Armbian take care of the OS / standard things , you take care of the customisation / overlay as presented in example.

Ubuntu is just officially supported host, while you can build almost on anything. CI is testing builds under 4 different host environments and two architectures.

It is difficult to unify boot process among those weird boot sequences define by hardware. Outside this its just a standard systemd way.

Its subjective matter, sure.

Builds systems are usually long term solutions where you need to invest some time to understand them. I used Yocto in some period of my life and it took me years to understand it little … This is much easier.