jock

@Vidhome drop the openvfd driver, recent armbian kernel have the tm16xx driver from @Jean-Francois Lessard already compiled in for rockchip64. You have to enable the beta repository, upgrade and everything should be already set up for X88 Pro 10: https://forum.armbian.com/topic/26978-csc-armbian-for-rk3318rk3328-tv-box-boards/?do=findComment&comment=203491 Don't forget to take a backup of your installation before enabling beta repository. Otherwise, you could compile the tm16xx driver it by yourself: https://forum.armbian.com/topic/43667-help-wanted-to-test-a-new-openvfd-alternative/?do=findComment&comment=202875

Actually the main trigger for bootloading is the miniloader, which leads to boot from sdcard or emmc depending on what it finds in sdcard. If there is a proper signature in some expected addresses, it will load u-boot and trust OS from sdcard, otherwise goes with emmc. Also it will check for GPT partition table searching for the address hints where to find uboot and trust os. Actually you should not need to supply a trust os: uboot (called the "loader) should suffice for the rockchip miniloader. Anyway, the main idea is to wipe all the proprietary blobs and keep the bare minimum to do the job. Currently, despite u-boot is capable of initializing DDRs on rk3328, the rockchip ddrbin is kept proprietary for broader DDR compatibility among the boards, the rest is fully open source. The proprietary trust OS would also allow DDR frequency scaling, but it is doing nasty things and crashes the SoC when you run it faster than 1.1GHz. Dual boot may be interesting, but at the moment I won't merge that unless there are very important advantages.

About the service and driver issues, you could post in the post of the author about the kernel module: I'm glad you tested also the indivual leds and they work; I will integrate those into the RK3318_V1.4 device tree overlay

@MattWestB I decided not to provide the service scripts yet because they provide different functionality and can be installed or altered manually by any user. Also not all the boards have the front display. The driver, clearly, is a different beast and is easier to be shipped within the kernel package. As you can see, the services can be downloaded from the github repository and installed manually or, if you like, you can package them into a .deb and I will be happy to host it on users.armbian.com By the way, the driver requires a device tree node, you can't just modprobe it into and expect it works. You have to select the right device tree overlay with rk3318-config and some leds (LAN, for example) will be autoconfigured as well. About the "command package", route is deprecated, you should use ip route instead thanks for reporting the digits order and segments order; individual leds can be accessed within /sys/class/leds as well

@MattWestB led-conf7 does not exist on rk3318 build, it is just up to led-conf5 I introduced very recently; your board should fit into the base device tree. Anyway, if you'd like to test the new tm16xx driver (which include support for fd6551 and several other led driver chips) you'd need to switch to the armbian beta repository, but beware of the dragons ahead! So take a full backup first! You can switch to beta repository in armbian-config or by changing apt.armbian.com to beta.armbian.com in /etc/apt/sources.list.d/armbian.list Then run apt update and upgrade at least the kernel, dtb and armbian-bsp-cli-rk3318 packages, then reboot, run rk3318-config and (for your specific case) you should be able to test the fd6551 driver with led-conf5 (YX_RK3318 board) Now that you are confirming me that RK3318_V1.4 also have a display panel and the fd6551, I can update your board device tree too. Notice that it should be handy to know if leds and segmentes are displaying correctly. You can make reference to the original driver https://github.com/jefflessard/tm16xx-display on how to configure and tweak the driver for your specific board. Everything which is there applies as-is. The same applies for other people with X88 and YX_RK3318 boards: there the led-conf that applies to their board should be already working out-of-the box!

In the meantime I integrated the driver into armbian for rockchip64 targets: https://github.com/armbian/build/pull/7338 , so it will be a bit easier to test it out-of-the box and it would also be easier for amlogic people to copy-paste the driver patch and integrate the device trees as well. My tests on hk1 rk3318 tv box (board silkscreen YX_RK3318) worked like a charm and the display is now pleasantly showing up-to-date date and time

@rampagepi indeed it works adding to the command line, but you did the bad way: on next uboot update the boot.scr will be overwritten. You need to add to extraargs in armbianEnv.txt to avoid being overwritten About the DE: you are changing the console framebuffer video resolution. Once in a graphical environment, you should tell that you want a different resolution its own way. Another way could be to supply an alternative EDID to the kernel to simulate the use of another monitor

@striga esp8089 module is already available in the armbian kernel releases. Proof is that if you run sudo modinfo esp8089 you get the module info. About the hdmi initial output, you should mention what board you have, and perhaps run rk322x-config to setup your board peculiarities

uhm no, as the last line it should have no effets; it may have an effect if you append to extraargs= line, or create such a line for that: extraargs=video=HDMI... here there is a comprehensive documentation: https://github.com/torvalds/linux/blob/master/Documentation/fb/modedb.rst

Hello @Jean-Francois Lessard, congratulations for the excellent driver! I stumbled here because I started making myself an fd6551 driver , and just after I discovered you already published a fully working product, which is way more polished than mine. Anyway, I did not have yet the chance to tm16xx driver, but will do soon and report here the result. I have a HK1 box with rk3318 and fd6551 chip on board.

@Netraam31 thanks for checking ,but actually no, your chip is not compatibile. Anyway my driver is just born and dead too, tm16xx is a much better alternative (and supports your chip too) I will integrate it into armbian sooner or later.

@hexdump Ah, no I wasn't! It looks like I reinvented the wheel 😅 And that kernel driver is written very well with broader support too.

@Netraam31 well, first of all it would be useful to share the board name you got and the led driver chip you have. perhaps I already got the dts and so you don't need to extract it. To extract it, the procedure is totally manual, I use a hex editor for that, so if you have no clue on how to do it never mind.

Hello, I am working on an alternative fd6551 and clones led driver for our tv boxes front displays. It is getting up in very good shape, but requires some tuning up; I would like to ask anyone who owns a box with a front led panel and is interested to report the board name, the display chip (common chips are fd6551, fd650, tm1650, etc...) and the original stock dts if possibile. It would make things easier to support already existing boards. Thank you! edit: for source code and reference: https://github.com/paolosabatino/leds-fd6551

@Perry S thread for rk3288 tv boxes was not too far away. Try this:

Sorry but this is the wrong place to ask about that; no Android or custom setups here, just armbian.

You'd better ask directly to Radxa for that, they probably know better the specs of their boards. I would take the power for disks from the PSU anyway if possible to avoid unnecessary stress to the board: I guess the SATA power pins on the board are there for those who wants to feed the board with 12V barrell connector, but if you got a fully-fledged ATX PSU, go with the classic power connection.

No hardware issue, the problem is rather finding the material time to do the task!

Mmmh 82°C seems rather low threshold to me. If you repeat the compilation and it hangs at the same temperature? Lowering the threshold to 82°C means that it should start throttling big cores around 75°C, throttle the rest at 78°C and reboot at 80/81°C

There is no grub in armbian. Try multitool or reinstall armbian.

I really don't understand where is the problem. You claim you cannot login, but root and 1234 are the default username and password, and those have always been for ages. You claim you cannot enter maskrom, but you should be perfectly able to boot from sdcard/USB either another armbian image or multitool to do maintenance or erase the eMMC and get back maskrom mode

It could also be some broken welding among the small SMD components. You may try with a hot air gun.

@pakos96 sorry 😔 , can't say exactly what version the server has built and when it did so... the patch is in mainline kernel armbian for more than one month now, 6.6.41 seems a bit old.

I'm not used to rkdevtool for windows, but indeed if the board does not get past the ddrbin, any tool won't work. The first thing the utilities do is upload a small binary (which contains the ddrbin as well) to initialize the board. The binary/executable then has the service functions that are invoked by the GUI utility when you click the button. You should be able to read the serial log while rkdevtool uploads the binary and tries to initialize the board, but this will probably give you the same errors you already know. The problem is that if you don't have the original firmware and nothing changes switching from 2T to 1T, there is nothing more you can do other than randomly trying firmwares, with the doubt your eMCP chip is even broken.

@Nixie do you have some logging on the serial? BTW, once you're in maskrom mode, you can wipe the internal flash with rkdeveloptool and do test and tricks on a sdcard with armbian/multitool on it, without the hassle of triggering the maskrom mode each time