RetroFan90

  • Posts

    44
  • Joined

  • Last visited

Reputation Activity

  1. Like
    RetroFan90 reacted to curse 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.
  2. Like
    RetroFan90 reacted to Elmojo in CSC Armbian for RK3318/RK3328 TV box boards   
    Good evening all,
    Using the excellent instructions by @jock in Post #1, I was able to get Debian Bullseye desktop [xfce] installed on my Pulierde T9 box.
    Everything is up and running, I can connect to my network, etc... So .... now what? lol
    I did this mostly as an interesting little exercise, and also because I'm loathe to throw away usable tech. However, now that it's a functional little linux box, what can I do with it?
    I have no need of any sort media streamer/server box, since I have a full server in my house.  I thought about maybe a pihole, or something to do with HomeAssistant, but I wouldn't know where to begin.
    So here's my question: What should I do with this little beast now?
    If it matters, this one is a RockChip 3328, 4GB RAM, 64GB ROM, Mali450 GPU
    Thanks for all the hard work that went into making this project a possibility!
    -E
  3. Like
    RetroFan90 reacted to ak007 in CSC Armbian for RK3318/RK3328 TV box boards   
    hi Jock, Thanks for your efforts on Armbian for RK3318. I installed latest image on H96+ Max, everything works except wifi. Wifi isdetected but unable to connect(With valid credentials). Please sugges how to fix the issue.
    Below are logs:
    http://ix.io/3F2c
  4. Like
    RetroFan90 reacted to curse 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, 
  5. Like
    RetroFan90 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!
  6. Like
    RetroFan90 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.
  7. Like
    RetroFan90 reacted to MX10.AC2N in CSC Armbian for RK3318/RK3328 TV box boards   
    You can try YUNoHost, it's cool I use it on my beelink gt-king pro with armbian-meson64 works fine and have many apps.
    Today I try install of Swizzin, on my RK3328 box that's work ( install process need root user "su -" )
    it's another possibility..
    https://github.com/swizzin/swizzin
    https://swizzin.ltd/getting-started/
  8. Like
    RetroFan90 reacted to chinhhut 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.
  9. Like
    RetroFan90 reacted to jock in CSC Armbian for RK3318/RK3328 TV box boards   
    First page, github repository has always been public
  10. Like
    RetroFan90 reacted to Elmojo in CSC Armbian for RK3318/RK3328 TV box boards   
    Now that is something I may be interested in! Thanks for the ideas!
  11. Like
    RetroFan90 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.
  12. Like
    RetroFan90 reacted to jock in Testing hardware video decoding (rockchip, allwinner?)   
    Hello, recent upgrades to armbian are regarding kernel 5.15.
    I noticed that many v4l2 fixes and enhancements went into this release, so I decided to compile ffmpeg using LibreELEC patched version and mpv over it.
    mpv turns out to be statically linked with ffmpeg, so I propose it here for people who is interested in cutting edge kernel and wants to do some tests.
     
    This has been tested on Debian Bullseye and Ubuntu Hirsute on following platforms:
    Rockchip RK3228/9 (kernel 5.10, 5.14) Rockchip RK3288 (kernel 5.14) Rockchip RK3318/28 (kernel 5.15)  
    It should work on allwinner platforms too, but I didn't test it there.
    Binaries are built by me on developing boards.
     
    The binary for armhf is available here
    The binary for aarch64 is available here
     
    Dependencies for Debian Bullseye and Ubuntu Hirsute:
    apt install libass9 libbluray2 librubberband2 libsdl2-2.0-0 libva-drm2 libva-wayland2 libva-x11-2 libva2 libvdpau1 libx264-160 libx265-192 libxss1 libxv1 libfdk-aac2  
    I have had issues with dependencies on Debian Buster/Ubuntu Focal, in particular libx264-160 and libx265-192 are not available there.
    I Solved the issue downloading the packages from Debian Bullseye web page and manually installing them.
    There may be the need for some other dependency depending upon your actual installation.
     
    Run mpv in a virtual terminal (videos up to 4K) with this CLI:
    mpv --vo=gpu --hwdec=drm --gpu-hwdec-interop=drmprime-drm --drm-draw-plane=overlay --drm-drmprime-video-plane=primary <video.mp4>  
    Mpv can be run in X11 with this other CLI, but due to buffer copying it requires a good CPU - rk3228 and rk3328 won't even play 720p, rk3288 do 720p fine:
    mpv --vo=gpu --hwdec=auto-copy --gpu-context=x11egl --gpu-hwdec-interop=drmprime-drm <video.mp4>  
    This is an experiment and your mileage may vary a lot:
    H.264 codec should be well supported around the boards; H.265 has more limited support VP8 should be generally supported VP9 seems to still require some work.
  13. Like
    RetroFan90 got a reaction from mkultra in CSC Armbian for RK3318/RK3328 TV box boards   
    it appears that someone has made a method to install libreelec for 3318/3328 on an sd card simply write the img file from libreelec to a usb sd card reader then fire up vmware with ubuntu and mount the usb sd in vmware and have the trust.img on the vm and send the command as root 
    dd if=trust.img of=/dev/sdb seek=24576
    unmount ant shut down the vm, then edit /extlinux/extlinux.conf to point to rk3318-box.dtb
    then put the rk3318-box.dtb wherever you pointed the /extlinux/extlinux.conf file to.
    eject the usb sd adapter from windows.
    insert the sd card into the box and boot it up, it will resize the sd card to any remaining free space for libreelec
    use version 10.0.1 rk3328-arm a1 box and it mostly works except bt/wifi/led/ir, but everything else more or less works normally
  14. Like
    RetroFan90 reacted to fabiobassa in CSC Armbian for RK3318/RK3328 TV box boards   
    Руслан Зинеев
    Привет , I used google translator to understand your post.
    The uart speed is contained into the image : you can put the image on a sd and under folder  /boot you will find a config item.
    but can you explain in english please exactly which is your problem ?
     EDIT: try to set your uart directly to 115200

    you will lose initial infos but then you can follow ll the boot process
     
  15. Like
    RetroFan90 reacted to fabiobassa in CSC Armbian for RK3318/RK3328 TV box boards   
    @mkultra
     
    If you go to my post of 5 November you will find all the necessary instructions. You need upload a loader before doing anything
     
    If you are tired or lazy to read the whole 3ad... Well...... that might be a obstacle...... ;-)
  16. Like
    RetroFan90 reacted to mkultra in CSC Armbian for RK3318/RK3328 TV box boards   
    ok I just discovered the 'like icon' - I wasn't seeing it on my bright monitor so apologies for the 'late likes' 
    will revisit the interesting rkdeveloptool tomorrow but still getting some errors
    $sudo ./rkdeveloptool db MiniLoaderAll.bin
    Creating Comm Object failed!
     
  17. Like
    RetroFan90 reacted to fabiobassa in CSC Armbian for RK3318/RK3328 TV box boards   
    @mkultra

    you must give the right path
    e.g. rkdeveloptool db /home/mickeymouse/miniloaderall.bin acodrlying where you have your miniloader
     
  18. Like
    RetroFan90 reacted to mkultra in CSC Armbian for RK3318/RK3328 TV box boards   
    cheers but no difference, same error
    edit: the only slight change I had to do was this cos the program wouldn't compile at first:
    Edit the main.cpp line 1491 from
    static inline uint32_t convertChipType(const char* chip) {
    char buffer[5];
    memset(buffer, 0, sizeof(buffer));
    to
    static inline uint32_t convertChipType(const char* chip) {
    char buffer[558];
    memset(buffer, 0, sizeof(buffer));
    No more error.
    https://github.com/rockchip-linux/rkdeveloptool/issues/55
  19. Like
    RetroFan90 reacted to jock in CSC Armbian for RK3318/RK3328 TV box boards   
    That is not maskrom mode, lsusb is telling you a wrong information.
    You are in rockusb mode, which is provided by u-boot and allows limited operation.
     
    To enter maskrom mode from rockusb mode, you need to get rkdeveloptool from rockchip github repository and run rkdeveloptool rd 3
  20. Like
    RetroFan90 reacted to mkultra in CSC Armbian for RK3318/RK3328 TV box boards   
    making a bit of progress lol
    It goes into 'mask mode' without shorting anything.....just toothpick and diy bodged male to male USB cable in the USB2 port
    Bus 005 Device 008: ID 2207:320c Fuzhou Rockchip Electronics Company RK3328 in Mask ROM mode
    BUT when I try and flash I get an error that I can't solve at the mo 
    sudo ./flash_tool.sh -c rk3328 -p system -i image/image.zip
    PARTITIONS OFFSET: 0 sectors.
    The device does not support this operation!
     
  21. Like
    RetroFan90 reacted to mkultra in CSC Armbian for RK3318/RK3328 TV box boards   
    @Gaususcool find cheers
    I found this interesting procedure for reflashing, especially if you use linux  https://www.armbian.com/z28-pro/
  22. Like
  23. Like
    RetroFan90 reacted to mkultra in CSC Armbian for RK3318/RK3328 TV box boards   
    help please! I hosed this box some months ago, tried the multitool image but nothing
    strangely the first time I tried that latest debian image from the 1st post I got a H96 Max+ splash screen and I got a bit excited but nothing afterwards and even when I burnt the SD card again I got nothing 
    anyone know where pins 7 and 8 on the BGA chip are? Or is there any point trying to do the UART serial thing?
    Thanks!
     


  24. Like
    RetroFan90 reacted to curse 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. 
  25. Like
    RetroFan90 reacted to jock in CSC Armbian for RK3318/RK3328 TV box boards   
    Well, since the sd controller on his board is swapped I don't think it will ever work.
    But sometimes is true, more expensive cards are not always better.