Jump to content

CSC Armbian for RK3318/RK3328 TV box boards


jock

Recommended Posts

9 hours ago, Gausus said:

 

Found info from this post:

 

Some general info her on u-boot for RK. https://u-boot.readthedocs.io/en/latest/board/rockchip/rockchip.html

 

1. Can you boot from Multitool.img ? , IF no then its will not be possible to boot Armbian from sdcard.

2. If you can , burn Armbian 22.08 - Debian image found inn first post  to sdcard.

3. Burn Multitool.img to another sdcard or mount image on Linuxpc

 

Manuel mount multitool.img

From terminal.

 

cd $HOME/Downloads/

 

# find first unused device  , /dev/loop(24)

losetup -f

 

# Mount img on /dev/loop24

 

sudo losetup -P /dev/loop24 multitool.img   

 

# Open file-browser  MULTITOOL/bsp/

# copy uboot.img and trustos.img to $HOME/Download Linuxpc

# Insert sdcard to linuxpc and find dev of sdcard / often last sdX

 

lsblk -f  

 

# My sdcard is assigned /dev/sdf

 

# DD uboot and trust IMG to sdcard armbian

# Replace /dev/SDCARD  to your dev for sdcard like sdf


 

sudo dd if=uboot.img of=/dev/SDCARD seek=16384 conv=fsync 
sudo dd if=trustos.img of=/dev/SDCARD seek=24576 conv=fsync

 

If this not work you can copy the generic DTB rk3318-box.dtb form multitool.img to sdcard.

You find generic DTB on root /  multitool.

Copy this to /boot/dtb/rockchip SDCARD to overwrite DTB on Armbian image.

 

Or burn older Armbian img to test if they boots form sdcard when Android on internal storage.

 

Happy booting!!

 

 

So I build a minimal image from sources with Armbian 22.08.0-trunk Bullseye with Linux 5.15.58-rockchip64 and burned it with multitool without erasing emmc this time.
Connected sigrok-pico to uart tx line and pulseview at 3mhz and 100M samples uart protocol decoder. It was a bit of a pain using a logic analyzer first time but I found a login prompt and so replaced sigrok-pico with ch340g usb uart and was able to login and create account without any issue this time. No wifi so I just stuck ethernet cable to my router and dhcp gave ip address to it. I connected hdmi and now that works as well. It seems that only 2gb of 4gb ram is detected but I can see that this kind of issues has been discussed before on this thread.


So to sum it up, it seems 5.18 kernel has no hdmi but if you stick ethernet cable to a dhcp capable router one can get the ip and ssh into it - you probably want to use 5.15 kernel for the time being though. Perhaps something along the lines of git-bisect to get to the bottom of the hdmi issue. I do find it a bit strange that hdmi did not seem to work immediately after flashing. Perhaps one needs to replug the hdmi cable after it has booted.

 

Feel like a winner already, thanks to everyone working on this!
 

Edited by Aapo Tahkola
Link to comment
Share on other sites

8 hours ago, Aapo Tahkola said:

So to sum it up, it seems 5.18 kernel has no hdmi but if you stick ethernet cable to a dhcp capable router one can get the ip and ssh into it - you probably want to use 5.15 kernel for the time being though. Perhaps something along the lines of git-bisect to get to the bottom of the hdmi issue. I do find it a bit strange that hdmi did not seem to work immediately after flashing. Perhaps one needs to replug the hdmi cable after it has booted.

Yep, it is way strange, "unfortunately" HDMI works fine on my board with both 5.15 and 5.18, so I can't experiment such issue.

dmesg may provide some useful information about, there is a dmesg attached to an older post were there was clearly a drm error I never encountered before and can't guess the reason causing it.

 

Anyway congrats to bringing the board up!

Link to comment
Share on other sites

On 8/2/2022 at 1:43 PM, jock said:

Yep, it is way strange, "unfortunately" HDMI works fine on my board with both 5.15 and 5.18, so I can't experiment such issue.

dmesg may provide some useful information about, there is a dmesg attached to an older post were there was clearly a drm error I never encountered before and can't guess the reason causing it.

 

Anyway congrats to bringing the board up!

It appears it does not matter when you plug in HDMI cable. But for 3d printer owners out there I made a parametric cooler case(well top of it anyway)

https://www.thingiverse.com/thing:5447782

Certainly sorts out the overheating issue for the time being. Tested with cpuburn-a53

ln -s /sys/devices/virtual/thermal/thermal_zone0/temp /root/temp; cat /root/temp

 

Edited by Aapo Tahkola
Link to comment
Share on other sites

6 hours ago, Aapo Tahkola said:

It appears it does not matter when you plug in HDMI cable. But for 3d printer owners out there I made a parametric cooler case(well top of it anyway)

https://www.thingiverse.com/thing:5447782

Certainly sorts out the overheating issue for the time being. Tested with cpuburn-a53

ln -s /sys/devices/virtual/thermal/thermal_zone0/temp /root/temp; cat /root/temp

 

same as my experience with 5.18 kernel except i didn't build armbian from source. thanks for the case @Aapo Tahkola will try it out. i got an rk3228 box running my printer at the moment occasionally testing rk3318 box as well, they both seem fine and on average use very little cpu and ram usage during printing, it seems these boxes can handle 2-3 simultaneous instances of klipper at the same time maybe even 4 with your case design.

Link to comment
Share on other sites

Hi all, Hi @jock

Today I upgrade to 5.18.10 with all the .deb from https://users.armbian.com/jock/rk3318/upgrade/

So I tried to use the CPU at 1.3GHz as I could before in schedutil mode but I had a problem of freeze suddenly I went down to 1GHz in schedutil mode too..

Maybe if I flash the new release => https://users.armbian.com/jock/rk3318/Armbian_22.08.0-trunk_Rk3318-box_jammy_edge_5.18.14_kde-plasma_desktop.img.xz

 

 

Link to comment
Share on other sites

@MX10.AC2N Didn't you try already 5.18? I remember you already had issues with 5.18, but that was my fault because I downvolted the CPU by mistake; upgrade debs should be fixed now and there should be no issues anymore, as long as also other people found them working stable so far.

 

About the Jammy edge image, it is an experimental image with KDE Plasma preinstalled. It works, but there is a kernel bug in lima that often causes kernel panics, so it is not "public" not suggested to put in any kind of use.

The bug seems to be fixed in 5.19, so I guess soon there will be a proper publishing.

Link to comment
Share on other sites

Quote

 

Ok, I double checked the cpu voltage supply and effectively it seems that in the latest device tree I pushed it way too low... The original device tree of my box said 1.375v@1.3Ghz, the voltage in mainline kernel says 1.300v@1.3Ghz and I set 1.200v@1.3Ghz. That is very good for temperatures and power consumption, but maybe it is a bit too low for stable operations.

 

I will rebuild the whole set of images, but in the meantime I updated the dtb deb package you can install that should fix issues: https://users.armbian.com/jock/rk3318/upgrade/linux-dtb-edge-rockchip64_22.08.0-trunk_arm64.deb

 

@jock

 

Thanks very much. You are the man.  👍👍👍

 I tried the latest build with Kernel 5.18.10-rockchip64, and now the TV box is able to boot & run @ 1.3 Ghz CPU speed without freezing & hang-up.

 

I did a complete EMMC erase and reinstallation though, just to prevent any mix of existing & newer configuration.

I will observe for a few more days, but feel fairly confident that it should work this time.

 

Link to comment
Share on other sites

Hello,

Hi All,

 

I am trying to flash\upgrade my H96Max 4K but unfortunately I can get it to but with any Armbian of LibeElec image.

Starting the TVBox with multitool from a SD card works, but any other image nothing. 

 

I can upload an image using the Factorytool  (https://chinagadgetsreviews.com/download-rockchip-factorytool-v1-64.html) and the toothpick method. After restart the H96Max splash screen show after a sort while the Android 9 boot animation start. 

 

TVBOX: H98Max

CPU: RK3318

RAM 4GB

ROM 64GB

OS Android 9.0 

 

I have also tried this walkthrough but still no luck: https://www.h96tvbox.com/module/xipblog/single?page_type=post&id=249&rewrite=android-90-tv-box-firmware-upgrade and https://androidpctv.com/firmware-h96-max-v11-update-restore/

 

Any help would be great 

 

Thanks

Link to comment
Share on other sites

Hi @jock, thank you for your wonderful work.

I got a T9 box, which like @Matteo Venturi's box in comment, but a 2GB+16GB cheaper one.

 

Multitool works good, backup, restore even eth netwrok works well (I can ping, apt update..),

 

But the real system can not boot, whether SD Card or burned into emmc. The cpu is warm, screen shows nothing.

I can't find the UART port, how can I debug this?

 

Thank you.

 

---

PCB mark: T9-RK3328-8X4-20190109-V1.7

184499790-4b35e719-6019-4c22-9fbe-4e0816

 

184499789-2d23a503-51fd-453b-80ee-dade51

 

184499783-510e662b-40be-456a-bf37-67d740

Link to comment
Share on other sites

@uehqsvbm Hello, are you able to ping the machine once armbian boots?

You should at least have a blinking led if the kernel is alive.

Even if there is a problem with HDMI or generally with the display output, your board at least should boot, get an IP from the network and be reachable; you should be able to access via ssh using root user (default pass: 1234).

 

Link to comment
Share on other sites

Announce:

 

Hello, I want to announce that Community Supported Configuration (CSC) board images are now built again by Armbian servers on a weekly basis!

This means that you can now download images for CSC boards (including rk3318-box) browsing from https://github.com/armbian/community

 

Images are built from trunk, GPG-signed and SHA-sum is provided.

 

I also removed the manual instructions for upgrades: Armbian 22.08 release is imminent and from that time on it will be sufficient to use apt to get kernel upgrades too! Thanks for your patience!

 

Feel free to donate if you find this useful and wish to offer support to the Armbian developers and maintainers.

 

Enjoy!

Link to comment
Share on other sites

 

 

On 8/14/2022 at 12:20 AM, jock said:

get an IP from the network and be reachable; you should be able to access via ssh using root user

 

 @jock thanks for your quick reply. I have tried but no lucky :(

eth network seems not work in armbian, I can't find ip addr in router.

the ip addr assigned in Multitool is not reachable after boot to armbian.

 

the last way is cut off some function and compile img and try ?

 

---

 

28 minutes ago, jock said:

Community Supported Configuration (CSC) board images are now built again by Armbian servers on a weekly basis

Great 🎉🎉🎉

Link to comment
Share on other sites

11 minutes ago, uehqsvbm said:

eth network seems not work in armbian, I can't find ip addr in router.

the ip addr assigned in Multitool is not reachable after boot to armbian.

 

the last way is cut off some function and compile img and try ?

ethernet is always working in armbian, it is embedded in the soc, so if it does not work it means that armbian did not boot.

Also the led should be blinking if the kernel is alive, but I see no leds on your board, am I right?


You may try one of the newer images built from trunk above, maybe you got an image with the invalid voltages I published by error some weeks ago.

 

The definitive way is to to debug this is using a USB-to-TTL serial adapter connected to the serial pads of the board, which are sometimes under the heatsink (but just sometimes...), or maybe are those pads in the lower right corner, near the IR receiver.

Link to comment
Share on other sites

Quote

@jock
Thanks very much. You are the man.  👍👍👍

 I tried the latest build with Kernel 5.18.10-rockchip64, and now the TV box is able to boot & run @ 1.3 Ghz CPU speed without freezing & hang-up.

 

I did a complete EMMC erase and reinstallation though, just to prevent any mix of existing & newer configuration.

I will observe for a few more days, but feel fairly confident that it should work this time.

 

Confirmed the Armbian system is still up & running after 3 days.  Suffice to say it's working OK now after CPU voltage adjustment.

@jock  Thanks again.

 

Link to comment
Share on other sites

@uehqsvbm

It could be that those three pins near ir receiver are just reversed order of ir receiver. I have seen similar designs. They just put multiple pads for different devices. I hear they are going to start doing more of that in future because of chip shortage. You can first the all the pins with a multimeter so that it is below 3.3v but I do not think this board has uart unfortunately. I guess if multiboot works you could get the sources and try to make it into something workable and find out what is wrong that way. Or build from sources and change as many things as possible and see if you get lucky. Actually the best option might be to configure uart TX pin on the led pin or one of the pins of the front led panel or ir receiver. I am pretty sure rk3318 chip is capable of that and I think I saw the full datasheet online. I do think the 1.5Mps uart is little risky high which can cause signal integrity problems.

 

@jock

Can you tell me where this blinking led is configured, it is now shining through the case and I do not like keeping anything that blinks in the house.

 

 

I have not been able to crash my box at 1.3ghz and performance governor with fan cooling. Might give a whirl to overclocking with voltage mod but do not know how yet.

Link to comment
Share on other sites

@oolonthegreat This thread is for rk3318 and not rk3188; please open a new thread for that request and also remove the long log lists from here because they make the browsing from mobile very difficult.

 

@Aapo Tahkola I meant the four pads at the right of the IR receiver, not the three pads near the led array: those are clearly pads for diodes if you pay attention to the symbols.

Looking at the back of the @uehqsvbm's board, those four pads have a different wiring than the IR receiver and from the front side there is no immediate connection to the IR receiver; It is not 100% sure because there could be some in-board layer connecting them to IR, but I may guess those are not for IR. Also the central pads immediate connection is to a couple of components that seem to be resistances.

They could also be spare connection for leds, but in such case a single resistance would suffice and placing resistors there is a waste of components since the board does not have leds there.

 

Looking at the front side, the rightmost pad is surely ground (it has the reverse triangle symbol), and the leftmost maybe is VCC (there is a path going to IR receiver), maybe the two central pads are uart RX/TX.

 

About the led blinking led issue, this is what google suggests as first answer: https://linuxreviews.org/HOWTO_Control_LED_Lights

Link to comment
Share on other sites

@oolonthegreat @uehqsvbm Do not get too attached to devices that refuse to cooperate after a reasonable amount of effort. Just sell it and recover what you can and get one that people have had better success with. I recently fell into this trap with one particular openwrt supported device I have already spent months on it.

 

Edited by Aapo Tahkola
typo
Link to comment
Share on other sites

On 4/16/2021 at 6:30 PM, jock said:

Installation (via SD card):

Building:
You can build your own image follow the common steps to build armbian for other tv boxes devices: when you are in the moment to choose the target board, switch to /TVB/ boards and select "rk3318-box" from the list.
   
Stable images:

 

 

@jock

I was able to test the Nightly build from trunk on Armbian Github ( https://github.com/armbian/community ) as you revised in the first post yesterday.

  

image.thumb.png.17e822454c58b63af6a418304eeb5292.png

 

 

 

I noticed that in both cases of jammy-current-cli & sid-current-cli build, they are consistently slower than the stables build in your tree ( https://users.armbian.com/jock/rk3318/ ).  You can notice it immediately when (1) trying to apt install stuff  (slower at 'Building dependency tree' ), or when (2) navigating inside armbian-config when loading softy modules, or reconfiguring SSH daemon.

 

In particular, the htop screen looks a little different and it shows something related to Systemd: degraded ( not shown in your build )

 

image.png.0bfa633a34c5e32bcd2e1a979f8bd36a.png

 

 

Is this slow behavior normal?  Or maybe you did some magic with the build in your tree so that it's running noticeably faster?

 

 

Edited by Willy Moto
cleanup typo
Link to comment
Share on other sites

2 hours ago, Willy Moto said:

Is this slow behavior normal?  Or maybe you did some magic with the build in your tree so that it's running noticeably faster?

Hmm, no it is not normal. There is no secret sauce in my builds, actually recent builds I tested privately were built against armbian master, as like as nightly are.

 

I checked the rk322x builds but not the rk3318 ones; I will take a look!

Link to comment
Share on other sites

Well, I just checked the jammy cli image and it looks pretty normal to me. After configuring it with rk3318-config and rebooting, I don't have the "degraded" systemd status, cpufreq-info shows the board running at most 1.3ghz, dram is running at expected 667 Mhz and everything seems at the right place.

 

Also openssl speed -multi 4 rsa gives me expected speed results (I usually take a look to the 4096 bits benchmarks)

rsa  512 bits 0.000065s 0.000005s  15428.9 182723.3
rsa 1024 bits 0.000313s 0.000016s   3195.9  62525.2
rsa 2048 bits 0.002079s 0.000056s    480.9  17820.1
rsa 3072 bits 0.006352s 0.000122s    157.4   8218.6
rsa 4096 bits 0.014272s 0.000212s     70.1   4725.6
rsa 7680 bits 0.110870s 0.000728s      9.0   1374.1
rsa 15360 bits 0.667811s 0.002874s      1.5    348.0

 

Screenshot_20220817_212923.png

edit: maybe apt update is slower because there are more packages installed (my images were minimal cli images, these looks like standard cli images; still server-oriented, but carry some more preinstalled packages)

 

Link to comment
Share on other sites

5 hours ago, jock said:

Well, I just checked the jammy cli image and it looks pretty normal to me. After configuring it with rk3318-config and rebooting, I don't have the "degraded" systemd status, cpufreq-info shows the board running at most 1.3ghz, dram is running at expected 667 Mhz and everything seems at the right place.

 

I found out the degraded service:  It is smartmontools.service

 

root@rk3318-h96max:/dev# systemctl --failed

  UNIT                  LOAD   ACTIVE SUB    DESCRIPTION                       
 smartmontools.service loaded "failed failed" Self Monitoring and Reporting Tech

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

 

 

Further investigation suggested that it appears the EMMC (where I installed Armbian) cannot be scanned by smartmontools.

 

root@rk3318-h96max:/dev# systemctl status smartmontools.service

× smartmontools.service - Self Monitoring and Reporting Technology (SMART) Daemon
     Loaded: loaded (/lib/systemd/system/smartmontools.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Thu 2022-08-18 09:00:19 HKT; 22min ago
       Docs: man:smartd(8)
             man:smartd.conf(5)
    Process: 2333 ExecStart=/usr/sbin/smartd -n $smartd_opts (code=exited, status=17)
   Main PID: 2333 (code=exited, status=17)
   Status:   "No devices to monitor"
        CPU: 194ms

Aug 18 09:00:19 rk3318-h96max smartd[2333]: smartd 7.3 2022-02-28 r5338 [aarch64-linux-5.15.60-rockchip64] (local build)
Aug 18 09:00:19 rk3318-h96max smartd[2333]: Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org
Aug 18 09:00:19 rk3318-h96max smartd[2333]: Opened configuration file /etc/smartd.conf
Aug 18 09:00:19 rk3318-h96max smartd[2333]: Drive: DEVICESCAN, implied '-a' Directive on line 21 of file /etc/smartd.conf
Aug 18 09:00:19 rk3318-h96max smartd[2333]: Configuration file /etc/smartd.conf was parsed, found DEVICESCAN, scanning devices
Aug 18 09:00:19 rk3318-h96max smartd[2333]: In the system's table of devices NO devices found to scan
Aug 18 09:00:19 rk3318-h96max smartd[2333]: "Unable to monitor any SMART enabled devices. Try debug (-d) option. Exiting... "
Aug 18 09:00:19 rk3318-h96max systemd[1]: smartmontools.service: Main process exited, code=exited, status=17/n/a
Aug 18 09:00:19 rk3318-h96max systemd[1]: smartmontools.service: Failed with result 'exit-code'.
Aug 18 09:00:19 rk3318-h96max systemd[1]: Failed to start Self Monitoring and Reporting Technology (SMART) Daemon.

 

 

I did some google search, and this discussion suggested that Smartmontools does not support EMMC.

 

Quote

root@rk3318-h96max:/dev# smartctl -d


smartctl 7.3 2022-02-28 r5338 [aarch64-linux-5.15.60-rockchip64] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

 

=======> ARGUMENT REQUIRED FOR OPTION: d
=======> VALID ARGUMENTS ARE: ata, scsi[+TYPE], nvme[,NSID], sat[,auto][,N][+TYPE], usbcypress[,X], usbjmicron[,p][,x][,N], usbprolific, usbsunplus, sntasmedia, sntjmicron[,NSID], sntrealtek, intelliprop,N[+TYPE], jmb39x[-q],N[,sLBA][,force][+TYPE], jms56x,N[,sLBA][,force][+TYPE], marvell, areca,N/E, 3ware,N, hpt,L/M/N, megaraid,N, aacraid,H,L,ID, cciss,N, auto, test <=======

Use smartctl -h to get a usage summary
 

 

 

Suppose I should just disable this service, if it's no use to EMMC where I installed Armbian.

Link to comment
Share on other sites

6 hours ago, jock said:

edit: maybe apt update is slower because there are more packages installed (my images were minimal cli images, these looks like standard cli images; still server-oriented, but carry some more preinstalled packages)

.

Thanks for the clarification.   I can see that the file size of sid-current-cli image close to double the size of your build.

That probably explains it.

Link to comment
Share on other sites

@Willy Moto uhm, smartmontools should not die so bad, as long as eMMC have no smart capabilities AFAIK; maybe debian sid has a wrong configuration in /etc/smartd.conf that causes the error, because right now have installed a fresh ubuntu jammy image on a sdcard (and no SMART devices attached) and has no such issue.

 

The only enabled directive in my /etc/smartd.conf is this one:

 

DEVICESCAN -d removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runner

 

 

Link to comment
Share on other sites

5 hours ago, jock said:

The only enabled directive in my /etc/smartd.conf is this one:

 

DEVICESCAN -d removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runner

 

My configuration /etc/smartd.conf seems to be the same as yours:

 

DEVICESCAN -d removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runner

 

 

So my suspicion is this: 

Is EMMC considered to be a removable device  ( -d removable ) or not? 

 

For USB storage or MicroSD card, the answer is obviously yes. 

 

Link to comment
Share on other sites

@Willy Moto well, I have an eMMC too but I have no such error. Maybe it is because I'm booting from sdcard, but absolutely I don't know what to say. Surely the "degraded" systemd status does not hamper the system in any way, but you should debug more to understand the real cause of that.

Link to comment
Share on other sites

15 hours ago, jock said:

well, I have an eMMC too but I have no such error. Maybe it is because I'm booting from sdcard, but absolutely I don't know what to say. Surely the "degraded" systemd status does not hamper the system in any way, but you should debug more to understand the real cause of that.

 

You are right.  I looked at a different RK3318 TV box with the build in your tree.

The same service is loaded and in active status.

 

root@boss-box:/etc# systemctl status smartmontools.service

 smartmontools.service - Self Monitoring and Reporting Technology (SMART) Daemon
     Loaded: loaded (/lib/systemd/system/smartmontools.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2022-08-17 23:19:09 HKT; 1 day 17h ago
       Docs: man:smartd(8)
             man:smartd.conf(5)
   Main PID: 669 (smartd)
     Status: "Next check of 0 devices will start at 16:49:09"
      Tasks: 1 (limit: 999)
     Memory: 3.2M
     CGroup: /system.slice/smartmontools.service
             └─669 /usr/sbin/smartd -n

 


Guess it's time to debug what's happening with the trunk build & my EMMC configuration.

Edited by Willy Moto
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