Jump to content

Firefly RK3399 support efforts (potential csc board?)

hjc

By hjc
in Rockchip

 Share

Recommended Posts

hjc

hjc

Posted
Posted

Recently I've been trying to build Armbian for Firefly RK3399, since I've purchased this board last year, and it has been lacking proper software support for a long time.

Here is my fork https://github.com/hjc4869/build/tree/development

 

Basically, It is a copy & paste of what's already done to support Odroid N1, by replacing the Hardkernel's kernel to what Firefly provides (an older 4.4.77 kernel), and replacing the Hardkernel u-boot with rockchip u-boot.

I created a new 'firefly' board family for convenience. Also tried to build the image with some other kernel variants (Rockchip 4.4 bsp and mainline 4.17-rc6) without success, still investigating reasons.

 

The image boots and runs flawlessly as a headless OS, but that's far from complete.

 

Remaining work:

 

Kernel

1. Replace mali r13 driver with r14. Since r14 supports fbdev and xf86-video-armsoc while r13 does not. Fbdev performance is terrible, though.

2. (Maybe) Use the latest rockchip 4.4.126 kernel instead of Firefly's old (and buggy) 4.4.77, since this branch seems to be a port-and-forget one, while Rockchip kernel is still been actively developed.

 

Userland

1. Rockchip xserver and libmali

This makes the desktop experience much better (glamor, and enables GLES for X11 window programs), but there are some problems related to desktop composition. In Firefly's official Ubuntu release, the desktop composition works just fine, but I haven't figure out how to enable that with my own build. Firefly team never provide any scripts/docs to build a usable rootfs.

Even without this, the desktop is definitely usable, including Chromium/Firefox, with mesa llvmpipe properly disabled.

 

 

2. Firmware

Rockchip's rootfs-build repo contains several firmware required by the board (WiFi/BT/DP/etc). These firmware are currently not packed into the image.

 

3. Rockchip Gstreamer for hardware video decoding

 

4. Bluetooth

This is troublesome even with Firefly's own Ubuntu image. They put some sort of magic in a `/usr/local/bin/enable_bt` script, and it must be executed right after user logon, or Bluetooth simply won't work.

Really terribly documented, never want to mess up with it again.

 

5. Sound

The board uses a rt5640 chip, which needs some tweaks related to ALSA.

 

Most userland tweaks are likely to be the same as other RK3399 boards, given the only difference should be bootloader/kernel related stuff.

Will it be possible to merge these into armbian/build as a community supported board in the future when RK3399 board family gets stable? (Of course with cleanup, e.g. use the rk3399 board family instead of a dedicated firefly family)

 

TonyMac32

TonyMac32

Posted
Posted

Someone in the devs would need the hardware.  As these RK3399 boards are a bit expensive to buy without need, I'm not sure that will happen.  Some ideas though, should you put together a solid PR against the Armbian build system:

 

Kernel:  Mali Midgard, right?  current rockchip is r18, but there are some config woes.

 

Rockchip x:  yes, there are some issues, @JMCC is better understanding from his work on RK3288, the other "fast" Rockchip processor.  He has the 3288 set up for mali and mpp, once we get the newest Rockchip drop stabilized again...

 

Firmware:  Can be pushed to the appropriate folder in the build system.

 

Rockchip gstreamer: See my earlier statement, gstreamer is not the only option.  :-)

 

Bluetooth:  AP6356S, is this correct?  You may want to completely ignore the rockchip bluetooth rfkill system and use something like (obviously different based on the chip/gpio's/HCIattach used):https://github.com/armbian/build/commit/ac8d0d86687007c894caf18b0ba85d99c38eb8b1#diff-720eab911ea238eb515a7dd36d99234e

  • The service calls the script on boot and enables it, then, if called again, resets the BT and re-initializes it.  It also required defining the UART fully in the DTS, as by default, at least on Tinker it didn't have the CTS and RTS assigned under the UART.

Sound:  can be adjusted during image build time in the script (Tinker does this, as do some others IIRC)

 

For a merge, you would need to make the needed changes and put in a PR, and some more discussion would have to go on about the potential risks/etc of supporting it.

Igor

Igor

Posted
Posted
17 minutes ago, hjc said:

Will it be possible to merge these into armbian/build as a community supported board in the future

 


Sure, why not, but we need to stick to one RK3399 family and for CSC targets it is recommended that atf and u-boot patches - if needed - are defined per board. 

 

The best legacy kernel is probably from Pine64 or/and Rockchip upstream while I am not aware how far is mainline support. Currently, we haven't done much - we have few Odroids N1 and we are about to get FriendlyArm T4, ... so I expect more progress with RK3399 during the summer time.

TonyMac32

TonyMac32

Posted
Posted
3 minutes ago, Igor said:

we have few Odroids N1 and we are about to get FriendlyArm T4

My addiction got the best of me and I picked up a RockPro 64 as well.  ;-)

 

OK, back to the cellar...

2
hjc

hjc

Posted
  • Author
Posted
17 hours ago, Igor said:

The best legacy kernel is probably from Pine64 or/and Rockchip upstream while I am not aware how far is mainline support.

Managed to boot rockchip kernel with two patches (this and this), so far it worked fine (headlessly. Mali Android drivers are causing compiler errors). These two patches are just to revert two commits in rockchip kernel (first and second). The first change is causing strange clock issues on Firefly board, and the second one causes a kernel panic.

These may be board specific issues. AFAIK RockPro64's kernel source included these changes (Odroid N1 and NanoPC T4 did not).

 

Maybe I should keep my fork and wait for a few more months, until it is decided which specific rk3399 kernel source will be used by other boards.

TonyMac32

TonyMac32

Posted
Posted
3 hours ago, hjc said:

Mali Android drivers are causing compiler errors)

Yes, TinkerBoard is likewise all messed up wrt Mali drivers with latest Rockchip updates.  Enable the mali_pwrsoft option.

hjc

hjc

Posted
  • Author
Posted
31 minutes ago, guidol said:

and it seems you did this also at the NanoPC T4? - https://twitter.com/hjc4869/status/1005321514432933888 

;)

TC4_armbian_small.jpg

 

Yes, with some patches, in the same repo. Only succeeded to boot the 4.4 legacy kernel, though.

 

Copy the device tree from FriendlyELEC's kernel, and it boots with Rockchip u-boot and kernel. Their kernel modifications are mostly for their accessories, like several LCD screens, touch screens, etc.

 

It's a rough port, especially for u-boot. Since T4 does not have upstream u-boot support, and I only spent a few minutes creating the dts file from the Linux one. (Still a lot of bugs, like USB is not functional, so you cannot load kernel from a USB device. but that's sufficient for booting linux kernel from emmc/sd)

 

As for 4.17 mainline kernel, it's still far from complete.

1. CPU-bound tasks are not pinned to the Cortex-A72 core automatically

2. HDMI not working

3. USB3/USB-C not working

 

so I did not spend time investigating on that running on T4. It may be a lot better later this year, though.

2
chwe

chwe

Posted
Posted
On 6/3/2018 at 9:52 PM, Igor said:

The best legacy kernel is probably from Pine64 or/and Rockchip upstream while I am not aware how far is mainline support.

Let's hope that they don't mess up the kernel to much/often, so that a 'rockchip-default' branch is not often needed to bring back the devices... :P 

 

Having all RK devices under the same kernelsource (with different kernelconfigs for RK3288/RK3328/RK3399 could be beneficial due to only one kernel has to be checked for updates). 

 

On 6/3/2018 at 9:15 PM, hjc said:

This makes the desktop experience much better (glamor, and enables GLES for X11 window programs), but there are some problems related to desktop composition. In Firefly's official Ubuntu release, the desktop composition works just fine, but I haven't figure out how to enable that with my own build. Firefly team never provide any scripts/docs to build a usable rootfs.

You may discuss with @JMCC he did a lot of tests and adjustments for the RK3288 with HW-acceleration (I think also for desktop).  Probably he has some useful tips. :) 

 

JMCC

JMCC

Posted
Posted
On 6/3/2018 at 9:15 PM, hjc said:

This makes the desktop experience much better (glamor, and enables GLES for X11 window programs), but there are some problems related to desktop composition.

From my many tests with the RK3288, regarding desktop composition you have basically four options:

  • Use framebuffer, so you will have no 3D nor video acceleration, but you will be able to enable desktop compositing.
  • Use the rockchip xf86-video-armsoc driver: It will provide 3D and video accel, though with very poor performance. You can enable desktop compositing, with an even higher performance loss.
  • Use a version of the Rockchip X server with glamor enabled, that has this commit reverted. It will give you good performance, but will be unstable. You can choose either to use the commit referenced here (not available in the main tree), or the older rockchip-1.18 branch. But those are unstable, and the old version doesn't have video vsync.
  • Use the rockchip-1.19 version of the driver, which does not allow compositing, but is stable and gives good performance in everything else.

Personally, I don't think compositing is worth losing all the other features. Plus, it is possible that future versions of the mali driver can fix the issue. More info here.

1
hjc

hjc

Posted
  • Author
Posted
5 hours ago, codnoscope said:

It seems OP overclocked his firefly RK3399 to 2.2GHz! Very nice!

Overclock isn't really recommended, and I'm just doing that for fun. Though, 2.2/1.8GHz is the max supported clock speed in Rockchip's driver code, so it's not really "over"clocking.

There's a slight performance gain, but it does not mean that you can run workloads that you can't do before the overclock. (In other words, it does not change the board's use case) It just made the numbers a little better, by significantly sacrificing power consumption and cooling.

 

5 hours ago, codnoscope said:

Have you tried the offical aluminium case for your firefly?

No, I don't think that it could be more efficient than a fan.

martinayotte

martinayotte

Posted
Posted

@hjc, I've used your dev tree to make an image for my newly received NanoPC-T4 !

Thanks for your work ! Do you planing having this effort merged into main branch by issuing a PR ?

 

1
tkaiser

tkaiser

Posted
Posted
1 hour ago, martinayotte said:

Do you planing having this effort merged into main branch by issuing a PR ?

 

The discussion how to proceed with the various upstream kernel branches for RK devices started and unfortunately also ended here: https://forum.armbian.com/topic/7498-nanopc-t4/ (no idea why there are zero responses to @ayufan's ideas)

 

Same here: https://forum.armbian.com/topic/7661-one-bsp-kernel-f-rk3399rk3328-and-rk3288/?do=findComment&comment=58352

 

 

hjc

hjc

Posted
  • Author
Posted
5 hours ago, martinayotte said:

@hjc, I've used your dev tree to make an image for my newly received NanoPC-T4 !

Thanks for your work ! Do you planing having this effort merged into main branch by issuing a PR ? 

I'd be glad to do so, but recently I've just graduated and begun working full time, and not having much time to re-organize those development efforts into a solid PR. I'm also lack of usable RK3399 boards for developing & testing, since some of my home services have already been deployed to NanoPC T4. I'll buy some NanoPi M4/NEO4 boards once available.

 

Besides, I still have some other boards to play with (Dragonboard 820c based on Qualcomm APQ8096), so maybe I could not contribute to Armbian for RK3399 directly these days. Sorry for that.

martinayotte

martinayotte

Posted
Posted
11 hours ago, TonyMac32 said:

Do you have a RockPro64?

Hi Tony ! Yes, I've received one last week. But until now, I'm only been able to run it with Ayufan build stretch-minimal-rockpro64-0.7.9-1067-arm64.img.xz, trying the image built for T4 on it didn't even start booting.

martinayotte

martinayotte

Posted
Posted
7 hours ago, hjc said:

Sorry for that.

No problem, I understand ... Time is always the missing ingredient (for me too) !

I didn't compared your tree with the Armbian master yet, is there tons of changes or only few ?

 

hjc

hjc

Posted
  • Author
Posted
1 hour ago, martinayotte said:

No problem, I understand ... Time is always the missing ingredient (for me too) !

I didn't compared your tree with the Armbian master yet, is there tons of changes or only few ?

 

Only a few changes. It's basically about creating a new board family with appropriate kernel/u-boot config and patches (called "firefly" here, but actually should be called rockchip64) and adding two boards' definition (Firefly-RK3399 & NanoPC T4).

 

see https://github.com/hjc4869/armbian-build/compare/56d614d1e5cb4d7ec3c803cfcf83bbe5bad04622...6d59a4fc93b46fd4de86bc8b1fa6a0adee4e7bc4

martinayotte

martinayotte

Posted
Posted

@hjc Thanks for doing the compare from your side, that way, I won't forget something.

I will try to merge that from my side as soon as "time ingredient" get back in stock ... ;)

hjc

hjc

Posted
  • Author
Posted

I've fixed the build on GitHub, and it now uses latest 4.4.143 kernel from rockchip.

Armbian seems to have changed a lot in recent days, haven't got time to rebase my work.,and haven't verified what works and what does not, but at least it builds and runs on my Firefly RK3399 (NanoPC T4 not tested).

TonyMac32

TonyMac32

Posted
Posted

Very nice, built a 4.4 image, working well so far!  Need to dig up an nvme, suggestions on an affordable one?  My build machine and main desktop aren't giving up theirs.  ;-)

Igor

Igor

Posted
Posted
1 hour ago, TonyMac32 said:

Need to dig up an nvme, suggestions on an affordable one?


Samsung OEM SM961 512GB, new or used is also good enough for such use, 150-100USD?

 

Yes, works well. Some small things, overclock, :) @JMCC media scripting, ...

Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept