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:

    Code
    1. setenv disppanel lcd:EDT-ET070080DH6


    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:

    Code
    1. setenv dispmode rate=60,hres=800,vres=480,...

    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:

    Code
    1. setenv dispflags lvds24,lvdsjeida



    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.

    Code
    1. tftp startscreen.bmp
    2. nand erase.part UserDef
    3. nand write $loadaddr UserDef $filesize
    4. setenv splashprepare nand read $loadaddr UserDef $filesize
    5. setenv splashimage $loadaddr
    6. saveenv

    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.

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

    Edited once, last by fs-support_HK ().

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

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

  • 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.


    Code
    1. setenv extra logo.nologo
    2. saveenv


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


    Your F&S Support Team

  • 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

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

  • 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:

    Shell-Script
    1. #!/bin/sh
    2. IMGFILE="/usr/share/splashscreen/splashscreen.ppm"
    3. /usr/local/bin/fbsplash -s "$IMGFILE"


    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:

    Code
    1. [Unit]
    2. Description=Show Plymouth Boot Screen
    3. DefaultDependencies=no
    4. Wants=systemd-ask-password-plymouth.path systemd-vconsole-setup.service
    5. After=systemd-vconsole-setup.service systemd-udev-trigger.service systemd-udevd.service
    6. Before=systemd-ask-password-plymouth.service basic.target
    7. ConditionKernelCommandLine=!plymouth.enable=0
    8. ConditionVirtualization=!container
    9. IgnoreOnIsolate=true

    I also set the UBoot bootargs to:

    Code
    1. setenv bootargs 'console=ttymxc3,115200 vt.global_cursor_default=0 quiet splash'

    and I changed the plymouth.conf file to:


    Code
    1. [Daemon]
    2. Theme=spinner
    3. Device=/dev/fb0


    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?

  • 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

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

  • 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.

    Shell-Script
    1. #!/bin/sh
    2. /sbin/plymouthd --attach-to-session
    3. /sbin/plymouth --show-splash

    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.