jock

Hello guys, I'm proud to say that the Q8 boards are now in mainline Armbian as CSC supported boards!
 
https://www.armbian.com/xt-q8l-v10/

Well, another solution is to patch brcmfmac kernel module to add ap6330 chip and revision. It's a very small patch, just adding another item to the list:
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c index a907d7b06..ec71996c7 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c @@ -619,13 +619,17 @@ BRCMF_FW_DEF(4354, "brcmfmac4354-sdio"); BRCMF_FW_DEF(4356, "brcmfmac4356-sdio"); BRCMF_FW_DEF(4373, "brcmfmac4373-sdio"); +/* AMPAK */ +BRCMF_FW_DEF(AP6330, "brcmfmac-ap6330-sdio"); + static const struct brcmf_firmware_mapping brcmf_sdio_fwnames[] = { BRCMF_FW_ENTRY(BRCM_CC_43143_CHIP_ID, 0xFFFFFFFF, 43143), BRCMF_FW_ENTRY(BRCM_CC_43241_CHIP_ID, 0x0000001F, 43241B0), BRCMF_FW_ENTRY(BRCM_CC_43241_CHIP_ID, 0x00000020, 43241B4), BRCMF_FW_ENTRY(BRCM_CC_43241_CHIP_ID, 0xFFFFFFC0, 43241B5), BRCMF_FW_ENTRY(BRCM_CC_4329_CHIP_ID, 0xFFFFFFFF, 4329), - BRCMF_FW_ENTRY(BRCM_CC_4330_CHIP_ID, 0xFFFFFFFF, 4330), + BRCMF_FW_ENTRY(BRCM_CC_4330_CHIP_ID, 0xFFFFFFEF, 4330), + BRCMF_FW_ENTRY(BRCM_CC_4330_CHIP_ID, 0x10, AP6330), BRCMF_FW_ENTRY(BRCM_CC_4334_CHIP_ID, 0xFFFFFFFF, 4334), BRCMF_FW_ENTRY(BRCM_CC_43340_CHIP_ID, 0xFFFFFFFF, 43340), BRCMF_FW_ENTRY(BRCM_CC_43341_CHIP_ID, 0xFFFFFFFF, 43340), This will let brcmfmac look for brcmfmac-ap6330-sdio.bin and brcmfmac-ap6330-sdio.txt firmware files, so there is no need for alternative paths. As long as brcmfmac only discriminates among Chip ID and Chip Revision, there is the drawback case where all those devices which have ID:0x4330 and REV:0x4 will be considered as AP6330.
After googling around for "BCM4330/4" (a string the driver produces in dmesg), all the sensible results always bind it to AP6330.
 
Although this looks tidier, my preference goes to the former solution because it seems "safer" (no id/revision clashing)

Guys,
I think we need to distiguish booting from sd and _unattended_ booting from sd.
In case of my hw (tx3-mini) I think unattended boot from sd is NOT possible without erasing[modifying] eMMC bootloader.
I think so as IPL by default is passing control to eMMC.
So if we want unattended boot from SD - we MUST:
1\ change eMMC content
2\ modify IPL
As IPL is in ROM (I think) -  only option 1\ is choice.
 
Reasonably written IPL should have fall-back to SD[USB] if SPL from eMMC fails (i.e. for case when flash ageing leading to data rot). In such case IPL should offer recovery by booting from SD and refresh eMMC SPL.
So I agree with initial @jock answer as IMHO his intention was to describe what needs t be done to have tv-box _unattended_ boot from sd
 
 

My plan is to reset the kernelconfigs from common base and enable brcmfmac and IR (and ancillary config options) as modules when possible.
Devfreq support and other things were just test bits that can be left out.
 
If AP6330 firmware binaries could make into armbian firmware repository I can remove the copy work in rockchip.conf - I can arrange a pull request myself for that.

My plan is to reset the kernelconfigs from common base and enable brcmfmac and IR (and ancillary config options) as modules when possible.
Devfreq support and other things were just test bits that can be left out.
 
If AP6330 firmware binaries could make into armbian firmware repository I can remove the copy work in rockchip.conf - I can arrange a pull request myself for that.

Finally, the version 2.0 for Armbian Bionic is out! Check the OP for documentation and download link.
 
CHANGELOG:
Updated all necessary packages to work with Ubuntu Bionic Updated versions of MPV and Kodi Added the GL4ES wrapper, to provide OpenGL support (thanks @jock for the tips). In order to use it, you must launch your app from command line using the wrapper "glrun" RELEASE NOTES:
I'm not sure whether the Widevine library is still working with newer versions of Chrome, and I don't have access to Netflix anymore to test it. Some feedback on this point is welcome. I'm still including the old cgminer as OpenCL example. If you want to try more recent algorithms and experiment with GPU mining just for fun, I recommend you to have a look to this sgminer for from the ODROID community (it works also with RK3288): https://github.com/hominoids/sgminer-arm As I said, just for learning, curiosity or fun. Trying to get money with a Tinkerboard is a waste of time. Plus, I think the whole crypto-mining idea is absurd, basing the value of a currency on wasting as much electricity as possible  Remember you need a default (4.4.y) kernel for HW video acceleration to work. It is not yet implemented in mainline (4.14.y).  
 

Nope, mali binaries take care of everything.
 
BTW, Bionic version of the script is done, I'm just brushing up the documentation.

... and I have build it and pushed to Armbian stable repository (Stretch, Xenial and Bionic; armhf+arm64). First boot scripts also creates CPUfreq config based on CPU count. More can be added if there is an interest ... Package can be installed via apt update and upgrade while auto config feature will work only on self made images.

Just In case anyone is interested I have pushed HTOP 2.2.1 to github, so it is possible to monitor big.LITTLE cores in real-time.
You can view the big.LITTLE in action, Vcore, Cpu thermal throttling and Cpu frequency for each big or LITTLE core.
 
HTOP is a nice console graphical tool for system-monitor, process-viewer and process-manager.
DEB package and source code in case you want to extend or fix things.
Be aware the process list and task can be very intrusive if you want to monitor many things at once.
It has been tested on NanoPi M4 (thanks to FriendlyElec for the samples) but should work on any SBC just adjust the Vcore path for different kernel version.
 
https://github.com/avafinger/htop-2.1.1_enhanced-version
 

I never thought you were in bad faith. Pity that my orange pi pc is in active use as my doorbell otherwise I could test it (though by reading the thread it seems there's still a lot of work to be done).

You're absolutely right, so let's back on the tracks.
 
A tv box is very handy if you're going to use it like a tvbox or some headless servering, here boxes with S905X are all around and mostly work good.
If you want an all-purpose device which you can use for development, kodi, interfacing to arduino, with best all-around compatibility and don't want to bother with GPU and VPU issues, take an RPi3 (maybe latest Model B+), but here you have to resign to some "latest and greatest" (hw decoding for H.265 most of all, but also capped gigabit ethernet and the ethically discutible BLOB firmware)
If you want to try armbian, get GPIO and be on the edge about performance and features, but also unable to use some features because of chipset manufacturers, you can select any board which sports Allwinner, Amlogic or rockchip (OrangePi, Odroid, Libre Computer, ...). This is the most adventurous and can be both satisfactory and frustrating when see you can't reach the goal (the same applies with tvboxes too, somewhat amplified)
 
Maybe this link can be helpful to clarify current hardware accelerated video status for various chips.

1. Can you provide a link where I said H3 with Armbian + KODI has full HW support? Those are NOT my words, I said something completely different in the purpose to give the OP an idea of the actual state of the art about the various chips, not trying to sell him something!.
2. Glad to hear, but developers are saying that's far from being usable, and the same applies for others too. But just stick to the thread "Kodi + Armbian" - not "S905X on LibreELEC" - would you?
3. The differences between utgard and midgard gpu architectures are totally irrelevant to this thread
 
That's your opinion, which may be respected but from my point of view is completely wrong. Start from vanilla Armbian and tell me how many steps you need to get GPU and VPU working for your favourite chip.
 
My rk3288 tvbox was nothing more than a brick a couple of months ago, stuck with Android 4.4, before I poured time and time to bring armbian on it... hardware is nothing without software support, and software support for tvbox is totally absent. Suggesting to buy an unsupported chinese tvbox for a person who asked something completely different is intellectually dishonest.

No non-sense, the OP asked for hardware acceleration and preferably mainline kernel, so the thing which scores the most this sense is H3, with all the cons I wrote in the post you quoted (plus the fact that I'm not fond of allwinner which is by far the most non-opensource company of the group).
AmLogic has no committment for mainline kernel and hardware video decoding is missing in mainline (linux-meson.com says "No" "WiP"), so to stay stick to the original question (armbian + kodi) is a step behind the H3. Now you can use it with the legacy kernel and get all the nice things working on a carefully crafted armbian image, but with an ancient kernel.
 
The summary of all this is that armbian + kodi requires a decent amount of exercise either because armbian target is not multimedia and because the "best" SoC here has still several missing things.
That's also the reason why many people said buy a RPi3 which has all the USB ports, GPIO, hardware acceleration (with the notable exception of H.265), 64 bits, chips, fries and desserts for the miserable price of €35

No non-sense, the OP asked for hardware acceleration and preferably mainline kernel, so the thing which scores the most this sense is H3, with all the cons I wrote in the post you quoted (plus the fact that I'm not fond of allwinner which is by far the most non-opensource company of the group).
AmLogic has no committment for mainline kernel and hardware video decoding is missing in mainline (linux-meson.com says "No" "WiP"), so to stay stick to the original question (armbian + kodi) is a step behind the H3. Now you can use it with the legacy kernel and get all the nice things working on a carefully crafted armbian image, but with an ancient kernel.
 
The summary of all this is that armbian + kodi requires a decent amount of exercise either because armbian target is not multimedia and because the "best" SoC here has still several missing things.
That's also the reason why many people said buy a RPi3 which has all the USB ports, GPIO, hardware acceleration (with the notable exception of H.265), 64 bits, chips, fries and desserts for the miserable price of €35

Maybe all the things you want may be found in an Allwinner H3 box, probably the best choice for armbian is Beelink X2 which is supported out-of-the-box.
Pros:
Cheap (below 30$) Have decent support in mainline linux, thanks to the effort of the community GPU drivers can run Bootlin works for reverse engineering the VPU and thus hardware video encoding and decoding Cons:
The SoC is a bit old nowadays (Cortex A7) The GPU is quite old (Mali 400) The GPU drivers are quite horrible (but if you just run Kodi they should suffice) and have no vsync I don't what is the status of the VPU hardware video decoding now, probably will require some months to mature. Maybe ask on Kodi forums about would turn out to be interesting  
Otherwise the most decent thing which has everything you ask, but not in mainline but fairly recent kernel, is rockchip family (rk3288/rk3328/rk3399).
However, except for the Beelink X2 (Allwinner H3) which are supported out of the box by armbian, it's a matter of luck getting a tv box and hoping everything works. I have a discontinued rk3288 tv box which is capable of being a decent media center, but I spent several weekends to reverse engineer lots and lots of details to make it useful (but now I can proudly write this comment from it )
AMLogic has the oldest kernel of the group, dunno what is the status of mainline kernel but I think they did not release their customized GPU drivers at all

Yes, indeed RPi3 is a good choice. The only drawback is that h.265 being software decoded because the VPU/GPU part has not been updated since their debut, on the other side you get plenty of support by community and foundation, and also an opensource GPU OpenGL driver which works pretty well, as opposite of the crappy blobs for ARM Mali GPUs

Well, you should at least specify the hardware you want to run armbian and kodi on.
If your intent is to just run armbian + kodi, usually you get most hardware acceleration (GPU + video decoding) if you use the kernel provided by the hardware manufacturer, but don't expect a warm soup ready for lunch.
Each SoC is a different story: GPU drivers are not always available (mostly due to ARM Mali license, the most common GPU in SoCs), and sometimes they are misbehaving. It's kind of puzzle-game where not always all the pieces are there to be fit togheter.
 
At the moment, I don't know any board which works out-of-the box with vanilla armbian.
Some work has been done by the community for rockchip rk3288 (see here). Rockchip are the most promising because the manufacturer provides documentation and source code and also GPU drivers works.
Allwinner provides GPU drivers for their old Mali400/450 GPUs. Bootlin reverse engineered the VPU on older SoCs (H3 and going back) to provide hardware acceleration for videos on mainline kernel and apparently some support is appearing in ffmpeg, although I don't know if it is ready to be used.
AmLogic is unknown to me, I think you should stick to their white-beard old kernel if you want GPU and VPU acceleration
 

@JMCC yes of course, I will do a small tutorial as soon as I have some spare time!
The compilation process is quite easy to accomplish, although documenting important environment variables is essential

I've adapted a set of patches from Urja Rannikko, which move the HDMI frequencies definition into the DTS file, with some preconfigured rates if none are defined in the DTS.
 
The original patches set is here : https://www.spinics.net/lists/arm-kernel/msg673156.html
The big patch I used as a basis is here : https://github.com/urjaman/arch-c201/blob/master/linux-c201/0020-RK3288-HDMI-clock-hacks-combined.patch
I included these patches by splitting them again : https://github.com/Miouyouyou/RockMyy/commit/57ff073fffb5678e75959e566704376f6f52ac17
 
These patches were suggested to me here : https://github.com/Miouyouyou/RockMyy/issues/3
 
Anyway, after some quick tests, these patches remove the dreaded bar of purple pixels at the left of my HDMI screen, when plugged to Tinkerboard systems and MiQi systems. Note that these bars only appear on my screen when using "good" (enough) USB power supply.
Still, with these patches, they are gone. However... I only tested these patches on my 60Hz 1080p screen, which is pretty much the de-facto standard screen.
I'd like to see people test these patches on other HDMI configurations which are known to have some issues with Tinkerboard, MiQi and others RK3288 systems.
 
So, yeah, if you'd like to test some kernel patches and are not afraid to see your screen go black after a reboot, have a try.
 
Note : This is completely unrelated with the CEC issue.

Oldies but goodies: a made a quick demo with my smartphone (sorry for the bad quality) of Quake2 running on rk3288 using GL4ES. The game works really well, it is totally playable and there are no issues of any sort 
 
 

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 is CSC Armbian for XT-Q8L-V10 boards, also known as Chiptrip Q8, Vsmart Q8, ENY 3288 Q8, etc...
 

 
All source code has been merged into Armbian mainline project.
I still keep my personal public Armbian fork for experimental features: https://github.com/paolosabatino/armbian-build
 
Nightly images: download directory
 
Quick installation instructions on eMMC:
Build or download your preferred Armbian image from Download directory 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 sd card, then push the power button for 1 second (the led will turn blue) After 10 seconds HDMI will turn on and you will get logging messages; On first boot you will be asked for entering a password for root user of your choice and the name and password for a regular user Run armbian-config to configure timezone, locales and other personal options Congratulations, Armbian is now installed!  
Boot from SD Card/USB stick (with Armbian already installed in eMMC, empty eMMC or no eMMC😞
Build or download your preferred Armbian image from Download directory; Burn the image on your SD card/USB stick; Plug the SD card/USB stick in the device; Push the power button for 1 second (the led will turn blue); After 10 seconds HDMI will turn on and you will get logging messages; On first boot you will be asked for entering a password for root user of your choice and the name and password for a regular user Run armbian-config to configure timezone, locales and other personal options Congratulations, Armbian is now installed!  
Boot from SD Card/USB stick (with original firmware or other firmware):
In case your box has the original firmware installed, use the Multitool to erase the internal flash.
Don't worry, you will not brick your box: once the eMMC is emptied, the box will automatically boot from SD Card. This is called Maskrom mode and is common to all Rockchip devices. Instructions and download links for the Multitool are at the bottom of this post.
After erasing the internal eMMC, just follow the "Boot from SD Card" procedure above and then you are fine.
 
Boot priority:
Newer images (those with mainline kernel >= 4.14.50) now support booting from multiple devices.
Priority is fixed and boot devices are probed in this order:
 
External SD card External USB storage device (Any USB Stick/Hard drive attached to USB host ports) Internal eMMC  
This way even if you install armbian to internal eMMC, you can still easily test different images booting from external devices.
Experts notes: when armbian is installed into eMMC you get U-boot installed too in eMMC. This is important to know because the box won't boot in Maskrom Mode, but instead will always boot the embedded U-boot, no matter if you put an sdcard/usb stick. In practice the embedded U-boot is totally responsible for the boot priority. If you want to restore the Maskrom Mode, just erase U-boot from eMMC using this command:
dd if=/dev/zero of=/dev/mmcblk2 seek=64 count=8128 conv=sync,fsync  
Current status:
Wireless: works. pretty fast and stable, signal is strong on my box; Bluetooth: works. I was able to transfer files and stream audio without problems USB ports: works, with autosuspend too. A quick benchmark show that transfer rate is quite good (topped at 34 MB/s) USB OTG: works in host mode. Transfer rate is very good (> 40 MB/s) MMC: works and is perfectly accessible as storage device. The images above with "eMMC friendly" have been tested and work when installed in eMMC using the standard armbian-config eMMC installer SDCard: works. legacy kernel is limited to high speed, while mainline works fine in UHS mode too. A quick benchmark with a Samsung EVO card shows the promised 48Mb/s read speed. Gigabit Ethernet: works, fast and reliably HDMI: works perfectly Serial: works Audio: both HDMI audio and SPDIF connector works IR remote: works on legacy and mainline kernels Reboot/Suspend process: rebooting the device is a working in progress, at the moment sometimes it works and sometimes it doesn't. Suspend is still not available. Hardware acceleration: everything which works for rk3288 boards applies here too. This guide or maybe the Media Testing Script will help you gain an hardware accelerated X11 and Chromium (using GL4ES I enjoyed Quake 2 from the start till the end, but also Quake and Quake III Arena work flawlessy, here a quick how-to to compile and install GL4ES)  
Multimedia:
On mainline kernel 3D acceleration is provided by Panfrost driver and is already enabled.
Hardware video decoding: https://forum.armbian.com/topic/19258-testing-hardware-video-decoding-rockchip-allwinner/
 
Multitool:
The Multitool is a small but powerful tool to easy operate on internal eMMC flash of RK3288 devices.
 
Features:
Backup the content of internal eMMC Restore a previously backed-up image to eMMC Erase the eMMC (via fast blkdiscard or zero-fill as fallback) Burn an Armbian (or LibreELEC) image directly on the eMMC Provide a recovery shell for manual maintenance Windows-friendly: everything is placed in a NTFS partition Image compression format autodetection: they are decompressed on-the-fly during burn process Network support for remote maintenance via SSH (instructions to access via network here)  
Instructions are simple:
Download the image from here Burn it on an sdcard Open the NTFS partition with your preferred file manager Place the images you want to burn on the device in images directory (backups will be stored in backups directory) Plug the sd card in the RK3288 device Power the device and wait few seconds, the Multitool menu will appear on screen and can be navigated with the keyboard  
Last edit: 07/06/2020 - updated installation instructions
 

Bump up due to some news:
New Xenial image with mainline 4.14.68 kernel New Xenial image with latest and greatest 4.18.6 dev kernel (which seems pretty stable to me) Both new images now fully support the IR Remote out of the box, in native mode via kernel keymappings and drivers. Kernel keymap table can be customized using ir-keytable tool. Kernel 4.18.6 also exposes the native lirc interface, so in theory any remote controller can be trained to work with the box Both new images enables the SPDIF connector (it is untested though due to lack of a Optical DAC at home) Added devfreq support for the GPU: at the moment the base frequency is 100 Mhz and maximum frequency is 600 Mhz. The GPU may be too lazy to switch frequency, so you can force a minimum frequency issuing (as root) echo 300000000 > /sys/class/devfreq/devfreq0/min_freq to force the pre-devfreq default operating frequency. You may also force 600000000 (600 Mhz) as minimum to run the GPU always at full speed. Beware the thermals anyway, when the core reaches 70°C it starts throttling and your performance may not be as you expect if you don't cool enough the SoC Every other thing which has been put into Armbian lately is also in the images Enjoy!
 
 

Bump up due to some news:
New Xenial image with mainline 4.14.68 kernel New Xenial image with latest and greatest 4.18.6 dev kernel (which seems pretty stable to me) Both new images now fully support the IR Remote out of the box, in native mode via kernel keymappings and drivers. Kernel keymap table can be customized using ir-keytable tool. Kernel 4.18.6 also exposes the native lirc interface, so in theory any remote controller can be trained to work with the box Both new images enables the SPDIF connector (it is untested though due to lack of a Optical DAC at home) Added devfreq support for the GPU: at the moment the base frequency is 100 Mhz and maximum frequency is 600 Mhz. The GPU may be too lazy to switch frequency, so you can force a minimum frequency issuing (as root) echo 300000000 > /sys/class/devfreq/devfreq0/min_freq to force the pre-devfreq default operating frequency. You may also force 600000000 (600 Mhz) as minimum to run the GPU always at full speed. Beware the thermals anyway, when the core reaches 70°C it starts throttling and your performance may not be as you expect if you don't cool enough the SoC Every other thing which has been put into Armbian lately is also in the images Enjoy!
 
 

Oldies but goodies: a made a quick demo with my smartphone (sorry for the bad quality) of Quake2 running on rk3288 using GL4ES. The game works really well, it is totally playable and there are no issues of any sort 
 
 

The Mali driver can use devfreq, and has various ways to be told how to vary the frequency of the GPU.
Now, I've been informed recently that a patch is necessary on mainline kernels to avoid some Mali Devfreq related warnings and panics.
A modified version of the patch is available here : https://github.com/Miouyouyou/RockMyy/blob/master/patches/Midgard/r19p0-01rel0/0010-GPU-Mali-Midgard-remove-rcu_read_lock-references.patch
The original is here : https://github.com/mihailescu2m/linux/commit/bbe73c3c1143e5991bdcaee3afaecf5c31af0647
 
That said, if you want to push the Mali GPU to higher limits, you can do something like this :
cd /sys/class/misc/mali0/device/devfreq/devfreq0/ echo `cat max_freq` > min_freq echo 10 > polling_interval This will force the GPU to be at its highest clock rate constantly (supposedly, I have no way to actually verify that).
 
Now, let's be clear, if you launch a GPU intensive task with these settings, while not having a beefy stable power supply, the board might just shut down or not provide any performance gain. Now that's mostly the case for USB power supplied board.
 
Still, these settings provide good performances gain on some benchmarks, very little on others. Frequency alone won't help you overcome bad optimizations. Also sometimes performances issues become CPU bound as the GPU gets faster.