NanoPi NEO4 is the smallest and cheapest RK3399 board so far, featuring the hexa-core processor into a $45 60×45 mm single board computer. FriendlyELEC usually provides decent documentation and software support for their boards, but Flatmax was not satisfied with the build system provided by Rockchip / FriendlyELEC. So he took the matter into his own hands, worked on and released a buildroot external tree for building NanoPi NEO4 SD card images.
Flatmax mentioned this is the first completely contained build system for the NanoPi NEO4. The build process is explained on Github, and basically goes like this:
- Clone buildroot
1git clone git://git.busybox.net/buildroot buildroot.neo4 - Install dependencies
12sudo apt-get install -y build-essential gcc g++ autoconf automake libtool bison flex gettextsudo apt-get install -y patch texinfo wget git gawk curl lzma bc quilt - Clone NEO4 buildroot external tree
1git clone git@github.com:flatmax/NanoPi.Neo4.buildroot.external.git NanoPi.Neo4 - Build the system
123. NanoPi.Neo4/setup.sh yourPath/buildroot.neo4mkdir yourPath/buildroot.dlmake - Flash it to the micro SD card
1sudo ./output/images/sd-fuse-rk3399/fusing.sh /dev/sdX buildroot
Just replace /dev/sdX with your actual SD card device.
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
> first completely contained build system
What does this mean?
maybe: “first completely SELF contained build system”?
And what should this be?
I mean when providing OMV images for those FriendlyELEC RK3399 devices two months ago all I did was checking out
github.com/armbian/build, uncommenting a single line to get all the OMV stuff added to the final image (customize-image.sh functionality) and then fired up one singlecompile.shcommand that created a fully functional image from scratch and even burned the image afterwards (using Etcher of course — verify is important!).To elaborate on the question or why I was excited about the mentioning of someone providing the ‘first completely contained build system’ — I thought he would have been able to get rid of the Rockchip BLOBs but in fact he didn’t and also uses them. So still no open source SPL implementation in the wild for RK SoCs and we need to rely on BLOBs to boot these devices. 🙁
Not 100% true. There are full TPL/SPL implementations for some Rockchip SoCs, including DRAM init. See http://git.denx.de/?p=u-boot.git;a=tree;f=arch/arm/mach-rockchip
I like buildroot and we use it in out projects. You can point it to the uboot and kernel trees. It also supports external tools chains. There is another option that copies in an overlay tree of files. That’s how we copy in the blobs. Once you set all of that up a single make command will build everything – uboot, kernel, user space. Output is a SD Card image. If you want to make a flash image there are hooks to support that too.
User space can be configured through a nice menu config system. That allows you to only select the packages you want and to minimize the image size. We were using 1.5GB debian images from the vendor. With buildroot we cut that down to 300MB.
The source control aspect is also really good. I have a single git repo that can reproduce my entire system. As upstream adds patches or moves to later versions it is easy to git merge those changes in.
What Jon said and…
If you have a fast desktop it’ll probably save you time over using something with a package manager. On many SBCs apt/dpkg is so slow you’ll forget what you started installing by the time it finishes. In a lot of cases you want to just run some python scripts or whatever.. buildroot is perfect for this and you might even be able to get an image so small it’s viable to boot over TFTP and save messing around with SD cards.
> On many SBCs apt/dpkg is so slow you’ll forget what you started installing by the time it finishes
Yep, but this is mostly related to random IO write performance of the storage in question. I did a time consuming test recently with an apt/dpkg orgy involving installation of ~400 packages on the same SBC (NanoPi M4) with exactly same Debian Stretch comparing 7 different SD cards and an el cheapo eMMC: https://github.com/ThomasKaiser/Knowledge/blob/master/articles/A1_and_A2_rated_SD_cards.md#results-overview
Almost 18 minutes vs. less than 3 minutes difference just due to different random write performance of the flash storage 🙂 And in the past I had a bunch of even more awful 4GB SD cards with way less random IO performance but fortunately they all died in the meantime 🙂
Maybe important: the test used an Armbian Stretch variant which implies ‘special’ filesystem mount parameters: 600 sec commit interval vs. 5 seconds with ext4 defaults. With default commit interval package management might take a lot more time (to be confirmed… but not by me).
While trusting another service can introduce risk, would there be any benefit to compiling by use of a online service. Then just downloading the result? ( providing resulting image is not to large )
To second tkaiser, a standard Armbian image for this board is also a single command, and writes the image to SD of your choice.
The big advantage of Buildroot is, that you can build Images that run completely in Ram. That is some thing Armbian can not do..