jock

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.

@Seth Here it is the device tree overlay: rk322x-led-conf3.dtbo
 
Put the file in /boot/dtb/overlays directory and then enable it editing in /boot/armbianEnv.txt (just replace the existing led-conf1 with led-conf3), and then reboot.
 
By default the other led is configured to blink during eMMC access, but you can change the behaviour following the instructions of the previous post: https://forum.armbian.com/topic/12656-csc-armbian-for-rk322x-tv-boxes/?do=findComment&comment=119748
 
About the walkthrough, well I converted the device tree filesystem structure into dts with:
dtc -I fs -O dts device-tree-copy -o device-tree.dts then looked into device-tree.dts to find out the gpio-leds compatible string, and there you will find this section:
power-led { status = "disabled"; compatible = "gpio-leds"; red { gpios = <0x75 0x08 0x00>; default-state = "off"; }; green { gpios = <0xa9 0x15 0x00>; default-state = "on"; }; };  
The "green" led is attached to the GPIO bank whose phandle is 0xa9 (following the phandle it will be GPIO bank #3), and the pin is 0x15 (21 in decimal, or RK_PC5 as rockchip constant from source code) - this is the default led which is attached this way on all the boxes no matter the manufacturer.
The "red" led is attached to GPIO bank #0 and the pin is 0x8 (RK_PB0 as rockchip constant).
 
This commit contains the changes to add the device tree overlay led-conf3 to armbian.
 

Hello @Seth, I inspected your device tree and it looks like you have a led which is connected to a GPIO pin which is different from the two existing configurations. I can arrange a device tree overlay if you're interested in getting support for the second led too.

@Seth I will take a look to the dtb, expecially for the led configuration (maybe yours is a special one)
 
@dale Congrats, finally you made it! Need to understand why the multitool is not booting although, on my box it boots fine from USB. May I ask what happens exactly when you power on the box with the USB stick into?
The system hangs and you see a black screen? The led is blinking or is steady on/off? Do armbian boots instead like no USB stick is in the port at all?
edit: about the temps, yes they are a bit weird. Some chips reports rather high temperatures, I have a board with rk3229 that is idling at 82°C and easily reaches 90°C, but never had any lock-up and the heatspreader is just regularly warm.

@dale
congrats for successful setup!
 
Anyway, i got a hold of the device tree copy from android as well as dmesg.
I figured, i'm gonna follow @hexdump's instructions. hope it all works out fine.
device-tree-copy.tar.gz dmesg_android.txt

@Seth I will take a look to the dtb, expecially for the led configuration (maybe yours is a special one)
 
@dale Congrats, finally you made it! Need to understand why the multitool is not booting although, on my box it boots fine from USB. May I ask what happens exactly when you power on the box with the USB stick into?
The system hangs and you see a black screen? The led is blinking or is steady on/off? Do armbian boots instead like no USB stick is in the port at all?
edit: about the temps, yes they are a bit weird. Some chips reports rather high temperatures, I have a board with rk3229 that is idling at 82°C and easily reaches 90°C, but never had any lock-up and the heatspreader is just regularly warm.

@dale Definitely the Multitool was not behaving correctly when used from USB - I was pretty sure someone else in the past used it successfully, but probably he/she made some modifications to let it boot and work correctly.
Anyway I have uploaded a new fixed version of the Multitool. Download it again from the first page.
 
Follow the instructions to install into NAND you find in the first page, of course burn the Multitool on the USB stick, then boot with the USB stick in the USB OTG port of the box and let's see if it finally works!
 
PS: if the Multitool still refuses to load, follow the suggestion to burn the Armbian legacy image directly on the USB stick and let's see if it at least works (BTW it should work, it has been tested in the past)

ap6210 is a package of two broadcom chips, don't know exactly which ones but dmesg will give some hints about the firmware and nvram you need.
The wlan driver is brcmfmac and is both in legacy and mainline kernel and works fine so far.
 

@Seth
Found some discussion about a similar wifi chip that uses the 9082xs kernel module. Some people modified an existing kernel module from realtek to make it compatible. Discussion is here: https://forum.libreelec.tv/thread/5457-s905x-unknown-wlan-chip/
 
About HDMI, it should work perfectly fine. At least it works perfectly fine on most boards.

@Alvaro Fernandez please follow @fabiobassa suggestion, it should work. ù
Also if you run rk322x-config it should configure the wifi modules for you automatically.

@Seth thanks for the brief reporting!
It looks to me it is everything ok. I only miss the reason why the legacy image with kernel 4.4 does not boot.
If the led is blinking it means the kernel is running, on first boot it may require some time to give you the prompt because it is enlarging the partition to fit the full size of the device.
The missing boot.env is ok, it's just there because u-boot environment has never been saved, and it is ok that way.
This one:
 
Failed to load '/boot/dtb/overlay/-fixup.scr' although is strange. Maybe you turned off the board before it was first completing the partition resize? It happens that if something goes wrong during the boot process, /boot/armbianEnv.txt file gets truncated. (this file contains some important u-boot environment variables used during boot).
About the wifi, S9012 is not a name I recognize and the photo is not clear enough to say what you have there.
To get X.org you can either install the packages or use the Ubuntu Focal desktop image.

Glad to hear it worked! Often the serial pins are easy to spot because there are three or four receptacles in a row, sometimes with RX/TX/GND printings, but sometimes they are hidden or not exposed at all.
PS: why the loader from the first post has to be flashed at oxcccccccc is still a mistery of rkdevtool for windows... Normally you don't need that loader and definitely it does not need to be flashed at oxcccccccc Maybe it is a limitation of the tool for windows, the Armbian image already has everything required to boot properly.

Yes, that's true. But beware you need to short the clock just for a little time during startup.
Also the serial is essential to debug such situations, even because your board is not a well-known one and may have some specifics.
 
edit: as a test for rkdevtool for windows, you may burn the multitool image and see if works. If the multitool image works this way, the problem is in the Armbian image, otherwise the problem is rkdevltool for windows
 

@Attilatilla Ok, fixed the device tree and updated the legacy kernel images in the first post.
They are still for testing, but seems to work fine so far with the media installer for tinkerboard in the apt repositories (don't remember the actual package, just search for tinkerboard and you'll probably find with ease).
I tried only the debian minimal image and Kodi was starting fine. Did not try any video though.
 
Feel free to report here!

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.
 

@Attilatilla Ok, fixed the device tree and updated the legacy kernel images in the first post.
They are still for testing, but seems to work fine so far with the media installer for tinkerboard in the apt repositories (don't remember the actual package, just search for tinkerboard and you'll probably find with ease).
I tried only the debian minimal image and Kodi was starting fine. Did not try any video though.
 
Feel free to report here!

@Joãobt If you're going to follow @SteeMan suggestion, please report here your experience!

Moved you post to the TV Box club.  You should read:  https://forum.armbian.com/topic/16407-please-read-first
Generally you are not going to find any Android TV boxes that will meet your needs with the armbian builds that you can install on them currently.  They were great for headless servers, or light desktop/browser use.  But you aren't going to find good video playback support currently in general and especially not at the price point you are looking at.  Just trying to set your expectations.  If you already had a box and wanted to experiment, I would say go ahead, but if you haven't yet bought something, you are likely going to be disappointed by the current state of armbian on TV boxes - the first clue to that state is that they aren't supported devices.

Hi all.
@Salvador Liébana has made a preview Armbian image with many emulators preinstalled.
Also Box86 with which you can play x86 Windows games and x86 Linux games.
Also running some Windows programs is possible with this.

Download Armbian Forged : https://drive.google.com/file/d/1gQtgWz2pH2TX9Qs_bcDU9zn7w4edfcVf/view?fbclid=IwAR0SRSC8M_1_qm825n4Bd7bqjLmO30qTpFo73qQQga-TC_LRuc2BVFcGzKU

Here my video about Windows games on the preview build.

Here some videos of @Salvador Liébana himself.
 
 
 

Hello, my armsoc fork has some bits here and there to allow working fullscreen acceleration with Mali proprietary drivers on mainline kernel using dumb buffers instead of private Ioctls for rockchip, allwinner and amlogic.
On rockchip it works fine also with the legacy 4.4 kernel too.
Hardware cursor works fine, just switch to HWCURSOR_API_PLANE the attribute here
 
The reason why it is currently set to software cursor is to allow the cursor work on rk322x.
rk322x has only two hardware planes and one plane is forcefully used as primary, so just one hardware plane is left for use.
Current rk322x-legacy armbian variant has a patch that allocates the spare hardware plane as overlay, so if I set armsoc to use hardware cursor, the cursor just disappears because there is no hardware cursor plane!
 
A smarter logic in armsoc would be to run over all the DRM planes looking for the hardware cursor one and use it. Otherwise, in case no hardware cursor plane is present, just use the software cursor.
 
To say it all, almost all rockchip SoCs (including rk3288, rk3339, rk3328 and rk322x) have a special dedicated hardware plane capable of up to 128x128 pixels just to be used for the cursor, so you don't have to sacrifice a general purpose hardware plane. I made an incomplete WIP patch for and it partially works, but has issues that cannot be fixed without changing some surrounding code

Glad to read that. Strange you had to write the trust.img and uboot.mg back onto the sdcard, they are already installed in the same position you burned again. Strange, I will check the scripts but thanks for reporting!
 
Ok, an amount of sectors of the eMMC are gone. I suggest you to erase it and leave it alone.
Once the eMMC is erased, you may try to burn the armbian image I gave you on the sdcard, it should boot directly.

I was run Multitool at last!
It could only start this way:
1. Rufus+Multitool.img
2. dd if=trust.img of=/dev/sdb seek=24576
3. dd if=uboot.img of=/dev/sdb seek=16384
 

Odd.
I read the log in the post above and the line SdmmcInit=0 NOT PRESENT says that the sdcard is not detected at all.
Can't say anything more at the moment, you need to use the maskrom mode if you want to proceed further.

First pull request for me: https://github.com/armbian/config/pull/123
It is a basic implementation with my humble knowledge in bash. It may be improved by experts if possible.
I tested on my armbian dev config and it seems to work. I hope to have follow the right way to make a PR since it is my first one.

I'm currently finishing the last features for builders, like :
the ability to provide a list of packages to uninstall before generating the image; limiting the desktops selection menus to the ones supported by Armbian and the architecture; parsing the distribution info from configuration files.  
I also went back to a clean Armbian fork, https://github.com/Miouyouyou/build/tree/desktop , so that pull requests are 'doable'. I still need to re-arrange the changes into specific branches to make pull requests "nicer" and also :
add documentation for the new features; remove the whole debug messages mess; refactor a good part of the new code.