Buildroot For NanoPi NEO4 RK3399 SBC

Orange Pi Development Boards

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.
Buildroot NanoPi NEO4 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:

  1. Clone buildroot
  2. Install dependencies
  3. Clone NEO4 buildroot external tree
  4. Build the system
  5. Flash it to the micro SD card

    Just replace /dev/sdX with your actual SD card device.
Support CNX Software - Donate via PayPal or become a Patron on Patreon

11
Leave a Reply

avatar
2 Comment threads
9 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
8 Comment authors
DaAlchemisttheguyukdgpSomeGuyTony mac Recent comment authors
  Subscribe  
newest oldest most voted
Notify of
tkaiser
Guest
tkaiser

> first completely contained build system

What does this mean?

L.Peter
Guest
L.Peter

maybe: “first completely SELF contained build system”?

tkaiser
Guest
tkaiser

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 single compile.sh command that created a fully functional image from scratch and even burned the image afterwards (using Etcher of course — verify is important!).

tkaiser
Guest
tkaiser

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. 🙁

SomeGuy
Guest
SomeGuy

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

Member

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.

dgp
Guest
dgp

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.

tkaiser
Guest
tkaiser

> 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).

theguyuk
Guest
theguyuk

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 )

Tony mac
Guest
Tony mac

To second tkaiser, a standard Armbian image for this board is also a single command, and writes the image to SD of your choice.

DaAlchemist
Guest
DaAlchemist

The big advantage of Buildroot is, that you can build Images that run completely in Ram. That is some thing Armbian can not do..