Jump to content

CSC Armbian for RK3318/RK3328 TV box boards


jock

Recommended Posts

@jock ok then i will wait an eventually new kernel by you, i wanted to get the benefits of 5.19 kernel but if wifi is broken then is useless to me.

 

PS: i did some modding in this free time of holidays, from Aliexpress with bonus new user at 0,01€ [see photos]

I got better (lower) temps also at fan off...difference in quantity of adesive thermal paste put by stock....
With fan on i hit 26° but at almost 0 load (firewall forwarding wifi-to-eth and pi-hole demon), if i attach HDMI i hit 30° stable.

 

 

DC-5V-12V-24V-3010-30mm-30x30x10mm-ventola-di-raffreddamento-con-dissipatore-di-calore-ventola-BGA.jpg

photo_2023-01-01_17-48-36.thumb.jpg.bc58fa30228b550b4e85cc0a630b8e39.jpgphoto_2023-01-01_17-48-41.thumb.jpg.31131958143ae1972e1ecd2daddc2c80.jpgphoto_2023-01-01_17-46-13.thumb.jpg.4814bfb445443c58525cc20e407d7171.jpg

Edited by MR01
Link to comment
Share on other sites

@MR01 Well I don't know if there will be newer kernels with libreelec patches imported like the special 5.19 one I did; it took me quite an amount of time to refactor the existing armbian patches and at last they went to waste despite they seem to provide compatibility and performance benefits.

Link to comment
Share on other sites

@jockthen can you give me some hints for headers so that i can compile myself the specific wifi driver for my realtek chip? Or is impossibile to use wifi at all in that kernel?

 

I think the solution to this question will be usefull to many others that want use wifi on 5.19 kernel.

 

Thanks

Link to comment
Share on other sites

Hi,

 

I'm fairly new to armbian, used it on a RaspberryPi 2 and an OrangePi Zero before, but only with "standard" images and no deeper digging into Linux specifics.

 

Now I have an RK3318 based TV box (RUPA 4GB/32GB). It boots right up with Multitool and I can backup and restore the original eMMC image and also erase eMMC.

Booting into armbian (from a different SD card than multitool, brand new SanDisk Ultra 32GB UHS-I) only works once for the first time. After reboot or shutdown armbian does not boot again.

I only found 1 way to boot into armbian again: 

1) boot multitool 

2) switch SD cards

3) select reboot from multitool menu

This works sort of fine for usage with monitor and keyboard, but is difficult to handle in headless mode via SSH.

 

Has someone experienced the same issue? Can someone give me a hint on a solution?

Maybe there has already been an answer in the 42 previous pages, but to be honest, I only read the first 5 and last 5 of them 😉

 

jock: Thank you very much for your work and support in this forum!

 

best regards,

kfj

 

Link to comment
Share on other sites

@kfj Hello, I imagine you are powering off and on the board when you experience such issue, aren't you?

 

The brand name of the tvbox says nothing about the board itself, so it is not helpful for other digging. Although sometimes it happens on a board of mine that on reboot the board does not boot from sdcard and then requires another power cycle to boot again.

 

Anyway you may want to install armbian on internal eMMC, since it looks it works ok on your board.

Link to comment
Share on other sites

Figured I would report back while I thank the community for all the work on these! 

 

I got a cheapo rk3318 / X88 Pro 10 running Android 11 off Amazon Canada (https://www.amazon.ca/dp/B08NDGG95P

 

Stupid me I didn't test an image on SD before flashing to emmc so, would not boot, bricked it pretty quickly - shuffled around micro soldering to short the clock pins, booted back into multitool and scrambled for hours before I realized you need to REMOVE THE SHORT right after booting if you want to access the emmc and erase / reflash it.

 

 After a few more hours of tinkering I figure only the 5.15.35 images are working on this (Armbian_22.05.0-trunk_Rk3318-box_bullseye_current_5.15.35_minimal) 

for some reason everything else I have tried is not working. 

 

This version of the board doesn't seem to have appeared around here yet, it's X88-Pro-B-RK3318-D4-V1.6 

 

In any case, I'm up and running that image, flashed to EMMC - going to have this thing run some 3d Printers with Klipper :D

 

20230107-223816.jpg

 

Link to comment
Share on other sites

On 1/8/2023 at 3:19 PM, snowphish said:

 After a few more hours of tinkering I figure only the 5.15.35 images are working on this (Armbian_22.05.0-trunk_Rk3318-box_bullseye_current_5.15.35_minimal) 

for some reason everything else I have tried is not working. 

Hello, good you finally had the board running happily armbian.

It would be nice if you could detail a bit over the non-working images: kernel version, where you did pick them, do you get something on the serial port if you have any, do the led is blinking while you try to boot or it is steady... You should be able to burn a testing image and a sdcard, plug it in and the system should boot from sdcard instead of internal eMMC.

Link to comment
Share on other sites

@jock Is it some planes making one more stable current release as the weekly edge builds ?

Im using one box for HA thread testing (need arm64 and BT) and its very bad is its loosing BT then the edge kernel is being updated (that have happening) ?

 

The RK3228 is possible finding in the armbian archive but the RK3318 is not being there and current stable is not build for it.

 

Thanks in advance for your work on our devices !!!

Link to comment
Share on other sites

6 minutes ago, MattWestB said:

@jock Is it some plans making one more stable current release as the weekly edge builds ?

Im using one box for HA thread testing (need arm64 and BT) and its very bad is its loosing BT then the edge kernel is being updated (that have happening) ?

 

The RK3228 is possible finding in the armbian archive but the RK3318 is not being there and current stable is not build for it.

 

Thanks in advance for your work on our devices !!!

@jock @Igor I have been thinking along the same lines for the aml-s9xx-box builds.  While having the weekly builds is great, they are very unstable, being built on current master with edge kernel and the unstable debian and ubuntu userlands.  While that is all good for testing purposes, it is far from desirable for running anything in a production environment (yes there are crazy people like me that use TV boxes for production servers).  Now that current has moved to 6.1 for meson64 and I suspect rockchip current will try to get to 6.1 soon, it would be nice to have stable builds based on a stable master, current kernel and supported userspace (i.e. jammy currently for ubuntu) for the TV Box targets, IMHO.

Link to comment
Share on other sites

@MattWestB @SteeMan I've been thinking about that too and I would have liked to ask @Igor in the last release meeting but I did not want to be off-topic.

Perhaps the community images are "too edgy", and perhaps it is more savvy to produce images with current kernel, then upgrade to edge via apt install, than starting with edge kernel, that is not guaranteed to work correctly, and then downgrade to current.

 

I just had a very brief test after burning an image with kernel 6.1 and, against all my thoughts because I was sure I already checked kernel 6.1, it does not boot on my rk3318 box, while kernel 6.0 had no troubles in booting (broadcom bluetooth was broken although).

 

Did not have the time and tools at hand to dig into the issue (moving into a new house...), but I hope to check better very soon, perhaps during the weekend.

 

About moving rockchip64 to 6.1 for the next release, I'm a bit reluctant and maybe a bit more testing is required.

32 bit rockchips although seems rather acquainted with 6.1, no issue and no troubles so far (my HA testing rig on rk322x has an uptime of 10 days and doing a variety of jobs that is pretty amazing for the piece of junk it was :D )

Link to comment
Share on other sites

@SteeMan You is not alone running important test rigs / production system on this (CY) hardware :-))

@jock I like the very edge build then having one test system and trying getting things that is not working and getting it fixed so its very OK.

But im missing is image with more stable user space and kernel for installing for not critical production / test system for other things like my HA Matter / Thread (need Arm64) and HyperHDR that shall not being broke more times in the months and need reinstalling the complete system every time and must patching for getting the BT working for pairing Matter / thread devices.

 

Way not adding it to normal armbian archive like RK322X and getting UB and DEB in Desktop, CLI and Minimal in latest major release of armbian so user can install "experimental stable" build that is getting updates and is not so likely being broken ?

 

By the way the USB is the most crappy part in this boxes then the system cant handle reconnect of USB devices and is oft blocking all USB posts (both USB 2 and 3) if one device is getting problems and must re power the box for getting USB working.

I think next box is being one aml-s9xx-box that have better hard / software implementation of the USB.

Link to comment
Share on other sites

12 hours ago, SteeMan said:

it would be nice to have stable builds based on a stable master

 

I am open for this idea - one of you needs to take responsibility to make it happen - I'll just run the build once is in the system. Can be discussed on regular developers meetings.

Link to comment
Share on other sites

2 hours ago, MattWestB said:

By the way the USB is the most crappy part in this boxes then the system cant handle reconnect of USB devices and is oft blocking all USB posts (both USB 2 and 3) if one device is getting problems and must re power the box for getting USB working.

Never had particular problems with USB on rk322x/rk3288, but on rockchip 64 bit (in particular rk3328) the USB3 implementation has some issue that makes it quite a bit troublesome. I never investigated very througly in it though.

Link to comment
Share on other sites

6 hours ago, MattWestB said:

Way not adding it to normal armbian archive like RK322X and getting UB and DEB in Desktop, CLI and Minimal in latest major release of armbian so user can install "experimental stable" build that is getting updates and is not so likely being broken ?

I'm not sure I understood what you mean with "normal armbian archive" and "experimental stable" terms

What I really would like is one and only one place for public images to be produced and deployed; at the moment this place is the github community repository and it is perfectly fine to have one single place with the images, just missing the stable kernel images for the reason I said above (ie: edge kernel is not guaranteed to always work).

 

The other images you find here and there, especially on users.armbian.com/jock URL, are old or experimental images, but surely unmaintained and prone to be erased sooner or later.

 

For all the other needs, there is always the option to build a custom image, it will receive regular updates via apt just as well as public images do.

Link to comment
Share on other sites

I recently flashed several different system images to my MX10. Incidentally, the `multitool` is _amazing_ for this. Fantastic tool.

 

My MX10 has `MXQ-RK3328-D4` printed on the board. Here's my results:

 

`Armbian_22.02.0-trunk_Renegade_bullseye_edge_5.16.8_xfce_desktop.img.xz`
 

Flashed fine, boots fine, HDMI fine, no ethernet support.

 

`Armbian_22.08.0-trunk_Rk3318-box_bullseye_edge_5.18.10_minimal.img.xz`

 

Flashed fine, boots fine, HDMI has regular horizontal black lines across it. Text will scroll off the screen implying that the system doesn't "know" the black lines are there.

 

`Armbian_22.11.1_Renegade_jammy_current_5.15.80.img.xz`

 

Flashed fine, boots fine, HDMI fine, no ethernet.

 

`Armbian 22.11.1_Rockpro64_jammy_current_5.15.80.img.xz`

 

Does not boot.

 

`Armbian_22.11.0-trunk_Rk3318-box_bullseye_edge_5.19.15_minimal.img.xz`
 

Flashed fine, boots fine, HDMI fine, ethernet works. Running `apt get upgrade` after this pushes a new kernel which on reboot demonstrates the HDMI scanline problem. That kernel ends up being `Linux rk3318-box 6.0.10-rockchip64 #22.11.1 SMP PREEMPT Wed Nov 30 11:20:25 UTC 2022 aarch64 GNU/Linux`

 

I'm happy to do more testing if it helps bisect toward understanding when this HDMI regression was introduced. Is there an open/known issue I could post information to?

Link to comment
Share on other sites

@Eli Ribble Thanks for testing. The missing ethernet is quite strange on that board. I have a sample of that board and it works fine on mine; maybe they are two different revision, but don't know.

 

About the HDMI problem, the 5.19.15 image you probably found here in the forum is an experimental image that uses the libreelec patches: when you upgraded the kernel, you got installed the standard armbian kernel without the libreelec patches and so the issue came back.

 

For now, the discussion to implement those patches is stuck, so don't expect seeing them as in armbian kernels soon. Sorry, but that's not my choice 😕 (see here for reference

Link to comment
Share on other sites

Hi. My usb3 and a jmicron sata-USB-adapter is reseting loop. Dmesg log looks like this ...

 

[  151.012061] scsi host0: uas_pre_reset: timed out
[  151.012328] xhci-hcd xhci-hcd.0.auto: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
[  151.012387] sd 0:0:0:0: [sda] tag#7 uas_zap_pending 0 uas-tag 1 inflight: CMD
[  151.012402] sd 0:0:0:0: [sda] tag#7 CDB: opcode=0x28 28 00 00 00 10 00 00 00 08 00
[  151.012566] sd 0:0:0:0: [sda] tag#7 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=DRIVER_OK cmd_age=16s
[  151.012581] sd 0:0:0:0: [sda] tag#7 CDB: opcode=0x28 28 00 00 00 10 00 00 00 08 00
[  151.012590] blk_update_request: I/O error, dev sda, sector 4096 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[  151.012836] blk_update_request: I/O error, dev sda, sector 4096 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[  151.012866] Buffer I/O error on dev sda, logical block 512, async page read
[  151.052340] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[  151.316238] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=0x07 driverbyte=DRIVER_OK
[  151.544542] usb 5-1: reset SuperSpeed USB device number 2 using xhci-hcd
[  151.571332] scsi host0: uas
[  151.580279] scsi 0:0:0:0: Direct-Access     JMicron                   2201 PQ: 0 ANSI: 6
[  151.584688] sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/466 GiB)
[  151.584722] sd 0:0:0:0: [sda] 4096-byte physical blocks
[  151.585079] sd 0:0:0:0: Attached scsi generic sg0 type 0
[  151.585220] sd 0:0:0:0: [sda] Write Protect is off
[  151.585235] sd 0:0:0:0: [sda] Mode Sense: 53 00 00 08
[  151.592690] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[  151.593439] sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)
[  151.730149]  sda: sda1 sda2
[  151.733670] sd 0:0:0:0: [sda] Attached SCSI disk

 

The adapter has no problem when use in usb 2.0 and work in PC USB 3.0.

 

Which one has problem , rockchip cpu, sata-usb adapter , linux or something else? 

 

edit: This adapter works in android usb3. This adapter may not compatible with linux driver.

Edited by tommy
Link to comment
Share on other sites

I have managed to install your image

Armbian_22.05.0-trunk_Rk3318-box_jammy_current_5.15.35_xfce_desktop.img

into my RK3328 box. Everything works, but the performance is simply atrocious, next to unusable, both with the default XFCE and with LXDE. How comes this box works so poorly with 4gb ram and a quad-core CPU? I have installed one of your stable legacy images into an older, RK3228 with only 1gb ram, and that box is way more fluid and useable. I cannot figure what is the issue, since Firefox and chromium are basically unusable with such a massive lag and delay loading even their main menu, with or without Hardware Accel enabled.

Any tips? It is a shame that such a nice minicomputer cannot be made justice.

Here is a pic of the box: HTB1_xJsnTZmx1VjSZFGq6yx2XXaM.jpg

Link to comment
Share on other sites

9 hours ago, Sergey Artemov said:

Hello, I accidentally stumbled upon your topic, but I have another question - is it possible to somehow force the multitool to start with USB 2.0 if the SD card slot does not work. Thanks in advance.

Yes, but you have to install armbian on the eMMC because the stock bootloader does not allow USB boot (armbian bootloader does).

Link to comment
Share on other sites

8 hours ago, Roszek said:

into my RK3328 box. Everything works, but the performance is simply atrocious, next to unusable, both with the default XFCE and with LXDE. How comes this box works so poorly with 4gb ram and a quad-core CPU? I have installed one of your stable legacy images into an older, RK3228 with only 1gb ram, and that box is way more fluid and useable. I cannot figure what is the issue, since Firefox and chromium are basically unusable with such a massive lag and delay loading even their main menu, with or without Hardware Accel enabled.

Any tips? It is a shame that such a nice minicomputer cannot be made justice.

4gb of ram and quad-core cpu are not a guarantee of good performance. The rk3328 armbian branch lacks some DRM kernel optimizations that rk3228 has, and in fact the desktop performance is a bit better on rk3228. You could try KDE Plasma or gnome: despite being fully-featured desktop environments, they work much better than xfce or lxde.

Ah, on xfce you should also disable composition from Settings -> Windows Manager Tweaks to improve performance.

Link to comment
Share on other sites

Hi everyone, first of all congratulations for the great work you've done so far.

 

I got a X88 Pro 10 from Amazon, with RK3318 / 2GB RAm / 16GB EMMC. the mainboard is exactly the one posted in this comment (X88 PRO-B-RK3118-D4-V1.6 / 2021-09-25).

 

I've installed the minimal build from the initial post, after running rk3318-config I also got WiFi working.

 

Everything seems to run fine, except the SPDIF output. I can see it from aplay -l, but if I try to run speaker-test selecting the corresponding soundcard I get no sound at all.

 

With the original Android11 image the SPDIF interface works without problems.

 

The very same image running on an old T9 with RK3228 processor doesn't have the same problem, SPDIF works fine. It could be that the dts for RK3118 requires different spdifout nodes, compared to RK3228?

Link to comment
Share on other sites

@Dario Murgiahello, very glad you had no issues installing the image.

About the SPDIF issue, actually I don't remember having really tested it on rk3318, I will check as soon as I can. Perhaps the alsa mixer worth a check, maybe the volume is low or there is some other setting (mute?) preventing the audio from spdif.

Link to comment
Share on other sites

21 hours ago, jock said:

About the SPDIF issue, actually I don't remember having really tested it on rk3318, I will check as soon as I can. Perhaps the alsa mixer worth a check, maybe the volume is low or there is some other setting (mute?) preventing the audio from spdif.

there are no controls for the SPDIF interface under alsamixer (also no controls for the other two, ANALOG and HDMI, but they work)

 

besides this small problem, I'm facing issues to boot local-built images from EMMC. the minimal image provided by jock in the first post can boot from SD and from EMMC without problem (EMMC flashed with multitool, image Armbian_22.05.0-trunk_Rk3318-box_bullseye_current_5.15.35_minimal).

If I build locally the image with the armbian build script (I cloned the official the repo yesterday), the image does boot only from SD and only if I have the jock's image pre-flashed on EMMC.

I didn't apply any change on the default configuration for rk3318-box (current, kernel 5.15.90). One week ago I tried to boot a local-built image on a RK3328 device with empty EMMC and it worked without problems.

 

I did log dumps from the UART debug port with several combinations of content on SD and EMMC, I've uploaded on my google-drive.

the big difference I see is the RAM frequency of the loader, 333MHz vs 666MHz. if there is a loader on EMMC with 333MHz, the loader on the SD is ignored and boot from SD works fine.

Looking at the jock's fork, the DDR_BLOB has been changed in June, and his working image is from April.

 

I also noticed the uboot version is different, compared to the local build.

 

Any idea or hint to solve this problem? I can't use the images provided by jock and then upgrade, I need to be able to compile working images for other reasons.

 

 

Edited by Dario Murgia
Link to comment
Share on other sites

@Dario Murgia It looks like the ddrbin @666Mhz is not working on your board. I was suspecting such bad behaviour from long time because in the past some other people with X88 lamented booting problems but no serial logs were provided, now there are some evidences that frequency is not universally compatible. That's a shame because 333Mhz for the DDR is limiting performances a lot, but I guess I will revert that change and use the ddrbin @333Mhz for the time being; I suggest you to take the previous binary from that commit and use that one to build your images.

Link to comment
Share on other sites

hi jock,

 

yesterday I reverted the change on config/boards/rk3318-box.tvb, selecting the 333MHz bin. I also selected a previous version of uboot (v2022.04 instead of v2022.07).

with those two changes I have an image booting fine from SD with an empty EMMC. I don't know if the change on uboot was really necessary, I don't think so but i'll test it later on.

 

regarding the issue with SPDIF, I'll try to obtain the .dtb from the original Android ROM, do you think it might help to verify if the spdif nodes are different?

Edited by Dario Murgia
Link to comment
Share on other sites

3 hours ago, Dario Murgia said:

I don't know if the change on uboot was really necessary,

v2022.07 should work fine either too; the ddrbin was clearly the issue there.

 

3 hours ago, Dario Murgia said:

regarding the issue with SPDIF, I'll try to obtain the .dtb from the original Android ROM, do you think it might help to verify if the spdif nodes are different?

It can indeed; the spdif nodes are surely different because the original android rom surely uses kernel 4.4 and in the meantime the syntax on how to declare the sound nodes changed. There may be some different gpios involved though, and the original dtb may help detecting them.

Link to comment
Share on other sites

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.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines