SpellKilleR

@Jean-Francois Lessard Thanks for the quick reply. I had already tried to insert the parameter "tm16xx,transposed;" in the dtbo, but it is completely ignored. Even removing and reloading the module there are no changes, apparently the display starts again in normal mode tm16xx spi3.0: Display turned off tm16xx spi3.0: Display initialized successfully Maybe I should try to recompile the kernel forcing the transposed parameter active in the display module

Good morning everyone, sorry for bothering, I'm having some trouble trying to get the display of a TV box to work correctly. The model is an X98k with RK3528a, in which I integrated the tm16xx driver into the kernel. An AiP1628 chip is mounted on the board to control the display, which in the original Android dtb is managed as tm1628. The display is 7 segments with usb, card, am, pm, wifi and lan LEDs, 4 to the left and 2 to the right of the digits. By reworking the dtb a bit, the display is detected and turned on by the driver, but with some issues: of the entire grid the two LEDs in the last column never light up, as if they were not detected/counted in any way I try to rewrite the order and mapping of the digits and segments in the dtb, two segments always remain off in each digit when testing the display, when a specific segment should light up to find the mapping, several mixed segments light up instead, including part of the first LEDs. Continuing with the tool, at each step the same segments always light up instead of varying on other segments. Changing the values in the dtb changes the LEDs and segments that light up, but they behave in the same way. The module does not report any errors in the dmesg. Could it be a simple problem writing the dtb with missing compatibility parameters and mapping or could there be interfacing problems between controller and driver? If you might need some specific logs, overlays or other details, I'm available Thanks for any advice

Hi @jock, thanks a lot for the reply, you are very quick and very kind in helping. For the leds, I'll see as soon as I can start the blue card too. Both boards have a small display in front, which I was able to get working at the time by modifying the dtb, and a multicolor led bar above, which I never managed to get working. The two classic red and blue LEDs are present only on the green board and already worked with the original dtb on the old Armbian build. I shorted the serial pins on the blue board and was able to get some boot messages. The boot sequence stops very quickly on the first few steps, with two different sequences of errors alternating. The most frequent output: The least frequent, it only happened to me a couple of times: Both with the SD created yesterday with the standard compiler configuration resulting in a board freeze. The same memory always boots without any problem on the green board and also boots on another box I have which instead has a rk3328 (obviously without working peripherals there, only fot test). Compiling by setting the ddr blob to 333Mhz shows the exact same result with the exact same output on the serial port. Is it then normal that 666Mhz still appears written at start up in this case too or something is not working in the compiler / did I forget to change other settings?

Good evening everyone and thanks in advance for any help or advice you can give me. I have two RK3318 TV Boxes, officially they are model A95X R5, which have a different motherboard, but apparently identical in terms of components and the exact same Android firmware loaded on them. if can be useful here is the link to the original Android firmware loaded on these boards: Looking at the components, the only ones that apparently seem grossly different to me are the eMMC and the LAN controller. These are some pictures of the two boards: On both I still have the same old version of Armbian installed and perfectly running, compiled and adapted in 2021 on Buster distro kernel 4 (everything working apart from wifi and some specific leds), sharing the same dtb and the same system configuration and loading using the old uboot.img and trust.img method. Due to the need to start over with a more updated version of kernel and OS I tried to compile a more recent release based on current Bullseye kernel 5.15 and here the difficulties begin. On the first board (the green one), which I've always used for preliminary tests, no problem and I was able to start everything strictly necessary right away with just a few modifications to the dtb rk3318-box.dtb. On the second board (the blue one) I can't start any build I tried to compile. The box remains stucked with the screen off, without anything being loaded. If I re-flesh Android it works, if I try to boot from a SD / flash the old system works. I had no results neither trying booting from SD (with both eMMC erased and the old Armbian flashed) nor from the eMMC using the Multitool (I had to unbrick the memory at least a dozen of times till now). The biggest difficulty arises from the impossibility when it comes to check trough the serial port what is happening on the board during boot process, as the SMDs have not been set up on the blue model to make the port work. I know that with so little information it is not easy to investigate and understand the source of these issues, but would you have any idea what could be the cause of this strange behavior of the board? There is something I'm missing? Thanks in advance for any suggestions