Buildroot For NanoPi NEO4 RK3399 SBC

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
Advertisements
Subscribe
Notify of
guest
11 Comments
oldest
newest most voted
tkaiser
tkaiser
1 year ago

> first completely contained build system

What does this mean?

L.Peter
L.Peter
1 year ago

maybe: “first completely SELF contained build system”?

tkaiser
tkaiser
1 year ago

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
tkaiser
1 year ago

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
SomeGuy
1 year ago

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

Jon Smirl
1 year ago

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… Read more »

dgp
dgp
1 year ago

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
tkaiser
1 year ago

> 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… Read more »

theguyuk
theguyuk
1 year ago

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
Tony mac
1 year ago

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
DaAlchemist
1 year ago

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

Advertisements