jock

@svdmk Thanks for posting the photos and the firmware!
I took a look to the device tree and found something that could be somehow intersting. I'm not absolutely sure it may be related to your issue, but there the device tree contains this gpio switch which is not usual:
 
gpio_poweroff { compatible = "gpio-poweroff"; gpios = <0xb3 0x11 0x01>; status = "okay"; }; it maps to gpio3 bank and pin 17 (PC1, in the rockchip documentation). That string says that the pin is active low, it means that when it is 0, the poweroff is active; when it is 1 the poweroff is inactive.
 
I may assume that gpio pin is used by the operating system to power off the system.
On other board that pin is not mapped in the device tree, so I may also assume it is not used anywhere.
In your case may (or may not) be related to the weird behaviour you're experiencing.
 
With this command (to be run as root), you can see how the pins is configured. In my case, the pin is set to output at 0 level, but since it is not wired on my board it just does not do anything. Could you please execute the same command on your board?
# grep 'gpio3-17' /sys/kernel/debug/pinctrl/pinctrl-rockchip-pinctrl/pinconf-pins pin 113 (gpio3-17): input bias pull down (1 ohms), output drive strength (8 mA), pin output (0 level)  
You can also control that pin:
# cd /sys/class/gpio # echo 113 > export # cd gpio113 # cat direction in # cat value 0 # echo out > direction # cat direction out # echo 1 > value # cat value 1 # echo 0 > value # cat value 0  
with echo 113 > export you will make the pin available for userspace, then a directory gpio113 will spawn and you can echo to direction and value to change the pin as input or output and switch levels.
If the pin is actually wired to something, it may be that when you switch direction of level the board may suddenly turn off.
 
Now you can also do another test: erase the emmc and verify you still have the shutdown issue. If that is the case, it may be interesting to see what is the pin state in that condition and if switching its condition causes the weird behaviour to stop or does not change anything.

That's right.
I use multitool only to erase internal flash and then use rkdeveloptool to flash loader and image as it is described in first page.
The device boots from sdcard in both cases, blank or flashed emmc but if there is a proper partition on internal flash Armbian works right, otherwise turns off(I heve tried to erase emmc and create partition with fdisk tool in Armbian, and OS works properly ). Armbian boots from internal flash too.
I think booting issue and turning off after minute are two different cases. Turning off probably is some kind of interaction between RAM and EMMC into EMCP chip itself(kingston 08emcp08-el3cv100).
This is dumped android firmware:
https://drive.google.com/file/d/1ZLl-KCvGS47SAO8tY1YDvCHDv6YWIWRP/view?usp=sharing

hmm, this is the commit that should have included the fix, but I made a quick diff and I could not find trace of the fix in the compiled u-boot dtb, so perhaps the fix didn't apply at all. Need to check better when I have more time, I hope I have the still the patch around.

Nope, they are not useful. To identify the issue I need the serial logs from the board UART when you boot multitool to understand the reason why it does not proceed.
 
Did you try to burn a second multitool on a USB stick, plug both the sdcard with multitool and USB stick with multitool and see if it boots?

Hello, which one is your device? And no, MXQ 4K market name does not help at all, you have to open the tvbox and look for the name printed on the board PCB.
 
What you can do to is:
* downloaded and try the latest multitool
* take photos of the board (both sides)
* provide the output of the serial log for the failing condition
 
 

I perfectly remember the change @ilmich did on libreelec to fix your use case, but I applied to same fix to multitool and it didn't work, so without logs it is impossibile for me to guess what is the problem with multitool and your board.

@audio kees if your need is just play video at 4k you probably won't go with armbian but rather with libreelec; if your goal is playing music you'd probably want to go with volumio either. Armbian is suited mostly for linux desktop replacement and server-like tasks.
Said so, tv boxes are the worst choice around in any case, especially if you choose among the lowest budget.
Much better if you go with properly supported Single Board Computer (SBC) and, as said, you'd better take a look to what libreelec suggests as preferred hardware (probably Raspberry Pi) if you want/need an out-of-the-box working system.
 
 
 

From the datasheet it seems interesting, but no, never seen such chip and never seen a driver for it
 

@audio kees Perhaps you can install armbian in eMMC and libreelec from sdcard/USB stick. It will work because armbian bootloader is capable of booting from several devices; altough it is quite strange libreelec bricks your board.

@audio kees
you need the most simple and stupid usb keyboard, not sofisticated ones nor wireless because of lack of drivers in multitool that has a very basic kernel
If you haven't one ... grab from a friend

remember.. kiss !!!  keep it simple (and) stupid

@audio kees did you try to press "Enter" on your keyboard?

@pakos96 attached to this message there is a script that does the trick to change the ddrbin frequency.
Can be used on the boot block device directly on the board, or on a file to modify a ddrbin binary or an armbian image before sdcard burn.
 
Usage and examples are in-built with the script, so launching it without arguments provides all the help that could be needed.
 
Some notes:
THIS IS AN EXPERT THING. If you're not an expert, do not do this; do not come here later sobbing you made a mistake, or you will receive more insults that will make you cry even more 🫣 always always always test the ddrbin frequency change on a system booting from sdcard if there is a bootloader installed in eMMC, it has priority: changing the ddrbin on sdcard won't have any effect until you clean the eMMC (or the bootloader) some boards (notably X88 Pro) do not like ddr frequencies above 330MHz: they won't boot changing the ddrbin frequency of the bootloader in the eMMC is very dangerous! You may brick the board (only way out: maskrom via eMMC clock pin gating)  
ddrbin-switch-freq.sh

No problem! I was intentionally being ironic  thanks again

@pakos96 attached to this message there is a script that does the trick to change the ddrbin frequency.
Can be used on the boot block device directly on the board, or on a file to modify a ddrbin binary or an armbian image before sdcard burn.
 
Usage and examples are in-built with the script, so launching it without arguments provides all the help that could be needed.
 
Some notes:
THIS IS AN EXPERT THING. If you're not an expert, do not do this; do not come here later sobbing you made a mistake, or you will receive more insults that will make you cry even more 🫣 always always always test the ddrbin frequency change on a system booting from sdcard if there is a bootloader installed in eMMC, it has priority: changing the ddrbin on sdcard won't have any effect until you clean the eMMC (or the bootloader) some boards (notably X88 Pro) do not like ddr frequencies above 330MHz: they won't boot changing the ddrbin frequency of the bootloader in the eMMC is very dangerous! You may brick the board (only way out: maskrom via eMMC clock pin gating)  
ddrbin-switch-freq.sh

The script allows you to go up to 800mhz, but I would not go further than 660MHz for a number of reasons

@pakos96 attached to this message there is a script that does the trick to change the ddrbin frequency.
Can be used on the boot block device directly on the board, or on a file to modify a ddrbin binary or an armbian image before sdcard burn.
 
Usage and examples are in-built with the script, so launching it without arguments provides all the help that could be needed.
 
Some notes:
THIS IS AN EXPERT THING. If you're not an expert, do not do this; do not come here later sobbing you made a mistake, or you will receive more insults that will make you cry even more 🫣 always always always test the ddrbin frequency change on a system booting from sdcard if there is a bootloader installed in eMMC, it has priority: changing the ddrbin on sdcard won't have any effect until you clean the eMMC (or the bootloader) some boards (notably X88 Pro) do not like ddr frequencies above 330MHz: they won't boot changing the ddrbin frequency of the bootloader in the eMMC is very dangerous! You may brick the board (only way out: maskrom via eMMC clock pin gating)  
ddrbin-switch-freq.sh

@pakos96 attached to this message there is a script that does the trick to change the ddrbin frequency.
Can be used on the boot block device directly on the board, or on a file to modify a ddrbin binary or an armbian image before sdcard burn.
 
Usage and examples are in-built with the script, so launching it without arguments provides all the help that could be needed.
 
Some notes:
THIS IS AN EXPERT THING. If you're not an expert, do not do this; do not come here later sobbing you made a mistake, or you will receive more insults that will make you cry even more 🫣 always always always test the ddrbin frequency change on a system booting from sdcard if there is a bootloader installed in eMMC, it has priority: changing the ddrbin on sdcard won't have any effect until you clean the eMMC (or the bootloader) some boards (notably X88 Pro) do not like ddr frequencies above 330MHz: they won't boot changing the ddrbin frequency of the bootloader in the eMMC is very dangerous! You may brick the board (only way out: maskrom via eMMC clock pin gating)  
ddrbin-switch-freq.sh

I guess there is no alternative download page, but you can download a nightly image following the link in first page

I confirm this 👍

The ddrbin is "packaged" by the u-boot command mkimage, then some other code (uboot SPL) is appended to the resultant binary.
 
In theory the ddr frequency is set in just a bunch of bytes in the ddrbin, so substituting the ddrbin (or altering the target bytes) on the sdcard/emmc with a bare "dd" command would work. But that requires some math and a hex editor to find the exact position where to put it with dd command AND I don't know if there are some CRC checks that would break the whole thing.
 
I need to investigate a bit about, surely it is a job for a script because manual intervention would be a bit risky.

@Slash402 Okay, so here it is.
I attach two "alternative" idbloaders, you can try both of them to see if something changes.
I strongly suggest you to do these tests on a sdcard rather than emmc. If something goes bad on the sdcard, swapping it is easy. If something goes bad on emmc, you will soft-brick the board and need to force it in maskrom mode (it is not pleasant task to do).
 
If you want to go the sdcard way, you will need to first erase the eMMC completely using the multitool, then just burn armbian on sdcard and boot the tvbox with the sdcard inserted.
 
The devices are:
sdcard = /dev/mmcblk0 emmc = /dev/mmcblk2  
To backup the existing idbloader:
dd if=/dev/mmcblkX of=idbloader.old bs=32k skip=1 count=4  
(change mmcblkX with the device you choose, so mmcblk0 if you choose the sdcard way, mmcblk2 if emmc)
 
To burn a new idbloader:
dd if=idbloader-333mhz-1.16.img of=/dev/mmcblkX bs=32k seek=1 conv=fdatasync  
(again, change mmcblkX accordingly as above).
 
then reboot and see if something changes.
You can also try idbloader-333mhz-alt.img idbloader using the same command.
 
 
idbloader-333mhz-1.16.img idbloader-333mhz-alt.img

You should not advise to buy shit, they are cheaper because:
* they are made of scrap parts, that often break after very short usage (see the emmc in the rk3318 thread)
* they have no kind of warranty
* the power supply is a joke, made of cheap components and very lousy - switching power supplies are one of the thing the more they weight the better; confront with a quality 5V/2A power supply and see the difference
* the HDMI cable is crap quality, often not capable to transfer CEC or collects any kind of interference at 1080p/4K
* the case is a bit of plastic, with little to no design for heat dissipation - right now I have a rk322x board here withing its case that reaches 97°C while simply installing a package with apt...
* many sorts of limitations to keep them as cheap as possible: no sd card UHS mode, no real shutdown/suspend, USB ports have limited power: be prepared to have headaches if you try to attach something that requires just a tiny bit more power like an external hard drive.
* wifi is a lottery and clearly tells you the general quality: you can find freshly made boards with wifi chips discontinued years ago!
 
Most of all: they have absolutely no software support; if you are able to run armbian on your tv boxes it is because some people within armbian and other projects spent their time for the fun of making it.
Tv box makers don't care at all, they just need to sell their cheap shit to make some profit. Some (not all) SBC makers at least in some way provide support, but tv box makers are mostly parasitic and should not be endorsed.
 
Now that you stated that about 20 pcs of different tv boxes run armbian, may I also ask you what you did in change for that for armbian? Because tv box makers obviously did nothing for armbian, still keeping up the servers infrastructure and the general maintenance cost real money to real people, and who pays that?

You should be following the instructions in this thread:
https://forum.armbian.com/topic/26978-csc-armbian-for-rk3318rk3328-tv-box-boards
 
And if you have any questions or issues you should post them there.

@some0ne I can't tell you why multitool does not find the eMMC anymore, could be several causes, but without the multitool log it is difficult.
 
A note about maskrom mode emmc clock pin, in case you are using or used that in the past: when the emmc clock pin is gated, emmc is de facto turned off.
 
If you are able to get in maskrom mode, then you can erase manually the eMCP connecting the board via male-to-male USB cable and using rkdeveloptool:
 
./rkdeveloptool db rk322x_loader_v1.10.238_256.bin Downloading bootloader succeeded. ./rkdeveloptool ef  
The loader file and other instructions are on first page.
 
However, at the moment I don't understand what you have on your eMCP, if Android boots, or is already empty or what?
Lastly, I don't know where your 60 seconds issue comes from. You should first clean the eMCP from anything on it and then boot pristine armbian from sdcard, then we may talk about that.

Hello, this quick tutorial is to introduce an experimental Debian and Ubuntu APT repository to install ffmpeg and mpv compiled with v4l2request and v4l2drmprime patches developed by Linux kernel, LIbreELEC and Kodi folks to allow hardware video decoding on stateless decoders like those implemented in Rockchip and Allwinner SoCs for h.264, h.265, vp8 and vp9 codecs.
 
The repository introduces a new package ffmpeg-v4l2request that integrates and substitues the base ffmpeg package and its related packages.
Also provides mpv 0.35.1 for Ubuntu Jammy, which has an overrall better support for hardware video decoders.
 
Preconditions:
Kernel should be 6.1 or more recent armhf or arm64 architecture Supported operating systems are Debian Bookworm and Ubuntu Jammy Rockchip and Allwinner have already been tested, but this should work on other platforms with stateless decoders supported in kernel  
APT REPOSITORY SETUP
To install the repository, just copy and paste the lines for your operating system in a terminal
 
For Debian Bookworm:
$ sudo wget http://apt.undo.it:7241/apt.undo.it.asc -O /etc/apt/trusted.gpg.d/apt.undo.it.asc $ echo "deb http://apt.undo.it:7241/debian bookworm main" | sudo tee /etc/apt/sources.list.d/apt.undo.it.list  
For Ubuntu Jammy:
$ sudo wget http://apt.undo.it:7241/apt.undo.it.asc -O /etc/apt/trusted.gpg.d/apt.undo.it.asc $ echo "deb http://apt.undo.it:7241/ubuntu jammy main" | sudo tee /etc/apt/sources.list.d/apt.undo.it.list  
INSTALL FFMPEG AND MPV PACKAGES
$ sudo apt update $ sudo apt install ffmpeg-v4l2request mpv  
SETUP MPV CONFIG FILE
$ sudo mkdir -p /etc/mpv $ echo -e "hwdec=drm\ndrm-drmprime-video-plane=primary\ndrm-draw-plane=overlay" | sudo tee /etc/mpv/mpv.conf  
You can now play your videos using mpv and they should run with hardware decoding if supported, either in virtual terminals or in X11/Wayland windows!
Enjoy!
 
Notes:
your mileage may vary a lot: the more recent is the kernel version, the better is support (you may need edge kernel) bug: when rendered in X11/Wayland window, video may show scattered tiles during frames bug: Lima driver (Mali 400/450) shows a red/pink tint when video is played in X11/Wayland (see https://github.com/mpv-player/mpv/issues/12968) (workaround below: https://forum.armbian.com/topic/32449-repository-for-v4l2request-hardware-video-decoding-rockchip-allwinner/?do=findComment&comment=177968) Panfrost driver should work flawlessy 10 bit HEVC are generally supported on all Rockchip devices (rk322x, rk3288, rk33x8, rk3399), but Allwinner H3 have no hardware support for that