Willy Moto

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.

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.

. 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.

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. Suppose I should just disable this service, if it's no use to EMMC where I installed Armbian.

@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. 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 ) Is this slow behavior normal? Or maybe you did some magic with the build in your tree so that it's running noticeably faster?

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.

@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.

@JMCC I think I have another one of these X88 Pro 10 TV box lying around (actually I managed to acquire quite a few RK3318/RK3328 TV boxes at a bargain sale store). It's of the model 4GB RAM + 128 EMMC storage. Do you still want it? UPDATE: It looks @Aapo Tahkola already posted a new firmware for X88 Pro 10 TV box. Would that help you?

I understand. I was googling for some time looking for memory benchmark tool to compare before & after this upgrade. I'll see if that effort goes anywhere . Will let you know. Thanks for the hint. I made sure to dump a backup of the original Android ROM image with multitool. Now to the task of dtb extraction. I'll see if I can get this done in a few days (currently still busy with a few other non-IT matters 😅).

I am using unlisted as my led-conf in rk3318-config. By the way, is there any command to confirm the actual DDR RAM speed ? As there is no traditional BIOS so dmidecode wouldn't work. I think you're right, but if I have to guess I think CPU 1.3 Ghz and DDR@333Mhz would also be fine. I have 2 TV boxes: one with RK3318, and one with RK3328. Not sure if it makes any difference, but I'll post back further after some more testings. Thanks for your work as always.

Running the latest Armbian build with Kernel 5.18.6: I have not applied the 333 Mhz idbloader.img yet (due to not sure which /dev/block to mount). So instead, I ran rk3318-config and also tuned down the CPU speed to 1.1 Ghz. This time, I was able to reboot without any issue . I am running the sudo memtester 512M right now. So far system is still stable 1.1 GHz CPU + RAM speed @ 667Mhz as you stated in this build. ======================== PS: If I know how to mount the FAT partition, I can try the different combination of 1.3 Ghz CPU + RAM speed @ 333 Mhz under Kernel 5.18.6 to compare the results. Believe I was under this combination when using Kernel 5.15.35.

Hi @jock Sorry was not able to get back sooner. I cannot find the mount device under /dev/ path. Which one points to the multiboot FAT partition?

@jock I have just tried to erase the eMMC, and then re-installed the latest Armbian 22.08 trunk build from scratch. 1) Unfortunately, it appears the latest edge Kernel 5.18.6 is unstable, at least for my TV box -- which is a H96 Max+ 4GB RAM/32GB EMMC model. Running rk3318-config and after reboot, the system produced some sort of error similar to previous screen, as in attached (I chose unlisted for led option). 2) By comparison, I fell back to previous Armbian 22.05 trunk build ( 5.15.35 current kernel ), on the same TV box. Running rk3318-config and after reboot, the system did not produce any error and running fine (I chose unlisted for led option). I guess it's either my H96 Max+ TV box sucks, or the 5.18.6 edge Kernel is pushing too far for my hardware configuration (ie. my TV box still sucks 🤣 ). Anyway, I fallback to the previous CSC Armbian version for now. Thanks.

@jock I just realized the previous Armbian Builds were based on Current-branch Kernel, while the latest Armbian Build is based on Edge-branch Kernel. 09/04/2022 19:20 237,289,900 Armbian_22.02.0-trunk_Rk3318-box_bullseye_current_5.15.25_minimal.img.xz 30/04/2022 00:13 248,048,016 Armbian_22.05.0-trunk_Rk3318-box_bullseye_current_5.15.35_minimal.img.xz 24/06/2022 12:23 248,776,832 Armbian_22.08.0-trunk_Rk3318-box_bullseye_edge_5.18.6_minimal.img.xz Would it cause any problem for manually running apt install to install the DEB Kernel package this way, as it would be switching to a different Kernel-branch? Just a thought.

@jock No worries. I knew pretty well the risk involved in running a CSC + still-in-bring-up Armbian build for an unsupported TV box device. You did great no matter what. I think whatever the cause, I managed to corrupt the ETH0 network driver. Here are some screen dump I got from an output console.

I was sure apt-mark hold was already run. That should leave all the kernel packages not upgraded by apt-get upgrade command. Let me check the console screen for sure. Be right back.

I tried to install the kernel upgrade manually using the DEB downloaded from: https://users.armbian.com/jock/rk3318/upgrade/ Also running "sudo apt-upgrade" at the same time. But the system was unable to boot afterwards. In the past, manual kernel upgrade ( Armbian 22.05 trunk build & beforehand), it used to work every time without issue. I will try to get a console screen and see if I can get some error message for debugging analysis. Thanks.

See also discussions:

According to Linux-Sunxi Wiki: device support for many H616 SBC / TV box has been merged since Kernel 5.14. It should be easier to get drivers integrated & working with a newer mainline kernel. https://linux-sunxi.org/Linux_mainlining_effort

Yes, RK3588 will be a beast. It will catch up to or even surpass some of the Intel Celeron-based CPU system. In addition, a lower-cost version RK3588S will also be released for those who does not need PICe 3.0 or multiple display output: https://www.cnx-software.com/2022/01/12/rockchip-rk3588s-cost-optimized-cortex-a76-a55-processor/

Yes, indeed exciting times. ROCK5 Model B RK3588 single board computer is up for pre-order for $79 and up - CNX Software (cnx-software.com) https://www.cnx-software.com/2022/01/09/rock5-model-b-rk3588-single-board-computer/ In addition, a lower-cost version RK3588S will also be released for those who does not need PICe 3.0 or multiple display output: https://www.cnx-software.com/2022/01/12/rockchip-rk3588s-cost-optimized-cortex-a76-a55-processor/

Try the URL hosted on official Armbian server ( the URL which ends with armbian.com in the domain ), posted by balbes150 in the 3rd post of this thread. You may also find suggestion on tools for burning USB aka USBImager , as stated in my few posts back.

I understand, but I wanted to make a shortcut & use UFW. Pi Hole documentation has the exact info for UFW rules. To make it simple, just want to protect the Armbian box & not allow anyone else to interfere & hack in. I understand. I am currently playing with another rockchip TV box lately (RK3328), but I thought not to bring this in here so as not to mix things up. I will observe a little longer but I am thinking if the older Kernel or NAND device driver could be the culprit? Because all other Armbian boxes I've worked on were all on latest Kernel 5.x, on SD-card / EMMC. They didn't have this high Load Average problem (ie. the discrepancy between Load Average vs CPU utilization ). I would try to gather more information and post back. Maybe I should run Mainline Kernel build (5.10.y Kernel on a USB drive) to compare.

Hi, it's me again. Have installed Armbian Buster via stepnand method, and running it for 2 weeks now. I observed something & would like to check: I found that the Load Average seems to be higher than other SoCs even the box is not running much loading. Here is the spec: RK3229 : 1GB RAM + 8 GB NAND storage OS: Armbian Buster 21.08.02 ( via apt-get upgrade ) Legacy Kernel 4.4.194 (for NAND memory model) Software installed & running UFW (for allow a few ports to access Pi-Hole) Pi Hole (installed via armbian-config, 3rd party softy menu) DuckDNS update curl script (crontab, only run once each hour) =========== Using htop, I found that the Load Average almost always stays at 1 1 1. It stays like that even there is not much DNS traffic going on... As RK3229 has 4 cores, this translates to 1/4 = 25% system load at all time. However, the CPU utilization is lower & mostly below 10%. I don't understand this discrepancy (25% system load vs 8~10% cpu utilization). For comparison, I am running Armbian on another Cubieboard 2 compatible TV box (1 GB RAM, CPU SoC is Allwinner A20 dual core A7 @ 1 Ghz). The load average in that TV box is very often 0.5 or below (remember it's only dual core system, running almost same software configuration except it's using latest mainline stable Kernel 5.10.y). Question: Is there something odd about the higher than usual Load Average value ( 1 1 1 ) in RK3229 (Legacy Kernel + NAND), even when not much task is going on?

Thanks for the insight shared. I end up getting a Station P1 Mini PC from a local online trading store, I am impressed with its real 4K video support.