Jump to content

CSC Armbian for RK3318/RK3328 TV box boards

jock

By jock
in Rockchip CPU Boxes

 Share

Recommended Posts

fabiobassa

fabiobassa

Posted
Posted

@Wester_Minsk
Your contribute is highly appreciated, don't worry ! If you like to continue experiment is ok !

Let me ask you : have you electronic skills ? Would you be able to connect a uart /ttl converter to those wonderfull uart pads I see int he photos ?

 

спасибо

0
Wester_Minsk

Wester_Minsk

Posted
Posted
  On 9/12/2021 at 6:13 PM, fabiobassa said:

@Wester_Minsk
Your contribute is highly appreciated, don't worry ! If you like to continue experiment is ok !
 

Expand  

I'm not worried, I just didn't want to bother you, unless absolutely necessary.

I will continue working with pleasure.

I am interested in this topic.

 

 

  On 9/12/2021 at 6:13 PM, fabiobassa said:

@Wester_Minsk
Let me ask you : have you electronic skills ? Would you be able to connect a uart /ttl converter to those wonderfull uart pads I see int he photos ?

 

Expand  

I have a modest experience, but I can handle it.

I'm friends with a soldering iron.

I have:

ch340 usb ttl,

RS485 to UART,

TTL to RS485,

USB to RS485.

 

0
fabiobassa

fabiobassa

Posted
Posted

@Wester_Minsk

ch340 should be ok. Remember the speed of rockchip is NON STANDARD at 1500000, yes 1 million 500000 !
It will be interesting :
full bootlog of android
full bootlog  with sd inserted but android still present in eemc

full bootlog of armbian in emmc

full bootlog of armbian in emmc plus sd inserted

In few words the most case we have, the better understanding of things !


 

0
Wester_Minsk

Wester_Minsk

Posted
Posted
  On 9/13/2021 at 7:27 AM, fabiobassa said:

@Wester_Minsk

ch340 should be ok. Remember the speed of rockchip is NON STANDARD at 1500000, yes 1 million 500000 !
It will be interesting :
full bootlog of android
full bootlog  with sd inserted but android still present in eemc

full bootlog of armbian in emmc

full bootlog of armbian in emmc plus sd inserted

In few words the most case we have, the better understanding of things !


 

Expand  

I'll try to figure it out.

Give me a hint, how to read these logs?

Maybe there is a manual or a link to the topic with such works?

0
jock

jock

Posted
  • Author
Posted

@Wester_Minskthanks for the firmware and photos. I had a quick look into the device tree and it looked quite standard to me: no particular hardware like Power Management ICs or other significant differences from regular tv boxes.

I will take a deeper look and check other compatibility things soon!

2
fabiobassa

fabiobassa

Posted
Posted

@Wester_Minsk
 

  Quote

Give me a hint, how to read these logs?

Expand  


Usually programs such as putty, extraputty and other putty derivatives have the ability to export logs captured in real time on the uart to a file called putty.log


Then copy paste here or upload somewhere @jock or myself can have a look

0
jock

jock

Posted
  • Author
Posted

@Wester_Minsk thanks for the logs.

I extracted the ddrbin from the backup you posted above and made an image with that. The ddrbin is the thingy that initializes the DDR memory, an initialization with bad timings may be harmful for the system stability, so give a shot to this experimental image (it's a debian bullseye with command line only):

 

https://users.armbian.com/jock/rk3318/Armbian_21.11.0-trunk_Rk3318-box_bullseye_current_5.10.64_minimal.img.xz

 

edit: if you try this on sdcard, be sure to erase the eMMC completely first!

2
Wester_Minsk

Wester_Minsk

Posted
Posted

14 hours up time on eMMC, with  Doker +HA + Pihole load. 

At the beginning there was one freeze, after which I removed the parameter "rk3318-box-emmc-hc200"  from the armbian-config. 

Then it works stably. 

This is already much better than it was, the changes are obvious. 

I will pick up a good sdcard, and start from it to eliminate the eMMC problem and continue testing. 

3
jock

jock

Posted
  • Author
Posted
  On 9/15/2021 at 6:13 PM, Wester_Minsk said:

14 hours up time on eMMC, with  Doker +HA + Pihole load. 

At the beginning there was one freeze, after which I removed the parameter "rk3318-box-emmc-hc200"  from the armbian-config. 

Then it works stably. 

This is already much better than it was, the changes are obvious. 

I will pick up a good sdcard, and start from it to eliminate the eMMC problem and continue testing. 

Expand  

Cool, thanks for reporting!

My box was also stable for hours with your ddrbin, so I think I will promote it as the new default ^_^

1
  • jock changed the title to CSC Armbian for RK3318/RK3328 TV box boards
lucky62

lucky62

Posted
Posted
  On 9/20/2021 at 4:55 AM, RetroFan90 said:

is there an option to boot from USB 3.0 hdd?

and not sure how many devices have 2GB ram and some have 4GB

Expand  

My box x88 pro 10 is booting from USB 3.0 HDD but only from USB 2.0 port.
USB 3.0 is not supported by U-boot, I think...

0
jock

jock

Posted
  • Author
Posted

Nope, USB 3.0 is not supported at all in u-boot, and USB 2.0 support is a bit lousy on rk3318/rk3328 too.

U-boot non-core code is not the best, it's just "good enough" to let basic things work.

0
maximilliangreat

maximilliangreat

Posted
Posted

Hi!

I have several rk3318 boxes at hands (H96 Max, X88 Pro) - all of them android 10.

I've tried to burn Buster legacy and Focal mainline to sdcard, but no success - it still boots into android.

But when I burn Multitool image to same sdcard, all boxes boots fine to multitool.

Maybe I'm doing something wrong? I used balenaetcher to burn sdcard.

 

The boxes are not mine, so I cannot dissassembe them or reflash emmc.

0
AlwinLub

AlwinLub

Posted
Posted

I've got a HK1 Max with a RK3318 (ordered a 3328, but got a 3318 delivered).

X11 works, but it has screen tearing issues. The HDMI output stops completely (as in no signal) when adding a new cvt mode via xrandr.

I'm using the build with the supplied drivers, and i was wondering if maybe things will run better under Wayland/Weston.

It needs to run a Python Kivy-app with many animations, so screen tearing is not ideal.

 

I have no clue how to install/compile wayland/weston, but i got something running which returns the following error: 

[15:00:37.291] weston 5.0.0
               https://wayland.freedesktop.org
               Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
               Build: unknown (not built from git or tarball)
[15:00:37.292] Command line: weston
[15:00:37.296] OS: Linux, 4.4.213-rockchip64, #5 SMP Fri Apr 16 17:25:31 UTC 2021, aarch64
[15:00:37.301] Using config file '/home/user/.config/weston.ini'
[15:00:37.304] Output repaint window is 7 ms maximum.
[15:00:37.308] Loading module '/usr/lib/aarch64-linux-gnu/libweston-5/drm-backend.so'
[15:00:37.333] Failed to load module: /usr/lib/aarch64-linux-gnu/libweston-5/drm-backend.so: undefined symbol: gbm_bo_get_offset
[15:00:37.333] fatal: failed to create compositor backend

 

I would really appreciate If somebody would like to point me in the right direction.

 

dmesg output:

  Reveal hidden contents

 

 

All modules worked right out of the box; Wi-Fi, HDMI (video and sound), Ethernet and IR.

 

Thank you so much, @jock for all the hard work you've put in to this.

0
jock

jock

Posted
  • Author
Posted

@AlwinLub

Running weston on legacy kernel could not be a good idea since closed binary blobs probably miss some needed functionality.

I suggest you to try the mainline images in the first page or also the mainline image I posted for @Wester_Minskright above

 

The screen tearing can be due to the video being not synchronized to refresh rate: that's normal and hardly we can do anything.

If tearing  is very heavy with pieces of display moving up and down during redraw, it could be caused by the very same issue @Wester_Minskis having, so I suggest trying also the experimental image I did for him (which has no X11, it has to be installed manually)

 

Soon I will refresh images on first page.

0
AlwinLub

AlwinLub

Posted
Posted

I've downloaded the mainline image you've built for Wester_Minsk. I will try it tonight.

I've seen people getting rid of screen tearing using weston since some say it's more optimized than X11 ever was (i can't confirm this, but it's worth a try).

 

For a little context on the screen tearing: I'm developing a Kivy app for advanced multimedia features (like Spotify Connect, IPTV playback, remote playback from the box via other devices) all built in a single app.

It already is a very complex interface, but it's running great at 60-120 fps, but the tearing throws me off when quickly animating objects. It's using gl4es and it seems hardware accelerated because without gl4es it runs at about 5-20fps.

 

Thanks again for your quick reply and help. I'll keep you posted!

0
jock

jock

Posted
  • Author
Posted

Mainline image contains Lima driver which already has support for opengl. It is good enough to run Kodi, so I don't know how much good will run for your app. 3d games are still quite slow on mali 400/450 and Lima.

0
AlwinLub

AlwinLub

Posted
Posted

I've tested your build on the little HK1 Max, and it works like a charm. I've left it running for about 10 hours without any hiccups. There is however one problem, my Kivy app recognizes the Mali and Mesa libraries, but it will only show a black screen under X, Wayland and headless (sdl2) mode. Weston works like a charm and i can move windows smoothly, and they will fade smoothly upon opening and closing. I've noticed that while using weston, there was no (noticeable) screen tearing.

 

When i try to open the Kivy-app in headless mode (running from the command line directly) it only shows a black screen with a cursor.

The app will open without Open GL ES under X11, but i'll only get 2-10 fps because it uses llvm instead of Mali450 as renderer.

 

As i suspect this is an issue with Kivy, i've already posted a topic via the Kivy Discord-channel, and i'm now waiting for a reply.

 

Kivy log:

  Reveal hidden contents

 

I've also noticed that while running setup.py, kivy will search for the following files when it detects Mesa: 

mali_paths = (
    '/usr/lib/arm-linux-gnueabihf/libMali.so',
    '/usr/lib/arm-linux-gnueabihf/mali-egl/libmali.so',
    '/usr/local/mali-egl/libmali.so')

 

None of these files exist and i don't know if this could be the possible issue.

 

Thanks again for taking your time with me.

0
jock

jock

Posted
  • Author
Posted

@AlwinLub

I guess that's a Kivy issue. Actually the opensource driver for mali 400/450 is called lima. It's not up to the performance of the closed source driver, but feature-wise it should be much more standard compliant than the proprietary ARM Mali driver.

In fact I can run many opengl/opengles games with Lima that just don't work or work bad with Mali proprietary driver.

Performance is not stellar, but they indeed render correctly.

 

The mali_paths python tuple is specifically for the mali proprietary driver, that's why those files are not present in the mainline kernel. You can even manually install the mali driver (and disable the lima driver), but it is something I would not suggest, much better stick to opensource!

 

I'm sorting out some USB3 issue right now for rk3318, once there I would like to update the images with something more recent, like kernel 5.14 and debian bullseye/ubuntu hirsute, so you can also get a much more recent Mesa library with latest fixes and features.

 

In the meantime let's wait for Kivy forum people, I wonder if they already had some experience with Lima driver; in case they are not, it is nice to do some pioneering work :D

 

0
jock

jock

Posted
  • Author
Posted
  On 9/21/2021 at 11:20 AM, RetroFan90 said:

what about recompiling the overclocked dtb file i sent?

can it be used in a armbian build?

 

i am trying the most recent build and it is fairly stable

still testing ...

Cheers

Expand  

I didn't see any overclocked dtb file here around... however I'm not really fond of overclocking for these chips: they already are scrap parts that somehow reach the nominal frequencies. Some of the rk3318 boxes are also downclocked by manufacturers to 1.1 Ghz to be stable, overclocking is not something I would really love about. It's already hard to get the things together and make the board working stable enough. Adding another big source of instability... hmm I don't think it is a wise idea. :unsure:

1
AlwinLub

AlwinLub

Posted
Posted
  On 9/21/2021 at 6:51 PM, jock said:

I didn't see any overclocked dtb file here around... however I'm not really fond of overclocking for these chips: they already are scrap parts that somehow reach the nominal frequencies. Some of the rk3318 boxes are also downclocked by manufacturers to 1.1 Ghz to be stable, overclocking is not something I would really love about. It's already hard to get the things together and make the board working stable enough. Adding another big source of instability... hmm I don't think it is a wise idea. :unsure:

Expand  

 

I've got my board running at 1.3 Ghz with the legacy kernel. When pushing the hardware (by compiling or letting the CPU sit at 100%) the temperatures would regularly hit 80-90 degrees celsius, which i'm not very comfy with. With the new image, it's sitting at 1Ghz (via armbian-config) with max 70-75 degrees under heavy load. I could install a bigger heatsink, but as you said, the RK3318 is a sketchy chip.

0
AlwinLub

AlwinLub

Posted
Posted
  On 9/21/2021 at 6:46 PM, jock said:

@AlwinLub

I guess that's a Kivy issue. Actually the opensource driver for mali 400/450 is called lima. It's not up to the performance of the closed source driver, but feature-wise it should be much more standard compliant than the proprietary ARM Mali driver.

In fact I can run many opengl/opengles games with Lima that just don't work or work bad with Mali proprietary driver.

Performance is not stellar, but they indeed render correctly.

 

The mali_paths python tuple is specifically for the mali proprietary driver, that's why those files are not present in the mainline kernel. You can even manually install the mali driver (and disable the lima driver), but it is something I would not suggest, much better stick to opensource!

 

I'm sorting out some USB3 issue right now for rk3318, once there I would like to update the images with something more recent, like kernel 5.14 and debian bullseye/ubuntu hirsute, so you can also get a much more recent Mesa library with latest fixes and features.

 

In the meantime let's wait for Kivy forum people, I wonder if they already had some experience with Lima driver; in case they are not, it is nice to do some pioneering work :D

 

Expand  

 

I did some research on how to install the proprietary drivers, but it's quite hard to get in to for developers like me who are more used to the high-level stuff (python, lamp stack). There is info out there but it's too complicated for my simple brain.

I've also tried running the kivy build script with and without OpenGL ES, Wayland and X11 without any improvement. I've even tried using OpenGL Kivy with GL4ES without any result (it doesn't get recognized by Kivy). I would like to help out wherever i can because i feel projects like Armbian are simply quite amazing. Thanks again for your help and your awesome builds, i'm really looking forward to using the updated images with the newer Mesa library and crossing my fingers somebody smarter than me comes up with a solution, or that the updated images will 'just work' with Kivy.

 

  Quote

Mainline image contains Lima driver which already has support for opengl. It is good enough to run Kodi, so I don't know how much good will run for your app. 3d games are still quite slow on mali 400/450 and Lima.

Expand  

 

On the Legacy kernel images with GL4ES, it runs at 60-80 fps without any (noticeable) dips. Kivy exclusively uses OpenGL/OpenGL ES to render the interface.

0

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept