Posts by bkeohane

    I use I2C_C for the SGTL5000 audio codec, and my layout also used I2C_C for the HDMI EDID (SDA,SLC), may this cause the issue of a nun.functional HMDI output? Is there a pinmux for this?

    Hello,


    I have drawn and layoutet a HDMI connector onto a custom board, and I took the SINTF hardware documentation as template.

    On SINTF, HDMI is working, but not on my custom board. I took another look at the documentation and realized, there exists a HDMI_DDCCEC_AUX_P pin (J24 plug). This one is not shown on J6 plug. Do we need it?


    I have attached the layout and schematic of my custom PCB. Pin 154 is connected to GND while 156 is the HDMI_DDCCEC_AUX_N signal.


    Thanks!

    In my console output shared before, I noticed:


    Code
    1. imx-ipuv3 2400000.ipu: IPU Warning - IPU_INT_STAT_5 = 0x00800000
    2. imx-ipuv3 2400000.ipu: IPU Warning - IPU_INT_STAT_10 = 0x00100000

    After some investigation, I come to the conclusion, that clone mode is not stable on this hardware with fbdev.


    Would you also relate to this?

    For LVDS, I use


    For HDMI, it is


    Code
    1. #define CONFIG_EFUSA9_HDMI_BPP 32
    2. #define CONFIG_EFUSA9_HDMI_PIX_FMT "RGB24"
    3. #define CONFIG_EFUSA9_HDMI_MODE_STR "1280x720M@60"

    See attached file for full DTS settings. We use a custom display.

    Hello,

    Quote

    However, I thing it is important to unblank the HDMI display before starting weston with the clone mode.

    Is this done correctly?

    Yes. Before starting any weston instance, I unblanked fb2. The application on LVDS remains blurry rendered with color shifts.


    I have attached the console output, when starting Weston in two instances in clone-mode and starting my GUI app.


    Thanks!

    Hi,


    thanks for your answer. It works.


    However, I experience false colors of the application rendered on the LVDS screen, as soon as I unblank fb2/ clone to the second weston instance on HDMI.


    The colors on HDMI are correct, whatsoever. Feel free to check the image I attached, to see what happens.

    Any suggestions? I feel, the switch to the open source driver that supports DRM is doable but may be an overload, especially since the HDMI feature shall be very simple.


    May any Kernel display driver configs (e.g. IPU settings) or device tree configs help (hardware mirroring)?


    Thanks!

    Hi,


    thanks for your answer.

    Quote

    Another would be to try to use the same framebuffer for both outputs. This however would require the displays to support the same resolution.

    Would this be an option?

    Our LVDS display is 1280x800, and I set the HDMI resolution to 1280x720 in the device tree. If there are a few pixels missing on the bottom, it is ok. So yes, this would be a quick solution.


    Is it also done in the device tree? May it will work, if the HDMI monitor requires hotplugging?

    I tried to make the HDMI use the same IPU as LVDS:

    Code
    1. #ifdef CONFIG_EFUSA9_HDMI
    2. &hdmi_core {
    3.     ipu_id = <0>;
    4.     disp_id = <0>;
    5.     // ...
    6. }


    But it does not work. I assume, it is because of different display timings.


    Hence, I am asking myself, how to achive a simple copy of the LVDS output to the HDMI output.


    Thank you!

    Hello, I also have an issue regarding HDMI.


    We use efusA9R2 Quad and Yocto. Besides the Primary screen (DISPLAY_LVDS0) our application shall support a second optional screen connected via HDMI. The second screen shall mirror the first one.


    - We patched efusa9r2q.dts by setting


    Code
    1. +#define CONFIG_EFUSA9_MXCFB0    DISPLAY_LVDS0
    2. +#define CONFIG_EFUSA9_MXCFB1    DISPLAY_HDMI


    to enable the display. We were able to display our app via HDMI using EGLFS as follows:


    Code
    1. export QT_QPA_PLATFORM=eglfs
    2. export QT_QPA_EGLFS_FB=/dev/fb2
    3. ./qt_app

    - In our first approach we simply copied the framebuffer using ffmpeg


    - local.conf:

    - remove wayland and x11: DISTRO_FEATURES:remove = "x11 wayland"

    - add ffmpeg: IMAGE_INSTALL:append = " ffmpeg"


    - activate HDMI: Done by starting an app like :


    Code
    1. export QT_QPA_PLATFORM=eglfs
    2. export QT_QPA_EGLFS_FB=/dev/fb2
    3. ./qt_app


    - close the app (HDMI is active)


    - start ffmpeg

    Code
    1. ffmpeg -f fbdev -framerate 30 -i /dev/fb0 -vf "scale=1280:720" -f fbdev /dev/fb2


    -> works but it is delay by at least 1 sec

    -> the LVDS Display does not Show the Colors correctly


    Wayland and Weston

    Since a single instance of ur app shall be Display on multiple screens we added wayland/weston to our Image. This works on our Primary Display. However we were not able to get HDMI to work.


    Code
    1. IMAGE_INSTALL:append = " weston weston-init qtwayland"

    -> weston is started. properly and our app is started.


    However the second screen HDMI does not work.


    Code
    1. ls /sys/class/drm/

    Shows


    Code
    1. card0@ renderD128@ Version

    -> no HDMI ...

    We assume, there is a graphics driver issue on iMX6 and Weston, e.g., the drm driver is not found. Our goal is to let the Qt app discover the second display, and the Qt view instance will make a copy of itself to the second display, when it is found. It works well on Windows. However, on Yocto Linux, it fails, due to the drm driver not being found.

    Any hints on how to get a second view of a Qt app running on a HMDI monitor simultaneously would be great, either using EGLFS (which I assume does not work) or Weston.


    Thanks in advance!

    Hello,


    I've built a core-image-minimal-initramfs image to test its deployment in RAM, and I changed the image type to:

    Code
    1. IMAGE_FSTYPES += "cpio.gz.u-boot"


    I changed the fdt variable to:


    Code
    1. fdt=nand read 12000000 FDT; bootm 11000000 13000000 12000000


    I have created a NAND partition "RamDisk", I download and store the initramfs image to RAM address 0x13000000, and I write it to this partition.

    I have also changed the variable:


    Code
    1. rootfs root=/dev/ram0


    When I boot, I run into the following:



    But when the actual rootfs shall be mounted, there is an issue:



    If I set the rootfs variable back to default:


    Code
    1. rootfs=rootfstype=ubifs ubi.mtd=TargetFS root=ubi0:rootfs


    The ramdisk image is still successfully read, bit this time, the boot sequence runs into:



    I assume, there is a problem with handing over from the initramfs to the actual rootfs. Any suggestions?


    Thanks!

    Bjørn

    I changed


    Code
    1. fdt=nand read 12000000 FDT; bootm 11000000 - 12000000

    to


    Code
    1. fdt=nand read 13000000 FDT; bootm 11000000 - 13000000

    which works.


    I realized, when creating the rootfs on TargetFS partition, the size is not set correctly. A reboot after setting the partitions solved this issue.


    The topic can be regarded as closed,

    Hello,


    thank you for your answer.


    I have setup the partition table accordingly, using the mtdparts env variable:

    Code
    1. mtdparts=mtdparts=gpmi-nand:256k(NBoot)ro,768k(UserDef),256k(Refresh)ro,768k(UBoot)ro,256k(UBootEnv)ro,24m(Kernel)ro,1792k(FDT)ro,-(TargetFS)


    and I changed fdtaddr to 0x13000000:



    However, after installing the new Kernel image, and reinstalling FDT and rootfs image, I run into an error:



    It is weird, that it seems to still look for a FDT at 0x12000000:

    Code
    1. ## Flattened Device Tree blob at 12000000


    May this be the issue? I used the command:


    Code
    1. nand write $loadaddr FDT $filesize


    to install the FDT. It seems counterintuitive, since the $loadaddr variable holds the address 0x11000000, but the output of writing to NAND was:


    Code
    1. efusA9r2 # nand write . FDT $filesize
    2. NAND write: device 0 offset 0x1a40000, size 0xbe16
    3. 48662 bytes written: OK


    So, it did write to the correct offset, as it seems.

    Is there any other address I need to change, or maybe I should use the command:


    Code
    1. nand write 0x13000000 FDT $filesize


    Thanks again for your support.

    Hello,


    I have built an Kernel image with a bundled initramfs, to show a bootscreen very early using Plymouth. The Kernel image is about 20 MB in size. The default partition size for the Kernel (address $Kernel in U-Boot) is 7 MB in size.


    I have repartitioned the Kernel partition using mkpart in U-Boot, by taking some memory space from the TargetFS. I made sure, the offsets and sizes of all partitions fit. When downloading and installing the Kernel image incl. initramfs to my Kernel partition, I boot into a kernel panic.


    Is there any reason behind this? I asked myself, can I not modify the partitions and its sizes inside a Yocto layer, by e.g., patching the u-boot configuration file (fsimx6.h)?


    Any hint on partitioning and making the bundled kernel image run would be helpful!


    Thank you.

    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.

    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?

    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

    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?