jock

­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 mainlined into Armbian project, but your mileage may vary; most recent developments live 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 and XHCI USB 3.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
    • 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. The procedure is explained here for rk322x, but for rk3318/28 is the same.

In most of the rk3318/28 boards, shorting the clock pin is difficult or impossible because eMMC are BGA chips with no exposed pins. 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.
 
This is a list of posts where forum users have been able to spot the eMMC clock pin to trigger the maskrom mode:
H96 Max+ (board signature: RK3318_V1.4) by @Gausus X88 PRO 10 (board signature: X88_PRO_B) by @mathgaming HK1 Max (board signature YX_RK3318) by @Constantin Gatej Ninkbox N1 Max RK3318 by @enigmasphinx  
 
Partecipation and debugging:
If you want to partecipate or need help debugging issues, do not hesitate to share your experience with the installation procedure of the boxes.
In case of issues and missed support, provide as many as possible of these things is very useful to try and bring support for an unsupported board:
 
some photos of both sides of the board. Details of the eMMC, DDR and Wifi chips are very useful! 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; and alternative is a link to the original firmware (you can do a full backup with the Multitool); dmesg and other logs (use armbianmonitor -u that automatically collects and uploads the logs online) attach a serial converter to the device and provide the output of the serial port;  
Multimedia:
Mainline kernel: 3D acceleration is provided by Lima driver and is already enabled. Hardware video decoding: https://forum.armbian.com/topic/19258-testing-hardware-video-decoding-rockchip-allwinner/ Legacy kernel: 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.
   
Prebuilt images:
Nightly stables - built from trunk by Armbian servers and GPG-signed: https://github.com/armbian/community  
Multitool:
Multitool - A small but powerful image for RK3318/RK3328 TV Box maintenance. Download it from here  
Quick installation instructions on eMMC:
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 NTFS 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 rk3318-config to configure the board specific options 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 eMMC, skip to the next step. Instead if you are running the original firmware you need to first erase the internal flash; 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 rk3318-config to configure the board specific options 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!  
Tutorial - How to install Armbian on your TV Box (by @awawa) :
https://www.hyperhdr.eu/2022/01/tv-box-mania-i-part-x88-pro-10.html
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  
The Multitool does not boot / How to burn image directly on eMMC:
 
Some boards have the sdcard attached to an auxiliary (called also sdmmc_ext or external) controller which is not the common one.
Forum findings declare that those boards are not able to boot from sdcard with stock firmware and they neither do in maskrom mode: the stock firmware always boots even if you put the multitool on sdcard.
 
In such case, burning images directly on eMMC is the only way to have a working Armbian installation.
You can follow these instructions by @fabiobassa to burn images directly on eMMC:
 
https://forum.armbian.com/topic/17597-csc-armbian-for-rk3318rk3328-tv-box-boards/?do=findComment&comment=130453
 
Notes and special hardware:
Script to change DDR memory frequency here Wireless chip AP2734, SP2734, HY2734C and similars: they are clones of AmPAK AP6334 which is combo wifi + bluetooth of broadcom BCM4334/B0 chips. You may need a special nvram file, instructions by @paradigman are here  
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
@MX10.AC2Nfor his patience in testing mxq-rk3328-d4 board support
All the rockhip64 maintainers at Armbian project who have done and do most of the work to support the platform
 
 

­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 mainlined into Armbian project, but your mileage may vary; most recent developments live 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 and XHCI USB 3.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
    • 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. The procedure is explained here for rk322x, but for rk3318/28 is the same.

In most of the rk3318/28 boards, shorting the clock pin is difficult or impossible because eMMC are BGA chips with no exposed pins. 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.
 
This is a list of posts where forum users have been able to spot the eMMC clock pin to trigger the maskrom mode:
H96 Max+ (board signature: RK3318_V1.4) by @Gausus X88 PRO 10 (board signature: X88_PRO_B) by @mathgaming HK1 Max (board signature YX_RK3318) by @Constantin Gatej Ninkbox N1 Max RK3318 by @enigmasphinx  
 
Partecipation and debugging:
If you want to partecipate or need help debugging issues, do not hesitate to share your experience with the installation procedure of the boxes.
In case of issues and missed support, provide as many as possible of these things is very useful to try and bring support for an unsupported board:
 
some photos of both sides of the board. Details of the eMMC, DDR and Wifi chips are very useful! 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; and alternative is a link to the original firmware (you can do a full backup with the Multitool); dmesg and other logs (use armbianmonitor -u that automatically collects and uploads the logs online) attach a serial converter to the device and provide the output of the serial port;  
Multimedia:
Mainline kernel: 3D acceleration is provided by Lima driver and is already enabled. Hardware video decoding: https://forum.armbian.com/topic/19258-testing-hardware-video-decoding-rockchip-allwinner/ Legacy kernel: 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.
   
Prebuilt images:
Nightly stables - built from trunk by Armbian servers and GPG-signed: https://github.com/armbian/community  
Multitool:
Multitool - A small but powerful image for RK3318/RK3328 TV Box maintenance. Download it from here  
Quick installation instructions on eMMC:
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 NTFS 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 rk3318-config to configure the board specific options 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 eMMC, skip to the next step. Instead if you are running the original firmware you need to first erase the internal flash; 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 rk3318-config to configure the board specific options 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!  
Tutorial - How to install Armbian on your TV Box (by @awawa) :
https://www.hyperhdr.eu/2022/01/tv-box-mania-i-part-x88-pro-10.html
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  
The Multitool does not boot / How to burn image directly on eMMC:
 
Some boards have the sdcard attached to an auxiliary (called also sdmmc_ext or external) controller which is not the common one.
Forum findings declare that those boards are not able to boot from sdcard with stock firmware and they neither do in maskrom mode: the stock firmware always boots even if you put the multitool on sdcard.
 
In such case, burning images directly on eMMC is the only way to have a working Armbian installation.
You can follow these instructions by @fabiobassa to burn images directly on eMMC:
 
https://forum.armbian.com/topic/17597-csc-armbian-for-rk3318rk3328-tv-box-boards/?do=findComment&comment=130453
 
Notes and special hardware:
Script to change DDR memory frequency here Wireless chip AP2734, SP2734, HY2734C and similars: they are clones of AmPAK AP6334 which is combo wifi + bluetooth of broadcom BCM4334/B0 chips. You may need a special nvram file, instructions by @paradigman are here  
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
@MX10.AC2Nfor his patience in testing mxq-rk3328-d4 board support
All the rockhip64 maintainers at Armbian project who have done and do most of the work to support the platform
 
 

In fact instructions in no case tell to erase flash when you use multitool.
In case of NAND chip (and multitool clearly tells you when the board is equipped with NAND), you must use steP-nand, as stated per instructions
 

Hello @gurzixo, most of your observations are true, I will add some precisations to make things more clear as long as I see you like having things tidied up
 
 
The box is surely intended by rockchip to run under Android, but tools are definitely OS-agnostic. Also the tools given by rockchip are intended also for other SoCs that are publicized and sold and supported for use in Linux (like rk3288, rk3399 and rk3328).
Not exactly. Armbian is a set of scripts and patches that allows building Debian-based (so Debian, but also Ubuntu) images capable to boot on several ARM-based Single Board Computers (SBCs). Since ARM device does not have a standard way to boot and does not have a BIOS like x86 system, there is the need to support each SoC/board in its own peculiar way. Once you install Armbian, you have a full Debian (or Ubuntu) on your system, with some extra packages that make life much easier.
Loader mode: right!
Maskrom mode: right also, but the chip enters maskrom mode also when it does not find a valid bootloader in both internal and external flash memory, or using rkdeveloptool rd 3
 
True. This page is the official rockchip documentation with the official way to handle things.
Clearly the most important thing is to put a valid loader at sector 0x40 of internal or external flash, otherwise the SoC does not boot at all.
You can of course alter the flow at any point, for example the idbloader can be made of rockchip blobs (ddrbin + miniloader) or can be made of full opensource software (U-boot TPL + U-boot SPL).
If you use the rockchip blobs, you must of course put the things in the locations proposed by them, but in reality there is still a large degree of freedom.
The DTB exists because these boards don't have a Plug and Play bios, so devices and peripherals cannot be autodetected by the kernel, but must be described somewhere. The DTB describes the devices of the board: where they are mapped in memory, whose interrupts, dmas, gpios they use, and so on. This way the kernel drivers knows how to devices.
The "compatibility" of the DTB is determined by the kernel version: since the kernel drivers are modified during time the way to describe the resources trivially changes too, and so the DTB needs to be adjusted.
Kernel 3.10/3.14 are waaay too old and so many things changed, so it is totally a bad idea take a dtb of such version and
bring it to kernel 5.10 or whatever.
 
No, according to the rockchip boot page, the very first loader is ROM code in the SoC. It is going to do these steps:
check sector 0x40 on internal flash memory for a valid second stage loader and run it if possible check sector 0x40 on external flash memory for a valid second stage loader and run it if possible resign itself and go in maskrom mode No, absolutely.
Putting the multitool on the internal eMMC is pointless, since it is an utility to easily install Armbian on eMMC using an sdcard.
Just substitute the armbian image you want in place of multitool.img at step #4 and you're done.
Also step #3 should not be really needed, because the armbian image already contains all the proper things at the right places.
The storage map is just the default way to arrange partition proposed by rockchip when all their blobs are used, but as I said there is wide degree of freedom. Partitions also are often intended as "location where to place things", and not always proper partitions in the partition table.
Armbian, for example, has just a single ext4 partition because all those partitions are definitely not needed and I don't use the rockchip blobs at all except for the very first DDR memory initializer.
Multitool image, by contrast, uses the rockchip blobs but has two real partitions, and u-boot image and trust image are just at the "right places".
 
That never worked for me, also GPT partition table is also not really needed. You can use it to customize the various binaries locations, but actually I don't think you need to complicate things.
 
Indeed, when you're in maskrom mode the SoC is waiting for some valid code to run; it is not providing any service and no devices are initialized yet. The only command that works is rkdeveloptool db: only when you provide a valid loader (it is called usbplug in this case) the dram and emmc/nand subsystems are initialized and ready to be used.

Keeping android on emmc is not supported because requires some additional steps and a different bootloader arrangement.

Very cool product, 3568 in action

@jock @fabiobassa hi after a long time!
I have spent many hours, tried several times, blá blá blá
After all, i got my board to work both with USB, and tried with Debian Image and nand was booted Fine!
 
I would like to give a huge thank you to you and everyone who could make this possible! 😁😁😁
 
edit:
 
I can't attach the images here, but in the link below has the proof and the df output
https://drive.google.com/folderview?id=1VJeOQczDYVTannltNl4cq0wk6WtvWokI
One more time, a big thank for u'all!! 

Hello @gurzixo, most of your observations are true, I will add some precisations to make things more clear as long as I see you like having things tidied up
 
 
The box is surely intended by rockchip to run under Android, but tools are definitely OS-agnostic. Also the tools given by rockchip are intended also for other SoCs that are publicized and sold and supported for use in Linux (like rk3288, rk3399 and rk3328).
Not exactly. Armbian is a set of scripts and patches that allows building Debian-based (so Debian, but also Ubuntu) images capable to boot on several ARM-based Single Board Computers (SBCs). Since ARM device does not have a standard way to boot and does not have a BIOS like x86 system, there is the need to support each SoC/board in its own peculiar way. Once you install Armbian, you have a full Debian (or Ubuntu) on your system, with some extra packages that make life much easier.
Loader mode: right!
Maskrom mode: right also, but the chip enters maskrom mode also when it does not find a valid bootloader in both internal and external flash memory, or using rkdeveloptool rd 3
 
True. This page is the official rockchip documentation with the official way to handle things.
Clearly the most important thing is to put a valid loader at sector 0x40 of internal or external flash, otherwise the SoC does not boot at all.
You can of course alter the flow at any point, for example the idbloader can be made of rockchip blobs (ddrbin + miniloader) or can be made of full opensource software (U-boot TPL + U-boot SPL).
If you use the rockchip blobs, you must of course put the things in the locations proposed by them, but in reality there is still a large degree of freedom.
The DTB exists because these boards don't have a Plug and Play bios, so devices and peripherals cannot be autodetected by the kernel, but must be described somewhere. The DTB describes the devices of the board: where they are mapped in memory, whose interrupts, dmas, gpios they use, and so on. This way the kernel drivers knows how to devices.
The "compatibility" of the DTB is determined by the kernel version: since the kernel drivers are modified during time the way to describe the resources trivially changes too, and so the DTB needs to be adjusted.
Kernel 3.10/3.14 are waaay too old and so many things changed, so it is totally a bad idea take a dtb of such version and
bring it to kernel 5.10 or whatever.
 
No, according to the rockchip boot page, the very first loader is ROM code in the SoC. It is going to do these steps:
check sector 0x40 on internal flash memory for a valid second stage loader and run it if possible check sector 0x40 on external flash memory for a valid second stage loader and run it if possible resign itself and go in maskrom mode No, absolutely.
Putting the multitool on the internal eMMC is pointless, since it is an utility to easily install Armbian on eMMC using an sdcard.
Just substitute the armbian image you want in place of multitool.img at step #4 and you're done.
Also step #3 should not be really needed, because the armbian image already contains all the proper things at the right places.
The storage map is just the default way to arrange partition proposed by rockchip when all their blobs are used, but as I said there is wide degree of freedom. Partitions also are often intended as "location where to place things", and not always proper partitions in the partition table.
Armbian, for example, has just a single ext4 partition because all those partitions are definitely not needed and I don't use the rockchip blobs at all except for the very first DDR memory initializer.
Multitool image, by contrast, uses the rockchip blobs but has two real partitions, and u-boot image and trust image are just at the "right places".
 
That never worked for me, also GPT partition table is also not really needed. You can use it to customize the various binaries locations, but actually I don't think you need to complicate things.
 
Indeed, when you're in maskrom mode the SoC is waiting for some valid code to run; it is not providing any service and no devices are initialized yet. The only command that works is rkdeveloptool db: only when you provide a valid loader (it is called usbplug in this case) the dram and emmc/nand subsystems are initialized and ready to be used.

@gurzixo hello. Yes, your board is doing absolutely weird things.
This is a rare situation I yet have to understand why it happens. I have a board with rk3228a that runs for days without any issue on legacy 4.4 kernel, but crashes immediately with messages similar to yours if I use the mainline kernel.
I tried almost everything I could think about on that board to solve or at least mitigate the issue, but with no success.
 
If you could extract the DTB, it would very helpful for clues that may explain what is happening.
The multitool DTB is a very basic DTB that should work on all boards, it is designed to be very compatible and usually works on most boards without complaints; the only testing thing I can imagine is to disable the vdd_log and vdd_arm regulators and removing/disabling the cpu operating frequency table to avoid frequency scaling.
 
I already did such experiments on my rk3228a board, but it did not improve stability at all, suggesting the issue is probably elsewhere.

@Alex83 I have no experience with tvheadend, I don't even know what it is. It looks to me that the error is somehow related to bad architecture.
Try to post a question in the general chit chat forum on how to compile it for armhf if it is your necessity.

@Alex83
Very good! I'm very pleased to read that finally we got the best out of the board
The wifi benchmark is excellent for a 72Mbit/s link,I'm not totally sure the chip is able to establish 40 Mhz links, I think it is a single stream chip so that is the maximum you can get from it, but nonetheless it is quite above the benchmarks I did in the past that were around 37Mbit/s.
 
Thanks again for the patience, now I go to put credits on first page and a link to the instructions for people who wants to upgrade the NAND bootloader

Ahah, no wait a second. I just spotted a mistake in the instructions!
The rkdeveloptool ef is removing again the bootloader you just installed sorry for that... (I'm going to fix them)
 
Let's try again:
Unplug the USB cable Plug the USB cable run upgrade_tool Wait for a minute Unplug the USB cable Then finally it should work as expected
 
edit: going to give you credits on first page if this madness works

Ok, so let's see if I understood:
you plug the USB cable lsusb is telling that the device is there if you run rkdeveloptool rd 3 it tells you "Reset Device failed!"  
If so, believe it or not this is the best condition
 
Repeat the procedure starting from upgrade_tool, hope this time works
 
 

@Alex83 Don't worry, your board won't become trash, you can always use the Android tool for windows to restore NAND functionality as you did in the past.
 
Tell me if things are working better with the v2.51 and v2.47 loaders, in the meantime I try to craft a new bootloader combining them with the 660 Mhz ddrbin so you could try them to get the best out the hardware.
Please have patience (as you see, that's very messy getting things working with these boards...)

Just use the multitool to backup your current installation if you want to. We are going to erase everything on the NAND so if you want to keep the content just do a quick backup.
I suggest you to install from scratch, but if you spent time to do some configurations you don't want to lose again, the multitool will make your life easier.
 
What you need:
from the ilmich/rkflashtool you need to clone/download the repository and compile the binary using the instructions there.  
The procedure (if you are already in maskrom mode, go directly to step 8):
Do the backup using the Multitool Do "Erase Flash" using the Multitool Unplug the power cord, detach all unnecessary things: no network, no hdmi, no sdcard, no power cord and no USB things; if serial adapter is attached, keep only ground and TX wires (stock bootloader uses 1.5mbps speed) Connect the USB male-to-male cable to the computer and then to the USB OTG port of the box The box should turn on automatically, you should see a device with ID 2207:320b running lsusb command Erase the flash bootloader: invoke the command rkflashtool e 0 8192 and wait a few seconds Now we have to put the the board in maskrom mode: unplug the USB cable, wait a few seconds and replug the USB cable. If you don't see anything on serial adapter and the device is listed in lsusb, you are in maskrom mode! As an alternative to unplug/replug, you can also run rkflashtool b 3, but it is preferred to do a power cycle. If you have a serial adapter attached, depending on the loader, you may need to set the speed to 1500000bps or 115200bps to see the box output. Upload the loader to the board: rkflashtool l bin/rk322x_loader_v1.10.238_256.bin Update the loader on the board: rkflashtool a bin/rk322x_loader_v1.10.238_256.bin Unplug the USB cable Done!  
If you are at step 9 and rkflashtool is stuck at "info: send ddrbin vendor code", do a power cycle and use the alternative 1T bootloader: bin/rk322x_loader_v1.10.238_256_1t.bin
You can now restore the backup using the multitool (or do a new installation).
 
Note: I also attached to this post a couple of known working bootloaders in case the one I suggested above does not work and you need to restore back the functionality of your board.
Use them if the one above does not work.
 
 
RK322XMiniLoaderAll_V2.51_spectek_en_ddr2_rd_odt_180703.bin RK322XMiniLoaderAll_V2.47_spectek_en_ddr2_rd_odt_171127.bin

I think neither ubuntu nor debian installs some firewall rules by default. I have debian on my NAS and I don't either have iptables installed, so I guess no firewall rules are installed by default on my box.
 
 
This is the result of a straightforward iperf3 run on my NAS box:
paolo@nas:~$ iperf3 -c localhost -t 60 -i 5 Connecting to host localhost, port 5201 [ 5] local 127.0.0.1 port 43690 connected to 127.0.0.1 port 5201 ^Y[ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-5.00 sec 964 MBytes 1.62 Gbits/sec 0 767 KBytes [ 5] 5.00-10.00 sec 971 MBytes 1.63 Gbits/sec 0 1.69 MBytes [ 5] 10.00-15.01 sec 852 MBytes 1.43 Gbits/sec 0 2.56 MBytes [ 5] 15.01-20.00 sec 935 MBytes 1.57 Gbits/sec 0 2.56 MBytes [ 5] 20.00-25.00 sec 966 MBytes 1.62 Gbits/sec 0 2.56 MBytes [ 5] 25.00-30.00 sec 962 MBytes 1.62 Gbits/sec 0 2.56 MBytes [ 5] 30.00-35.00 sec 966 MBytes 1.62 Gbits/sec 0 2.56 MBytes [ 5] 35.00-40.00 sec 968 MBytes 1.62 Gbits/sec 0 2.56 MBytes [ 5] 40.00-45.01 sec 966 MBytes 1.62 Gbits/sec 0 2.56 MBytes [ 5] 45.01-50.00 sec 939 MBytes 1.58 Gbits/sec 0 2.56 MBytes [ 5] 50.00-55.00 sec 964 MBytes 1.62 Gbits/sec 0 2.56 MBytes [ 5] 55.00-60.00 sec 960 MBytes 1.61 Gbits/sec 0 2.56 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 11.1 GBytes 1.60 Gbits/sec 0 sender [ 5] 0.00-60.01 sec 11.1 GBytes 1.60 Gbits/sec receiver I got a much better result of 1.6 gbit/s and two cores were at 100%, one core was hogged by iperf3 client instance and the other one by iperf3 server instance. Can't see any way to use more threads with iperf3
 
The fact is, as I think already stated previously, that you are just stressing the local network stack, so mostly you are moving chunks of data from a memory location into another memory location, with the added overhead of linux network stack code. That's all, it does not reflect the real performance of the hardware because no network hardware is in use.
 
Moreover, with such kind of benchmark mostly you are benchmarking the SoC memory subsystem and its throughput.
Boxes come in two memory flavours mostly:
DDR2 in 32 bit configurations DDR3 in 16 bit configurations DDR2 chips usually are 333 Mhz (rarely 400 Mhz) parts, and DDR3 memory chips usually are 667 Mhz (often 800) parts.
Both are initialized at 330 Mhz during the very first boot stage, so in this condition (both at 330Mhz) the bandwidth of the DDR2 memories is twice the DDR3 memories (note: I don't consider the access timings here for simplicity)
 
Despite being installed with half the bus, DDR3 memories support runtime reclocking via DDR Memory Controller (DMC) kernel driver: they usually can be reclocked up to 800 Mhz, depending on the load. The DMC is disabled in armbian for a good reason: memory chips have different access timings and memories have different configurations, so having a one-for-all configuration and guarantee system stability is hard if ever possible.
 
The good news is that the bootloader (actually a piece of it called ddrbin) that is shipped with armbian is configured to boot DDR2 at 330 Mhz and DDR3 at 660 Mhz, so both kind of memories are mostly on par with bandwidth. The ddrbin is a proprietary rockchip 10 kbytes closed-source blob (bad thing), but is able to autodetect the memory timings (called training) for optimal performance (good thing).
 
Here comes your situation: since you have a NAND flash, the bootloader part is not accessible to the linux kernel rknand driver. For this and other reasons, the bootloader on NAND can't be updated using the multitool or via generic linux, so you are stuck with the original bootloader that initializes the memories at ~330 Mhz (some ddrbin are configured even as low as 300 Mhz).
 
Since you are ultimately benchmarking your memory, the number of 670 mbit/s is a quite good approximation of your memory bandwidth. If I do some rough calculations, supposing your bootloader initializes your DDR3 memories at 300 Mhz, based upon my benchmark and yours, I get this number:
 
1600 (mbit/s, my benchmark result) * 0.5 (16bit DDR3 vs 32bit DDR2 bus ratio) * 0.9 (your 300Mhz DDR3 / my 330Mhz DDR2 ratio) = 727 mbit/s
 
which is roughly the number you get from your benchmark (still I'm not considering memory timings, neither CPU frequency, which may explain the little lower benchmark figure you get). Now this number is just some guessing; it may be totally invented number, since I don't really know your hardware.
 
About the comparison against Orange Pi PC, that's a different platform with different memories, a different memory controller (this is very important!) and probably a totally different kernel configuration, so comparison is very hard. I guess it has DDR3 800 Mhz chips to, but I have no time to check mine now. Yet if there is room for improvement (like the 4-core usage vs. 2-core usage) I'll dip my nose into
 
I hope this lengthy post clarified some dark corners about your iperf3 benchmark.
 

Hello.
Unfortunately NAND-based boards have this issue about rebooting. It is common among most of them and still could not sort it out.
Curiously using the mainline 5.10 kernel my NAND board reboots ok, but of course NAND is not accessible because the kernel driver is still missing.

good questions are always welcome

Release Planning: April 3rd. Meeting in IRC channel #armbian on freenode. Meeting starts at 2pm GMT.
(let me know if this is a bad date, because it is around easter holiday in Germany for example)
 
Code Freeze: 2021-04-19 (Monday April 19th)
Release Date: 2021-05-09 (Sunday May 9th)
Release Candidate: https://github.com/armbian/build/tree/v21.05.0-rc
Changelog: https://docs.armbian.com/Release_Changelog/#v2105-2021-05-09
Coordinator: @Heisath
 
The goal of this thread is to discuss testing, bugfixes, and the overall quality of the release. 
 
Open topics:
- complete desktop branch merge into master (this seems generally done, but might need fine tuning)
- enable 3D support (also done? Bugfixing)
- discuss support for desktops (IIRC it was planned to have a longer supported LTS desktop version, we need a maintainer for that, if it happens)
- check if remaining boards can / have been updated to LK5.10 (some were left out last release)
- check possible u-boot updates
- complete remaining Jira issues
- cycle and check board support status (espressobin for example needs a new maintainer (otherwise EOS) @Pali maybe?)
- late topics: 
- business meeting schedule
- kernel config changes on arm64
 
Release Planning Meeting Agenda:
 
Please add developers and more topics below, I will then also add them here.
@Myy @TonyMac32 @balbes150 @piter75 @sfx2000 @ebin-dev @chwe @ning @lanefu @gprovost @aprayoga @5kft @JMCC @martinayotte @going @jeanrhum @dolphs @jock @belfastraven @TRS-80 @Bozza @Rich Neese @sgjava @Mangix @Pali

After several months of development, we finally bring desktop development to the daily driver state. Our desktop builds follow KISS philosophy. They are build around proven technology, we are not touching things that are done well. Just fixing things here and there and removing most / hopefully all bloatware that is added upstream. We are preparing a wide selection of desktop variants
 
 
while we will officially only support a few of them but anyone is welcome to join and tweak / support its desktop of choice. We will support you in best possible manner! And this way things starts the voyage to become officially supported one day. Only if you join. We can't take more load.
 
        

We support XFCE since early days and that will remain primary desktop since it represent a best combination between functionality, speed and beauty. Second desktop, which we are adding now is Gnome because its clean and most stable among advanced / bulky desktops. It can ran fairly smooth as low as on Allwinner H5 / 1Gb memory, while it runs very well on some RK3399 hardware. In both cases it uses open source 3D acceleration - Lima and Panfrost. New desktop option will be added gradually, but for now:

Orange pi 4: Budgie, Gnome, Cinnamon, Gnome, Mate
https://www.armbian.com/orange-pi-4/
 
Pinebook PRO: Gnome
https://www.armbian.com/pinebook-pro/
 
Nanopi T4: Budgie, Gnome, Cinnamon, Gnome, Mate
https://www.armbian.com/nanopc-t4/
 
Nanopi M4V2: Budgie, Gnome, Cinnamon, Gnome, Mate
https://www.armbian.com/nanopi-m4-v2/
 
What about others?

- ASAP. Those are semi manual builds, some are manually tested and it takes a lot of time. On top of that we are having some infrastructure troubles ATM ...
- we still need to fix few minor bugs, before we put on stamp as "supported" even those builds are IMO generally in a better shape then other images on the market
- you can help by testing and enabling specific builds by sending a PR to this file. https://github.com/armbian/build/blob/master/config/targets.conf It will help to get things up faster.

Erasing the NAND with rkdeveloptool was not a smart move, as you noticed right now the NAND is not detected anymore.
First of all, be aware that everytime you reboot the box, unplug the power cord and detach the serial connectors from the board if you have them attached: NAND boxes are very sensitive to even the lowest current.
As long as you tried both Armbian and LibreELEC, you should specify what image you did try: forget the mainline kernel images, they won't work with NAND because there is no driver. You must use legacy 4.4 kernel images.
 
From my point of view, as long as you erased the flash (thus removed the original idbloader), you may do something smarter and use the sdcard to understand if legacy kernel Armbian/LE boots from sdcard or not.
If it is not booting, you need to attach a serial adapter and take some logs because something wrong is happening and the kernel is not able to boot.
Note that probably you will need to erase the flash again if you installed a non working idbloader to make the board boot from sdcard without interferences.
 
Instead, if Armbian or LE are booting fine from sdcard, proceeding to restoring the NAND functionality can happen.
 
As @fabiobassa said, photos and signatures of the board as useful to understand if it is a known board or similar. I have an MXQ Pro 4K tv box right here and it looks similar to yours, but the commercial name is worthless since the board inside may be of a different revision with different components.

Erasing the NAND with rkdeveloptool was not a smart move, as you noticed right now the NAND is not detected anymore.
First of all, be aware that everytime you reboot the box, unplug the power cord and detach the serial connectors from the board if you have them attached: NAND boxes are very sensitive to even the lowest current.
As long as you tried both Armbian and LibreELEC, you should specify what image you did try: forget the mainline kernel images, they won't work with NAND because there is no driver. You must use legacy 4.4 kernel images.
 
From my point of view, as long as you erased the flash (thus removed the original idbloader), you may do something smarter and use the sdcard to understand if legacy kernel Armbian/LE boots from sdcard or not.
If it is not booting, you need to attach a serial adapter and take some logs because something wrong is happening and the kernel is not able to boot.
Note that probably you will need to erase the flash again if you installed a non working idbloader to make the board boot from sdcard without interferences.
 
Instead, if Armbian or LE are booting fine from sdcard, proceeding to restoring the NAND functionality can happen.
 
As @fabiobassa said, photos and signatures of the board as useful to understand if it is a known board or similar. I have an MXQ Pro 4K tv box right here and it looks similar to yours, but the commercial name is worthless since the board inside may be of a different revision with different components.

On the contrary, not removed, but developed. But not fast enough yet. I hope to add support for building images for rk3188 to my GIT in the future (and if there is a demand, it is possible to send a PR to the official GIT).

Hello, I investigated quite a bit the u-boot issue, but it is not an immediately solvable issue, so it has to wait for the time being.
About the leds, they can be controlled using the sysfs interface available in /sys/class/leds.
 
In particular, you can do cat /sys/class/leds/working/trigger that will tell you a list of acceptable options, and use echo value > /sys/class/leds/working/trigger (change value with something you got from the list) to change the led behaviour.

Hello, I investigated quite a bit the u-boot issue, but it is not an immediately solvable issue, so it has to wait for the time being.
About the leds, they can be controlled using the sysfs interface available in /sys/class/leds.
 
In particular, you can do cat /sys/class/leds/working/trigger that will tell you a list of acceptable options, and use echo value > /sys/class/leds/working/trigger (change value with something you got from the list) to change the led behaviour.