Mity CPU Platforms » MitySOM-AM62, MitySOM-AM62A, & MitySOM-AM62P

There was some change I think around TI's SDK 9, that greatly delayed the /dev/fb0 creation. I didn't dig into it at the time, but I agree its not ideal.

I do think that getting the u-boot splash screen support working would make the most sense. I integrated some of TI's changes when they started adding the feature but haven't tried testing it to see what parts I'm missing to get it fully supported. I'm probably only missing a few small changes.

If your looking into it, i'd be happy to review and integrate any fixes you find. If you'd like me to look into it, we just need to look into getting it on my schedule as I have a few urgent tasks i'm working on.

Sounds good. Getting an early image on the display is one of the last big things I need to do to get our device in a good state so I'll be looking at it a lot this week. My initial plan was to just try and get the framebuffer created by U-boot that the Linux kernel can use as soon as it's started but if it ends up not being too much more to get the splash screen started in U-boot then that would be even better.

I'll leave updates here once I get some things functional

Holden Wozniak wrote in RE: Getting the Splash Screen to Appear Earlier:

Sounds good. Getting an early image on the display is one of the last big things I need to do to get our device in a good state so I'll be looking at it a lot this week. My initial plan was to just try and get the framebuffer created by U-boot that the Linux kernel can use as soon as it's started but if it ends up not being too much more to get the splash screen started in U-boot then that would be even better.

From my read of their doc and my own experience, usually getting u-boot to show the splash screen is the first step. Getting u-boot to gently pass that frame buffer to linux (so the screen doesn't flicker when linux takes over) is trickier and usually happens later, though they do document how to do it.

I'll leave updates here once I get some things functional

Sounds good

If you run into any roadblocks, let me know. We can schedule a working meeting if needed.

Just for some clarification, the documentation says to modify board/ti/am62ax/evm.c to change the SPL init function and enable video even in custom boards based on the am62ax SoC. Is all board configuration contained within the board/cl directory and a new evm.c should be created here or does it ever reference files in board/ti/am62ax?

When searching the build directory, the only "evm" files I see are from ti-linux-firmware which is part of the build dependencies.

Our som.c is mostly a copy of their evm.c

https://support.criticallink.com/gitweb/?p=u-boot-ti.git;a=blob;f=board/cl/mitysom-62x/som.c;h=a4ba0e88f4c3fc4f537efc095bf9e6069109ecd5;hb=refs/heads/mitysom-u-boot-2025.01#l199

I was able to create nodes in the u-boot device tree for my panel, pwm-backlight, and the video driver (dss).

In drivers/video/tidss/tidss_drv.c added the compatible line for the am62a7 so the tidss driver can bind properly

static const struct udevice_id tidss_drv_ids[] = {
    { .compatible = "ti,am625-dss" },
    { .compatible = "ti,am62a7-dss" },
    { }
};

In U-boot, the dm tree and dm uclass commands show those nodes with drivers bound to them but they do not probe (likely because I have not written any code to trigger them to yet) but

=> dm tree
 Class     Seq    Probed  Driver                Name
-----------------------------------------------------------
 root          0  [ + ]   root_driver           root_driver
 rsa_mod_ex    0  [   ]   mod_exp_sw            |-- mod_exp_sw
 simple_bus    0  [ + ]   simple_bus            |-- bus@f0000
 simple_bus    1  [   ]   simple_bus            |   |-- bus@4000000

 . . .

 video         0  [   ]   tidss_drv             |   |-- dss@30200000
 remoteproc    2  [   ]   k3_dsp                |   `-- dsp@7e000000

 . . .

 regulator    12  [ + ]   regulator_fixed       |-- vdd_mmc1
 regulator    13  [ + ]   gpio regulator        |-- som_vdd_sd_dv
 regulator    14  [   ]   regulator_fixed       |-- wlan_en
 clk           1  [   ]   fixed_clock           |-- clk-0
 backlight     0  [   ]   pwm_backlight         |-- pwm-backlight
 panel         0  [   ]   simple_panel          |-- panel
 firmware      1  [   ]   psci                  |-- psci

 . . .

=> dm uclass panel
uclass 81: panel
0     panel @ fd5c9db0, seq 0

=> dm uclass backlight
uclass 82: backlight
0     pwm-backlight @ fd5c9cd0, seq 0

=> dm uclass video    
uclass 130: video
0     dss@30200000 @ fd5c88c0, seq 0

Despite having drivers listed the devices are never probed so I am unable to test putting an image to the display with bmp (though I can load a bmp to the loadaddr and print out its info). Does the probing have to be done in u-boot code or do you know of any way to probe these kind of devices from the uboot command line?

Can you share the changes you've made so far as a patch/diff?

I am also attaching the Linux dts, I know the bindings are a little different for the u-boot drivers so I tried to match as closely as possible for the panel and backlight nodes

Note one thing I ran into is the ti-dss driver in 2025 u-boot, doesn't currently support switching to video port 1 (where the 62a connected the VOUT pins). There is a upstream patch to add this support so I'm testing if it can be backported.
https://github.com/u-boot/u-boot/commit/209c5d9da18375a6ea320786254803d28486e739

I have made some good progress on this today. I've got to do some cleanup but i'll try to push a test branch for you to test. Note i'm using our devkit with the hdmi output but I believe switching to your touchscreen should be straight forward.

https://support.criticallink.com/gitweb/?p=u-boot-ti.git;a=shortlog;h=refs/heads/2025.01-am62a-hdmi-splash

Here are my changes so far, pushed to a test branch, please test it and let me know.

This loads a splash.bmp.gz from the boot partition of the sdcard and loads it during the A53 SPL. Note splash.bmp needs to be <1M uncompressed. There may be a config to increase this limit. I didn't bother enabling the bmp cmd or splash screen support during u-boot proper, but I did test to verify the SPL will handoff the framebuffer to u-boot proper when it is enabled.

I haven't tried to get the linux framebuffer handoff working yet, so a couple seconds into the linux boot, the framebuffer gets a bit scrambled before it draws its own splashscreen. But I wanted to give you at least some progress.

The changes work great, got it working with our display no problem!

I see what you mean with the scrambled splashscreen, I was going to start following the documentation for handing the frame buffer off to Linux and see what happens with that

Okay good to hear.