RK3399 Orange Pi

[pbies]

@chwe OPi is at this moment at seller's place (China) awaiting AliExpress decision to make me a refund. If that will not work, I'll get the board from them and then I will have time to mess with it. Research that I have done tells me, that there are some files needed to run Wi-Fi and Ethernet as I expect, and they are files in the below folders:

 

/system/etc/firmware/

/system/vendor/firmware/

 

I know that I've put some files in these folders and everything with Wi-Fi and Ethernet has began to work. However Wi-Fi was holding up the device after few hours of beign used and there was no possibility to run Ethernet at 1Gbps.

 

I am not exactly interested in Armbian in that case, but I can flash it, if all the hardware will be working properly with it (CPU cores, eMMC speed, Wi-Fi, Ethernet). I can build the software, I have Windows and Linux on my PC, but I have no certainty that at 16.04 like version of ARM OS the Ethernet will work at 1Gbps which is crucial here for my appliance.

[NicoD]

17 hours ago, chwe said:

So a free offer from my side.. If you still have the board (or did you send it back?), and you don't care to waste a few other hours with it, I happily waste a bit of time trying to get familiar with the buildscript to build your own image with armbians buildscript, doesn't involve any sort of 'official armbian support'. It's just me giving you some hints here and there. Obviously you need an x86_64 buildmachine running ubuntu (or a virtual box) on it. No guarantee it will work better after its.. 

@pbies

I would not doubt a second before saying, yes please. Thank you.
Having help with things like this teach you things you would not learn in a year of research on your own. I hope you still have your board.
If so, keep on it until you've fixed it. The knowledge you'd get from that would learn you a lot. It's ok to yell and curse on it. If it's getting too much, lay it on the side.

I'm also no Linux guru. I have to learn most on my own. Every time I think I undestand it, something else comes and makes me feel so dumb again.
Once you find all the pieces of the puzzle then it all just works like it should.

I've been a programmer(18 years ago), a pc technician and a network admin.
But I never worked with Linux until 2 years ago. When I started with Linux all my experience was almost useless.
 

For me that's the biggest reason why I'm hooked on it. It brings me back to the old days where every day was a new adventure.
If you could make it work with chwe then you are the one with the great image everybody wants.

Good luck

[chwe]

as far as I can see, the same wifi chip as for the firefly is populated on this board.. so by using the same drivers, and ensure it's properly defined in DT chances are high(er) that it should work 'as expected'. Using the same kernel as @hjc used for the firefly..

 

GbE is also the same, then it should be just adjustments in case DT definition changed slightly..  And if it performs badly:

https://github.com/ayufan-rock64/linux-build/blob/master/recipes/gmac-delays-test/range-test

 

10 minutes ago, pbies said:

I am not exactly interested in Armbian in that case, but I can flash it, if all the hardware will be working properly with it (CPU cores, eMMC speed, Wi-Fi, Ethernet).

well you've to be in case you want to give it a try.. I'll only help you.. build and test is then up to you... I prefer to mess with DT rather than fixing then broken things after the image is created.. From the sources, this is mostly a reference board with a few additional stuff populated (http://vamrs.com/sapphire-excavator).. There's not much an reason why things should not work. 

 

11 minutes ago, NicoD said:

Having help with things like this teach you things you would not learn in a year of research on your own.

doesn't need years, DT is good enough described in the documentation to learn it.. 

[pbies]

@chwe @NicoD thank you guys, I really appreciate your effort. Board is in China so I have no possibility to move on. I'll let you know what will happen next. Maybe some Skype in night hours would be good for that, I'll let you know in a private message. I have CEST time here but willing to go over night to make the things work, as you will have time to help me.

 

However support from seller is ready to help me giving ready solution, which I cannot accept. I was asking them for instructions, as I will reflash the board few times so their solution is not acceptable.

[Igor]

1 hour ago, pbies said:

I am not exactly interested in Armbian in that case, but I can flash it, if all the hardware will be working properly with it

But you should be if you want that "all hardware work properly". That is your best chance, perhaps the only one but sadly this board is not supported by Armbian. 

 

Board makers Android based Linux backed by a few inexperienced engineers is usually a little further then proof of concept. Getting from proof of concept to rock stable Linux cost thousands of hours/people/money and you are clearly not willing to pay for that. You expect that hardware maker will do the job of community of pro's? You can only rant about that they fool you and that you failed to do the homework prior to purchase. That's all.

This board is not as simple as proprietary device/toy backed with huge community (Raspberry Pi). One more to think which might open your mind: we provide much better software support but without rights to complain. Linux support comes always as is or you have to pay for it.

[pbies]

@Igor that is another one reason to make the seller refund me.

 

Nobody needs a hardware, when there is no proper software for it.

 

If company wants to make hardware omitting software, then it should take responsibility for its actions. No more theory needed for that.

[Igor]

8 minutes ago, pbies said:

Nobody needs a hardware, when there is no proper software for it.

 

We do  and others who play with it or do the low level software support. Latest hackers board were not meant to be used for the projects. Some needs months, some years to get to that level. Some never came.
 

8 minutes ago, pbies said:

If company wants to make hardware omitting software, then it should take responsibility for its actions. No more theory needed for that.

Main problem here is marketing which is in general a mixture of lies. They communicate OS support: Android, Debian, Ubuntu ... which is ofc only half true but since all makers repeat this it become a true. They give you some kind of operating system but this is Linux. It can be good or trash. Legally you can't do anything except asking for a refund without a reason. But you have 90 days on Aliexpress for that IIRC? After that, you can forget about. You learned something.

[pbies]

On 10/20/2018 at 9:59 PM, Igor said:

Main problem here is marketing which is in general a mixture of lies. They communicate OS support: Android, Debian, Ubuntu ... which is ofc only half true but since all makers repeat this it become a true. They give you some kind of operating system but this is Linux. It can be good or trash. Legally you can't do anything except asking for a refund without a reason. But you have 90 days on Aliexpress for that IIRC? After that, you can forget about. You learned something.

 

Well, not 90 days, but 30. Yes, for future I need to test the hardware in a shorter period of time and send it ASAP to get refund. In this case seller should act like a good EU company and just make a refund, not making any problems as they just did.

[chwe]

As far as I can see, the BSP doesn't look that bad actually.. DT is a bit messy opi.dts --> rk3399-excavator-sapphire.dtsi --> rk3399-sapphire.dtsi --> rk3399.dtsi so linked through a bunch of DTS to sport everything populated on the board.. the u-boot opi_defconfig is in fact a .config not a defconfig.. but you can extract the few bits you actually need (e.g. UART for debug, the rest looks mostly generic). The images are built with Rockchips build script, as far as I can see with their generic binary blobs for ram and their u-boot fork. Not really polished but ok-ish. 

They have a bunch of wifi/bluetooth binaries maybe they're crap, who knows.. Same chip as firefly.. so we could likely reuse those drivers.. and crappy GbE sounds likely like bad RX/TX settings in DT. cause they came untouched from the rk3399-sapphire.dtsi so, this would me my first bet to fix the problems.. 

 

But still don't get my board booting..  (the tv box, not that people think own a OPi Rk3399)

[pbies]

@chwe maybe some introduction: what are these abbreviations? BSP, DT, DTS, config file, defconfig file, dtsi.

[pbies]

Well, guys, I am just letting you know that:

1. I will get my money back for Orange Pi RK3399 or just sell it as it does not meet my standards, that is it has USB 2.0 instead of USB 3.0 and following the unresolved by support problems (Wi-Fi, Ethernet) I am rejecting this board as it does not comply with my needs
2. I was interested in Firefly RK3399 which has no bugs like OPi RK3399 but will not currently invest money in it, however it seems like a great board
3. Move my RPi 3 B+ in-house hosting to Virtual Private Server as I need more performance power

So this is how ends my adventure with single-board computers. From now on I will be using them just for testing purposes.

 

Anyway thank you all very much for help and comments. I appreciate your effort and wish you good luck in your battles with these quite fun parts of electronics.

[Myy]

I got my hands on an Orange Pi 3399 and I'm also fighting against U-Boot.

 

However, I backed up a few things before blowing everything up and being stucked on RockUSB.

 

1. I got the previous cmdline that was used to boot the Android image that was on the board

 

earlycon=uart8250,mmio32,0xff1a0000 swiotlb=1 androidboot.baseband=N/A androidboot.selinux=permissive androidboot.hardware=rk30board androidboot.console=ttyFIQ0 init=/init mtdparts=rk29xxnand:0x00002000@0x00002000(uboot),0x00002000@0x00004000(trust),0x00002000@0x00006000(misc),0x00008000@0x00008000(resource),0x0000C000@0x00010000(kernel),0x00010000@0x0001C000(boot),0x00018000@0x0002C000(recovery),0x00038000@0x00044000(backup),0x00040000@0x0007C000(cache),0x00600000@0x000BC000(system),0x00008000@0x006BC000(metadata),0x00002000@0x006C4000(baseparamer),0x00000400@0x006C6000(frp),-@0x006C6400(userdata) storagemedia=emmc loader.timestamp=2017-08-23_15:15:41 hdmi.vic=-1 androidboot.mode=emmc

 

2. I got the previous parameters.txt

 

FIRMWARE_VER: 6.0.1
MACHINE_MODEL: RK3399
MACHINE_ID: 007
MANUFACTURER: RK3399
MAGIC: 0x5041524B
ATAG: 0x00200800
MACHINE: 3399
CHECK_MASK: 0x80
PWR_HLD: 0,0,A,0,1
#KERNEL_IMG: 0x00280000
#FDT_NAME: rk-kernel.dtb
#RECOVER_KEY: 1,1,0,20,0
#in section; per section 512(0x200) bytes
CMDLINE: androidboot.baseband=N/A androidboot.selinux=permissive androidboot.hardware=rk30board androidboot.console=ttyFIQ0 init=/init
mtdparts=rk29xxnand:0x00002000@0x00002000(uboot),0x00002000@0x00004000(trust),0x00002000@0x00006000(misc),0x00008000@0x00008000(resource),0x0000C000@0x00010000(kernel),0x00010000@0x0001C000(boot),0x00018000@0x0002C000(recovery),0x00038000@0x00044000(backup),0x00040000@0x0007C000(cache),0x00600000@0x000BC000(system),0x00008000@0x006BC000(metadata),0x00002000@0x006C4000(baseparamer),0x00000400@0x006C6000(frp),-@0x006C6400(userdata)

3. I thrashed my partitions so I'm trying to recover them little by little.

 

I've been able to advance a little bit by downloading the RKTool_Linux.zip archive, and flashing the u-boot.img image at 0x2000 and the trust.img image at 0x4000 with rkdeveloptool. Yeah, I just used the archive for the .img .

 

./rkdeveloptool wl 0x2000 Linux_Pack_Firmware/rockdev/uboot.img
./rkdeveloptool wl 0x4000 Linux_Pack_Firmware/rockdev/trust.img

However, now I still have to understand how uboot is configured.

Currently U-Boot is configured to boot in 0 second. I'd like to put it to ~5 seconds, and then try to mount the whole eMMC through USB to install something in it ASAP.

 

I always hate the whole U-Boot ordeal on Rockchip systems.

 

[Myy]

Yeah, after trying to play with the "upgrade tool" for Linux provided by Orange Pi, I got the quiet Maskroom issue... And yeah, shortcuting pins doesn't do anything...

 

First these pins are not at the back of the board, like the documentation says, they're near the upper left of the eMMC chip, but they're useless.

 

Now, I guess I should buy some kind of shortcuter that I can lie on a board. Because rebooting while shortcuting two pins *that* close to each other is pretty difficult.

[Myy]

Ok, I was able to get a bootloader back, without shortcuting because shortcuting sucks, with one of their RK3399MiniLoader image.

I wonder why the official Rockchip loader didn't work...

 

Whatever, the command is :

 

./rkdeveloptool db /path/where/you/unpacked/Linux_rockdev/rockdev/RK3399MiniLoaderAll_V1.05_DDR666MHz.bin

Anyway, there's enough emotions for today.

I guess that the next logicial step should be : trying to understand how to compile a U-Boot and Miniloader for that board, so that I can have a configurable U-Boot...

Their images date from the 17th June 2015...

[Myy]

Well, it seems that you can also load the same .bin as the firmware with :

 

./rkdeveloptool ul /path/where/you/unpacked/Linux_rockdev/rockdev/RK3399MiniLoaderAll_V1.05_DDR666MHz.bin

 

And that gives you back the reboot the button... So much wonders...

 

It still doesn't boot anything useful, but at least you get messages printed on the serial line and that's recomforting... for 10 seconds.

[TonyMac32]

Haha.  I got frustrated and put down the RockPro64 for a little bit, the miniloader and RAM blobs seem to work *most* of the time, but then U-boot just plain kills it instantly and it sits there in stasis.

 

Spent my day getting used to my Chinese CNC engraver for PCB's.  Not bad, but I won't be doing anything too exciting with it.  ;-)

[Myy]

Well, I was able to compile an official U-Boot image, pack it in a "Rockchip" way and load it with rkdeveloptool.

 

To compile U-Boot, you'll need the arm-trusted-firmware.

To compile the arm-trusted-firmware for RK3399, you'll need the arm-none-eabi- toolset.

Unpack the toolset somewhere, set your PATH to /path/to/toolset/bin/

Check that arm-none-eabi-gcc can run.

 

Then, compile the ARM Trusted Firmware :

git clone https://github.com/ARM-software/arm-trusted-firmware.git --depth 1

cd arm-trusted-firmware

make realclean

make CROSS_COMPILE=aarch64-unknown-linux-gnu- PLAT=rk3399 bl31

cp arm-trusted-firmware/build/rk3399/release/bl31/bl31.elf /tmp

 

Then, compile U-Boot :

git clone https://github.com/u-boot/u-boot --depth 1

cd u-boot/

export CROSS_COMPILE=aarch64-unknown-linux-gnu- # Set this to your ARM64 GCC toolset prefix. Set nothing if you're compiling on an ARM64 machine.

export PLAT=rk3399

export ARCH=arm64

make firefly-rk3399_defconfig

make -j16 # N virtual cores. AMD Ryzen here.

cp /tmp/bl31.elf .

make u-boot.itb

cp u-boot-dtb.bin /tmp

 

Then get the "Rockchip tools" :

git clone https://github.com/rockchip-linux/rkbin.git --depth 1

cd rkbin/tools

./loaderimage --pack --uboot /tmp/u-boot-dtb.bin /tmp/uboot.img

 

Then get Rkdeveloptool :

git clone https://github.com/rockchip-linux/rkdeveloptool --depth 1

cd rkdeveloptool

autoreconf -i

./configure

make

cp rkdeveloptool /path/to/your/local/bin

 

Then get RKTool_Linux.tar.gz from Orange Pi : https://mega.nz/#F!K1BQFQjL!W9rYedaoGpV4y8vHfrGEfQ!ekYA0AwR

Extract it.

Extract the Linux_rockdev_2015-06-17_for_RK3399.zip archive contained in it

Copy the RK3399MiniLoaderAll_V1.05_DDR600MHz.bin contained in it to some place

Then do :

/path/to/your/rkdeveloptool db /path/to/RK3399MiniLoaderAll_V1.05_DDR600MHz.bin

/paht/to/your/rkdeveloptool ul /path/to/RK3399MiniLoaderAll_V1.05_DDR600MHz.bin

/path/to/your/rkdeveloptool rd

/path/to/your/rkdeveloptool wl 0x2000 /tmp/uboot.img

 

Wait for a bit and you'll get your new U-boot ! ... YAY ... At least you can configure this one...

[Myy]

This procedure was recovered from tidbits of my bash history, I might be missing a few things . So, to anyone who got an Orange Pi RK3399 : Give it a shot, tell me how it fares.

[Myy]

I burned a NanoPC T4 image on an SD card and was able to boot it, though I had to put the SDCard once the compiled U-Boot was booting, else the initial Rockchip U-Boot would b0rk and die.

 

The image provides some networking, X11 display but no USB support.

 

Now, I'm trying to understand :

- How I can update U-Boot again, since keeping the recovery button pressed doesn't work.

- How to copy the SDCard image onto the eMMC.

 

Then, if the eMMC can boot, the final question will be :

- How to put the whole thing at once (U-Boot + Linux image) with rkdeveloptool, so that new owners can install prebuilt image into the board.

[Myy]

Okay, I was able to transfer the image on the eMMC. Now, I'll try to get an image of the eMMC again and find a way to flash it "again".

[Myy]

Alright, I was able to do a full "get into MaskRom mode, restore the bootloader and firmware, restore U-Boot" and reboot on the already written eMMC.

 

Now, the last steps should be :

- Resize the NanoPC T4 armbian image partition of the eMMC. I'm using this image as a basis, since it works "just enough" on the Orange PI to get network and display.

- DD it.

- Flash the eMMC

- Rewrite the eMMC through this image.

 

Almost done.

[Myy]

# Install a U-Boot image and Loader image from Maskrom mode (Mute mode)

/path/to/your/rkdeveloptool db /path/to/RK3399MiniLoaderAll_V1.05_DDR600MHz.bin # Write the Bootloader
# Should display a few things on the serial console
# The 666Mhz image doesn't work for me
/path/to/your/rkdeveloptool ul /path/to/RK3399MiniLoaderAll_V1.05_DDR600MHz.bin # Which is also their firmware
/path/to/your/rkdeveloptool wl 0x4000 /path/to/uboot.img # Write the U-Boot image
/path/to/your/rkdeveloptool wl 0x6000 /path/to/trust.img # Write the Trust bits
# "Turn it off and on again" by unpluging and plugging the power cable back (Either the USB-C cable or the power plug)
# Rebooting through the little button generate "Tinkerboard"-esque issues with the eMMC, which won't be properly power up anymore.

 

[Myy]

# Flash an already prepared eMMC image in Maskrom mode (Mute mode)

/path/to/your/rkdeveloptool db /path/to/RK3399MiniLoaderAll_V1.05_DDR600MHz.bin # Write the Bootloader
/path/to/your/rkdeveloptool ul /path/to/RK3399MiniLoaderAll_V1.05_DDR600MHz.bin # Which is also their firmware
/path/to/your/rkdeveloptool wl 0 /path/to/eMMC.img # This will be STUPIDLY slow. You'll have to wait between 10 and 30 minutes.
# Unplug and plug the power cable back again, after the command finishes.

 

[gounthar]

I got myself one after reading "Orange Pi RK3399: HDMI recording on a budget" as I still have my project to record and broadcast talks in conferences with SBCs.
I will try to get my POC working with the OrangePi image, but will keep an eye on Armbian for this board, as I would like to use a consistent distro across all my devices.
By the way, would anyone have a recommendation for a heatsink/fan combo for this board?
Thanks.

[gounthar]

Would anyone know anything regarding the camera boards I could use with this OrangePi RK3399?
I have no documentation regarding the pinouts, the sensors supported, or anything else.
I had a look at the Firefly RK3399 board, and the OV13850 is cited, but I don't know anything else.

 

My goal would be to use CS camera so that I can use various  zoom lenses.

Thanks.

[gounthar]

I have a dumb question (yes, one more).
I have bought this TLL2USB, and don't know how to plug it into the OrangePi UART.

The documentation is sparse, and I did not find anything regarding which pin is what on the RK3399 board...

Can anyone help?

[NicoD]

16 minutes ago, gounthar said:

I have a dumb question (yes, one more).
I have bought this TLL2USB, and don't know how to plug it into the OrangePi UART.

The documentation is sparse, and I did not find anything regarding which pin is what on the RK3399 board... 

Can anyone help?

Here's the schematics for it.
https://mega.nz/#F!K1BQFQjL!W9rYedaoGpV4y8vHfrGEfQ
 

Mega is blocked here in Belgium, so I can't download it(without a lot of hassle)
Strange that ttl has 6 pins. I don't understand how that works, USB only has 4 pins. (no idea what cts or dtr is)
It should just work, I don't think those extra pins change anything.

[martinayotte]

24 minutes ago, NicoD said:

Strange that ttl has 6 pins. I don't understand how that works, USB only has 4 pins. (no idea what cts or dtr is)
It should just work, I don't think those extra pins change anything.

Right, No needs for the CTS/RTS as well as VCC. Only GND/TX/RX are needed ...

[gounthar]

Thanks for your input. I had already downloaded that document, but I am not able to find my way into it.
Unless it is as in this picture, TX on the left, then RX, then Ground... or strictly the opposite.

By the way. A colleague just dropped that on my desk

It physically can be connected to the board, but would it work? I must admit I know nothing about mSata, mini pcie and other variations...

[martinayotte]

32 minutes ago, gounthar said:

Unless it is as in this picture, TX on the left, then RX, then Ground... or strictly the opposite.

The GND Pin#1 is indicated by the white triangle ...