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.
Share this:
FacebookTwitterHacker NewsSlashdotRedditLinkedInPinterestFlipboardMeWeLineEmailShare

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress

ROCK Pi 4C Plus

11 Replies to “Buildroot For NanoPi NEO4 RK3399 SBC”

      1. 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, uncommenting a single line to get all the OMV stuff added to the final image ( functionality) and then fired up one single command that created a fully functional image from scratch and even burned the image afterwards (using Etcher of course — verify is important!).

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

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

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

        1. > 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:

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

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

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

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

Leave a Reply

Your email address will not be published. Required fields are marked *

Khadas VIM4 SBC
Khadas VIM4 SBC