jock

Members
  • Content Count

    476
  • Joined

  • Last visited

Reputation Activity

  1. Like
    jock got a reaction from MaxT in CSC Armbian for RK322X TV Boxes   
    I think the boot process is the same or very similar among rk322x and rk3318/rk3328. I had the time to study the rk322x boot and make some intresting experiments.
    The standard firmware boot that uses proprietary rockchip binaries and sources usually do these steps:
    the SoC ROM code reads the ddrbin at sector 0x40 and executes it to initialize DDR memory the SoC ROM then reads the code that follows the ddrbin and finds the miniloader (you can find various versions of miniloaders from the kwiboo repository I linked before) the miniloader takes control and checks for GPT partitions called "uboot" and "trustos", if partitions are found sets PTR_UBOOT and PTR_TRUSTOS pointers to the partitions sectors, otherwise sets the pointers to default values respectively of 0x2000 and 0x4000 the miniloader looks for the "LOADER" (that's exactly a string with uppercase characters) signature at PTR_UBOOT sector, if the signature is found loads u-boot in memory, otherwise increases the PTR_UBOOT pointer by 0x800 sectors and retries the miniloader looks for "TRUST" signature at PTR_TRUSTOS to do the same job the miniloader boots the trust os (that's a build of the ATF), which installs itself, and then boots u-boot u-boot finally loads the device tree and boots the kernel when you use prepare the u-boot and trust images with  loaderimage --pack command, is actually decorating uboot/trust image with a header (the LOADER/TRUST signatures, maybe other things like checksums and the memory location where the image should be loaded into).
    Likewise you can extract u-boot and trust images from flash memory looking at those locations and obtain the originals using loaderimage --unpack command. @knaerzche extracted a working trustos from a rk3228 box image this way and now LibreELEC uses that blob as trustos for all rk322x images. I'm also using a trustos extracted this way to boot the multitool, and it works pretty well.
     
    The other boot process that uses mainline u-boot and Opensource OPTEE (in place of ATF) is as follows:
    The SoC ROM code reads the u-boot TPL at sector 0x40, this initializes DDR memory the SoC ROM code reads the u-boot SPL that immediately follows the TPL u-boot SPL executes the OPTEE trustos u-boot SPL executes the main u-boot u-boot loads device tree and boots the kernel For some extents, you can mix the two boot processes, for example in Armbian I use the second boot process, but at the step 1 I use the proprietary ddrbin because u-boot TPL does not support DDR2 memories.
     
    My guess is that the rk3318/rk3328 boot process is very much the same
     
  2. Like
    jock reacted to Werner in Major forums update   
    Invision Community version has been bumped to 4.5.3
    Everything is still pretty rough, both at the frontend as well as the backend. Might probably take a few days until everything is in good shape.
    The good news is that for the most part the forums are usable
  3. Like
    jock got a reaction from nokirunner in CSC Armbian for RK322X TV Boxes   
    Updated mainline images with kernel 5.8.9
     
    Finally the mainline kernel has been pushed further and it looks very promising.
    Link to the new images are in the first page.
     
    PS: trying the Ubuntu Focal image, I'm happy Firefox is performing decently, but had to blacklist lima module to get good 2D desktop experience and (of course) disable window compositing.
  4. Like
    jock got a reaction from hatran in 25$ TV Box running Armbian "out of the box"   
    @Armin
    if you need just something such small, you may find nanopi or orange pi boards. Some small models are pretty cheap (<10$) and well supported by armbian. Tv boxes have no exposed GPIOs, which can instead be very useful for domotic applications.
    For example, I have an old Orange PI One (Allwinner H3) which has ethernet, 1 USB port, 512mb of ram and some exposed GPIO. I paid less than 10$ some year ago. I guess now you can get something similar with wifi too at the same price.
  5. Like
    jock reacted to Matteo Venturi in CSC Armbian for RK322X TV Boxes   
    Hi. This is my experience with H96mini (CPU 3228A without sd slot).
     
    Download and compile rkdeveloptool (https://github.com/rockchip-linux/rkdeveloptool)
    Download rk322x_loader.bin and your favorite OS image from forum (decompress image from .xz format to .img)
     
    While continuing to press the button inside AV port(use toothstick), then connect power cable to device.  Release the button insiede AV port, then connect the TV box to the PC using USB port number 1, the closest one to the edge. 
    Device will boot in mask rom mode.
    Run following commands:
    ./rkdeveloptool db rk322x_loader.bin
    ./rkdeveloptool wl 0x0 your_image_os.img
    ./rkdeveloptool rd
     
    Don't poweroff device.
    Connect devide to monitor or TV using HDMI.
     
    Wait while device booting.
     
    Good luck!
  6. Like
    jock got a reaction from gounthar in Device tree translation   
    There is not really "translation" between android dts to linux dts. Android could be considered a Linux distribution like Ubuntu or Debian.
    What you are referring as "android" dts is nothing more than a device tree wrote for a very old Linux kernel (probably 3.10 or 3.14).
    As long as things change during time, so the device tree specifications become more standardized and well-defined. Device trees for old kernels (3.10 is very old nowadyas) are very messy and generally harder to read and understand.
     
    Device trees describe the hardware equipment of  your board. On the x86 world there is something which was used to be called Plug&Play in the early days: Plug&Play let the devices expose themselves to the operating system, which is able to discover and configure them properly without the user intervention. On ARM side this mechanism does not yet exists (to be precise, something exists, but is not available on SBCs), so to let the hardware being discovered you have to tell the operating system. The device tree does exactly this.
     
    All the properties and nodes in the device tree are read back by the kernel and kernel drivers. The "compatible" property tells the kernel which driver needs to be loaded, the driver then reads the node properties to know the resources associated with the device (memory regions, registers, interrupts, dma channels, gpio pins, etc...) and its specific characteristics (for example the clock frequency, FIFO queues, etc...), so it can proceed to initialize and make the device available to the system.
     
    Being aware of this and getting back to the original question, there is no magic translation tool, you have to do the hard job of reading the old device tree and translate into the new. Experience and documentation are fundamental (you can find the documentation on the device tree bindings shipped with every linux kernel in Documentation/devicetree/bindings directory). Intuition and general knowledge of how electronic devices work are very helpful for such task.
     
     
  7. Like
    jock got a reaction from gounthar in Understanding Device Trees   
    I am a bit ashamed of citing myself, but this is a small post I wrote some time ago with some explanations:
     
    https://forum.armbian.com/topic/14752-device-tree-translation/?do=findComment&comment=106284
     
  8. Like
    jock got a reaction from Bozza in Understanding Device Trees   
    I am a bit ashamed of citing myself, but this is a small post I wrote some time ago with some explanations:
     
    https://forum.armbian.com/topic/14752-device-tree-translation/?do=findComment&comment=106284
     
  9. Like
    jock got a reaction from Werner in Device tree translation   
    There is not really "translation" between android dts to linux dts. Android could be considered a Linux distribution like Ubuntu or Debian.
    What you are referring as "android" dts is nothing more than a device tree wrote for a very old Linux kernel (probably 3.10 or 3.14).
    As long as things change during time, so the device tree specifications become more standardized and well-defined. Device trees for old kernels (3.10 is very old nowadyas) are very messy and generally harder to read and understand.
     
    Device trees describe the hardware equipment of  your board. On the x86 world there is something which was used to be called Plug&Play in the early days: Plug&Play let the devices expose themselves to the operating system, which is able to discover and configure them properly without the user intervention. On ARM side this mechanism does not yet exists (to be precise, something exists, but is not available on SBCs), so to let the hardware being discovered you have to tell the operating system. The device tree does exactly this.
     
    All the properties and nodes in the device tree are read back by the kernel and kernel drivers. The "compatible" property tells the kernel which driver needs to be loaded, the driver then reads the node properties to know the resources associated with the device (memory regions, registers, interrupts, dma channels, gpio pins, etc...) and its specific characteristics (for example the clock frequency, FIFO queues, etc...), so it can proceed to initialize and make the device available to the system.
     
    Being aware of this and getting back to the original question, there is no magic translation tool, you have to do the hard job of reading the old device tree and translate into the new. Experience and documentation are fundamental (you can find the documentation on the device tree bindings shipped with every linux kernel in Documentation/devicetree/bindings directory). Intuition and general knowledge of how electronic devices work are very helpful for such task.
     
     
  10. Like
    jock got a reaction from jeanrhum in Best TVBOX for armbian used as micro services server   
    For less than 100$ you can go with Odroid N2/N2+ which is plenty powerful, but as already suggested float around properly supported SBCs and find one that best suits your need.
     
    Expensive tvboxes from known vendors usually are good quality, but I would not suggest to buy them to do server jobs.
    IMHO SBCs are a couple of notches superior for build quality, support and warranty, tv boxes are for toying around mostly
  11. Like
    jock got a reaction from xwiggen in CSC Armbian for RK322X TV Boxes   
    Ok much better, but at the moment I have no idea this is happening.
    The libreelec boot is somehow engaged because the behaviour changes if you leave the sdcard into, but the reason why it hangs is not clear to me yet.
    I will try to replicate soon on a board of mine
     
    edit: @jaum20 problem solved! Long story short: substitute the file rk3228a-box-mxq4kpro.dtb in the root of the libreelec sdcard with the one attached here. Important: if you're going to update/upgrade LibreELEC, you will need to replace again this file. This is a "problem" I will likely ask to @knaerzche if it can be solved somehow.
     
    Detailed answer for experts: the device tree with the legacy kernel is missing the property arm,cpu-registers-not-fw-configured in the timer section. It is needed on armbian but it is not needed on Libreelec because armbian has OPTEE as trust os (which requires the property), instead Libreelec uses the proprietary u-boot and trust os (which does the timer initialization by itself).
    rk3228a-box-mxq4kpro.dtb
  12. Like
    jock got a reaction from hexdump in CSC Armbian for RK322X TV Boxes   
    I think the boot process is the same or very similar among rk322x and rk3318/rk3328. I had the time to study the rk322x boot and make some intresting experiments.
    The standard firmware boot that uses proprietary rockchip binaries and sources usually do these steps:
    the SoC ROM code reads the ddrbin at sector 0x40 and executes it to initialize DDR memory the SoC ROM then reads the code that follows the ddrbin and finds the miniloader (you can find various versions of miniloaders from the kwiboo repository I linked before) the miniloader takes control and checks for GPT partitions called "uboot" and "trustos", if partitions are found sets PTR_UBOOT and PTR_TRUSTOS pointers to the partitions sectors, otherwise sets the pointers to default values respectively of 0x2000 and 0x4000 the miniloader looks for the "LOADER" (that's exactly a string with uppercase characters) signature at PTR_UBOOT sector, if the signature is found loads u-boot in memory, otherwise increases the PTR_UBOOT pointer by 0x800 sectors and retries the miniloader looks for "TRUST" signature at PTR_TRUSTOS to do the same job the miniloader boots the trust os (that's a build of the ATF), which installs itself, and then boots u-boot u-boot finally loads the device tree and boots the kernel when you use prepare the u-boot and trust images with  loaderimage --pack command, is actually decorating uboot/trust image with a header (the LOADER/TRUST signatures, maybe other things like checksums and the memory location where the image should be loaded into).
    Likewise you can extract u-boot and trust images from flash memory looking at those locations and obtain the originals using loaderimage --unpack command. @knaerzche extracted a working trustos from a rk3228 box image this way and now LibreELEC uses that blob as trustos for all rk322x images. I'm also using a trustos extracted this way to boot the multitool, and it works pretty well.
     
    The other boot process that uses mainline u-boot and Opensource OPTEE (in place of ATF) is as follows:
    The SoC ROM code reads the u-boot TPL at sector 0x40, this initializes DDR memory the SoC ROM code reads the u-boot SPL that immediately follows the TPL u-boot SPL executes the OPTEE trustos u-boot SPL executes the main u-boot u-boot loads device tree and boots the kernel For some extents, you can mix the two boot processes, for example in Armbian I use the second boot process, but at the step 1 I use the proprietary ddrbin because u-boot TPL does not support DDR2 memories.
     
    My guess is that the rk3318/rk3328 boot process is very much the same
     
  13. Like
    jock got a reaction from pro777 in CSC Armbian for RK3288 TV Box boards (Q8)   
    New Armbian 20.08 Ubuntu Focal Desktop image with kernel 5.8.1, on my box it works pretty fine, but feel free to test it on yours:
     
    https://drive.google.com/file/d/14iUGANr_-Cr3LvAP6wm3K0kLJAveHPhF/view?usp=sharing
  14. Like
    jock reacted to victroniko in CSC Armbian for RK322X TV Boxes   
    Quick update on ESP8089: with this module, it works every time 
     
    Didn't do any speed tests as I'm somewhat far from the router (the box lost connection randomly, but my laptop does that too). General web browsing and system upgrades were on par with ethernet. Need to do final tests but I feel we're 95% there... a BIG thank you @jock!!
  15. Like
    jock got a reaction from fabiobassa in CSC Armbian for RK322X TV Boxes   
    Never heard about rockchip 3028, it is quite sure you have a rk3328, or maybe the little rk3318 brother.
    To be sure, you should read what's printed on the soc itself. There is also this table: https://forum.xda-developers.com/showpost.php?p=56219933&postcount=2 that matches the USB vendor/device ids with the soc. I don't know if it is verified.
     
    Once you got the SoC, you will need the usbplug binary for both the db and ul commands, but this will flash another rockchip proprietary loader, which I don't know it is what you want...
     
    edit: I just read about @hexdump instructions, that's a good recipe on how to compile and install mainline u-boot as a bootloader, but I'm understand it correctly, there is some chain-loading between proprietary u-boot and mainline u-boot. You can customize the boot options and avoid being slave of the rockchip u-boot binaries, but requires manual intervention. I would point out some clarifications: as @fabiobassa once told me, the 0x2000 offset when using rl/wl commands of rkdeveloptool is due to maskrom or loader mode: in maskrom mode there is no offset, so you can write the entire eMMC/NAND. In loader mode the first 0x2000 sectors are hidden, hence the offset.
     
  16. Like
    jock got a reaction from jeanrhum in Choice of TV box.   
    H3 is very well supported in armbian and linux mainline, but I don't know if there is a NAND driver actually.
    The choice of the box vastly depends on what you need to do and how much horsepower you need with that one.
    If you want to be sure you get what you actually want, buy a proper SBC with eMMC and a case.
    Hardware of tv boxes, expecially cheap ones, is always a lottery, as you already experienced by yourself.
  17. Like
    jock got a reaction from NicoD in panfrost on RK3288 and GPU on 600MHz problems   
    Applied the patch, left the rk3288 with 5 hours of this:
     
    it worked without an itch, dmesg was clean.
  18. Like
    jock reacted to mboehmer in Odroid C2 on seafloor (part II)   
    Hi all,
     
    as a small status update on the seafloor business, here are some pictures of the new Odroid C2 based instruments which will be deployed in September/October in the northers Pacific.
    Ten modules with different functionality will be deployed, all based on a standard setup of Odroid C2, TRB3sc FPGA based TDC DAQ system, one PADIWA preamp, and a modded mdedia converter serving as a fully configurable mini switch.
     

     
    One of the modules carries several Hamamatsu mini spectrometers, as well as a camera, to observe bioluminescence.

     
    Another module is targeting at muon tracking with SiPM based readout:

     
    I have some more picture of the more "fancy" PMT based modules, but don't want to flood this forum now with too many pictures.
     
    To all of you: thanks for the support you gave us over the last year, and the discussions on specific topics!
     
    Deployment pictures will follow once the modules are in place on the seafloor, 2600m deep in the Pacific (and operational, hopefully, this time we just have a GbE fiber, no serial port...)
     
    See you, Michael
     
     
  19. Like
    jock got a reaction from jaum20 in CSC Armbian for RK322X TV Boxes   
    You can use the multitool to dd image files directly on the device: it has a fully functional bash shell to do such kind of maintenance tasks. Nonetheless you need to do know what you are doing.
    Maybe you can burn the "bad" backup you made and then burn the rootfs from the image @fabiobassa provided. You need to do some juggling with the original image, but if you are able to do so you can try.
     
    Your board is a new revision of the r329q family. In alternative you may have more luck tryingr other images for boards which are older r329q revisions (v2.0, v3.0, v7.0, ...)
  20. Like
    jock got a reaction from jaum20 in CSC Armbian for RK322X TV Boxes   
    Good news, expecially for @nokirunner and @DaviMesquita
     
    Finally we managed to make the ssv6x5x driver work on the ssv6256p chipset and it turns out the it is also working pretty well. I removed most of the logging messages it was spamming on the dmesg log, now it is much more silent and it is ok this way. Teaming with @fabiobassa we optimized performances quite a bit, so expect ~60 Mbit/s at least on optimal setups. It works on both 2.4Ghz and 5Ghz bands.
     
    The driver will be included in the armbian images soon, but in the meantime anyone can test it.
    Download ssv6x5x.koand put it into /lib/modules/$(uname -r)/kernel/drivers/net/wireless Download ssv6x5x-wifi.cfgand put it into /lib/firmware Download ssv6x5x-sw.bin and put it into /lib/firmware Run depmod -a Add blacklist ssv6051 in /etc/modprobe.d/blacklist-rk322x-box.conf (ssv6051 and ssv6x5x kernel modules clashes, we need to blacklist ssv6051 for the other to work) Reboot!  
    Any testing report is appreciated!
     
  21. Like
    jock reacted to DaviMesquita in CSC Armbian for RK322X TV Boxes   
    @jock and @fabiobassa
     
    You are awesome! I only had time to try the new wifi driver now, and it worked like magic, very smoothly!
     
    I tried both 2.4G and 5G and both worked fine, with a nice speed!
     
    Thank you very much again!
  22. Like
    jock got a reaction from nokirunner in CSC Armbian for RK322X TV Boxes   
    Good news, expecially for @nokirunner and @DaviMesquita
     
    Finally we managed to make the ssv6x5x driver work on the ssv6256p chipset and it turns out the it is also working pretty well. I removed most of the logging messages it was spamming on the dmesg log, now it is much more silent and it is ok this way. Teaming with @fabiobassa we optimized performances quite a bit, so expect ~60 Mbit/s at least on optimal setups. It works on both 2.4Ghz and 5Ghz bands.
     
    The driver will be included in the armbian images soon, but in the meantime anyone can test it.
    Download ssv6x5x.koand put it into /lib/modules/$(uname -r)/kernel/drivers/net/wireless Download ssv6x5x-wifi.cfgand put it into /lib/firmware Download ssv6x5x-sw.bin and put it into /lib/firmware Run depmod -a Add blacklist ssv6051 in /etc/modprobe.d/blacklist-rk322x-box.conf (ssv6051 and ssv6x5x kernel modules clashes, we need to blacklist ssv6051 for the other to work) Reboot!  
    Any testing report is appreciated!
     
  23. Like
    jock got a reaction from jaum20 in CSC Armbian for RK322X TV Boxes   
    Ok much better, but at the moment I have no idea this is happening.
    The libreelec boot is somehow engaged because the behaviour changes if you leave the sdcard into, but the reason why it hangs is not clear to me yet.
    I will try to replicate soon on a board of mine
     
    edit: @jaum20 problem solved! Long story short: substitute the file rk3228a-box-mxq4kpro.dtb in the root of the libreelec sdcard with the one attached here. Important: if you're going to update/upgrade LibreELEC, you will need to replace again this file. This is a "problem" I will likely ask to @knaerzche if it can be solved somehow.
     
    Detailed answer for experts: the device tree with the legacy kernel is missing the property arm,cpu-registers-not-fw-configured in the timer section. It is needed on armbian but it is not needed on Libreelec because armbian has OPTEE as trust os (which requires the property), instead Libreelec uses the proprietary u-boot and trust os (which does the timer initialization by itself).
    rk3228a-box-mxq4kpro.dtb
  24. Like
    jock got a reaction from fabiobassa in CSC Armbian for RK322X TV Boxes   
    Good news, expecially for @nokirunner and @DaviMesquita
     
    Finally we managed to make the ssv6x5x driver work on the ssv6256p chipset and it turns out the it is also working pretty well. I removed most of the logging messages it was spamming on the dmesg log, now it is much more silent and it is ok this way. Teaming with @fabiobassa we optimized performances quite a bit, so expect ~60 Mbit/s at least on optimal setups. It works on both 2.4Ghz and 5Ghz bands.
     
    The driver will be included in the armbian images soon, but in the meantime anyone can test it.
    Download ssv6x5x.koand put it into /lib/modules/$(uname -r)/kernel/drivers/net/wireless Download ssv6x5x-wifi.cfgand put it into /lib/firmware Download ssv6x5x-sw.bin and put it into /lib/firmware Run depmod -a Add blacklist ssv6051 in /etc/modprobe.d/blacklist-rk322x-box.conf (ssv6051 and ssv6x5x kernel modules clashes, we need to blacklist ssv6051 for the other to work) Reboot!  
    Any testing report is appreciated!
     
  25. Like
    jock got a reaction from Tido in panfrost on RK3288 and GPU on 600MHz problems   
    Applied the patch, left the rk3288 with 5 hours of this:
     
    it worked without an itch, dmesg was clean.