dfahren

Yes of course, there is such a file '/boot/armbianEnv.txt', but it is generated on the fly by the Armbian build system and if you don't know this build system in and out, you are pretty easily lost ... You have to set specific environment variables and put the file mentioned in my post in a specific folder and then a valid and correct armbianEnv.txt will be generated by the build system. I'm thinking about how I manage to get this in the standard Armbian build. I don't want to mess with the complex build process only to do something that is very specific for my TV box.

@Jean-Francois Lessard Thanks for your revised version of your tm16xx driver. I downloaded it from your github repo and installed it in Armbian via a git patch. However, getting the configuration parameter into the driver was (at least for me) quite complicated and took me hours to resolve. But here comes what I found out: You proposed to configure the module parameter in extlinux.conf. Well, there is no such file in the Armbian kernel, or at least I could not find it. If that doesn't work, why not setting up a dedicated tm16xx.conf file in /etc/modprobe.d . I did that, but it has no effect. Once my Tv box boots up, it shows all 8s and all LEDs being on. May be this option works if you use insmod to install the driver, something I don't want to because I want the "boot" writing right at the start. I consulted the documentation of Armbian and found some sections about "armbianEnv.txt". A file in which you can define parameters being passed to the kernel and its modules. That sounds at least promising to me, so I tried to let the Armbian build system set it up for my TV box. Unfortunately, getting such a file accepted by the Armbian build system, which, to say the least, in its complexity IS NOT dumb man's friend .... is harder than one might think. Finally I arrived at a solution and what can I say, "boot" is displayed in the LED line dispaly at the same time the other LEDs of the board also light up. So this solution works. I attach the parameter file to this post. It has to go in the folder "userpatches/bootenv/rk35xx.txt" of the Armbian distribution. So IMHO what remains to do is to amend the patch @jock has published for the current 6.12. Armbian distribution to include the new version of the tm16xx driver from you, Jean-Francois. I thank both of you for being of great help to me. This H96MAXV56 gets better and better and may be one day all features of this TV box run smoothly satisfying everybody. rk35xx.txt

This also sounds like a good way if this sort of parameter can be read right at the start of the boot process.

@jock But the original tm16xx driver displays something! In fact all LEDs and all 8's are on. Do you consider this pheonomenon already a "user business". If so, why and if not, why not? Please explain. Moreover, I have the impression our discussion might go "philosophical" and I also fear different people understand different things when they use "separation". I think you both refer to SOLID, which can be read up on here: https://en.wikipedia.org/wiki/SOLID Unfortunately C is not C# or C++ so our possibilities are limited. I'd definitively go the route Jean-Francois suggested with the tm16xx.conf file, but whatever is displayed in the end, such a config file is processed too late. Unfortunately. What can I do? All the tv boxes I know display 'boot' or some "dancing segments" or something crazy like that. I'd rather have a simple text being displayed right at the start of the box. Nothing more nothing less. I think we agree that the functionality to display something on a line display is one thing and the "what" is the other (aka configuration). So it makes sense to delegate the "what" to a different file, for example, a suggestion I outlined above. To cut this story short I try, like I mentioned at the outset, to create some sort of a "c overlay" activated by a CONFIG switch to enable the "boot" display, I think this the route with the least complaints, right?

@Jean-Francois Lessard Yes, yes, you are so right, one can write this tm16xx.conf file as you state and 'boot' or whatever text will show in the line display. All well and good. My point, however, is that if you configured a text like this, you would see it much later than the red LEDs start to blink with heartbeat rate, but at that point in time the boot process is ongoing for quite a while (usually 2 to 3 seconds). I want to display 'boot' right at the start of the cpu and that means once the driver (which must be built-in, not a .ko) initializes has to set up the LEDs to display 'boot', which it does in my code. But I think you wanted to put forward a different point ... maybe ... You don't want your code edited by some random guy from the Internet. It is already merged in Armbian code (by Paolo), seems to work and there is from your point of view no need to amend it, right? Let me check this out: Maybe I can override the function with my code in a different file (perhaps like in C++) and activate it with a CONFIG switch. I think this should be fine with you, right? The second point I mentioned earlier was, that I can make this writing "boot" configurable in the dts. Maybe I also pursue this idea, don't know right now. Everything is a question of time and inclination, right? @watou Your kernel is fine, your version is my version. Could be that your dts doesn't contain necessary definitions pertaining to the LED line display. Please check my dts file attached to the post above. When you issue "modprobe -a tm16xx", please post the last lines of "sudo dmesg" output, then we can see what goes wrong.

@jock Yes indeed, the driver written bei Jean-Francois is already integrated in Armbian by your patch, I know. Yes it works with the correct dts all is good. I struggled quite a bit until I arrived at the solution outlined in my last posting and I also wanted to have the writing 'boot' to show up right at the get-go in the LED line display. So I had to amend his driver a bit. One additional thing I could do to the driver is making the writing configurable in the dts, so that you only have to edit the text to show some other writing once the tv box boots up. This might be pretty easy, now I'm looking for some spare time ....

@Jean-Francois Lessard You won't believe it, but I found my error(s) .... For the solution I had to look at the dts Paolo (https://github.com/paolosabatino/leds-fd6551) suggested in his code. I missed a line that effectively makes SDA really open-drain. However, pinctrl is not relevant in this context. The fist line is bloody important, the second not so: i2c-gpio,sda-output-only; i2c-gpio,scl-output-only; Although they do incur warnings in the kernel log, they are indispensable because without them, i2c signals don't reach the fd6551 controller. Now everything works as expected. It shows (in fact, it showed ...) 88:88 right at the start and after that the actual time. Great! I'm going to write a pull request for Nicolas' Github repo so that he can integrate it with the Armbian distribution. I also edited your tm16xx source code to show 'boot' instead of 88:88, which is not my cup of tea. You also have to make sure you compile the driver als built-in and not as a kernel object. So you get the 'boot' writing roughly around second 2.8 in the boot process when plugging in the mains adapter and this is early enough for me. I attach all of the sources to this post. I hope you don't mind too much that I messed with your code and I apologize upfront. Best wishes, Deetsh tm16xx_boot.c display-client-snippet.dts

@Jean-Francois Lessard Thanks for your comprehensive answers. They helped me a lot, but as ill luck would have it, new questions arose ... As far as I can tell, the driver is loaded at second 2.7, which is perfectly early enough for me. Once the driver is ready to operate 8888 should be visible. Well, should .. I managed to get it running once and then I changed the config or the board dts or whatever and I never reached this state again, what a sh*t! May be you can spot any error in the dts, but I have the feeling that the error lurks somewhere else. You are so right, one can comment accurately on my questions if there is no dts you can look at. This time I attach my full dts to this post, promised. BTW, like I said before, I have an H96 Max V56, which has an FD6551 on the board. So there is no confusion. Rest assured, brightness is behaving as expected but is waaay to dark for me. If only those leds had white color ... Well I have made the led display "brighter" in a rather unconventional way -> I used a saw and sawed out a little rectangle from the front. Maybe my tv box doesn't look as pleasing as before, but the led display is much brighter now. Form follows function , ya know?! 🤣 Since the led display did work once, I think both SDA and SCL are configured correctly. i2c-6 is, in fact, the i2c node the kernel assigned to the tm16xx driver. When my tv box starts, somewhere in the kernel log I get i2c-gpio display-client: using lines 12 (SDA) and 11 (SCL) ... tm16xx 6-0024: Failed to set brightness: -6 tm16xx 6-0024: Failed to initialize display: -6 (-6 is ENXIO -> no device) The driver simply is unable to talk to the chip and I really don't know why. BTW my kernel has version 6.12.12 and the tm16xx is not built in but is a .ko Understood, I tried them and they worked, but thanks for the explanation (I found them earlier on your Github pages.) Yep, later. Led display isn't working right now ... 🙂 I have the feeling that using pinctrl would necessitate a "slight" rewrite of your driver and at the moment my inclination to go down this rabbit hole is, well, limited... But the question is,if there is a pinctrl definition regarding these two GPIO lines, will this definition interfere with the definition of the gpio lines in the display-client section? When using pinctrl I couldn't find any way to set the baud rate used for the communication. Is it unnecessary or is there some sort of auto-negotiation? So if you have any idea how I can arrive at a working led display again, please(!) let me know. Currently I'm at my wits end. All the best, Deetsh P.S.: oh, there is one thing I need to ask you: Do you know a way to make testing new versions of the dts easier than building an image and downloading in the emmc? myboard.dts

@Jean-Francois Lessard: First of all, thanks for your very nice tm16xx driver. I'm using it with my rather new TV box H96 Max V56. I finally managed to get all leds light up during boot. I don't use an overlay like in your source code but an amended dts file. So far so good. Now a couple of questions arose which I hope you can answer I noticed that the heartbeat led starts flashing way earlier than the lights of the blue front display. Is there a way to get this tm16xx driver starting up much earlier in the boot process? The display is rather dull. Is that normal? cat /sys/class/leds/display/brightness says 8 May be we can change the dts file a bit so that the leds get more amps, is that possible? Kernel messages have the following lines which bother me. Do they point to a problem later on? i2c i2c-6: Not I2C compliant: can't read SDA Jan 31 17:42:03 h96-tvbox-3566 kernel: i2c i2c-6: Not I2C compliant: can't read SCL Jan 31 17:42:03 h96-tvbox-3566 kernel: i2c i2c-6: Bus may be unreliable The most annoying problem though is that I can't do didi@h96-tvbox-3566:~$ sudo echo 1 >/sys/class/leds/display::wlan/link bash: /sys/class/leds/display::wlan/link: Keine Berechtigung which means even as root I don't have permission to change an led from off to on (this is merely an example. All single leds and the 7-segments can't be switched on or off) What might cause this problem? Finally the topmost segment is on when in fact the bottommost segment is supposed to. So there is a mapping problem. By the way I took the overlay dts from your repo. Maybe I can tweak the mapping but I don't know how. Oh, there comes another one to my mind: Do we need pinctrl in dts or will it cause troubles down the road? Your help is highly appreciated! All the best and Cheers, Deetsh

@Hqnicolas: Thanks for the invitation! I have the impression, you overestimate my capabilities to participate in this project. NPU, for example, I'm completely blank, have no idea what it is about. May be I'm able to integrate this particular OpenVFD driver in the kernel, but that is something for the (hopefully not so distant) future. Panfrost, rkvdec and so on is for the DEVs with high stakes and - without any doubt - boat loads of time, which, very unfortunately, have not ... 😞 I'll get back to this forum once I have good news to share (or questions to ask). Till then: all the best to everybody!

@Hqnicolas I submitted a PR for you to review. Notice that it is somewhat fragmented and may not be mergable right away. I hope you can integrate it with your repo. Feel free to get back to me if you have questions or want amendments or the like ... 🙂 Best wishes, Deetsh

@Hqnicolas Thanks! Yes and yes. 😀 I'd like to have others test this u-boot, too, if you don't mind. In due time, you will get a PR for your repo and may include it in Armbian. However, I think it is too special for inclusion right into Armbian source code, but you can decide once you looked at the PR.

Hi folks, my pondering about whether or not it is sensible to boot into LOADER mode once you press the recovery button has reached a conclusion. I decided that entering LOADER mode is a silly idea because flashing an Armbian.img file always starts at sector 0x00 of the emmc chip. In LOADER mode flashing is allowed at address 0x2000 only so we can't flash Armbian or other IMGs. So if you press the recovery button, the board resets and enters BROM mode. After that you can use either "rkdeveloptool" (Linux) or "rkdevtool.exe" (Windows, version should be greater that 2.85, mine is 3.19). As an attachment you can find my freshly created u-boot.bin file for you to test. But hold on for a second, I have to tell you a couple of things so that you don't feel miserable after you did things whose implications you couldn't fully grasp. This new image is a conglomerate of u-boot, spl, and atf, no optee. It is based on u-boot tag 2025.01 and is applicable to kernel 6.12.10 (maybe it works for others, too -> please tell me.) It uses the rockchip blob for DDR chip training and configuration that was created for RK3568 chips by Rockchip themselves, the last frequence selected is 1536MHz, which seems to be ok for our SK hynix LPDDR4 chips that operate with 3733Mbps. --- DISCLAIMER --- In what follows, everything you are doing on your on risk! I will not be held accountable for any damage, lost time, broken plates, dead tv boxes whatsoever and other misery that may or might result from you doing the next steps mentioned below. Keep that in mind! Now you are on your own. I strongly encourage you to attach a serial converter UART-to-USB to the board so that you can see all the statements u-boot is going to output. This is especially important if something goes wrong. Most likely your tv box won't run your Armbian installation after completing the flashing procedure! Be aware of that. You may, however, press the recovery button on your board and restart it with a USB-A cable plugged in on both ends and enter MASKROM mode. Flashing procedure Unpack the archive that is attached to this post (e.g. "xz -d <archive name>") and store it for later use. Insert a USB-A-to-USB-A cable in your tv box. Short the pins CLK and GND on your board and insert the other side of the cable into a free slot of your pc. If you don't know where to find the pins on the board, please don't flash this u-boot and read this thread thoroughly. These operations here are not for novices! Open a shell (I prefer Linux, but you can do the same in Windows) and type "rkdeveloptool ld" (or doubleclick on "rkdevtool.exe" in Windows) You should see something like this "DevNo=1 Vid=0x2207,Pid=0x350a,LocationID=101 Maskrom". If not, repeat step 2 again until you can see the output. In Windows you would see something like "MASKROM device found". Find yourself a loader bin, this thread has one for 4gb and one for 8gb. We select the one for 8gb whose name is "H96-MAX-8gb-MiniLoaderAll.bin" but you equally well take the other one, it really doesn't matter. Issue the command "rkdeveloptool db H96-MAX-8gb-MiniLoaderAll.bin". After a short while you should get a success message Next issue the command "rkdeveloptool wl 64 <path-to-your-bin-file>/u-boot-2025-01-rockchip-6.12.10.bin", where <path-to...> is a placeholder you substitute with what it states, right? You should also get a success message. Unplug the USB cable and attach the UART-to-USB converter to your pc for reading serial console output. Notice, if you have a CP2102-based converter, you can't use it with standard drivers in Linux! Well, of course you can, but you would see garbled output only.) Power on your tv box and read the output on the serial console. If everything goes well, your Armbian should boot. Shutdown Armbian, power off your device. Press and keep pressed the recovery button, start your tv box by plugging the USB-A cable in both tv box and PC, read the output of the serial console. Once you see "resetting..." you can issue the command in step 4 to check that in fact you tv box is in MASKROM mode now. That's it, I hope this is useful for you and again: Please don't do this procedure, although it seems easy to follow, if you need a working tv box. Most likely you are going to brick it! Cheers! P.S.: Please post here and tell me your results, especially in case you are unable to enter MASKROM mode. Thanks! u-boot-2025-01-rockchip-6.12.10.bin.xz

@Hqnicolas: Very good finding, this is the location where one should investigate further ... which I did. This litte posting is to let you all know that I was able to tweak u-boot so that when pressing the recovery button our tv box enters (at least for now) MASKROM mode. Stay tuned for an advanced u-boot.bin for you to test! So in the future we no longer need soldered wires to short the test points, which, at least in my opinion, is a good step forward. I'm still in the test phase of my amendments to u-boot and I'm still unable to enter LOADER mode, but I hope I'm able to solve this (hopefully little) issue, too. Until then, cheers and I'll keep you posted.

@Hqnicolas That means before May 2024 (the time the source code has been tagged) pressing the reset button on our board makes Uboot go into LOADER mode, correct? After that commit, it won't show this behavior anymore. If it were a fault in the dtb/dts files, it would be easy to spot the changes in your source code, but I think your DTS file hasn't changed since then at least not with respect to the reset button. So it must be a source code change, presumably in the Uboot source. Can you give me a pointer to the source code where I can take a look and check if there is something I can revert so that we get this reset-and-boot-in-LOADER functionality back. My small pads CLK and GND start to get worn out ... Ouch! @paradigman I spotted errors in my build (e.g. used a 6.6 config for 6.12. and other mishaps), so I'd rather build again and upload later. Thanks for the hint at Cinnamon, will give it a spin!