hexdump

  • Content Count

    350
  • Joined

  • Last visited

Reputation Activity

  1. Like
    hexdump reacted to jock in CSC Armbian for RK3318 TV box boards   
    ­DISCLAIMER (PLEASE READ): everything you can find in this thread (binaries, texts, code snippets, etc...) are provided AS-IS and are not part of official Armbian project. For this reason not people from Armbian project nor myself are responsible for misuse or loss of functionality of hardware.

    Please don't ask about support or assistance in other non-community forums nor in the official Armbian github repository, instead post your questions in this thread, in the TV Boxes forum section (hardware related) or in the Peer-to-peer support section (general linux/software related).

    Thank you!
     
    This thread is to give stable and mature long-term range support to rk3318/rk3328 found in many tv boxes in Armbian project as Community Supported Configuration (CSC).
    The current work is in early stages, it may or may not work for you; if and when it will be considered mature enough, it will be hopefully merged into Armbian master, but in the meantime it lives on my personal fork on github -> here <-
     
    Important notes: is just a personal opinion, but apparently widely supported, that rk3318 chip is not an official rockchip part. They probably are scrap rk3328 parts which have not passed conformance tests but are sold anyway to tv boxes manufacturers. They don’t reach the same operating frequency of the rk3328, have much higher leakage currents (and thus higher temperatures) and often the boards they are installed on are low quality with low quality components, in fact a very very common issue is the eMMC failure due to bad parts and bad soldering. So said, I personally suggest not to buy any rk3318 tv box, but instead find a properly supported SBC (Single Board Computer) if you need a reliable product. In the unfortunate case you already have such product, this thread may help you have some fun with them.
     
    What works:
        • Works on RK3318 and RK3328 TV boxes with DDR3 memories
        • Mainline u-boot
        • Mainline ATF provided as Trusted Execution Environment
        • All 4 cores are working
        • Ethernet
        • Serial UART (configured at stock 1.5Mbps)
        • Thermals and frequency scaling
        • OTG USB 2.0 port (also as boot device!)
        • EHCI/OHCI USB 2.0 ports
        • MMC subsystem (including , SD and sdio devices)
        • Hardware video acceleration (fully supported via RKMPP on legacy kernel, support via hantro and rkvdec kernel driver on mainline)
        • Various WIFI over SDIO are supported
        • Full acceleration on legacy kernel and mainline kernel. Mainline has lima driver compiled in but X11 is albeit slow - you are still free to compile and install mali kernel driver on mainline yourself.
        • U-boot boot order priority: first the sdcard, then the USB OTG port and eventually the internal ; you can install u-boot (and the whole system) in the internal and u-boot will always check for images on external sdcard/USB first.
     
    Unbrick:
    Technically, rockchip devices cannot be bricked. If the internal flash does not contain a bootable system, they will always boot from the sdcard. If, for a reason, the bootable system on the internal flash is corrupted or is unable to boot correctly, you can always force the maskrom mode shorting the clock pin on the PCB. Here there is the procedure (for rk322x, but on rk3318 is the same), but you can also google around if you get stuck on a faulty bootloader, the technique is pretty simple and requires a simple screwdriver.

    There are however some unfortunate cases where shorting the clock pin is difficult or impossibile, like BGA chips with no exposed pins. In those cases pay double attention when burning something on the internal flash memory and always test first the image booting from the sdcard to be sure it works before burning anything in internal flash.
     
    Multimedia:
    If you need multimedia features, like OpenGL/OpenGL ES acceleration, hardware accelerated Kodi, ffmpeg and mpv you can take a look to this post
     
    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.
       
    Development images:
    Debian Buster Minimal - mainline kernel 5.10.31 - Download from here Debian Buster Minimal - legacy kernel 4.4.213 - Download from here  
    Multitool:
    Multitool - A small but powerful image for RK3318/RK3328 TV Box maintenance. Download it from here  
    Quick installation instructions on :
    Build or download your preferred Armbian image and a copy of the Multitool; Burn the Multitool on an SD card; once done, place the Armbian image in images folder of the SD card FAT partition; Plug the SD card in the TV box and plug in the power cord. After some seconds the blue led starts blinking and the Multitool appears; OPTIONAL: you can do a backup of the existing firmware with "Backup flash" menu option; Choose "Burn image to flash" from the menu, then select the destination device (usually mmcblk2) and the image to burn; Wait for the process to complete, then choose "Shutdown" from main menu; Unplug the power cord and the SD card, then replug the power cord; Wait for 10 seconds, then the led should start blinking and HDMI will turn on. The first time the boot process will take a couple of minutes or more because the filesystem is going to be resized, so be patient and wait for the login prompt. On first boot you will be asked for entering a password for root user of your choice and the name and password for a regular user Run armbian-config to configure timezone, locales and other personal options Congratulations, Armbian is now installed!  
    Despite the procedure above is simple and reliable, I always recommend to first test that your device boots Armbian images from SD Card.
    Due to the really large hardware variety, there is the rare chance that the images proposed here may not boot. If a bad image is burned in , the box may not boot anymore forcing you to follow the unbrick section at the top of this post.
     
    Quick installation instructions to boot from SD Card:
    If you are already running Armbian from , skip to the next step. Instead if you are running the original firmware you need to first erase the internal ; to do so download the Multitool, burn it on an SD Card, plug the SD Card and power the TV Box. Use "Backup flash" if you want to do a backup of the existing firmware, then choose "Erase flash" menu option. Build or download your preferred Armbian image; Uncompress and burn the Armbian image on the SD Card; Plug the SD Card in the TV Box and power it on; Wait for 10 seconds, then the led should start blinking and HDMI will turn on. The first time the boot process will take a couple of minutes or more because the filesystem is going to be resized, so be patient and wait for the login prompt; On first boot you will be asked for entering a password for root user of your choice and the name and password for a regular user Run armbian-config to configure timezone, locales and other personal options, or also to transfer the SD Card installation to internal ; Congratulations, Armbian is running from SD Card!  
    A note about boot device order:
    With Armbian also comes mainline U-boot. If you install Armbian, the bootloader will look for valid bootable images in this order:
    External SD Card External USB Stick in OTG Port Internal  
    How to partecipate:
    If you want to partecipate, do not hesitate to share your experience with the installation procedura of the boxes.
    In case of issues and missed support, providing these things is very useful to try and bring support for an unsupported board:
     
    upload the device tree binary (dtb) of your device. We can understand a lot of things of the hardware from that small piece of data; attach a serial converter to the device and provide the output of the serial port  
    Critics, suggestions and contributions are welcome!
     
    Credits:
        • @fabiobassa for his ideas, inspiration, great generosity in giving the boards for development and testing. The project of bringing rk3318 into armbian would not have begun without his support!
        • @hexdump for his precious support in early testing, ideas and suggestions
        • All the rockhip64 maintainers at Armbian project who have done and do most of the work to support the platform
  2. Like
    hexdump reacted to XFer012 in OrangePi Zero2 - Allwinner H616   
    Ok, so let's see the steps I followed.
     
    1. Installed Armbian Unstable for OrangePi Zero2:
    https://imola.armbian.com/dl/orangepizero2/nightly/Armbian_21.05.0-trunk.77_Orangepizero2_hirsute_edge_5.11.11.img.xz
     
    2. Forced ethernet at 100 mbit/s, otherwise it did not work: added in /etc/rc.local
    ethtool -s eth0 speed 100 duplex full autoneg off
     
    3. Downloaded hexdump's precompiled kernel (derived from jernej's 5.11.0rc1 kernel):
    https://github.com/hexdump0815/linux-mainline-and-mali-allwinner-h6-kernel/releases/download/5.11.0-rc1-stb-616%2B/5.11.0-rc1-stb-616+.tar.gz
     
    4. Extracted the various parts and fixed the symlinks:
    Image -> Image-5.11.0-rc1-stb-616+
    uInitrd -> uInitrd-5.11.0-rc1-stb-616+
    dtb -> dtb-5.11.0-rc1-stb-616+
     
    5. Inside dtb-5.11.0-rc1-stb-616+, created a new folder "allwinner" and moved the 3 .dtb there; otherwise, initramfs would not find them
     
    6. Rebooted. Voilà, we now have a working mainline-ish kernel (patched 5.11.0rc1) with USB support!
    [ 57.289791] usb 2-1: new high-speed USB device number 2 using ehci-platform [ 57.454110] usb-storage 2-1:1.0: USB Mass Storage device detected [ 57.454976] scsi host0: usb-storage 2-1:1.0 [ 59.122397] scsi 0:0:0:0: Direct-Access Lexar USB Flash Drive 1100 PQ: 0 ANSI: 6 [ 59.124408] sd 0:0:0:0: [sda] 125038592 512-byte logical blocks: (64.0 GB/59.6 GiB) [ 59.125522] sd 0:0:0:0: [sda] Write Protect is off [ 59.125549] sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00 [ 59.126563] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 59.163290] sda: sda1 sda2 [ 59.168389] sd 0:0:0:0: [sda] Attached SCSI removable disk  
  3. Like
    hexdump got a reaction from XFer012 in OrangePi Zero2 - Allwinner H616   
    @XFer012 - in case you run into any problems while trying get it working based on my notes, just open an issue on that git repo and i may try to help you to resolve them
     
    good luck - hexdump
  4. Like
    hexdump got a reaction from gounthar in OrangePi Zero2 - Allwinner H616   
    @XFer012 - you can also build a kernel directly on the box - takes a bit of time, but works well - i'm building all my arm kernels on arm devices
  5. Like
    hexdump got a reaction from XFer012 in OrangePi Zero2 - Allwinner H616   
    @XFer012 - i think the best approach might be to build your own kernel and then you can change the original dts and dtsi files directly (with labels etc.) instead of dealing only with the compiled versions ... maybe my notes from playing around with the h616 on tv boxes might be helpful for you: https://github.com/hexdump0815/linux-mainline-and-mali-allwinner-h6-kernel
     
    i also built a kernel with working usb and early hdmi (based on the code of @jernej): https://github.com/hexdump0815/linux-mainline-and-mali-allwinner-h6-kernel/releases/tag/5.11.0-rc1-stb-616%2B - i did not test it on a orange pi zero 2 myself (as i only tried it on a h616 tv box), but at least i tried to keep the opi zero 2 dtb up to date, so it might just work
     
    all that is not a perfect solution, but maybe its helpful for you on your way
     
    good luck and best wishes - hexdump
  6. Like
    hexdump got a reaction from gounthar in Jetson Nano   
    just a little update: i got the open source nouveau gpu driver working with the mainline kernel finally by using a self compiled xorg server from the latest sources (required - see: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3505), a self compiled mesa 21.0.1 (not sure if this is really required) and the "nouveau.modeset=1" kernel cmdline parameter - what is nice is that it is opengl 4.3
     
    so far the good part, the bad part is that it is extremely slow (glmark2 score of 68) as it is clocked at the lowest gpu frequency by default and trying to increase the gpu frequency via /sys/kernel/debug/dri/128/pstate seems to make the system quite unstable or quickly hangs it (maybe my power supply - 5.1v/3a - is not powerful enough?)
     
    i'm also able to run a wayfire wayland session using the nouveau gpu driver, but it shows quite a few graphical artifacts when scrolling in a terminal or doing other activities - glmark2 score here is 83, but its also for lima or panfrost higher in wayland/wayfire than in xorg/xfce
     
    all in all it looks like the quality of the open source nouveau driver on the jetson nano (maybe even in general?) is not really the best and as it looks to me far behind the quality of the lima and panfrost open source drivers for the mali gpus in other socs
  7. Like
    hexdump got a reaction from lanefu in Jetson Nano   
    just a little update: i got the open source nouveau gpu driver working with the mainline kernel finally by using a self compiled xorg server from the latest sources (required - see: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3505), a self compiled mesa 21.0.1 (not sure if this is really required) and the "nouveau.modeset=1" kernel cmdline parameter - what is nice is that it is opengl 4.3
     
    so far the good part, the bad part is that it is extremely slow (glmark2 score of 68) as it is clocked at the lowest gpu frequency by default and trying to increase the gpu frequency via /sys/kernel/debug/dri/128/pstate seems to make the system quite unstable or quickly hangs it (maybe my power supply - 5.1v/3a - is not powerful enough?)
     
    i'm also able to run a wayfire wayland session using the nouveau gpu driver, but it shows quite a few graphical artifacts when scrolling in a terminal or doing other activities - glmark2 score here is 83, but its also for lima or panfrost higher in wayland/wayfire than in xorg/xfce
     
    all in all it looks like the quality of the open source nouveau driver on the jetson nano (maybe even in general?) is not really the best and as it looks to me far behind the quality of the lima and panfrost open source drivers for the mali gpus in other socs
  8. Like
    hexdump got a reaction from gounthar in 8Gb RAM in a TV Box   
    @gounthar - i think you do not need esxi as kvm and maybe xen (and some other free hypervisors) are working quite well on aarch64 already ...
  9. Like
    hexdump got a reaction from lanefu in Chainloaded uboot images for amlogic   
    @lanefu - for those amlogic tv boxes chainloading u-boot means the old legacy u-boot on the box is loading a mainline u-boot.bin (which has nice features like extlinux.conf support and allocates less memory for itself) which is then loading the kernel
     
    @SteeMan - this looks a bit like this box has a non standard mmc setup which might be not so easy to track down (one would need to extract the android dtb from the box - see: https://github.com/hexdump0815/u-boot-misc/tree/master/misc.h616-legacy/android-device-tree-copy and then the mmc entries should be compared to the android dtbs of other boxes where emmc works - here is for instance my h96max-x3 android dtb: https://github.com/hexdump0815/linux-mainline-and-mali-amlogic-kernel/blob/master/misc.aml/dtb/meson-sm1-h96max-x3.dts.android - this is a big puzzle and a lot of trial and error might be required without the guarantee to get it working)
     
    the patch is to remove some code which will not work in our scenario (getting linux working on it) - it looks like the mainline u-boot code for the s905x3 i used as a base was only done for android which has a different partition (+table) setup than what we plan to use
     
    the uEnv.txt file is read before extlinux.conf, so things can be set there which partially cannot be defined in the extlinux.conf (which is quite limited) - in armbian that file usually is called armbianEnv.txt i think, so you should maybe adjust the filename to be in sync with armbian if you want to get it closer to a standard armbian setup
     
    just an idea: you might also try the newer u-boot 2021.01 or soon the upcoming 2021.04, but i think nothing really changed in there for amlogic
     
    @lcapriotti - it would be very helpful if you could find out how you got it to work on your box - this might getting this resolved easier for @SteeMan maybe
     
    good luck and best wishes - hexdump
  10. Like
    hexdump got a reaction from manuti in Jetson Nano   
    did anyone already test to boot this image on the 2gb model of the jetson nano? i just tried it and it does not boot - the nano already has the new u-boot in the spi ... looks like i have to connect a serial console when i find some time
  11. Like
    hexdump got a reaction from lanefu in CONFIG_RT_GROUP_SCHED=y harmuflull for real time applications   
    @Piezo - did you already try "sysctl -w kernel.sched_rt_runtime_us=-1" - it works well for me for jackd ...
     
    best wishes and good luck - hexdump
  12. Like
    hexdump got a reaction from Seth in CSC Armbian for RK322X TV Boxes   
    @Seth - it might be good to get the dtb from the box - in case no other way works, this approach so far worked for nearly every android tv box for me: https://github.com/hexdump0815/u-boot-misc/tree/master/misc.h616-legacy/android-device-tree-copy
     
    good luck - hexdump
  13. Like
    hexdump got a reaction from fabiobassa in CSC Armbian for RK322X TV Boxes   
    @Seth - it might be good to get the dtb from the box - in case no other way works, this approach so far worked for nearly every android tv box for me: https://github.com/hexdump0815/u-boot-misc/tree/master/misc.h616-legacy/android-device-tree-copy
     
    good luck - hexdump
  14. Like
    hexdump reacted to jernej in OrangePi Zero2 - Allwinner H616   
    If someone has too much time, here is extremely basic and hackish H616 display driver (HDMI up to 1080p only): https://github.com/jernejsk/linux-1/tree/h616-hdmi (take branch as-is, USB works too)
  15. Like
    hexdump reacted to jernej in OrangePi Zero2 - Allwinner H616   
    Good thing is that things are coming together slowly. There is a hack to make USB work and first part of display stack started to work (not usable yet).
  16. Like
    hexdump reacted to jock in Planned changes to the TV Box area   
    I'm always happy about tidying up things, and tv boxes section is still far from being ideal. Honestly I don't know if it is a wise idea to have a section "TV Boxes running Armbian" and I explain why: it could work well with serious and proper brand products, but if you mean to tidy up the forum against the chinese brands, well, we have to face the reality that cheap chinese tv boxes don't have any proper nomenclature. Often you get a recognizable pattern, sometimes you don't. This is especially true for the cheapest products and so things that have the same market name may have a different hardware, either "just" the wifi chip or a completely different board with another SoC. Anyway, trying is costless, so let's try it
     
    Personally I maintain the rk322x and rk3288-xt-q8l-v10 (xt-q8l-v10 is a rk3288 tv box board) CSC threads and so far I have to say I never had to ask a moderator to delete a post or ban a person. We never faced any major inconveniences with users, yet people has been very collaborative in some cases that we brought up hardware support remotely (esp8089 wifi support, for example) and very often people sends device trees to be analyzed. The rk322x thread has been a great source of fun
     
    IMHO they work well because:
    the subject is clear - since most of the problems are related to the hardware, bringing in many architectures in the same place will incredibly increase confusion. One architecture and its related kernels, that's more than enough. the first post covers the basics - though I have to say that preparing such pages to be simple and effective took a lot of time and effort - it is terribly useful for users. Most people read this and finds their way. Some don't read the first page, so you kindly redirect there, some skilled or unskilled people read the first page, don't get it and post. They get attention as long as they show to be collaborative. If they acts like childish leeches they will just get ignored. the thread is a linear history of what happened and when - except for the first page which is often updated with the "must read" infos, reading the last 2/3 pages of the thread are enough to get up to date stay within the armbian rules - it means that even if they are tv boxes, they fit and integrate into the armbian ecosystem as much as possible. For example: if FAT is not supported by armbian (yet it is, but that's an example ), don't use your own hacky thing to make a FAT partition but bring FAT support into armbian; if the board uses some firmware, don't put the firmware somewhere hidden but commit the firmware to armbian-firmware repository and fix the thing with a generic patch, and so on... It's harder, but it's better and brings much better cooperation at all levels and people will find the stable board/box images in the right place (the Download page), not elsewhere.  
    Getting back of the tv box club, I share my wonders about how it could be arranged - that's just an idea, it could be totally wrong...
    Along with the "Overview" and "General chat" sections, since there are just 3 major vendors they could be put as main tv box club sections.
    Overview is cool because it's a "what's new" overview page. I consult it often and finds it very useful to spot recent posts that may be interesting.
    General Chat is where newbie people will probably post, along with generic threads and posts asking for help. There I would put a pinned "FAQ" and "must read, forums rules" thread.
     
    The three vendors sections (Rockchip, AmLogic, Allwinner) will be less touched by newbies which don't even know what Rockchip/Allwinner/AmLogic are; people with just a tiny bit of experience instead would post vendor specific questions in the vendor sections.
    I would put the "CSC megathreads" in the vendor specific sections. People who wants to cooperate to support some chip of that vendor or talk about that vendor could freely do that in the vendor section; if interesting discussions arise (like happened in the recent past for S905X3), threads could be pinned or CSC support materializes for a tv box/board/architecture, there could be a pinned thread for that too.
    As an example, S905X3 tv boxes don't have CSC support, but may have a pinned thread (one pinned thread for one architecture) to let people discuss about it in one place, decent tv boxes (Beelink S922 ones just popped in my mind) may have a separate pinned thread if there is a CSC maintainer for that board if there is discussion or enough interest about.
     
  17. Like
    hexdump got a reaction from TRS-80 in Free and Libre Open Source SBC List Thread   
    i think you can run some allwinner socs (at least the h6) and some rockchip socs nearly blob free as they do the memory setup themself, have open source atf (and sometimes optee too) and u-boot. maybe a free usb wifi might be required as boards sometimes come with wifi requiring blobs. this way one might even be able to make a cheap h6 tv box into a blob free system
  18. Like
    hexdump got a reaction from TRS-80 in Free and Libre Open Source SBC List Thread   
    but those are fixed ip cores in the hardware and not loaded later - if you want to get rid of those i think you have no chance to get a useable system going at all ...
  19. Like
    hexdump got a reaction from Werner in RK3318 device (Magicsee N5 Nova 4g/64g) with dead NAND   
    @Lambert or some moderator: i think what is ment here is rk3318 and not rk3188 - it might be good to adjust the title ...
  20. Like
    hexdump got a reaction from guidol in High cpu usage by interrupts in A20 system   
    i think it could be a generic a20 problem - maybe have a look at:
     
    https://forum.armbian.com/topic/7575-k-worker-problem-on-a20-based-boards/
    https://forum.armbian.com/topic/14282-headless-systems-and-sun4i_drm_hdmi-a10a20/
    https://superuser.com/questions/1515001/debian-10-buster-on-cubietruck-with-bug-in-sun4i-drm-hdmi
     
    best wishes - hexdump
  21. Like
    hexdump got a reaction from sucotronic in High cpu usage by interrupts in A20 system   
    i think it could be a generic a20 problem - maybe have a look at:
     
    https://forum.armbian.com/topic/7575-k-worker-problem-on-a20-based-boards/
    https://forum.armbian.com/topic/14282-headless-systems-and-sun4i_drm_hdmi-a10a20/
    https://superuser.com/questions/1515001/debian-10-buster-on-cubietruck-with-bug-in-sun4i-drm-hdmi
     
    best wishes - hexdump
  22. Like
    hexdump got a reaction from TRS-80 in High cpu usage by interrupts in A20 system   
    i think it could be a generic a20 problem - maybe have a look at:
     
    https://forum.armbian.com/topic/7575-k-worker-problem-on-a20-based-boards/
    https://forum.armbian.com/topic/14282-headless-systems-and-sun4i_drm_hdmi-a10a20/
    https://superuser.com/questions/1515001/debian-10-buster-on-cubietruck-with-bug-in-sun4i-drm-hdmi
     
    best wishes - hexdump
  23. Like
    hexdump got a reaction from anbodearg in s905x3 board died, no led, no hdmi output   
    i think the best you can do is trying to connect a serial console to it - then you'll see for sure if it still gives signs of life from it or not and what you get then might help you to find possible options to recover it if recovery is still possible ... a dead emmc might result in the behaviour you describe: as the balbes images use the legacy u-boot on emmc on the box for booting on amlogic and a broken or dead emmc might result in nothing happening when turning on the box, but of course it can also be completely dead or just something trivially corrupted.
  24. Like
    hexdump got a reaction from NicoD in Since Tanix TX6 can boot from the SD card   
    allwinner h6 tv boxes usually do not have a voltage regulator for the cpu voltage and thus always run at full voltage even if the frequency is scaled down, so throttling is very inefficient here - in my experience they close to always need active cooling to deal with any serious load for a longer time at full cpu frequency ... i only have one board where i replaced the original heat sink with a much larger one and added fresh high quality thermal paste between it and the soc and that one can run without a fan if not in a case (i.e. good air flow) ... s905x3 is much cooler as its cores are done in a 12nm process vs. the 28nm process of the h6
  25. Like
    hexdump reacted to jock 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