AM3352: Uboot DM video support for splash screen

Hi Richard,

Richard_McAleer said:

In the past I have used the instructions from: http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components_U-Boot.html#u-boot-splash-screen

to incorporate a splash screen in to my u-boot build.

Unfortunately this piece of documentation is out of date. I'll make a note to have it removed. AFAIK we no longer support this.

Richard_McAleer said:

are there any updated examples that describe what's necessary to get the am335x lcd driver working in u-boot via dts?

I'm not aware of anybody in the recent past that has implemented this. So I'm not sure as to what the effort would be to resurrect this feature.

I've seen a recommendation here to instead use Falcon boot, and let the Kernel handle the boot image display. Perhaps that's something worth looking into as an alternative?

https://lists.denx.de/pipermail/u-boot/2014-July/184871.html

Richard_McAleer said:

I am now trying to port to a more up to date yocto and find that it's expecting a splash screen to be done using CONFIG_DM_VIDEO

specifically it complains about CONFIG_SYS_EXTRA_OPTIONS="SPLASH",  CONFIG_LCD_NOSTDOUT

What specific errors do you get? We can try to bring this up remotely but it might be a tedious effort (we don't have the resources at the moment to provide a readily-ported example in the context of our E2E support).

Regards, Andreas

Thanks Andreas

Andreas Dannenberg said:

I'm not aware of anybody in the recent past that has implemented this. So I'm not sure as to what the effort would be to resurrect this feature.

I've seen a recommendation here to instead use Falcon boot, and let the Kernel handle the boot image display. Perhaps that's something worth looking into as an alternative?

That's not going to work unfortunately; the reason for using a splash screen is to get something displayed in much less time than it takes to load the kernel

Andreas Dannenberg said:

What specific errors do you get? We can try to bring this up remotely but it might be a tedious effort (we don't have the resources at the moment to provide a readily-ported example in the context of our E2E support).

I've decided against trying to squeeze the old configs in (which were causing the errors) and am looking at how the DM side of things should work

I've added the following via config

CONFIG_CMD_BMP=y
CONFIG_DM_VIDEO=y
CONFIG_VIDEO_BPP32=y
CONFIG_BOARD_LATE_INIT=y

and inserted 

#define CONFIG_VIDEO_BMP_GZIP
#define CONFIG_SYS_VIDEO_LOGO_MAX_SIZE (1366*767*4)

in my /configs/mybaord.h

At present I can control my backlight via PMIC and I am configuring the screen via GPIO bashed 1 wire spi via the board_late_init function

I can read a gzipped bmp from SPI NOR and it's parsed happily by the BMP commands

=> bmp info ${loadaddr}
Image size    : 240 x 360
Bits per pixel: 24
Compression   : 0

What looks to remain to be done is getting the LCD driver and frambuffer (or framebuffer proxy)  in to u-booot

=> dm tree
 Class     Index  Probed  Driver                Name
-----------------------------------------------------------
 root          0  [ + ]   root_driver           root_driver
 rsa_mod_ex    0  [   ]   mod_exp_sw            |-- mod_exp_sw
 simple_bus    0  [ + ]   generic_simple_bus    `-- ocp
 simple_bus    1  [   ]   generic_simple_bus        |-- l4_wkup@44c00000
 simple_bus    2  [   ]   generic_simple_bus        |   |-- prcm@200000
 simple_bus    3  [   ]   generic_simple_bus        |   `-- scm@210000
 simple_bus    4  [   ]   generic_simple_bus        |       `-- scm_conf@0
 gpio          0  [ + ]   gpio_omap                 |-- gpio@44e07000
 gpio          1  [ + ]   gpio_omap                 |-- gpio@4804c000
 gpio          2  [ + ]   gpio_omap                 |-- gpio@481ac000
 gpio          3  [ + ]   gpio_omap                 |-- gpio@481ae000
 serial        0  [ + ]   omap_serial               |-- serial@44e09000
 i2c           0  [ + ]   i2c_omap                  |-- i2c@44e0b000
 i2c_generi    0  [ + ]   i2c_generic_chip_drv      |   `-- generic_24
 mmc           0  [ + ]   omap_hsmmc                |-- mmc@48060000
 blk           0  [ + ]   mmc_blk                   |   `-- mmc@48060000.blk
 mmc           1  [ + ]   omap_hsmmc                |-- mmc@481d8000
 blk           1  [   ]   mmc_blk                   |   `-- mmc@481d8000.blk
 watchdog      0  [ + ]   omap3_wdt                 |-- wdt@44e35000
 timer         0  [ + ]   omap_timer                |-- timer@48040000
 timer         1  [   ]   omap_timer                |-- timer@48042000
 timer         2  [   ]   omap_timer                |-- timer@48044000
 timer         3  [   ]   omap_timer                |-- timer@48046000
 timer         4  [   ]   omap_timer                |-- timer@48048000
 timer         5  [   ]   omap_timer                |-- timer@4804a000
 spi           0  [ + ]   omap3_spi                 |-- spi@48030000
 spi_flash     0  [   ]   spi_flash_std             |   `-- spi-flash@0
 misc          0  [ + ]   ti-musb-wrapper           `-- usb@47400000
 usb           0  [ + ]   ti-musb-peripheral            |-- usb@47401000
 eth           0  [ + ]   usb_ether                     |   `-- usb_ether
 usb           0  [   ]   ti-musb-host                  `-- usb@47401800
=>

If anyone has any clues to how this might be done I would be very grateful

All the best,

- Richard

Hi Andreas

that driver has been around for a while (it's the one i used in my previous u-boot) 

the code I'm looking at just now is based on v2020.01 and if I compile in CONFIG_AM335X_LCD it starts looking for structures/definitions that have been elided in other platforms by CONFIG_DM_VIDEO (e.g in lcd.h)

so it looks as though the support is in limbo at the moment

I'll have a look through the notes on transitioning to the DM_VIDEO model once I've sorted out my device tree porting to the new kernel 

- I get the impression from the other drivers that it should be quite simple (given that's the idea of the DTS model)

All the best

- Richard 

Hi Richard,

Richard_McAleer said:

that driver has been around for a while (it's the one i used in my previous u-boot) 

Richard_McAleer said:

the code I'm looking at just now is based on v2020.01

Yes, but there have been changes in upstream since 2020.01, for example there's a commit that adds support for DM/DTS. Sounds like something you'd want to use.

a0797059@jiji:~/git/u-boot (HEAD detached at upstream/master)
$ git log --oneline v2020.01... drivers/video/am335x-fb.c
c05ed00afb common: Drop linux/delay.h from common header
f7ae49fc4f common: Drop log.h from common header
295ab882d9 video: omap: change include order
0aff8e2615 video: omap: fix pixel-per-line bitfield setting
96b109ba74 video: omap: add support for DM/DTS
a9df3c50ed video: omap: create two routines to set the pixel clock rate
9d7f53c1e5 video: omap: add loop exit conditions to the dpll setup
9aead9ae09 video: omap: fix debug message
41f76a01f3 video: omap: rename LCD controller registers
017295f31d video: omap: fix bitfields order
3af43750df video: omap: fix coding style on use of spaces
e3f82b80cd video: omap: add missing bitfield masks
a2f4706479 video: omap: use BIT() and GENMASK() macros

Richard_McAleer said:

I'll have a look through the notes on transitioning to the DM_VIDEO model once I've sorted out my device tree porting to the new kernel 

Let us know once you get there and need anything else on that.

Regards, Andreas

Thanks Andreas

I had fetched and pulled but not looked in master 

- I can see the changes you refer to now and I'll use them as a reference when I next look at this

Thanks for the help

- Richard