jock

It won't work, openvfd is another driver and wants things a different way. Not to blame the author, but unfortunately openvfd is badly designed. tm16xx driver instead is very well designed, and is the way to go. 👌

The first thing that pops in my mind is that if the dtb for a board has been introduced with a naming convention (whatever it is), if you change the naming convention, it will mostly break the user installations when they upgrade the kernel/dtbs.

@ROOD what do you mean unavailable? I just downloaded a copy of it is perfectly readable

@ROOD see the first page and the paragraph "Special hardware"

Normally it should work this way: armbian bootloader (u-boot) priority was first to sdcard, then USB stick, and finally eMMC. Recently (months ago) I bumped to a newer version of u-boot and there was some people reporting that the priority somehow changed, but I had no time to check it by myself; so take that with a grain of salt.

@ROOD ok that's fine, yes default credentials are root:1234 You probably may go burning on eMMC, surely it won't brick and you should be able to run multitool or armbian on sdcard to handle maintenance if you need; I would anyway first configure the board with rk3318-config script and, when you found an optimized and stable setup, then burn on eMMC and replicate the setup

@ROOD good Important premise: when you short the pads you're actually excluding the eMMC from boot, so the SoC will boot from sdcard and, if there is no sdcard, then will go in maskrom waiting for something. Hence you have different options: burn the multitool on sdcard, then insert the sdcard and turn on the board with pads shorted. The multitool should boot and then you can erase the eMMC burn a good image (use the @otus links) onto the SDCard and boot (with pads shorted) Armbian from sdcard. Once booted, then erase the eMMC with dd (first 4 megabytes will sufficed) or with blkdiscard upload a loader with RkDevTool (or rkdeveloptool from Linux, without uploading a loader you won't be able to do anything; you should be able to find it in first page or somewhere in this thread, can't remember...), then erase the eMMC The first option seems the easiest to me. Once you erase the eMMC, the board will boot from sdcard and you can test a valid Armbian image. Obviously burn an image onto eMMC only when you're sure it boots from sdcard. You can get access to the TTL serial uart from the three aligned pins that lay between the LCD display and the USB 3.0 port, if you have a serial adapter of course. Also, don't trust too much the eMMC: these particular boards were affected by bad eMMC/soldering iron that often caused it to fail.

@Ian Goodacre yes I confirm you broke the dtb, and for that reason u-boot does not take the kernel from sdcard anymore, then tries other boot options (USB, PXE). You should recover the device tree to let linux boot again. Funnily enough, u-boot is able to pick up an IP address from DHCP 😅 This is the merge request where I fixed the Gigabit LAN port on RockPi-E, I understand that you already read about the merge request, perhaps the problem is similar to yours. BTW, the phy chip should be automatically recognized by the kernel code because each chip exposes some ID that can be picked up by the driver, so you should not worry about. If you still have issues, post the link returned by armbianmonitor -u or at least the dmesg log.

@ROOD your board (YX_RK3328) should be already supported by rk3318-box image. The "marketing name" of the TV Box means nothing, the only important discriminant is the board name printed on the PCB. Anyway you made two mistakes: took the image from an unkown source burnt a non-working image in eMMC Now your only chance to restore board functionality is to go in maskrom mode: eMMC is always first priority, so you don't have any chance to boot from SDcard if a image that does not boot is stored in eMMC.

Not to hijack the thread, but there is a much better alternative driver rather than OpenVFD, you can take a look here

Well, not really. SOLID does not apply just to object oriented languages like C# or C++. They are principles, so by definition they always apply. Also note that the linux kernel is written in C (a non object oriented language) but most of the Linux kernel is indeed object oriented. It's a common mistake to think that OO software can be written with OO languages, but it is absolutely not true. OO languages makes easier and safer to handle OO principles, but you can apply the same OO principles even with C language. Getting back from philosophycal, I also agree that a module parameter is the right choice to fulfill what you need and keep the separation of concerns. Perhaps you may also go with an udev rule. I was wondering though if you want the led panel to show the string at the very power up of the board because you mentioned the stock firmware. In that case (the stock firmware) the boot loader (u-boot) is turning on the led panel chip and instructing it to show the boot string (via a driver, or even just tinkering directly with the I²C bus). Later the kernel boots and loads its own driver, and then changes the boot string with the clock or with the moving segments or whatever...

I would say, and I bet @Jean-Francois Lessard agrees, that is not a matter of "messing with my code" thing, but rather a matter of principles. A kernel module is supposed to do a kernel module or, In simple words, it interfaces the kernel with the hardware. The kernel means are to give the userspace a way to access the hardware. The module should not run any user business (eg: display something user-specific at boot/shutdown/whatever), but should in turn provide a service for the userspace to control the hardware. That's a simple principle in software engineering that's called "separation of responsibility", and is generally considered a good habit to agree with that principle. By the way, if your board has one or more colored leds, they are generally set up in the device tree and access basic GPIO system, so they are turned on as soon as the kernel starts.

@dfahren tm16xx driver from @Jean-Francois Lessard is already integrated in the armbian rockchip64 family patches, this is a typical device tree overlay configuration you can take as an example that is, by the way, basically similar to my (discontinued) driver

@paradigman try looking here for latest rockchip64 kernel headers, but I'm not sure the version will match. Usually I install the kernel headers via regular apt, so don't know if armbian-config is ok or is broken.

@Constantin Gatej added on first page, thanks!