Taz Posted August 2, 2022 Share Posted August 2, 2022 (edited) 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 August 2, 2022 by Aapo Tahkola 3 Quote Link to comment Share on other sites More sharing options...
jock Posted August 2, 2022 Author Share Posted August 2, 2022 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! 1 Quote Link to comment Share on other sites More sharing options...
Taz Posted August 3, 2022 Share Posted August 3, 2022 (edited) 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 August 3, 2022 by Aapo Tahkola 3 Quote Link to comment Share on other sites More sharing options...
Seth Posted August 4, 2022 Share Posted August 4, 2022 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. 0 Quote Link to comment Share on other sites More sharing options...
MX10.AC2N Posted August 4, 2022 Share Posted August 4, 2022 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 0 Quote Link to comment Share on other sites More sharing options...
jock Posted August 5, 2022 Author Share Posted August 5, 2022 @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. 1 Quote Link to comment Share on other sites More sharing options...
Willy Moto Posted August 12, 2022 Share Posted 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. 0 Quote Link to comment Share on other sites More sharing options...
jangac Posted August 13, 2022 Share Posted August 13, 2022 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 0 Quote Link to comment Share on other sites More sharing options...
uehqsvbm Posted August 13, 2022 Share Posted August 13, 2022 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 0 Quote Link to comment Share on other sites More sharing options...
jock Posted August 13, 2022 Author Share Posted August 13, 2022 @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). 0 Quote Link to comment Share on other sites More sharing options...
jock Posted August 15, 2022 Author Share Posted August 15, 2022 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! 4 Quote Link to comment Share on other sites More sharing options...
uehqsvbm Posted August 15, 2022 Share Posted August 15, 2022 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 🎉🎉🎉 0 Quote Link to comment Share on other sites More sharing options...
jock Posted August 15, 2022 Author Share Posted August 15, 2022 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. 1 Quote Link to comment Share on other sites More sharing options...
Willy Moto Posted August 15, 2022 Share Posted 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. 0 Quote Link to comment Share on other sites More sharing options...
fabiobassa Posted August 15, 2022 Share Posted August 15, 2022 @oolonthegreat Pardon but we have studied rk 3228 or 3229 ( 322x) and rk 3318. You are speaking of rk 3188 Is that correct? If so i think It Will not work on your board 0 Quote Link to comment Share on other sites More sharing options...
Taz Posted August 16, 2022 Share Posted August 16, 2022 @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. 1 Quote Link to comment Share on other sites More sharing options...
jock Posted August 16, 2022 Author Share Posted August 16, 2022 @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 3 Quote Link to comment Share on other sites More sharing options...
oolonthegreat Posted August 16, 2022 Share Posted August 16, 2022 (edited) @fabiobassa oops, you are right of course. my dyslexia strikes again! @jock sorry about that! will edit the post as soon as I get my post edit privileges. @SteeMan could you help with that? looks like I can edit the new posts I make, but not the old problematic one. Edited August 16, 2022 by oolonthegreat 1 Quote Link to comment Share on other sites More sharing options...
Taz Posted August 16, 2022 Share Posted August 16, 2022 (edited) @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 August 16, 2022 by Aapo Tahkola typo 1 Quote Link to comment Share on other sites More sharing options...
SteeMan Posted August 16, 2022 Share Posted August 16, 2022 4 hours ago, oolonthegreat said: could you help with that? looks like I can edit the new posts I make, but not the old problematic one. Moved post to a new thread and edited the log files into spoiler sections 2 Quote Link to comment Share on other sites More sharing options...
Willy Moto Posted August 17, 2022 Share Posted August 17, 2022 (edited) 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 ) 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 August 17, 2022 by Willy Moto cleanup typo 0 Quote Link to comment Share on other sites More sharing options...
jock Posted August 17, 2022 Author Share Posted August 17, 2022 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! 0 Quote Link to comment Share on other sites More sharing options...
jock Posted August 17, 2022 Author Share Posted August 17, 2022 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 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) 0 Quote Link to comment Share on other sites More sharing options...
Willy Moto Posted August 18, 2022 Share Posted 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. 0 Quote Link to comment Share on other sites More sharing options...
Willy Moto Posted August 18, 2022 Share Posted 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. 0 Quote Link to comment Share on other sites More sharing options...
jock Posted August 18, 2022 Author Share Posted August 18, 2022 @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 0 Quote Link to comment Share on other sites More sharing options...
Willy Moto Posted August 18, 2022 Share Posted 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. 0 Quote Link to comment Share on other sites More sharing options...
jock Posted August 18, 2022 Author Share Posted August 18, 2022 @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. 0 Quote Link to comment Share on other sites More sharing options...
Willy Moto Posted August 19, 2022 Share Posted August 19, 2022 (edited) 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 August 19, 2022 by Willy Moto 0 Quote Link to comment Share on other sites More sharing options...
ninh Posted August 20, 2022 Share Posted August 20, 2022 Hi, has anyone tried to install armbian on x96Q box with RK3328? Thank you. 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.