curse

Members
  • Posts

    35
  • Joined

  • Last visited

Reputation Activity

  1. Like
    curse got a reaction from Sigma7 in CSC Armbian for RK3318/RK3328 TV box boards   
    No. The Snapdragon 7c is different from the RK3318/RK3328. You'd have to find an image for the Snapdragon 7c. 
  2. Like
    curse reacted to jock in CSC Armbian for RK3318/RK3328 TV box boards   
    @MarcoFdN I updated the debian bullseye image and the upgrade packages to include the fix for bluetooth and rk3318-config script.
  3. Like
    curse reacted to Wester_Minsk in CSC Armbian for RK3318/RK3328 TV box boards   
    There was a simple way, and it was in front of my nose.

    This is the standard way from the official instructions of the Armbian:
     
    Start the install script:
    nand-sata-install
    I chose:
    of booting from eMMC/NAND, system to SATA/USB
     
    The system migrates to a USB3 SSD
    Restart and boot the system from USB3
     
    now a stable start with USB3
  4. Like
    curse reacted to jock in CSC Armbian for RK3318/RK3328 TV box boards   
    Well not just the kernel, but the whole rootfs must sit on SSD.
    Plus if you cloned you sdcard on SSD, both sdcard rootfs and SSD rootfs have the same UUID, and this may confuse the kernel about which rootfs use at boot.
    This is pretty normal if you think about it: how does the kernel can know if you want to boot from sdcard or boot from SSD when both contain the same bootable system?
    The rootfs UUID is specified in /boot/armbianEnv.txt.
     
    There are several approaches:
    You clone the sdcard on SSD, then you remove the rootfs partition from the sdcard Install just the bootloader on the eMMC erasing the eMMC and then copying the first 4 megabytes of the sdcard (/dev/mmblk0) on the eMMC (/dev/mmcblk2) Change the UUID of the sdcard rootfs, but this will prevent the sdcard rootfs from full boot The most clean approach is #2, taking in account that you should not plug both sdcard and SSD at the same time when the same cloned filesystem is on them for the usual UUID reason of above.
  5. Like
    curse got a reaction from RetroFan90 in CSC Armbian for RK3318/RK3328 TV box boards   
    Wouldn't it be easier to modify Armbian as you want it before installing it in the first place? I don't know how to do it, but example. Download @jock's Armbian, or compile your own. Modify the files on the .iso. write it to the SD card and install it on box 1 without the need to modify it later. Then do it on box 2, box 3, etc.
  6. Like
    curse got a reaction from RetroFan90 in CSC Armbian for RK3318/RK3328 TV box boards   
    If it's a similar problem as I had with my H96 Max Plus (RK3328) 
    @jock gave me a few good hints Here, 
  7. Like
    curse got a reaction from fabiobassa in CSC Armbian for RK3318/RK3328 TV box boards   
    Wouldn't it be easier to modify Armbian as you want it before installing it in the first place? I don't know how to do it, but example. Download @jock's Armbian, or compile your own. Modify the files on the .iso. write it to the SD card and install it on box 1 without the need to modify it later. Then do it on box 2, box 3, etc.
  8. Like
    curse reacted to jock in CSC Armbian for RK3318/RK3328 TV box boards   
    It depends upon your actual board and how much it is well built.
    Keeping all the emmc options off is the most stable but also the slowest setting.
    Enabling DDR or HS200 modes may improve the eMMC throughput a lot, but may also make your eMMC not work anymore and depends upon your board quality.
    Despite eMMC declare their supported modes and kernel is perfectly able to select the best suited, it is not possible to resort to automatic selection because of the board quality.
    HS200 mode is preferred over DDR.
     
    rk3318-config is telling you: select the board configuration looking on the markings of the board. The right configuration solve problems with devices detection like leds, wifi, bluetooth and improve general stability
    You have to open the box and look at the signature of the board: that is the "name' of the board. Most external devices of the boards (emmc, sdcard, infrared receiver, USB ports, HDMI, etc...) are usually wired to the same GPIO pins to the SoC described in the reference design. This is the base configuration.
    Some manufacturers wire other devices (leds, but also wifi, and others too) in a different way, so you need to fix the configuration for specific boards, hence you need to select the right one here.
    If your board is not in the list, it means that nobody (actually me) has ever made a configuration for your specific board, so use the Generic option.
    There is no 'trial and error" here, you have to know the board name, otherwise stick to generic one.
     
    About the leds, I don't know your setup, but after first rk3318-config run, the main led is configured as "power on".
    The behavior can be easily changed setting the appropriate trigger in /sys/class/leds/working/trigger file (see google for that, "working" is the name of the led).
     
    I hope so. I would like to merge soon, but it depends upon the compatibility reports that are posted here.
     
     
    Could be useful, yes. Useful also are photos of the board to identify the signature and chips.
     
    I don't think it is possible to tag single posts. It would not useful though: the board you find inside the box is not always the same.
    We have seen that tv boxes with the same commercial name may contain different boards.
    That's the reason because rk3318-config does not list boards per commercial name (H96Max+, HK1, T95P, ...) but per board signature.
     
    Normally you don't need to read all the posts of the thread: the first post is regularly updated with all the information needed for newcomers and board specialties are integrated into rk3318-config to make life easier as soon as new boards appear.
     
    A good idea though is to read the last couple of pages of the thread to quickly get updated to the latest bits. The whole thread will give you the idea of the progress, but a post about your board of one or two years ago will probably be outdated and not so useful. First page is always the source of truth.
  9. Like
    curse reacted to jock in CSC Armbian for RK3318/RK3328 TV box boards   
    @chinhhut @curse
    The backup made by multitool (and rkdeveloptool) is per nature a full backup of all the physical eMMC sectors. It has no knowledge of the abstract structures like filesystem and files.
    The compression gives back a more manageable file which is not the entire size of the eMMC, but up to a few gigabytes, depending on how much data is stored on the eMMC and how much compressible it is.
     
    Indeed if you decompress it, you get the whole size of the eMMC, it is expected and it is advisable too. If it is not so, it means the backup process didn't went right.
     
    Now should be clear there is a problem about the "blank" part: how we can know if a part is "blank" and not, for example, a piece of a file which just contains a long string of 0x00 bytes? This is crucial: if you say that you skip those parts which are, supposedly, blank, you may (and probably will) fail to restore files that contains long string of 0x00 bytes. You won't get 0x00s in those places, but you will instead find there the contents of the unwritten eMMC sectors.
     
    So a full restore of all sectors is essential to restore the exact previous condition when doing a full backup.
     
    One helpful thing that may be helpful here is to use the native page erase feature of eMMCs, which is the thing blkdiscard program do and is at the bottom of the famous TRIM feature: flash memories are divided into "pages", ranging from several kilobytes to few megabytes usually.
    Erasing those pages using the discard command is very fast, much faster than zero-filling. You can erase all the pages of a whole eMMC in a few seconds, while zero-filling all the pages would require dozens of minutes.
     
    Doing an erase with blkdiscard and then restoring the backup skipping the blank parts now becomes sensible!
    There is an issue though: discarding pages does not fill them with 0x00 bytes, but with 0xff bytes, so the real blank parts now are not those which contains string of 0x00s but those which contains strings of 0xff bytes. Those may or may be not so common. Surely they are common in non-programmed sectors, but results may vary.
     
    As a conclusion: restoring the whole count of eMMC sectors, despite being slower, is surely the simplest and most reliable way!
  10. Like
    curse got a reaction from chinhhut in CSC Armbian for RK3318/RK3328 TV box boards   
    I noticed the same when I was trying to restore my backup. It got stuck at around 20-25 percent and I thought it might work better if I uncompress it first.
    Oups, I have a 64GB eMMC, and the SD card I had at the time was only 16 or 32 GB. 
    The backup is a raw disk image of the eMMC, and it will always be the same size as the eMMC until it's compressed, and "removing the blank data" is part of the compression process. 
  11. Like
    curse reacted to jock in CSC Armbian for RK3318/RK3328 TV box boards   
    @MX10.AC2N
     
    As @curse noticed, probably you need the bison and flex packages to install headers. But you don't really need headers in case you don't want to compile kernel modules by yourself.
  12. Like
    curse got a reaction from MX10.AC2N in CSC Armbian for RK3318/RK3328 TV box boards   
    My French is not the best but for me it seems like the folders named "/boot/dtb-5.14.13-rockchip64/rockchip", "/boot/dtb-5.14.13-rockchip64/rockchip/overlay" and "/var/lib/initramfs-tools" are missing and the packages "bison" and "flex" needs to be installed.
  13. Like
    curse got a reaction from RetroFan90 in CSC Armbian for RK3318/RK3328 TV box boards   
    And perhaps try with different SD cards. I first used some expensive recommended 64GB SanDisk card and nothing worked then I tried a "no-name" cheap 8GB card and it worked perfectly. I think it's up to luck when it comes to the SD cards. The recommended expensive cards might work more often than the cheap ones, but sometimes it's the other way around. 
  14. Like
    curse got a reaction from fabiobassa in CSC Armbian for RK3318/RK3328 TV box boards   
    And perhaps try with different SD cards. I first used some expensive recommended 64GB SanDisk card and nothing worked then I tried a "no-name" cheap 8GB card and it worked perfectly. I think it's up to luck when it comes to the SD cards. The recommended expensive cards might work more often than the cheap ones, but sometimes it's the other way around. 
  15. Like
    curse got a reaction from chinhhut in CSC Armbian for RK3318/RK3328 TV box boards   
    And perhaps try with different SD cards. I first used some expensive recommended 64GB SanDisk card and nothing worked then I tried a "no-name" cheap 8GB card and it worked perfectly. I think it's up to luck when it comes to the SD cards. The recommended expensive cards might work more often than the cheap ones, but sometimes it's the other way around. 
  16. Like
    curse got a reaction from RetroFan90 in CSC Armbian for RK3318/RK3328 TV box boards   
    Just one question. How did you "burn" the iso to the SD-card? did you use dd, rufus, etc? Just in case the error is there and not with the box or the iso?
  17. Like
    curse got a reaction from chinhhut in CSC Armbian for RK3318/RK3328 TV box boards   
    I have the plus. However, I was never able to boot Armbian from the SD card, I used Multitool from this thread. Added the Armbian ISO to it, multitool booted fine from the SD card, then took a backup of the stock ROM with multitool and then erased eMMC and installed Jock's Armbian via multitool. 
     

  18. Like
    curse got a reaction from fabiobassa in CSC Armbian for RK3318/RK3328 TV box boards   
    I have the plus. However, I was never able to boot Armbian from the SD card, I used Multitool from this thread. Added the Armbian ISO to it, multitool booted fine from the SD card, then took a backup of the stock ROM with multitool and then erased eMMC and installed Jock's Armbian via multitool. 
     

  19. Like
    curse got a reaction from fabiobassa in CSC Armbian for RK3318/RK3328 TV box boards   
    Have fun experimenting. I myself is "hooked" on playing with the TV-boxes. First I had an old Mini M8S II Amlogic S905x 2/8 box that had been in a drawer for years, and I thought it should be possible to use it as a mini server and found Armbian. Then I felt that 8GB was a bit tiny, and started to look around for something slightly bigger though still cheap. I was choosing between Rockship RK3328 and Allwinner H6 since it looked like they both had fairly good support already, and not an Amlogic S905x(2,3,4) since I read here on the forum about some bad practice from Amlogic. After finding out that the H6 only can handle 3GB RAM, I went for the RK3328. In my subjective experience, the Amlogic felt easier to work with and also felt faster... No idea if it is for real. Thinking about getting a box with an Allwinner chip as well, just so I have one each of the three bigger brands, but it will have to wait for some savings to pile up. The RK3566 boxes with 8GB RAM looks fun as well, but I don't think I use anywhere near 4GB at the moment...
  20. Like
    curse got a reaction from fabiobassa in CSC Armbian for RK3318/RK3328 TV box boards   
    Ahh. So it's a HK1 thing...I got a H96 Max+ and at least it seems to have the specified RAM/eMMC size.
     
    Welcome to Armbian 21.11.0-trunk Bullseye with Linux 5.10.68-rockchip64 No end-user support: built from trunk System load: 55% Up time: 2 days 21:36 Memory usage: 17% of 3.88G IP: 192.168.0.13 192.168.0.15 CPU temp: 75°C Usage of /: 10% of 57G storage/: 74% of 1.9T storage temp: 31°C curse@H96MaxPlus:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 1.9G 0 1.9G 0% /dev tmpfs 398M 44M 355M 11% /run /dev/mmcblk2p1 57G 5.4G 51G 10% / tmpfs 2.0G 0 2.0G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 2.0G 32K 2.0G 1% /tmp /dev/sda1 1.9T 1.4T 490G 74% /home/curse/Media /dev/zram1 49M 22M 24M 49% /var/log tmpfs 398M 0 398M 0% /run/user/1000 curse@H96MaxPlus:~$ free -h total used free shared buff/cache available Mem: 3.9Gi 711Mi 308Mi 43Mi 2.9Gi 3.1Gi Swap: 1.9Gi 4.0Mi 1.9Gi  
  21. Like
    curse got a reaction from RetroFan90 in CSC Armbian for RK3318/RK3328 TV box boards   
    While I was in Sweden some month ago, I only had access to an old 1024x768 monitor, connected via an HDMI to DVI adapter. It did NOT work. Multitool, yes, everything else, no.
    I would not recommend to do an apt update && apt upgrade before you have gone through "armbian-config" and frozen firmware and kernel updates, or frozen them by other means.
  22. Like
    curse reacted to jock in CSC Armbian for RK3318/RK3328 TV box boards   
    Update!
     
    Images on first page have been updated to kernel 5.14.13
     
  23. Like
    curse reacted to jock in CSC Armbian for RK3318/RK3328 TV box boards   
    @curse
    Yes, it is possible. Temperatures are quite varying with these chips and reportings are not very reliable IMHO. The problem is very similar with rk322x too.
    Cpu usage in top is the sum of all cores/processors, so it can go beyond 100% if your process is doing multithreaded work.
  24. Like
    curse got a reaction from RetroFan90 in CSC Armbian for RK3318/RK3328 TV box boards   
    I replaced the existing /lib/firmware/brcm/brcmfmac4334-sdio.rockchip,rk3318-box.txt with this file. Then it worked in nmcli
    #nmcli device wifi list shows available wifi networks then #nmcli --ask device wifi connect vodafone5CC8 and it asked for the password for my wifi named vodafone5CC8, and now it connected, before it didn't. My overlays are: overlays=rk3318-box-cpu-hs rk3318-box-emmc-ddr rk3318-box-led-conf1 rk3318-box-wlan-ap6334
  25. Like
    curse got a reaction from RetroFan90 in CSC Armbian for RK3318/RK3328 TV box boards   
    No, I'm quite bad at screwing and such because of an injury. Sorry. Oh... I have the H96Max+ RK3328 4GB/64GB Voice Remote version (not that I have tried using voice commands on it). Who knows, the Voice Remote version and the normal remote version might differ.