Willy Moto

Armbian now has a community supported build target for amlogic TV Boxes (aml-s9xx-box).  You can now build your own builds directly with the Armbian build system.
 
This is now an opportunity for members of the community to move the support for amlogic TV boxes forward within the Armbian framework.  If you are not familiar with the Armbian build system check out the Armbian developer documentation.  If you have idea on how you would like to see things evolve/change please use this forum to share your thoughts and ideas and submit PRs for any code changes you would like to see.
 
I am currently testing this code against the four different amlogic based boxes I own, but would appreciate others testing as well.  Once I have completed my testing, I will be updating the FAQ amlogic install instructions with this information.

After a fix committed this past week, these builds now work on all the amlogic based boxes I have:
TX3mini (s905w)
X96mini (s905w)
H96MaxX2 (s905x2)
TX3 (s905x3)

Change usb cable first. Had similar problems with one of my pi4s .. and it was new cheap chinese cable. Also check dmesg and see if there is something with usb logged there lile recconect or disconnect msgs.

Sent from my SM-S901B using Tapatalk

A guide to installing Armbian on the H96 Max V11 (RK3318_V1.4 blue PCB)
 

 
What you will need
Your H96 Max V11 TV box with the power supply and the HDMI cable that came with it; A TV or a monitor with an HDMI port; A wired USB keyboard (or a wireless one with a USB dongle); An Ethernet cable to connect to a router on your home network that has Internet access; A Micro SD card (minimum 1GB, more if you're going to back up Android on your box before overwriting it with Armbian); A USB card reader for Micro SD cards; A Windows PC connected to your home network;  
Installation steps
Download the experimental Armbian image (kernel 5.19.15 and libreelec patches — alas, that's the latest version that works correctly with our box) and a copy of the Multitool; Burn the Multitool on the SD card using Rufus (no need to change any settings, just click "SELECT" and locate multitool.img.xz or drag and drop the file on Rufus and then click "START"); Connect your TV box to the TV or monitor, connect the keyboard, plug in the Multitool SD card and then plug in the power cord; Wait a minute (while SD card partitions are being resized) for the Multitool main menu to appear, then select "Shutdown"; Unplug the power cord and the SD card, then plug the SD card into your PC. Two new drives should appear, labeled BOOTSTRAP and MULTITOOL. If you see both, skip the next step. If you only see the BOOTSTRAP, proceed to the next step; Start Disk Management (press Win+X, K). Scroll down the list of disks (use the scrollbar, because mouse wheel doesn't work there) to locate your SD card, and on the MULTITOOL partition right-click, then press C, and click "Add", "OK"; Open the MULTITOOL drive in Windows Explorer (or your favorite file manager) and copy the downloaded Armbian image to the images folder; Safely remove (eject) the SD card, plug it into the TV box and plug in the power cord. The Multitool main menu will appear in a few seconds; If you don't care about stock Android firmware on your TV box, skip the next step. If you want to back up the Android firmware, proceed to the next step; In the Multitool main menu select "Backup flash" and click through (there will be only one option). Name your backup file. Wait for the backup to finish. The backup file will be saved to the backups folder on the SD card's MULTITOOL partition; Now it's time to replace Android with Armbian. In the Multitool main menu select "Burn image to flash" and click through (there will be only one option). Wait for the process to complete, then in the main menu select "Shutdown"; Unplug the power cord and the SD card, then replug the power cord. Wait a few minutes for Armbian to get everything ready for its first launch, and then follow the initial setup prompts; You will be taken to the login prompt. Log in with the name/password for the regular user you've created; Connect your TV box to your home network router with an Ethernet cable; In Armbian, enter the command sudo cat /run/motd.dynamic and note the IP address assigned by the router to the TV box; Now you will need to connect to your TV box on the home network via the SSH protocol. If you're running Windows 10 or later, press Win+X, I, Enter. A PowerShell/Terminal window will open. Enter the following command, substituting the words in angle brackets with actual values: ssh <IP address from the previous step> -l <name for the regular user>. Type yes at the prompt asking if you really want to connect to this unknown host. At the next prompt that appears, enter the password for the regular user you've created. Skip the next step; If you're running an older version of Windows, you will need to download PuTTY, an SSH and Telnet client, set up an SSH connection to your TV box with the IP address above and log in with the name/password for the regular user; Now it's time to fix the settings for the Wi-Fi chip that doesn't work out of the box on the H96 Max V11. To delete the old settings, copy the command sudo rm -f /usr/lib/firmware/brcm/brcmfmac4334-sdio.rockchip,rk3318-box.txt and paste it by right-clicking in the SSH window, then press Enter; To create the new settings file, enter (copy-paste) the command sudo nano /usr/lib/firmware/brcm/brcmfmac4334-sdio.rockchip,rk3318-box.txt The nano text editor will open with a new empty file; Now open this small text file (a copy of nvram_2734c.txt from this forum topic), press Ctrl-A to select all text in it, then Ctrl-C to copy it to the clipboard; Switch to the SSH window, right-click to paste the copied text to nano then press Ctrl-S to save and Ctrl-X to exit; Enter (or copy-paste) the command sudo reboot -f to reboot Armbian. After that you can either close the SSH window and proceed with the physical console or start a new SSH session once Armbian has restarted; Enter (or copy-paste) the command sudo apt update && sudo apt install armbian-config After the update and installation is completed, run armbian-config to configure various software and hardware settings (including Wi-Fi). It is recommended to select "Freeze" in System settings to disable Armbian kernel upgrades because our kernel is compiled with custom patches enabling HDMI output on H96 Max V11 to work properly that are unavailable in other kernel versions.

You would try an Ubuntu distro and enable the oibaf repository to get cutting edge mesa.
Default mesa from debian and ubuntu is a bit older and does not contain specific fixes for mali-400/450
 
Oibaf repository is already set in /etc/apt/sources.list.d but the line is commented by default.
Removing the comment and then running apt update && apt upgrade should do the trick.
 
Also note that in X11 you may want to enable the vsync when possible, which turns out to perform much much better because with vsync on the driver will use page flipping, with vsync off will use buffer copy that reduces performances a lot.

works like a dream @jock. here's my freshly installed/updated hk1 max box dmesg using latest libreelec hdmi patched 6.3.13 kernel. i hope mainline gets around to updating hdmi timing stuff. brcm 6334 2.4G and 5G works out of the box. using it currently as pi hole box.
 
for those having problems with rtl 2734c (rtl8237cs). wireless module that gets detected but cannot connect to AP, here's a reuploaded nvram you can try out (no guarantees though), it solved my problem way back with the rounded h96 max i am using as klipper host. file is not mine, credits to the original uploader.
dmesg.log nvram_2734c.txt

I'm trying to do that, but your forum software is giving me problems (Invision, you were at the forefront 20 years ago, but now you're way behind the curve). It can't copy its own formatting between Edit screens in different posts ("Press Ctrl+V to paste. Your browser doesn‘t support pasting with the toolbar button or context menu option.") I tried both Edge and Firefox, so two different engines. What does it want, Chrome? (Insert Cyberpunk reference here) I'll have to recreate the formatting from scratch. Anyway, I'm on it. ... Aaand done!

I overclocked the CPU to 1.4MHZ using the voltage 0x1437c8, governor = conservative.
opp-1200000000 { opp-hz = <0x00 0x47868c00>; opp-microvolt = <0x13d620>; clock-latency-ns = <0x9c40>; status = "okay"; }; opp-1296000000 { opp-hz = <0x00 0x4d3f6400>; opp-microvolt = <0x137478>; clock-latency-ns = <0x9c40>; status = "okay"; }; opp-1392000000 { opp-hz = <0x00 0x52f83c00>; opp-microvolt = <0x1437c8>; clock-latency-ns = <0x9c40>; status = "okay"; }; The system has been working steadily for several hours and the browser is working faster.
Earlier I tried to overclock to 1.4 using the voltage 0x1312d0, but the system received errors almost immediately as soon as I started the browser.
My DDR is still 533MHZ. I want to raise the frequency to 600 - 660MHZ.
As I said earlier, I use a radiator with a fan
 
Just in case, a photo test point for RK3318 v.1.4 to launch a TV box in the maskrom mode

I created idbloader666.img , but my TV box RK3188 freezes literally a couple of minutes after loading with a frequency of 666MHz idbloader666.img
At a frequency of DDR 333MHZ, it works for months.
 
Using the HEX editor, I created rk3318_ddr_400Mhz_v1.16.bin and collected idbloader400.img with a DDR frequency of 400MHZ.idbloader400.img
The CPU operates at a frequency of 1.3 MHZ - it has been working stably for an hour.
Now I have launched memtester 512M
 
After a successful memory test, I continued experimenting with the HEX editor and increased the DDR frequency to 533MHZ and my TV Box started
Now I'm restarting the memory test
 
idbloader533.img

Thank you!
Yes, I have this comportamento:
echo 0 > /sys/class/leds/working/brightness -------- BLUE LED
echo 255 > /sys/class/leds/working/brightness ----------- RED LED
 
and I set:
echo "disk-activity" > /sys/class/leds/working/trigger
 
but I didn't have the blue led when there are I/O operations.
I see two led (red and blue when read/write) only in the first steps of armbian startup
 
Board: RK3328_8D4_V1.1

@Dario Murgia Don't worry, it is not essential, it was just good to know. However the fix has been mainlined in armbian

thanks for having a look. 
 
anyhow, I have SPDIF working now (on kernel 5.15.90)!
 
digging a bit into the dts generated from your rk3318-box.dtb and the rk3328 datasheet, I realized there are three pins capable of being set as SPDIF-out
 
spdif-0 { spdifm0-tx { rockchip,pins = <0x00 0x1b 0x01 0x66>; phandle = <0x13>; }; }; spdif-1 { spdifm1-tx { rockchip,pins = <0x02 0x11 0x02 0x66>; phandle = <0xd8>; }; }; spdif-2 { spdifm2-tx { rockchip,pins = <0x00 0x02 0x02 0x66>; phandle = <0xd9>; }; };  
in your DTB the first one was selected, in the pinctrl-0 declaration
 
spdif@ff030000 { compatible = "rockchip,rk3328-spdif"; reg = <0x00 0xff030000 0x00 0x1000>; interrupts = <0x00 0x1d 0x04>; clocks = <0x02 0x2e 0x02 0x13a>; clock-names = "mclk\0hclk"; dmas = <0x12 0x0a>; dma-names = "tx"; pinctrl-names = "default"; pinctrl-0 = <0x13>; #sound-dai-cells = <0x00>; status = "okay"; phandle = <0x10>; };  
so I tried to replace 0x13 (corresponding to spdifm0) with 0xd8 (corresponding to spdifm1), rebuilt the DTB and then I had SPDIF up and running on my x88pro-10!
 
 

@FatalWorld
there is a kernel oops about swapper being tainted. your board is the same as mine albeit with different wifi chip. these are the things i would try if that was my board:
1. backup original firmware and try flashing different firmwares on the emmc chip from the github page.
2. if running from sd card, i would try a different sd card just to test filesystem stability.
3. i would also try ram testing.
4. upload logs for different test image used. just do a "dmesg >> dmesg519.log", download that log using winscp and include it in your next post, it would help jock and others with debugging where your problem is coming from. got mine solved that way.
 
cheers and good luck!

Even better, 6.1.0.
 
Browsers that are using the qt5-qtwebengine backend in a wayland environment (e.g. Falkon) are working flawless. The Qt Multimedia module uses the gstreamer framework and wayland uses proper KMS/DRM support.

GPU is only doing 3D graphics.
Media applications are accelerated by VPU, which is a totally different part of the chip. I think gstreamer is already quite capable of using the v4l2 interface to profit of media acceleration drivers already in mainline kernel (namely hantro and rkvdec for rk3318, both accelerating h.264, vp8, vp9 and hevc, but some codecs still have partial support on rockchip64 armbian branch).
Ffmpeg needs to be built with patches and in a custom way because kernel interface for codecs has been made "stable" very recently (I guess in kernel 5.19).
Also mpv has the capability to use hardware video decoding via v4l2, but still need a custom build because it uses in turn ffmpeg. There is this old thread where I provided a custom build binary of mpv, but it was for ubuntu hirsute and debian bullseye; surely it would require some adaptations and tinker if you want to run on newer distros.
 
Accelarerating youtube in a browser is a whole different story. I don't know what is the current status (maybe @usual user has some clues?), but surely it is much more challenging than standalone video playing.
 

hello. 5.19.15 kernel works both on rounded and square h96 max box v1.4 boards and so far they are both running stable with hdmi display for about 6 hours now. attached are the dmesg logs for both boxes. for the square box, i did a fresh install of @jock's full image and for the rounded one, i have installed the new kernel and dtb. i2cdetect -l needed sudo and the output is the same as @MattWestB's.
dmesg-square.log dmesg-rounded.log

@Seth Very much thank you for the photos!
I looked at them side by side trying to spot differences, and the board layout and printings seems exactly the same to me. The squared has a 2146 printed below the heatsink, the rounded has 2147; I may guess it is a something like lot number; the date "2020/06/29" maybe is the date when the board was designed. @FRIKIdelTO has the 2151 lot number but the same 2020/06/29 date on his board.
The differences are, as you already noticed, in some pads being populated with components or just unpopulated.
 
I may guess the fx8934 comes with an on-board crystal which is below the metal shield, instead the sp2734c requires an external crystal and the inductor too.
I checked the nvram files, and both the default shipped with armbian and the alternative version for the 2734c have the crystal set to 37.4MHz.
My HK1 board comes with an HK6334Q, has the external 37.4MHz crystal but works with the default firmware like the fx8934 that has no external crystal. Very messy 😄
 
About the HDMI, on kernel 5.19 it does not work on both of them or just on the "squared" one?
 
I cleaned, sorted and finally made a diff of the two nvram fiels I attach here for curiosity and study purposes.
You can see there are several calibration parameters that differs a bit, but there are also some obscure parameters like swctlmap that probably control some chip registers to behave in a way or another.
Use zless -R to see it correctly with colors.
diff-def-alt-nvram.txt.gz

there seems to be 2 types of h96 max on the market, one is the more rounded and smaller case which has an rk3318 and 2734c chip that is working only on 2.4GHz and the other one has a bigger case with square corners which has real 4334 wifi chip and supports both 2.4GHz and 5GHz bands. Some square box with lower specs for storage 2GB ram +16GB has 2734c but 4GB+32GB almost always has real 4334 chip. i bought both. the square one is about $3 more expensive than the rounded one. my square h96 max seems to have real rk3328 (verified by using hexdump) and am testing xfce 5.15 version at the moment, hdmi sound doesn't seem to work though. but overall stable at 1.3GHz with a little bit of active cooling. anyways, if you're gonna play with boxes like this, make sure you have an extra cable to the router ready always. my setup includes an always ready rig for uart, usb male to male, ethernet cable and 5v supply ready for quick hookup. the rounded one i have is currently running my 3d printer and will not be updated anytime soon. i'm planning on getting an hk1 max as that is @jock's testing platform, i hope i get lucky and get the same specs.

i got myself a new box, still an h96 max, same as what @paradigman has. it also has a 2734c wifi chip, his posted nvram from the manufacturer works. hdmi on edge kernel still doesn't work on my monitor/tv but i can access it via ssh after install so everything is good. thanks again @jock, @fabiobassa and @paradigmanfor the awesome community support.

@Keeper : check my previous post, because the the error is familiar to me
 
https://forum.armbian.com/topic/17597-csc-armbian-for-rk3318rk3328-tv-box-boards/?do=findComment&comment=143890
 
 

@oolonthegreat This thread is for rk3318 and not rk3188; please open a new thread for that request and also remove the long log lists from here because they make the browsing from mobile very difficult.
 
@Aapo Tahkola I meant the four pads at the right of the IR receiver, not the three pads near the led array: those are clearly pads for diodes if you pay attention to the symbols.
Looking at the back of the @uehqsvbm's board, those four pads have a different wiring than the IR receiver and from the front side there is no immediate connection to the IR receiver; It is not 100% sure because there could be some in-board layer connecting them to IR, but I may guess those are not for IR. Also the central pads immediate connection is to a couple of components that seem to be resistances.
They could also be spare connection for leds, but in such case a single resistance would suffice and placing resistors there is a waste of components since the board does not have leds there.
 
Looking at the front side, the rightmost pad is surely ground (it has the reverse triangle symbol), and the leftmost maybe is VCC (there is a path going to IR receiver), maybe the two central pads are uart RX/TX.
 
About the led blinking led issue, this is what google suggests as first answer: https://linuxreviews.org/HOWTO_Control_LED_Lights

No prob, I was counting on the possibility of bricking it, but it was just a 20€ crappy device laying around. And it is not bricked after all, yet it works faster than factory with Armbian, and even have WiFi, which I didn't expect 😆
I'm on vacation and I don't have any USB-OTG cable here, so I cannot use the RK flashing tool. There is an option to create an "upgrade SD card", but it only supports cards up to 16GB, not bigger (WTH?), and also requires a reset button which seems not to be present on the device.
 
This also motivates me to spend some time finishing the media integration for Mainline, so I can at least use Kodi on this 😄
 

Yes, you can. Actually the choice to remove any Android code from the board is a deliberate choice by me 😝 but has some performance and compatibility reasons, since this way the user is in control of the ddrbin, miniloadloader/SPL and trustos.
 
The explanation is not exactly simple because these three pieces then cause unwanted behaviours, especially  the proprietary trustos does not allow rk3318 to run above 1.1GHz. I guess rockchip put an artificial cap because the chip can run fine at 1.3GHz or even overclocked at 1.5GHz. A pro of the proprietary trustos is that it allows DDR frequency scaling, that is not allowed by the opensource trustos, but to overcome this I patched the ddrbin to use ram at 667MHz with great benefits in terms of multimedia and general performance. If you run stock Android you are forced to use the "stock" ddrbin at 300/333 MHz because the rockchip boot always happens from internal flash... so it's a chain of issues and to avoid all of these hassles I prefer to erase Android and start fresh.
 
If you still want to go the "Android" mixed way, @hexdump wrote a document on his github on how to do, but I always forget the bookmark the link... That's still something that should be exclusive for the power user because that belong to the same class of those I explained above are around the corner.
 

@dicky soeliantoro On first page you can find the "Prebuilt images" links. The "archived" ones are quite recent with kernel 6.1.x are good to go with stable kernel.
There are also the "nightly stables", which have 6.3.x kernel, which is newer and with more features, but also could be less stable.
 
The choice is yours, it depends on what you want to do with the box.

Two days of uptime on X88 pro using original power supply and the AP6330 wifi crashed again flooding dmesg with "err=-110". https://lkml.iu.edu/hypermail/linux/kernel/2105.3/05569.html goes into some detail about -110. "rmmod cfg80211 brcmfmac && modprobe brcmfmac" caused firmware loading error. So is this limited to X88 pro or all AP6330 I do not know. However since this a hard to reproduce bug there probably isn't much that can be done to actually fix it. I've been using MT7601U usb wifi module that landed on my hands for 5 days without issues. I measured about 600mA current draw on these devices under load so the power supply should be fine I guess. Using MT7601U it takes about 100mA more than with AP6330. I haven't bothered to measure but MT7601U feels about as fast AP6330.