jock

Tested, works, merged!

@Maker39
not more than yesterday, in private chat @jock and me we were saying that this 3ad is SUPER because many others users, such as you actively help people.
This is right spirit of a forum

@zero48, With people like @jock and @fabiobassa , this board couldn't win this fight
Congratulations on your success
 
I was rooting for you, but nothing could help

@zero48
Apparently you have emmc and not NAND flash, so use the other instructions

Unless you have rtl8189etv as wifi chip you don't need that.
Just configure the board with rk322x-config so can you get back soon to spend some time with your family

The wireless is fully working with overlays=wlan-alt-wiring wlan8189-etv-al.Thanks again!!!!!!!!!
 

You may try this very work in progress build effort made by @fabiobassa, @hexdump and me.
 
Burn it on a sdcard and try, but your mileage may vary

I don't understand what's wrong with your setup, but did you decompress the multitool (that's its name), as suggested by @fabiobassa before burning on the sdcard? If you are burning the .xz archive as is it will certainly never work!
 
Also in Windows you must see the MULTITOOL FAT partition on the sdcard, otherwise you're doing it wrong.
 

It happens because when you burn the multitool image on the sdcard, the FAT partition is 2GB large by default. The partition is then enlarged the first time you boot the multitool on the box to fit the whole size of the sdcard itself.
Once you boot the multitool in the box, you can then plug again the sdcard on your computer and the FAT partition will be as large as the sdcard.
 
There two strange things though:
* the images for rk322x are all less than 2gb in size, so if you are not putting more than one image on the sdcard you should be fine even with default partition size
* AFAIK, rk3229 with 4Gb of RAM cannot exist, probably 4Gb of RAM are just on the label of the box
 

@zero48
 
as already @Maker39 said you don 't need nothing to start from sd but the sd itself
Mee too I always use win32disk imager so first extract the content of the xz file and burn it with win32imager

Try Rufus https://rufus.ie/
 I always keep "Rufus", "Win32 Disk Imager" and "HP USB Disk Storage Format Tool" handy for recording images.
And you no need press "magic button" for boot with Multitool .

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!
 

If you followed the instructions, the patch applies and you still don't get the device recognized you should first start getting the VID/PID of the device and see if it fits into the list covered by the patch. Also be sure to install the kernel correctly (both the kernel image and the modules). I'm not very into bluetooth so can't help with the command line tools to get the info you need, but I quite sure you can find something around for that.

Amlogic has no real-world interest in Armbian or any other mainline tracking Linux distro so they are not going to fork over any $$$ for support. Their business is heavily focussed on Android and some other niche use-cases. Like most/all SoC manufacturers, their responsibilities are to their customers (integrators who buy their silicon chips) and their shareholders, not consumer end-users in the Linux community who want to reflash a $30 device with a $0 distro image that doesn't use any of their software (which is a good thing, the BSP sucks).
 
"Board" devices from any vendor are generally simple to support since the vendor ships u-boot and kernel sources with varying levels of contact and engagement with the community. "Box" devices are a completely different game, with a massively larger amount of guesswork required to get working and a huge issue with device cloning and hidden spec changes. For example; the current X96-Air (S905X3) model which is popular ships in three different configurations and has been witnesssed with 4x different SDIO WiFi/BT chips; which necessitate a different device-tree file to have the right drivers (which mostly don't exist in mainline) probed. These devices are great when they work, but mostly they don't, and they're a massive and frustrating time sink to support, and the percentage of self-entitled users who get whiny about them seems to be an order of magnitude greater than those using boards. So any sane distro maintainer will (and should) focus on supporting boards. Once in a while there will be box exceptions, but they will be infrequent.
 
Any attempt to cause deliberate harm to user installations via software is unethical and I would expect the Armbian forum moderators to take appropriate action to deny promotion or access to such images via this forum if that actually happened. I know that I would take swift action to delete posts/threads and perhaps temp-ban users if this happend in the LibreELEC forums. However I suspect some of the alarm is caused by GoogleTranslate more than Oleg .. it does seem to translate Russian > English with very firm (borderline aggressive) words. Once in a while I've made him post in his native language, which I can read/undertand to a moderate level, and the tone is different.
 
As a side note, I'm stunned to hear that Armbian running costs are 2,000-5,000 EUR per-day .. LibreELEC runs around $2,500 per year

Glad you went a step further.
This looks definitely a new board I never dealt with.
 
The multitool sources are available on my repository https://github.com/paolosabatino/multitool
However if you can boot the multitool from the USB stick you can get a shell and look into dmesg for further details, like for example if the emmc and sdcard are seen by the kernel, it's a starting point to understand why u-boot does not detect the sdcard.
 
You should also be able to interrupt the u-boot bootstrap and use it's interactive shell to get further info about the mmc subsystem. Commands like mmc info and mmc list should be useful to start with. U-boot shell has its own shell commands, but you should be easily find them somewhere on the net.
 
 

@Alex83 @tediwildan I checked the issue with apt-get upgrade and actually it happens only on NAND boards due to some misbehaving code in armbian. I'm fixing the issue, in the meantime you can plug an sdcard in the sd slot and then run apt-get upgrade: the presence of the sdcard in the slot is sufficient to avoid the issue and the upgrade should install fine.

@Alex83 @tediwildan I checked the issue with apt-get upgrade and actually it happens only on NAND boards due to some misbehaving code in armbian. I'm fixing the issue, in the meantime you can plug an sdcard in the sd slot and then run apt-get upgrade: the presence of the sdcard in the slot is sufficient to avoid the issue and the upgrade should install fine.

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
 

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

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.

@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.

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!

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.
 
 

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
 

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