0
pbies

Orange Pi RK3399 and Armbian

Recommended Posts

Hello All,

 

I recently bought Orange Pi RK3399 and had some problems with it. At this moment I've solved most of them, but still no luck with such an old OS like Ubuntu Server 16.04 or Debian 9 which were provided by the manufacturer (images to flash).

 

What I am thinking now is to move this board to Armbian. Will it work?

 

How should I in this case organize the partitions on eMMC and where to load kernel and rootfs?

 

I don't see this board in supported ones.

Share this post


Link to post
Share on other sites
2 hours ago, pbies said:

What I am thinking now is to move this board to Armbian. Will it work?

Of course it could work, but as I said before, you'd need at least mainline or a recent (2017.x) u-boot working. This means if your board vendor does not provide mainline u-boot support (like most RK3399 devices except Firefly), you need to somehow write a u-boot device tree for your board, just like what I did for NanoPC T4. Unfortunately, you need to do this by yourself.

 

2 hours ago, pbies said:

How should I in this case organize the partitions on eMMC and where to load kernel and rootfs?

Armbian use a single ext4 partition, so you don't need to mess up with those default Rockchip partition layout (7 partitions is really a mess for an SBC)

 

BTW, I don't know exactly how Orange Pi RK3399 works, but normally, RK3399 will boot from SD card if eMMC/SPI flash is not available or there's no u-boot SPL on eMMC/SPI flash. You may erase the eMMC (blkdiscard) and use an SD card for debugging, which is more convenient.

Share this post


Link to post
Share on other sites
1 hour ago, hjc said:

normally, RK3399 will boot from SD card if eMMC/SPI flash is not available

 

This would be not a bad idea, if the SD card wouldn't be few times slower than the eMMC.

 

As I have good SD card, exactly microSD, it does not give reasonable speeds on this board. 20MB/s for linear read is not enough.  eMMC is giving me 200MB/s in average. I suspect that OS is too old to provide faster speed for this SD card. If it is possible to run it faster.

 

I am not enough advanced about these boards to mess with u-boot.

Share this post


Link to post
Share on other sites
5 hours ago, hjc said:

Armbian use a single ext4 partition, so you don't need to mess up with those default Rockchip partition layout (7 partitions is really a mess for an SBC)

funnily mediatek had 5 or so... :P I think this comes from this 'fallback' methods for updates.. An SBC is allowed to fail.. some random TV box/router shouldn't end in a boot loop when doing updates.. But as soon as  u-boot works and is able to read ext4 this doesn't matter anymore.. :) 

 

3 hours ago, pbies said:

As I have good SD card, exactly microSD, it does not give reasonable speeds on this board. 20MB/s for linear read is not enough.  eMMC is giving me 200MB/s in average. I suspect that OS is too old to provide faster speed for this SD card. If it is possible to run it faster.

seq. read write performance doesn't matter.. read through @tkaiser comments on this topic...

 

for sure, good eMMC will perform better. But thinking about eMMC before the board boots from SD-Card is not worth to think about.. step by step...

 

4 hours ago, pbies said:

I am not enough advanced about these boards to mess with u-boot.

read through this one:

and this one:

 

I think @hjc and me were beginners when we started our board bring up... you can learn it by reading and testing.. There's a android source code folder in orangepi's downloadsite.. Look inside, look what's there and what is missing. RK provides a bunch of stuff on their github repo. And there are several RK3399 boards in WIP to get some background how stuff is done. But cause nobody else with experience in board bring up has this board at hand, you've to do the work on your own. Bring up a device which you don't have at hand to test doesn't work. 

Share this post


Link to post
Share on other sites
27 minutes ago, chwe said:

seq. read write performance doesn't matter

 

For some use cases they do matter but unfortunately some users prefer questionable 'benchmarking' methods and ignore the importance the block size makes when accessing storage.

 

That's why common tools like hdparm, dd and pv all simply suck when it's about to determine maximum storage performance or insights in general:

 

SBC users seem to not want to accept most simple facts:

  • testing with hdparm is always wrong since it uses just 128k block sizes when reading from disk. 128k were a sufficient number last century when the defaults were defined since back then the fastest HDD storage was slow like hell. Today it's just a joke to test with 128k.
  • testing with pv is always wrong when not using -B switch (which no one does) since buffer size will then be calculated dynamically [1] and you get random numbers
  • testing with dd can result in 'good' numbers if dd flags and block size has been set accordingly. Problem is: Usually these informations are not shared when dd 'benchmark' numbers are published so you simply not know whether testing was correct or just the usual 'benchmarking gone wrong'. That's why looking at dd numbers is almost always useless

[1] quoting pv manual page:

-B BYTES, --buffer-size BYTES
    Use a transfer buffer size of BYTES bytes. A suffix of "K", "M", "G", or "T" can be added to 
    denote kibibytes (*1024), mebibytes, and so on. The default buffer size is the block size of 
    the input file's filesystem multiplied by 32 (512KiB max), or 400KiB if the block size cannot 
    be determined.

 

Share this post


Link to post
Share on other sites
On 8/29/2018 at 8:03 PM, tkaiser said:

For some use cases they do matter but unfortunately some users prefer questionable 'benchmarking' methods and ignore the importance the block size makes when accessing storage.

  

That's why common tools like hdparm, dd and pv all simply suck when it's about to determine maximum storage performance or insights in general:

I agree with this. When I run storage benchmarks for my review videos, (using Phoronix), I run through the full gamut of options, (block sizes, reads, writes, etc), as well as using several different tools. This usually ends up taking a week to complete just the storage benchmarks, but gives a *MUCH* better picture on overall performance.

 

Share this post


Link to post
Share on other sites

I've received my OrangePi-RK3399 recently ...

Just for trials, before doing any real development, I gave a try with a NanoPC-T4 4.19.y image compiled a month ago, and it worked "as is", even eMMC and WiFi is running fine.

That it is a good starting point !

 

Of course, to be able to boot from SDCard, we need to short the eMMC clock using the test point TP50265 :

 

image.png

Share this post


Link to post
Share on other sites
4 hours ago, Arinze Izukanne said:

Were you able to load armbian and boot from eMMC?

Yes !

4 hours ago, Arinze Izukanne said:

Do the onboard sensors Hall, Gyro, Compass etc work with the NanoPC-T4 4.19.y image?

No needs of NanoPC-T4, since I've created an OrangePi-RK3399 template, so you can build an image for that.

Sensors are appearing on /dev/i2c-4, so you simply need to get proper software/library to use them.

4 hours ago, Arinze Izukanne said:

How stable is the board?

Pretty stable !

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
0