Display/Panel Driver

[alexcaoys]

Currently the display is green-ish. I have already experimented a lot but couldn't get it to display correctly (with correct refresh rate)

I have already contacted Neil, the main contributor of Amlogic Display Driver. He will take a look since he has this device too, but I believe he's also super busy.

Current status:

Changes I made: https://github.com/unifreq/linux-6.6.y/commit/38a3dc150b7eb1e4f6af06e3e55b71c09d88f483

Newest changes for G12A MIPI DSI: https://patchwork.kernel.org/project/linux-arm-kernel/cover/20240403-amlogic-v6-4-upstream-dsi-ccf-vim3-v12-0-99ecdfdc87fc@linaro.org/ (It's better to simply diff Linux 6.6 vs Linux 6.10 in drivers/gpu/drm/meson)

stock kernel: https://github.com/spsgsb/kernel-common/blob/buildroot-openlinux-201904-g12a/arch/arm64/boot/dts/amlogic/mesong12a_panel_superbird.dtsi (lcd_8 + extern_7)

ST7701S white paper should be available somewhere, please Google.

[Fexiven]

this works for me:

         .clock          = 36000,

         .hdisplay       = 480,
         .hsync_start    = 480 + 50,
         .hsync_end      = 480 + 50 + 160,
         .htotal         = 480 + 50 + 160 + 50,

         .vdisplay       = 800,
         .vsync_start    = 800 + 10,
         .vsync_end      = 800 + 10 + 500,
         .vtotal         = 800 + 10 + 500 + 10,

[alexcaoys]

Wow! That's awesome. I noticed it's actually something I've tested before. I tried it again but it still not works for me.

Is there anything else you modified in your version?

Another thing is, do you know why these numbers work? From what I read these numbers should affect refresh rate and all the code I saw implemented as

htotal * vtotal * refresh_rate(60) ~= clock * 1000

But this number definitely doesn't align with this.

[Fexiven]

Wow! That's awesome. I noticed it's actually something I've tested before. I tried it again but it still not works for me.

Is there anything else you modified in your version?

Another thing is, do you know why these numbers work? From what I read these numbers should affect refresh rate and all the code I saw implemented as

htotal * vtotal * refresh_rate(60) ~= clock * 1000

But this number definitely doesn't align with this.

Yes i noticed that too, so maybe it's not 100% right. I will attatch my Image, but i also removed a lot of packages for faster compiling.

https://drive.google.com/file/d/1s2ISyzq5WlBLJ5A_eXZCpOYQvFqrGwj2/view?usp=sharing

[alexcaoys]

Sadly this Image is still giving me green screen.

By the way, so the original settings I put there (clock=30000 ...) was actually not working for you, right?

Although I highly doubted if that's the reason. Since I was using Buildroot 2024.2.1, I am actually building from scratch using Buildroot 2024.2.3. Let's see if this works for me.

[Fexiven]

Sadly this Image is still giving me green screen.

By the way, so the original settings I put there (clock=30000 ...) was actually not working for you, right?

Although I highly doubted if that's the reason. Since I was using Buildroot 2024.2.1, I am actually building from scratch using Buildroot 2024.2.3. Let's see if this works for me.

Hmm... That's weird, yes 30000 gave me the same green screen.

[Fexiven]

I found something. If i run the Image while the Display is already initialized via --enable_burn_mode i get the green tint. If i do the Button 1&4 method, then enable --burn_mode and then run the Image it works without green tint

Since im not so familiar with u-boot could we wipe/repartition the emmc to start from a common straight forward system?

Maybe its possible with different boot modes like here https://github.com/bishopdynamics/superbird-debian-kiosk/blob/main/files/env/env_switchable.txt

But i really don't know how to do it

[alexcaoys]

Wow. Thanks! That's a great finding, and rather Interesting. Never though the boot mode will affect the screen/color in a way. Reading the code, --burn_mode is sideloading some boot image from the host to the device, which I am not sure if we can mimic within the device. To be honest, I don't really want to touch the u-boot part since if it didn't work, it will for sure brick the device. I will run some experiments probably this weekend. Hopefully we can bypass that restriction.

[Fexiven]

https://wiki.libreelec.tv/hardware/amlogic

this seems to be somewhat usable for out purpose? Im not too familiar with embedded system reversing. But since we already are able to boot a custom Image can we also boot the Generic Box Image with the dtb from you?

i also found this https://github.com/LibreELEC/amlogic-boot-fip and this https://forum.libreelec.tv/thread/28285-aml-boot-sequence/?postID=189836#post189836

So if im corrent as long as we don't touch the BL1, we should always be able to USB boot again//flash the bl2 from stock again?

[alexcaoys]

OK, I got this. By removing run init_display; from https://github.com/bishopdynamics/superbird-tool/blob/main/stock_env.txt#L35 and sending it back to the device env. It now gives me the same result as using --burn_mode. I believe the sideloading BL doesn't have the preboot steps at all (So the screen is black). But this is not ideal, the stock firmware will give a black screen now. (I guess because I didn't let u-boot to initialize the display lol)

And then I tested the config. Although it looks ok with Tux (the Linux Penguin), it actually is yellow-ish overall, which can be seen by fb-test -p 0 (provided by fb_test_app in Buildroot) and gives something like this:

Sadly I guess this config is still not good enough.

As for LibreELEC, the problem is LibreELEC is not a general-purpose OS which makes it even harder to work with. I would say Armbian makes more sense. But because I made a bit tweak to the Mainline Kernel, a few features (Bluetooth, the wheel, and the screen) won't be available at all for both LibreELEC or Armbian. I believe this is the LibreELEC kernel, which I tried and not working: https://github.com/chewitt/linux/tree/amlogic-6.10.y So my main target is still working with this kernel + Buildroot. Maybe later we can make Armbian work with it.

For U-Boot, currently I guess we can use the stock one for now. If there are some major drawback with it, then we can consider switch it.

[alexcaoys]

Good news, I found a working, color correct config. But the refresh rate is still not right. I will organize everything again and put the Image on the release later. But we still need to find a way get 60Hz refresh rate though.

    .clock          = 36000,

    .hdisplay       = 480,
    .hsync_start    = 480 + 32,
    .hsync_end      = 480 + 32 + 120,
    .htotal         = 480 + 32 + 120 + 32,

    .vdisplay       = 800,
    .vsync_start    = 800 + 16,
    .vsync_end      = 800 + 16 + 640,
    .vtotal         = 800 + 16 + 640 + 16,

[Fexiven]

Thats great, i noticed the yellow tint in tux too but didn't think of it too much. Sadly im on vacation for a while now and can't test. But according to the formula...

H_Total*V_Total*FPS

H_Total = 480 + 32 + 120 + 32 (664)
H_Total = 800 + 16 + 640 + 16 (1472)
FPS = 60

Would ~58644 (60000?) be the right clock speed? Unfortunately i cannot test it

[alexcaoys]

Oh, enjoy your vacation!

Actually there are two formulas, one for that clock (pixel clock) and another one for MIPI clock in the dts file.

pixel_clock = h_total * v_total * refresh_rate
CLKID_GP0_PLL = CLKID_MIPI_DSI_PXCLK = pixel_clock * 24 (RGB888) / 2 (number of lanes)

I tried to change both or either of these in our config but it won't give me usable result anymore. I think I will come back for this later once I document everything and build a usable system for everyone.