U-boot Display

Yes, showing an image on the display is basically possible since release fsimx6ul-B2019.11. However we want to add quite some more features for the display in the future, for example more image formats. So this version is only a first step and usage may change in the future. This is why we didn't put any emphasis on this feature in the past and the documentation is still rare.

DIsplay Usage in U-Boot

There are some new environment variables

disppanel: Port and Name of a display

dispmode: Timing parameters for the display

dispflags: Additional flags

disppanel

The variable disppanel has the form <port>:<name>. <port> is one of the following values

lcd Display is located on the parallel RGB port

hdmi Display is located on the DVI/HDMI-Port (not supported yet)

lvds0 Display is located on the first LVDS channel (not available on fsimx6ul)

lvds1 Display is located on the second LVDS channel (not available on fsimx6ul)

<name> is either a name from a list of predefined displays and then the parameters are taken from the internal entry. Or it is an own name and then the display parameters have to be given in dispmode and dispflags. At the moment only the following three Displays are predefined. These are the displays that we provide with our Starterkits.

EDT-ET070080DH6

ChiMei-G070Y2-L01

Jinghua-J070WVTC0211

The easiest way is to use one of the predefined display. Then only one variable has to be set:

For an own display, you simply take a freely defined name and add at least the dispmode variable.

dispmode

Variable dispmode contains pairs of the form <name>=<value>. They are seperated by commas and describe the display timings and clock polarities.

clk: Pixelclock (in Hz, optional)

rate: Refresh rate (in fps, default: 60 fps)

hres: Horizontal Resolution (in pixels or clk-ticks)

vres: Vertical Resolution (in rows)

hfp: Horizontal Front Porch (in clk-ticks)

hbp: Horizontal Back Porch (in clk-ticks)

hsw: HSYNC Width (in clk-ticks)

vfp: Vertical Front Porch (in rows)

vbp: Vertical Back Porch (in rows)

vsw: VSYNC Width (in rows)

hsp: HSYNC Polarity: 0: Active Low, 1: Active High

vsp: VSYNC Polarity: 0: Active Low, 1: Active High

dep: DE Polarity: 0: Active Low, 1: Active High

clkp: Pixelclock Polarity: 0: Latch on falling edge, 1: Latch on rising edge

il: Interlaced: 0: No, 1: Yes (Not supported yet)

Example:

The parameters can be taken from the display data sheet. If you already have values for the Linux device tree, then you can use these:

hactive -> hres

vactive -> vres

hfront-porch -> hfp

hback-porch -> hbp

vfront-porch -> vfp

vback-porch -> vbp

hsync-len -> hsw

vsync-len -> vsw

hsync-active -> hsp

vsync-active -> vsp

de-active -> dep

pixelclk-active -> clkp

dispflags

Variable dispflags contains a list of flags, separated by commas. Flags are often meant for a specific display port. If a flag is given, the value is set. If it is not given, the value is unset. For now only flags for LVDS are defined.

lvds2ch: LVDS display is in Dual-Channel-Mode (1st channel even pixels, 2nd channel odd pixels (not supported yet)

lvdsdup: Both LVDS channels show the same image, i.e. it is a duplicated image on similar displays (not supported yet)

lvds24: LVDS is using 24 bits per Pixel, four LVDS lanes (default: 18 bits per pixel, three LVDS lanes)

lvdsjeida: LVDS data is using JEIDA mode (Default: SPWG) (only relevant in 24-bit mode)

Example:

Supply a boot image

When you have defined your display as shown above (don't forget to use saveenv), then you'll see an F&S logo and the U-Boot version on the display on the next start. However this logo is *not* intended to be replaced with your logo. You can define your own (and even larger) logo (or other start image) in a completely independent way. This image can even fill the whole screen. There are gain two environment variables for this.

splashimage: Address where the image to show is located in RAM

splashprepare: Commands to be executed to get the image to RAM

For now, the image must use the BMP format. First you have to think about where to store the image, so that it is available at the next start. For example use an own MTD partition in NAND. By setting the splashprepare variable, you load the image from this source to RAM and by setting the splashimage variable, you tell U-Boot that it should show a boot screen and where the image is located in RAM.

Example:

We have a small MTD partition UserDef that is exactly meant for things like that. So if you use a BMP image with 8 Bit/Pixel and you have a display resolution of 800x480, then the image will fit in this UserDef partition. The following commands will store the image there and prepares the board to show this image at every start.

The first command loads the image via TFTP. Then the second and third commands store the image in the UserDef partition. The fourth command stores a nand read sequence in the splashprepare variable that will load the image from the UserDef partition to $loadaddr in RAM. The fifth command sets the splashimage variable that tells U-Boot that there is an image at $loadaddr in RAM that should be displayed.

As I said, this is only the beginning with display support in U-Boot. We have plans for quite some more stuff, for example that several displays can be activated at t eh same time and that also texts and graphic primitives can be shown. In addition the transition from U-Boot to Linux should be made seamless. At the moment, the boot screen vanishes when Linux starts.

Yes. U-Boot is the same in the Buildroot and the Yocto releases.

is this solution still valid under fsimx6-Y2024.04 for eFus i.MX6 Quad? And does it get rid of the penguins?

Yes, activating the display in U-Boot still works this way. However we have detected an issue in Linux when the display is activated in U-Boot. You need to apply the following patch to Linux or the display will not work in Linux afterwards.

In this solution, the screen still goes blank after U-Boot and is newly initialized in Linux. So the penguins are still there. But getting rid of the penguins is simple. Just add logo.nologo to the Linux command line, for example by adding it to the extra environment variable in U-Boot. The content of this variable is added to the command line.

This is also explained in the "Linux On F&S Boards" documentation in chapter 6.5.9.

Your F&S Support Team

Thank you.

My display is working without the patch, but I will test it.

Is there also a way to replace the penguins with a custom image?

What file format shall one use to load an image from RAM to the bootloader using splashprepare/splashimage?

I use a 8bit Bitmap, and it is not shown in original colors. I compressed it to RLE, but UBoot says:

Error: compression type 1 not supported

When using splashimage, the image has to be a BMP image. If 8-bits do not work, try to use a 24-bit image. The display is using True Color anyway. As U-Boot is a rather minimalistic implementation, they may have spared the conversion from 8-bit with Color Lookup Table to 24 bit RGB in the code.

Replacing the penguins is not the correct way to handle a splash screen in Linux. The number of penguins tells the number of CPU cores. So if you simply replace the penguin with another graphic, you will also see this graphic twice or four times on a dual/quad CPU.

It is better to use a program like fbsplash to show a regular image or logo on the screen. This program is part of Busybox and is available on all our boards. It also supports showing a progress bar. We even have a document showing how to do this:

https://www.fs-net.de/filelice…fileid=11901&locale=de_DE

Your F&S Support Team

Hello,

thank you for your answer.

I made the experience, that fbsplash and plymouth both do not start as early in the boot process as the penguins logos used to show up.

I use a systemd service to start the fbsplash.sh script very early:

It works, but there are several seconds of black screen until the ppm file appears.

----

The same if true for Plymouth, but here, it completely fails to run at boot.

Plymouth-start.service:

I also set the UBoot bootargs to:

and I changed the plymouth.conf file to:

Once the eFus has fully booted, I can manually run the plymouth splashscreen by restarting the plymouth.start.service, but it fails to appear directly after UBoot exited and the Kernel boot sequence is running.

Is there a configuration I am missing?

Quote from bkeohane

I made the experience, that fbsplash and plymouth both do not start as early in the boot process as the penguins logos used to show up.

Yes.that's true. The penguins appear immediatley when the display driver is activated. fbsplash and plymouth cannot appear before the root filesystem is mounted, because they are taken from there. One solution may be a modification of the boot process. Currently, many of the drivers are built into the kernel image itself. By making all these drivers to kernel modules, the main boot process would speed up and the bigger part of the drivers would also be loaded later when the rootfs is available. This could reduce the time until the splash screen is visible in Linux, relative to the other drivers.

To speed up the boot process even further, it might be useful to introduce an initramfs as an intermediate root filesystem. This is how desktop Linuxes typically work. They start up with a rather small subset of drivers in the initramfs RAM disk, including fbsplash or plymouth. Because of the small size, this intermediate rootfs is mounted very quickly and you can see the splash screen very early in the boot process. Then the main rootfs is mounted from flash media, with all the remaining device drivers, which takes considerably longer. Then the rootfs is switched over from the intermediate rootfs to the main rootfs and the boot process of all the remaining drivers continues.

Having a smoother pass-over of the splash screen from U-Boot to Linux without the black gap inbetween is on our todo list for quite some time. But it is more difficult than it seems on the first glance. For example to be able to show the image that was visible in U-Boot, requires a memory region for the framebuffer that holds this image. This memory region has to be reserved in Linux, so that it is not used for regular tasks when booting up. How to provide such a reserved memory region at boot time but still be able to re-use it later on? Moreover, current Linux display drivers often do not use a framebuffer anymore at all, they use DRM. So how to pass on a framebuffer to a system that does not use a frambuffer? And if the image should be visible all the time, the display sub-system has to stay alive all the time. How to keep a subset of the clocks valid and enabled when Linux re-initalizes the whole clock tree? How to keep the display on when Linux re-initializes the display driver and backlight infrastructre in a completely different way?

We actually will have a look at this in the near future again, as we want to have display support in U-Boot for i.MX8 and i.MX9 CPUs, too. But I cannot promise that we will find an easy solution for all the mentioned problems.

Your F&S Support Team

Hi,

thank you for the detailed answer. I now see the problem is of bigger concern.

However, I could successfully build an initramfs, bundled with the Kernel in a single image. I use this recipe in my custom layer, and I use Plymouth for bootscreen.

The init file is a simple bash script.

The spinner theme and all its coresponding files were already located on the Fedora VM.

Of course, one needs to activate the initramfs support in the Kernel configuration.

This page also gives some hints: 12 Building — The Yocto Project ® 5.1.999 documentation

Thanks.