A cordial request for help: DTB for MIPI display on SOM-RK3399

[cu6apum]

Hi there.

More than a year ago i started a project on this CPU and mainly succeeded with Nanopc-T4 board, old Armbian (5.95/4.4.179) and a custom DTB. The hardware project included the SBC and a Chinese TFT dashboard-style display panel (thus - MIPI/DSI, as I could not find the same for LVDS).

Mainly using the poke-and-peek method I collected the way to mod the DTS so the DSI port is active, and the display worked like a charm. Mostly I pasted the DSI part from OrangePi DTS.

I must admit that that turned out to be pure luck. Because once I moved (after big pause) to the SOM and self-designed carrier board (identical in USB, SSD, MMC, video section to FriendlyElec's carrier PCB) the image refused to boot, so does it on original SOM-RK3399 dev board. Simply "Loading the kernel..." and then total death.

 

The really silly decision was to purge the old install and roll on the most current image. (20.08.2/5.8.6). It does boot! However, the DTB differs so much from 4.4 so I literally have no idea HOW to insert the panel code to make it work! I tried to push the old DTB into the current uboot, and it says it cannot reserve memory for FDT (the old file is 160+KB size, the current ones are ~70KB, maybe this is the reason?) and even does not reach the kernel.

 

The piece of panel-related code (copied from old OrangePi DTS) conflicts in the new structure with almost all phandles, some pincontrols, resets et al. I feel totally lost, as I can't catch the very tail of all that FDT mystique in order to unroll it in my mind. The first logic conflict is that ALL the main peripherals in the T4 and the SOM must be totally compatible, whilst they eventually are not - otherwise the old image HAS to boot cleanly on the SOM, etc etc.

 

Please assist, I'd love not to bury this project.

[cu6apum]

My working piece of code that I would love to make alive in 5.8:

Spoiler

       dsi@ff960000 {
                compatible = "rockchip,rk3399-mipi-dsi";
                reg = <0x00 0xff960000 0x00 0x8000>;
                interrupts = <0x00 0x2d 0x04 0x00>;
                clocks = <0x08 0xa2 0x08 0x170 0x08 0xa3>;
                clock-names = "ref\0pclk\0phy_cfg";
                power-domains = <0x15 0x0f>;
                resets = <0x08 0xfb>;
                reset-names = "apb";
                rockchip,grf = <0x16>;
                status = "okay";
                #address-cells = <0x01>;
                #size-cells = <0x00>;
                phandle = <0x138>;
                
                ports {

                        port {
                                #address-cells = <0x01>;
                                #size-cells = <0x00>;
                                
                                endpoint@0 {
                                        reg = <0x00>;
                                        remote-endpoint = <0xb7>;
                                        phandle = <0xac>;
                                };
                                        
                                endpoint@1 {
                                        reg = <0x01>;
                                        remote-endpoint = <0xb8>;
                                        phandle = <0xa4>;
                                };
                        };
                };

                panel@0 {
                        status = "okay";
                        compatible = "simple-panel-dsi";
                        reg = <0x00>;
                        backlight = <0xb9>;
                        enable-gpios = <0x36 0x0d 0x00>;
                        reset-gpios = <0x3f 0x1e 0x01>;
                        reset-delay-ms = <0x05>;
                        init-delay-ms = <0xc8>;
                        prepare-delay-ms = <0x0f>;
                        dsi,flags = <0x803>;
                        dsi,format = <0x00>;
                        bus-format = <0x100a>;
                        dsi,lanes = <0x04>;
                        panel-init-sequence = <0x390002cd 0xaa390002 0x65083900 0x23a1439 0x23200 0x39000236 0x2390002 0x67823900 0x2692039 0x26d01 0x39000268 0x390014 0x53191715 0x12121213 0x1515100c
                        panel-exit-sequence = <0x5000128 0x5780110>;

                        power_ctr {
                                rockchip,debug = <0x00>;
                                phandle = <0x139>;

                                lcd-rst {
                                        rockchip,power_type = <0x00>;
                                        gpios = <0x3f 0x1e 0x00>;
                                        rockchip,delay = <0x05>;
                                        phandle = <0x13a>;
                                };
                        };

                        display-timings {
                                native-mode = <0xba>;

                                timing0 {
                                        clock-frequency = <0x3780fc0>;
                                        screen-type = <0x07>;
                                        out-face = <0x00>;
                                        hactive = <0x190>;
                                        vactive = <0x500>;
                                        hback-porch = <0xa0>;
                                        hfront-porch = <0xa0>;
                                        vback-porch = <0x0a>;
                                        vfront-porch = <0x0c>;
                                        hsync-len = <0x05>;
                                        vsync-len = <0x05>;
                                        hsync-active = <0x02>;
                                        vsync-active = <0x02>;
                                        de-active = <0x00>;
                                        pixelclk-active = <0x00>;
                                        swap-rb = <0x00>;
                                        swap-rg = <0x00>;
                                        swap-gb = <0x00>;
                                        phandle = <0xba>;
                                };
                        };
                };
        };

 

 

 

Edited December 7, 2020 by TRS-80
put long code block inside spoiler

[cu6apum]

After spending another day I got the following.

 

1. DTB compiles now with no errors on the current system. Shall i post the source?

2. There's NO sound about mipi/dsi neither in the boot log, nor in dmesg. On the older system it's showing as initialized.

3. The backlight is OFF. No idea what's going on, BECAUSE

5. The panel and the mipi@ff960000 are PRESENT in /proc/devicetree with status OKAY!!!

UPD. 6. dw_mipi_dsi module is loaded and used by rockchipdrm module. Still no display visible to X.

 

Another night and some more strong tea.

[cu6apum]

Still no backlight despite it shows "okay" in the devtree...

Will short the BL pin temporarily to Vcc, will see... i suspect the dsi port is down.

WHY???

[cu6apum]

Thank everybody for MASSIVE support...

 

Either 5.x kernels are not working with MIPI/DSI, or the DTB structure has changed so hard so I cannot get even a dmesg on whether or not the panel is detected at all.

Managed to boot ubuntu with 4.4.179 (armbian REFUSED to boot whatever I do), decompiled the old successful DTB, modded the distro one (still no source files; there's only nonworking crap in source tree) and combined.

After 2 more days I do have the panel alive.

[TRS-80]

On 11/30/2020 at 6:16 PM, cu6apum said:

Thank everybody for MASSIVE support...

 

I read this several days ago, and it bother me, although I didn't know what to say about it.  It bother me for days, actually.  Until today reading this post make me think of you again, so I come searching back and find this thread so I can reply.

 

When you said

 

On 11/27/2020 at 6:11 PM, cu6apum said:

Another night and some more strong tea.

 

I picture you toiling away in your lab, as many of us do, often alone, in order to solve some problem.  I think all sciences have advanced through millennia by such efforts.

 

I think you just got unlucky with some (very specific) question.  Apparently the right people did not see your thread.  Or maybe no one knows anything that can help.  I have seen many times in these forms people replying to old threads from months, even years ago with some additional information, partial, or full solution.

 

Anyway, now there is a solution, thanks to your efforts.  I thank you for sharing your results, which I think are even more important as that is the only way we all may advance together.

 

However, next time you are feeling alone, and/or discouraged, please do drop by IRC and say hello.  Until then, cheers, mate!

[cu6apum]

Well, hi.

I just can't get the very idea of something having QUIETLY stop working in a newer kernel. This is not an Armbian prob, no. And only hell knows where is it (btw, this is the fact I dislike VERY seriously about current linuces).

Having reverted to 4.4 ubuntu let me solve this AT LEAST using some error output! Several thousand peeks and pokes, and we're in.

 

Now I'm getting into another big battle: mainline drivers for KSZ9xxx ethernet switch I must control, are present only in 5.x - so will look to transplant them into 4.4.

 

[TRS-80]

2 hours ago, cu6apum said:

I just can't get the very idea of something having QUIETLY stop working in a newer kernel.

 

I don't think it's that uncommon.  Linux kernel development always going forward, some times the cost of progress are breaking some thing that worked already and there is a regression.

 

2 hours ago, cu6apum said:

This is not an Armbian prob, no.

 

I'm glad you recognize that.  In fact one of main reasons for the Armbian project to exist in the first place is to try and smooth over some of these rough edges.  Which there will always be.  However I think we would be so much worse off without some place to come together and try and organize some standard approach and share our work.  I think some people (not you) forget that when they come to these forums and complain.  Because things could (and were) actually much worse at one point than they are currently.

 

3 hours ago, cu6apum said:

And only hell knows where is it (btw, this is the fact I dislike VERY seriously about current linuces).

 

Yes this is the challenging part.  I would blame the hardware manufacturers more than Linux and other devs who I think are doing the best they can with what they have to work with.  Meanwhile most of these manufacturers just want to sell chips and provide no support at all.  Allwinner is even violating GPL since a very long time now (in that case, the community got support to a good state not because of their help but rather in spite of it).

 

3 hours ago, cu6apum said:

Having reverted to 4.4 ubuntu let me solve this AT LEAST using some error output! Several thousand peeks and pokes, and we're in.

 

Now I'm getting into another big battle: mainline drivers for KSZ9xxx ethernet switch I must control, are present only in 5.x - so will look to transplant them into 4.4.

 

I have no idea the specifics you are dealing with, but I have read many devs on the forums saying that working towards mainline is usually the goal (in general).  This is not always possible, especially early on for any particular board, however over time most of the work does seem to move in that direction.  Just something to keep in mind for all your effort.

[iamdrq]

hi,you can read this know how to write panel dts for kernel 5.x

 

https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt

[elektroman]

I've stumbled across your thread for some unnamed panel with 1920x1152 pixel in dimension ...

With 0x5000128 ...

 

backlight = <0xb9>;

should pointing at PWM ...

 

maybe you need a panel driver

panel-init-sequence

panel-exit-sequence

 

is not uptream !