Jump to content


  • Posts

  • Joined

  • Last visited

Reputation Activity

  1. Like
    chinhhut got a reaction from jpa in CSC Armbian for RK3318/RK3328 TV box boards   
    could you share the way to boot Armbian from your H96 max 4/64? I've tried to follow exactly the steps from the guide in this topic but unable to boot from SD card.
    My box look like this photo below:

  2. Like
    chinhhut reacted to antoni in MAC address changes every time I reboot the system.   
    Good evening,
    I have got Orange pi 5 board. MAC address of this board network interface `end1` changes every time I reboot the system. I tried adding entry in /boot/armbianEnv.txt, I tried specifying hwaddress in /etc/network/interfaces. Neither of those two options worked.
  3. Like
    chinhhut reacted to Hqnicolas in Efforts to develop firmware for H96 MAX V56 RK3566 4G/32G   
    andy.yan@rock-chips.com start to patch the RK3566 boards
    i think this board will be supported by kernel 6.1
    give it a try!
  4. Like
    chinhhut reacted to Gausus in CSC Armbian for RK3318/RK3328 TV box boards   
    Thank you for the tips @jock
    I have 2 H96max+ RK3328 ∕ 4GB  tvboxes.
    Armbian 22.08 - Debian Bullseye minimal - mainline kernel 5.18.10
    BOX1 :  On internal eMMC
    BOX2:   Boot Armbian from SDCARD  , Android on internal eMMC
    Benchmark from terminal:
    mbw 1000  
    Box1 : RAM 667Mhz CPU @ 1,3GHz
    AVG    Method: MEMCPY    Elapsed: 0.82118    MiB: 1000.00000    Copy: 1217.764 MiB/s
    AVG    Method: DUMB    Elapsed: 0.88632    MiB: 1000.00000    Copy: 1128.263 MiB/s
    AVG    Method: MCBLOCK    Elapsed: 0.27756    MiB: 1000.00000    Copy: 3602.800 MiB/s
    Box2 : RAM 333Mhz (Android uboot) CPU @ 1,3GHz
    AVG    Method: MEMCPY    Elapsed: 1.51033    MiB: 1000.00000    Copy: 662.107 MiB/s
    AVG    Method: DUMB    Elapsed: 1.62614    MiB: 1000.00000    Copy: 614.955 MiB/s
    AVG    Method: MCBLOCK    Elapsed: 0.54709    MiB: 1000.00000    Copy: 1827.854 MiB/s
    To boot from sdcard when Android on internal storage.
    1. Flash Armbian on sdcard
    2. Download Multitool.img 
    3. Mount multitool.img on linuxpc or flash to another sdcard.
    4. Copy  trustos.img and uboot.img from bsp folder to a folder on linuxpc,
    5 . DD trustos.img and uboot.img to sdcard Armbian from linuxpc
    sudo dd if=uboot.img of=/dev/SDCARD seek=16384 conv=fsync sudo dd if=trustos.img of=/dev/SDCARD seek=24576 conv=fsync  
  5. Like
    chinhhut reacted to MattWestB in CSC Armbian for RK3318/RK3328 TV box boards   
    Ubuntu 22.04 LTS rk3318-box is up and running nicely with working Docker and HA supervised looks working OK.
    Up time is only some hours after install but the prereleases was also working stable so hopefully it shall doing the same.
    Great thank devs for making it happening !!!
  6. Like
    chinhhut got a reaction from fabiobassa in CSC Armbian for RK3318/RK3328 TV box boards   
    @fabiobassa Yes. I'm thinking about the defective emmc issue because I have several 3318 boxes and 1 box get this kernel panic issue, an other box get crashed after several hours running, other ones work well over time. 
  7. Like
    chinhhut reacted to fabiobassa in CSC Armbian for RK3318/RK3328 TV box boards   
    home assistant is a great project but at the same time is very hard disk intensive and resource eating. In special mode if you even have motion plug-in or other pugins that extensively use the hard disk and/or internal emmc
    And it also coul be a defective emmc since many chinese tvboxes are badly assembled with faulty components
  8. Like
    chinhhut reacted to jock in CSC Armbian for RK3318/RK3328 TV box boards   
    @chinhhut Ah ok, an error during shutdown... well I never experienced such issue, may be an error in the kernel or in the trust OS which is leading some spurious interrupt after secondary cores are brought down... I'm not able to recognize anything specific from that crash dump, but I may suggest you do add "panic=10" in the kernel command line: this way, when a kernel panic happens, the kernel may still try to reboot after 10 seconds so you don't get stuck.
  9. Like
    chinhhut reacted to jock in CSC Armbian for RK3318/RK3328 TV box boards   
    No idea. From the "screen shot" (literally :D) it seems to happen right during startup or does it happen during regular runtime too?
  10. Like
    chinhhut reacted to fabiobassa in CSC Armbian for RK3318/RK3328 TV box boards   
    What services/app have installed?
    Did kernel crashed before new installation or crashes even with unloaded system ?
    As @jockexplained me, no user space applications should ever freeze/panic the kernel , unless drivers are involved.
    And if kernel crashes I am afraid you Will not have any log either
  11. Like
    chinhhut reacted to jock in CSC Armbian for RK3318/RK3328 TV box boards   
    If the kernel crashes then you have no other way than attach a serial adapter to the board UART to log continously, in the hope the kernel says something before the freeze happens.
  12. Like
    chinhhut got a reaction from tommy in CSC Armbian for RK3318/RK3328 TV box boards   
    @fabiobassa @jock I've followed your guide and got success. Thank you so much.
    root@mybox:~/rkdeveloptool# ls 99-rk-rockusb.rules Makefile.in RKComm.h RKImage.h RKScan.h cfg configure.ac main.cpp CMakeLists.txt Property.hpp RKComm.o RKImage.o RKScan.o config.h.in crc.cpp main.o DefineHeader.h RKBoot.cpp RKDevice.cpp RKLog.cpp Readme.txt config.ini crc.o parameter_gpt.txt Endian.h RKBoot.h RKDevice.h RKLog.h aclocal.m4 config.log gpt.h rkdeveloptool Makefile RKBoot.o RKDevice.o RKLog.o autom4te.cache config.status license.txt Makefile.am RKComm.cpp RKImage.cpp RKScan.cpp boot_merger.h configure log root@mybox:~/rkdeveloptool# ./rkdeveloptool ld DevNo=1 Vid=0x2207,Pid=0x320c,LocationID=101 Loader root@mybox:~/rkdeveloptool# ./rkdeveloptool rd 3 Reset Device OK. root@mybox:~/rkdeveloptool# ./rkdeveloptool db MiniLoaderAll.bin Opening loader failed, exiting download boot! root@mybox:~/rkdeveloptool# ./rkdeveloptool db /root/MiniLoaderAll.bin Downloading bootloader succeeded. root@mybox:~/rkdeveloptool# ./rkdeveloptool wl 0X0 /root/Armbian_21.11.0-trunk_Rk3318-box_bullseye_edge_5.14.14_minimal.img Write LBA from file (100%) root@mybox:~/rkdeveloptool# ./rkdeveloptool ---------------------Tool Usage --------------------- Help: -h or --help Version: -v or --version ListDevice: ld DownloadBoot: db <Loader> UpgradeLoader: ul <Loader> ReadLBA: rl <BeginSec> <SectorLen> <File> WriteLBA: wl <BeginSec> <File> WriteLBA: wlx <PartitionName> <File> WriteGPT: gpt <gpt partition table> WriteParameter: prm <parameter> PrintPartition: ppt EraseFlash: ef TestDevice: td ResetDevice: rd [subcode] ReadFlashID: rid ReadFlashInfo: rfi ReadChipInfo: rci ReadCapability: rcb PackBootLoader: pack UnpackBootLoader: unpack <boot loader> TagSPL: tagspl <tag> <U-Boot SPL> ------------------------------------------------------- root@mybox:~/rkdeveloptool# ./rkdeveloptool ld DevNo=1 Vid=0x2207,Pid=0x320c,LocationID=101 Maskrom  
  13. Like
    chinhhut reacted to jock in CSC Armbian for RK3318/RK3328 TV box boards   
    You should ask Android people then.
    AFAIK Android images have some hardwired settings that make it work only on internal eMMC.
    These settings should be changed to make it work, but don't ask me: never dig into.
  14. Like
    chinhhut reacted to paradigman in CSC Armbian for RK3318/RK3328 TV box boards   
    @lucky62 : I have a board with a 3318 CPU and a 7-segment display, driven by a 6334 controller. I would like to ask if the openvfd driver you created will be good for this too? If so, am I still asking that your openvfd driver is already included in the jock's bullseye minimal image? I want to set up and control this display.
  15. Like
    chinhhut reacted to flippy in Methods to fix x96 max plus(s905x3) gigabit ethernet problem   
    I found the correct method to fix the bug that the x96-max-plus(s905x3) gigabit ethernet  does not work:
    Up to now, only HK1Box/vontar x3 is the only s905x3 TV box that can be used perfectly in armbian.  So I extracted the bootloader of hk1box and wrote it into x96-max-plus, and it worked.
    This method is very simple, so it is recommended to everyone in need.
    Step 1:  upload three dtbs into /boot/dtb/amlogic :
        meson-sm1-hk1box-vontar-x3.dtb  (Similar to meson-sm1-x96-max-plus.dtb, only the modal name is changed)
    Step 2:  modify /boot/uEnv.txt, replace dtb with meson-sm1-x96-max-plus-100m.dtb,  restart the Armbian system
    Step 3:  upload hk1box-bootloader.img to /tmp
    Step 4:  Run these commands under the shell:
    dd if=/tmp/hk1box-bootloader.img of=/dev/mmcblk2 bs=1 count=442
    dd if=/tmp/hk1box-bootloader.img of=/dev/mmcblk2 bs=512 skip=1 seek=1
    Step 5:  modify /boot/uEnv.txt, replace dtb with meson-sm1-x96-max-plus.dtb, and restart again.
    meson-sm1-x96-max-plus.dtb meson-sm1-x96-max-plus.dts meson-sm1-hk1box-vontar-x3.dtb meson-sm1-hk1box-vontar-x3.dts hk1box-bootloader.img.xz meson-sm1-x96-max-plus-100m.dtb meson-sm1-x96-max-plus-100m.dts
  16. Like
    chinhhut reacted to Igor in How to build for an unsupported board (Pine64 Quartz64)?   
    Officially no. Too many hardware is seeking for very low time and expertise.

    Example of first start
    Yes, it might looks complicated, but we are working on to improve the procedure. That is generally more useful for us.
    Documentation - start there first:
    ... and do small steps.

    That kernel is shipped with the chip, while path to modern kernel is long, hard and expensive:
    Armbian framework help yes, while for hardware related features - we can't finance hardware vendor business.
  17. Like
    chinhhut reacted to balbes150 in Board Bring Up Station P2 rk3568, M2 rk3566   
    Update version 20211124 with legacy kernel.
    p.s. Now I am testing a new image with a 5.16.rc2 kernel, in which HDMI and USB work. After all checks are completed, new versions of images with a new kernel will be available. 
  18. Like
    chinhhut reacted to fabiobassa in CSC Armbian for RK3318/RK3328 TV box boards   
    I know is not fine answer to a question with another question but in this case
    comes very natural ask  : why did you modded it ??? Just for fun ? You didn't have a defined purpose in trying linux ?

    Anyway, just to answer , in my personal study case I have done on it:
    voip pbx ( asterisk)
    network nas
    network firewall
    pihole dns firewall
    openvpv, wireguard and tinc vpn
    home assistant
    special ip cam monitoring and data acquisition

    and I guess I could experiment more..... if only I would study more potential applications
  19. Like
    chinhhut reacted to jock in CSC Armbian for RK3318/RK3328 TV box boards   
    @callegar Thanks for spotting it out.
    Actually it is my fault the package installs things in /usr/local/bin.
    I will change that to install in /usr/sbin which is probably more appropriate
    @chinhhut It could work, but it couldn't
    The problem is shrinking the partition, you don't just need to reduce the partition size, you also need to shrink the filesystem appropriately otherwise you lose data and possibly the partition does not get mounted when restored.
    Enlarging the partition (and the filesystem) is easy and almost cheap, shrinking can be painful. But you can try indeed! (And maybe realize that losing some time to restore the wholly 64Gb eMMC is better than a headache )
  20. Like
    chinhhut reacted to jock in CSC Armbian for RK3318/RK3328 TV box boards   
    @chinhhut Actually armbian provides a way to introduce user-level patch files which can modify the behaviour of the installed system.
    It means that you can, to some extent, launch sudo ./compile.sh and finally produce an image customized for your needs.
    Armbian documentation will help you further.
  21. Like
    chinhhut reacted to jock in CSC Armbian for RK3318/RK3328 TV box boards   
    First page, github repository has always been public
  22. Like
    chinhhut got a reaction from Ben N Voutour in CSC Armbian for RK3318/RK3328 TV box boards   
    I will study more how to patch some additional files but could you share the source code to build RK3318 image?
    Thank you so much for your support.
  23. Like
    chinhhut got a reaction from ghoul in RK3566 and Armbian   
    Personally, we still hope our hero @jock will take a look on rk3566 soon in near future. For now, I feel happy with my 3318 box.
  24. Like
    chinhhut 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!
  25. Like
    chinhhut reacted to curse 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. 
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines