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.