Willy Moto

August 19, 2022

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.

August 18, 2022

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.

August 18, 2022

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.

August 18, 2022

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.

August 17, 2022

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:

Nightly stables - built from trunk by Armbian servers and GPG-signed: https://github.com/armbian/community

Stables provided by my (unsigned): https://users.armbian.com/jock/rk3318/

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

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?

August 15, 2022

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.

August 12, 2022

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.

July 26, 2022

On 7/12/2022 at 7:10 AM, JMCC said:

Sorry, anybody has a stock-android flash backup for X88 Pro 10, made with jock's Multitool? I have been trying to use the official Rockchip tool to flash the firmware, but no luck, these devices are so crappy...

(More info: I made a backup, but it is corrupted due to the 4Gb bug)

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

July 1, 2022

On 6/30/2022 at 4:19 PM, jock said:

No, there is no such thing. The only way to know what kind of memory you have is read the signature on the chips and look for the datasheet.

But usually DDR3 shipped with these tvboxes are 667 or 800 MHz parts.

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.

On 6/30/2022 at 4:19 PM, jock said:

That would be interesting since you have two different boards; often those with rk3328 have a power regulation chip and rk3318 have none, but you have to look to the boards PCB.

Generally, choosing the right led-conf/GPIO pins configuration for the board is essential to get stability and functionality, but without A ) detailed photos of the board and B ) original dtb from Android it is impossible to produce suitable GPIO pin configuration.

Now this kernel v5.18 looks like is having issues of which I don't grasp yet the nature of...

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

June 30, 2022

7 hours ago, jock said:

@Willy Moto If you're stable with 1.1Ghz and DDR@667MHz there is no sense in downgrading to 333MHz; the issue is not the DDR neither kernel; the problem is the CPU@1.3GHz.

I don't remember your board and the led-conf you were using, but for example @MX10.AC2N has exactly the same problem as yours. If you were using led-conf3 because your board has a regular rk3328 with the proper power regulation chip then there is some issue there: either the power regulator or the device tree overlay has some issues and needs to be fixed to let the CPU works stable at 1.3GHz.

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.

June 29, 2022

On 6/27/2022 at 3:31 PM, jock said:

AFAIR rk3328 is advertised a 1.5ghz part, but actually is 1.3ghz, I can be wrong, though.

The suggestion to try 1.1Ghz is to understand if the problem is due to voltage regulators (the reason why it is very important for you to use led-conf3 overlay) or there is something wrong elsewhere.

BTW you are now back to v5.15 or still on v5.18? Are you using 333MHz idbloader or 667MHz one?

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.

June 29, 2022

On 6/25/2022 at 5:37 PM, jock said:

@MX10.AC2N @Willy Moto Ok I managed to compile just the idbloader that does the DDR initialization to 333 MHz.

This is the binary with the 333MHz ddrbin: idbloader.img

And you can install from the box itself on the eMMC (should be suitable for @MX10.AC2N, mmcblk2 should be the eMMC, but please verify!) installation doing:

dd if=idbloader.img of=/dev/mmcblk2 bs=32k seek=1 && sync

Or you can boot into multitool (this should be the case for @Willy Moto) and do the same via shell. Of course you need to transfer the file on multitool FAT partition, boot with multitool and then mount the FAT partition manually via shell.

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?

June 24, 2022

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

June 24, 2022

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

June 24, 2022

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

June 24, 2022

26 minutes ago, jock said:

That's exactly the reason the automatic upgrades must not be run, and instead manual installation with deb packages is the way to go.

Did you run apt-mark hold on kernel and dtb packages as stated in the first post before running this?

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.

June 24, 2022

12 hours ago, jock said:

UPDATE!!

Hello, I'm pleased to announce that rk3318 CSC configuration has been accepted into mainline kernel!.

This means that next Armbian release (probably August) will provide regular kernel upgrades offered by Armbian ecosystem via normal apt upgrade command.

Until then, please stay stick to the usual manual upgrade!

But there is something more: new update for the rk3318/rk3328 images!

Most important changes:

Kernel upgraded to version v5.18.6

Memory clock set to 667 MHz (was 333 MHz), providing a nice boost in general, desktop and GPU performance; despite this works fine on my board I always warn you to test images first via sdcard

Introduces MGLRU patches from @yuzhaogoogle (you can read about here and search google for more details), which should provide much snappier experience especially on low-memory devices

You can find the images and deb packages for upgrades browsing the directory pointed on first page as usual.

You can visit the Armbian MGLRU topic, if you have questions about the features or kernel issues (like crash dumps which involve kswapd, for example)

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.

February 7, 2022

See also discussions:

February 7, 2022

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.

Quote

Merged into 5.14

H616

PMIC - AXP305

New Devices Supported

H616

Tanix TX6s

X96 Mate

Xunlong Orange Pi Zero2

https://linux-sunxi.org/Linux_mainlining_effort

January 24, 2022

On 1/11/2022 at 10:53 PM, ScottP said:

Rock5 model B is up for preorder now - pay $5 now and get $50 off when it ships in Q2 https://www.cnx-software.com/2022/01/09/rock5-model-b-rk3588-single-board-computer/?amp=1 Its going to be a beast - about 4x performance of rk3399 multi core and GPU up to 10x performance in some tests

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/

January 24, 2022

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/

October 14, 2021

7 hours ago, ILikeLinux said:

Wich armbian image i have to choose i tried the newest ones from Mega.nz and burned them with Rufus but all didnt work for me

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.

October 7, 2021

19 hours ago, fabiobassa said:

@Willy Moto
And finally.... if you real want to open port , use iptables and iptables-persistent and not user space 3rd programs ( ufw)

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.

Quote

This is another long story ... often done on this 3ad. Is not possible compare raspberry or amlogic or allwinner among themselves or among rockchip. Is a bit comparing pears and appples
Is fundamental understand different behaviours due to different topology even if the substrate is always arm architecture

To obtain more complex infos, unplug lan , stop pihole and again htop to check if there is offending tasks

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.

October 7, 2021

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?

October 6, 2021

On 9/23/2021 at 5:09 PM, balbes150 said:

If you do not need maximum performance, I recommend paying attention to the new Station P2 and M2 models (these are full-fledged mini PCs). At the moment, there are systems with the Legacy core for them, but the development of support for the main core for the rk35x is very fast. And soon there should be a "monster" with very strong characteristics - RK3588. But if you need the most ready-made solution with the main core right now, I recommend P1\M1 . Just yesterday I tested the work of new versions of KODI with full HW support for playing full-screen video on P1\M1 on the main core (I pay attention not to the Legacy core, but the latest stable 5.10), everything works fine even with 4K. By the way, P1 (RK3399) copes with 720p full-screen video in the Chrome browser without problems , there are not big artifacts in 1080p mode, but with the release (I hope it will be in the coming months) of the new version of FFMPEG and adding its support to browsers, rk33xx (P1\M1) will easily cope with 4k in full-screen browsers.

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.

Sign In

Forums

Store

Crowdfunding

Applications

Events

Raffles

Community Map

Posts posted by Willy Moto

Important Information