jock

5v, no less no more. Anything else will probably destroy the board. Unfortunately I don't think you can do anything with maskrom mode; I don't have such a board so I absolutely don't know what is going on with that particular board. All we can do is guessing 🤷‍♂️ rkdeveloptool via maskrom mode if you have a full-image backup, or AndroidTool and the upgrade images for your board you can find on the internet. You have to find the right one though, which can be a time consuming task. Well, tvboxes are not really serious things. If you really need the board to do something minimally serious, it is better to go with a proper SBC and even better a proper SBC officially supported by armbian. if you want to toy around, tvboxes can be funny but beware they are often assembled with scrap parts stick together with hacks, especially the cheapest ones, and supporting them is quite painful.

@Scmel actually it is neither armbian nor homeassistant problem. I mean, armbian community does not have to tell you how to install homeassistant, and homeassistant does not have to tell you how to install it on every platform available on the planet. You have to find the way through, as I said I installed the core version successfully following the instructions on the homeassistant site and it was sufficient to me.

@Scmel Honestly, you should ask on homeassistant forums perhaps, or read the documentation. I have an instance of homeassistant core installed on a rk322x box and works fine, but you have to install it manually by yourself. The other versions may require virtualization or other unsupported/unavailable features.

Hello @guitoscan , two possible issues come up to my mind right now: 1. the system is unstable because some of some wrong cpu/memory setting (voltage too low, frequency too high, things like that) 2. the trust os is doing something bad, and since it is closed source, we could never know what it is doing. To handle the former issue, you can try adding cpu-stability overlay in /boot/armbianEnv.txt adding a line like this: overlays=cpu-stability beware that running rk322x-config will overwrite the overlays line, so you will have to append cpu-stability to the other overlays if you run rk322x-config The latter issue can't be solved easily right now 😕

Yes, then the red and blue leds are alternative and cannot be controlled independently. It is very common. For making them blink on "disk" operations, for which I intend sdcard/emmc IO, you have to echo the right mmc device (mmc0, mmc1 or mmc2 - depending on what you want) to trigger.

@pakos96 https://linuxreviews.org/HOWTO_Control_LED_Lights, in particular the paragraph "Inspecting Your LED Lights" Note that, depending on the board, red and blue leds can be controlled independently or are mutually exclusive (ie: "on" state turns red led on, "off" state turns blue led on)

@spinning banner Yes, it should work that way (except your board has some more other flaws which I'm not aware about...)

@spinning banner Hello! Unfortunately R29 boards seem to have a widely well-known issue with HDMI output, which is not working for some unknown reason. Some research has already been done in the past on device trees, inspecting photos and logs, but still the problem is unknown, as long as I don't have such a board in my lab to really study where the problems are. The S9012P wifi chip also is a no-name chip, as long as I remember it is a chinese chip with no known drivers that "emulates" a realtek chip (not a broadcom one, like those which AP6xxx are based upon), but I can be wrong. @RaptorSDS did some research on that chip, but as far as I know, there is no solution because there is no driver for that (see https://forum.armbian.com/topic/12656-csc-armbian-for-rk322x-tv-boxes/page/57/#comment-156548) R29 is a quite weird board actually; despite being very similar to others, has some compatibility issues all-around and it does not surprise me the multitool has troubles with emmc, although it should have none. From the android dmesg I see on android the eMMC runs at 31.25 MHz; Multitool runs it at standard 50 MHz, and that may be the cause of the flash storage issues on multitool. The reason could be a very poor quality board or eMMC, because ALL the boards with eMMC I have ever seen runs the eMMC at 50Mhz perfectly fine and I never had to downclock the eMMC frequency to solve an issue like that.

@olivluca well, it is not totally a stupid idea, but consider that tv boxes are mostly just-for-fun kind of product; I would rather go with a properly supported SBC, or at least a community supported SBC. For example, today I test a Radxa Pi-e board (very small, one gigabit eth, one fast eth, 802.11ac/b/g/n wifi) that turned out being a very impressive throughput of > 100mbps on a 300mbps 802.11n 2.4ghz link, and the access point was one floor above! SImilar results came from an Orange Pi 4 LTS; the tv boxes I tried couldn't reach such bitrate and one of them which had the ssv6051 wifi on board was not even working right. I never tried RaspAp, but looks very good if it does what it promises. But if you want something reliable, go with an SBC + armbian, otherwise find an access point that supports openwrt.

There is no prebuilt image of that kind on purpose: whenever you do an update of the kernel/uboot, it will break the system and it won't boot anymore.

@Anthony Walter The Mali-400 GPU is supported out of the box with recent kernel and distributions. There is already a driver in the kernel, but (I guess) it has to be properly set up in the device tree and in userspace for your particular board. Since your board is not maintained by anyone, support is community based. If someone step out for help good, otherwise you have to do it yourself.

@http418 Still, the necessity of the boot logs are sine-qua-non condition to understand why the board does not boot, otherwise anyone can't be of any help here. To get the boot logs you need the serial adapter and to find the serial pads/pins on your board. Possibly they are below the heatsink, but I have no such board so I don't know. About your board, an R29, the HDMI port is reported to not work and I can't fix that, because - again - I have no such board. Did you try to access via SSH to the board after 5 minutes it booted to see if is working or not?

@sermayoral if you search through this thread, you will see that box vendors are often altering the specs on purpose to fraud people, other time they are just coarse.

@http418 If you don't provide any logs, photos, description of the issue (you were talking about the loader before, now you talk about armbian dtb...) you will be banging the head for yet long time...

Nope, the cpu is 32 bits.

This is not for rk3188, but for rk3318. And no, you have to handcraft yourself the device tree for that or use the existing overlays to overclock the thing

Try this other bootloader: RK322XMiniLoaderAll_V2.51_spectek_en_ddr2_rd_odt_180703.bin Very useful tool to know what is going on. I suggest you to buy one or two or them.

@primoitt perhaps you should consult first page on "Multimedia" paragraph. The way to go on mainline kernel is, as suggested by @fabiobassa, use ffmpeg, but AFAIK you still have to patch it manually with some libreelec patches to let it work.

@mikes123 Actually I don't know what is going on with your wifi: the chip is detected regularly and the firmware is correctly uploaded. If you tried swapping the nvram as suggested and still does not work, honestly I don't know what else can be. Perhaps you could extract the firmware and nvram from your original firmware and try them.

@Ethanol6 Then I need the detailed UART serial output to help you with diagnostics, if the image boots from sdcard but not from emmc there is something going on.

@immS Since you have an X88 Pro board, try also to run again rk3318-config: your board has a particular different and rk3318-config should have told you to run the script again after reboot to let it autodetect the wifi and apply the necessary device tree overlays.

Well I stopped building and actively supporting the legacy image. The only missing thing is the NAND driver, for all other uses mainline kernel should be better.

@mikes123 run again rk3318-config, select again led-conf2 and then reboot again. It should appear wlan-ap6334 in overlays line in armbianEnv.txt

The question is absolutely relevant and very welcome. The answer is quite simple although: for historic reasons, those overlays are called led-conf but actually, during time and studies on the boards, they should be more properly called gpio configs or board configs: they deal with the peculiarities of the specific boards and integrate the "base" device tree. The led-conf dtbs overlays don't necessarily carry the information about the wlan chip: the boards are designed to host several different wifi chips and the wifi chips are in turn designed to be "drop in replaceable". Wifi chips exchange data with the SoC via SDIO bus, but also have other pins for other essential purposes (power, reference clock, antennas, etc...). One of these pins is the enable pin. The enable pin turn on and off the wifi chip. It is like a button, which is in turn connected to a SoC GPIO pin that can be controlled by the software: the linux kernel can turn on and off this pin which will turn on and off the wifi chip. The problem is very simple: most boards use the same SoC GPIO pin to control the enable pin of the chip, but some others use another one, or swap its polarity. You need to tell the kernel which GPIO pin is the right one, otherwise the kernel just can't turn the wifi chip on and, in fact, the wlan0 device does not even appear to the system. The GPIO pin for this functionality is specific to the board design, hence it is described in the led-conf overlay. As an example, the boards with T066 marking needs such treatment (led-conf4, see here), but also other boards require it (I count at least three different configurations in those overlays, plus the base one). Using the right led-conf is usually enough to get the wireless appear and work, because the kernel can turn on the wifi chip, poke the SDIO bus for the device id and load the right driver. In some other cases, there is the need for a supplementary dtb overlay to get full functionality for the wifi chip: rtl8723cs/rtl8703bs is right the case to get also the bluetooth working, because it requires some other bits for complete configuration. Normally the rk322x-config script deal with this automatically. You may need to run it a second time after reboot to complete the configuration though, in case in the first run it was unable to detect the wifi/bluetooth chip.

@Tiago Barsan rtl8703bs uses the 8723cs driver, which is already included in regular armbian images. Perhaps you need to select the right led-conf from rk322x-config script for your board, which is unknown because you didn't wrote and didn't post photos of it.