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?
Posts by bkeohane
-
-
Yes, you are correct, I use an eFusa9r2. I accidently posted into armstone, sorry.
I will have a look, thanks for your suggestions! -
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!
-
I adjusted my device tree as you porposed, but I am afraid, it did not work.
-
In my console output shared before, I noticed:
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
Code- #define CONFIG_EFUSA9_LVDS0_BPP 32
- #define CONFIG_EFUSA9_LVDS0_PIX_FMT "RGB888"
- #define CONFIG_EFUSA9_LVDS0_DATA_WIDTH 24
- #define CONFIG_EFUSA9_LVDS0_MAPPING "spwg"
- #define CONFIG_EFUSA9_LVDS0_TIMING \
- wvga { \
- clock-frequency = <72400000>; \
- hactive = <1280>; \
- vactive = <800>; \
- hfront-porch = <76>; \
- hback-porch = <80>; \
- hsync-len = <4>; \
- vback-porch = <17>; \
- vfront-porch = <17>; \
- vsync-len = <1>; \
- de-active = <1>; \
- pixelclk-active = <0>; \
- }
For HDMI, it is
See attached file for full DTS settings. We use a custom display.
-
Hello,
QuoteHowever, 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!
-
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.
QuoteAnother 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: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
to enable the display. We were able to display our app via HDMI using EGLFS as follows:
- 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 :
- close the app (HDMI is active)
- start ffmpeg
-> 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.
-> weston is started. properly and our app is started.
However the second screen HDMI does not work.
Shows
-> 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:
I changed the fdt variable to:
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:
When I boot, I run into the following:
Code- Loading from nand0, offset 0x240000
- zImage detected
- NAND read: device 0 offset 0x1240000, size 0x1c0000 1835008 bytes read: OK
- ## Booting kernel from zImage at 11000000
- ## Loading init Ramdisk from Legacy Image at 13000000 ... Image Name: core-image-minimal-initramfs-fsi Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 5526515 Bytes = 5.3 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK
- ## Flattened Device Tree blob at 12000000 Booting using the fdt blob at 0x12000000 Loading Kernel Image Loading Ramdisk to 4ee0d000, end 4f3523f3 ... OK Using Device Tree in place at 12000000, end 1200ee15 Setting run-time properties
- ## Overwriting property gpmi-nand@00112000/fus,ecc_strength from device tree!
- ## Overwriting property bdinfo/ecc_strength from device tree!
- ## Keeping property bdinfo/board_name from device tree!
- Starting kernel ...
But when the actual rootfs shall be mounted, there is an issue:
Code- Run /init as init process
- Starting version 250.5+
- mtdblock: MTD device 'NBoot' is NAND, please consider using UBI block devices instead.
- mtdblock: MTD device 'UserDef' is NAND, please consider using UBI block devices instead.
- mtdblock: MTD device 'Refresh' is NAND, please consider using UBI block devices instead.
- mtdblock: MTD device 'UBoot' is NAND, please consider using UBI block devices instead.
- mtdblock: MTD device 'UBootEnv' is NAND, please consider using UBI block devices instead.
- mtdblock: MTD device 'Kernel' is NAND, please consider using UBI block devices instead.
- mtdblock: MTD device 'RamDisk' is NAND, please consider using UBI block devices instead.
- mtdblock: MTD device 'FDT' is NAND, please consider using UBI block devices instead.
- mtdblock: MTD device 'TargetFS' is NAND, please consider using UBI block devices instead.
- Waiting for removable media... 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0...
- Mounted filesystems
- Available block devices
- major minor #blocks name
- 1 0 8192 ram0 1 1 8192 ram1 1 2 8192 ram2 1 3 8192 ram3 1 4 8192 ram4 1 5 8192 ram5 1 6 8192 ram6 1 7 8192 ram7 31 0 256 mtdblock0 31 1 768 mtdblock1 31 2 256 mtdblock2 31 3 768 mtdblock3 31 4 256 mtdblock4 31 5 8192 mtdblock5 31 6 8192 mtdblock6 31 7 1792 mtdblock7 31 8 241664 mtdblock8 179 0 3817472 mmcblk2
- Cannot find rootfs.img file in /run/media/* , dropping to a shell
If I set the rootfs variable back to default:
The ramdisk image is still successfully read, bit this time, the boot sequence runs into:
Code- Run /init as init process
- Starting version 250.5+
- mtdblock: MTD device 'UserDef' is NAND, please consider using UBI block devices instead.
- mtdblock: MTD device 'NBoot' is NAND, please consider using UBI block devices instead.
- mtdblock: MTD device 'Refresh' is NAND, please consider using UBI block devices instead.
- mtdblock: MTD device 'UBoot' is NAND, please consider using UBI block devices instead.
- mtdblock: MTD device 'UBootEnv' is NAND, please consider using UBI block devices instead.
- mtdblock: MTD device 'Kernel' is NAND, please consider using UBI block devices instead.
- mtdblock: MTD device 'RamDisk' is NAND, please consider using UBI block devices instead.
- mtdblock: MTD device 'FDT' is NAND, please consider using UBI block devices instead.
- mtdblock: MTD device 'TargetFS' is NAND, please consider using UBI block devices instead.
- root 'ubi0:rootfs' doesn't exist or does not contain a /dev.
I assume, there is a problem with handing over from the initramfs to the actual rootfs. Any suggestions?
Thanks!
Bjørn
-
I changed
to
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:
and I changed fdtaddr to 0x13000000:
Code- efusA9r2 # mtdparts
- device nand0 <gpmi-nand>, # parts = 8
- #: name size offset mask_flags
- 0: NBoot 0x00040000 0x00000000 1
- 1: UserDef 0x000c0000 0x00040000 0
- 2: Refresh 0x00040000 0x00100000 1
- 3: UBoot 0x000c0000 0x00140000 1
- 4: UBootEnv 0x00040000 0x00200000 1
- 5: Kernel 0x01800000 0x00240000 1
- 6: FDT 0x001c0000 0x01a40000 1
- 7: TargetFS 0x0e400000 0x01c00000 0
- active partition: nand0,0 - (NBoot) 0x00040000 @ 0x00000000
However, after installing the new Kernel image, and reinstalling FDT and rootfs image, I run into an error:
Code- NAND read: device 0 offset 0x1a40000, size 0x1c0000
- Non-correctable error in page at 0x01a40800
- Non-correctable error in page at 0x01a41000
- Non-correctable error in page at 0x01a41800
- Non-correctable error in page at 0x01a42000
- Non-correctable error in page at 0x01a42800
- Non-correctable error in page at 0x01a43000
- Non-correctable error in page at 0x01a43800
- Non-correctable error in page at 0x01a44000
- Non-correctable error in page at 0x01a44800
- Non-correctable error in page at 0x01a45000
- Non-correctable error in page at 0x01a45800
- Non-correctable error in page at 0x01a46000
- Non-correctable error in page at 0x01a46800
- Non-correctable error in page at 0x01a47000
- Non-correctable error in page at 0x01a47800
- Non-correctable error in page at 0x01a48000
- Non-correctable error in page at 0x01a48800
- Non-correctable error in page at 0x01a49000
- Non-correctable error in page at 0x01a49800
- Non-correctable error in page at 0x01a4a000
- Non-correctable error in page at 0x01a4a800
- Non-correctable error in page at 0x01a4b000
- Non-correctable error in page at 0x01a4b800
- NAND read failed at 0x01a40000 with error -74
- 0 bytes read: ERROR
- ## Booting kernel from zImage at 11000000
- ## Flattened Device Tree blob at 12000000
- Booting using the fdt blob at 0x12000000
- Loading Kernel Image
- Using Device Tree in place at 12000000, end 1200ee15
- fdt_find_or_add_subnode: memory: FDT_ERR_BADSTRUCTURE
- ERROR: arch-specific fdt fixup failed
- - must RESET the board to recover.
- FDT creation failed! hanging...### ERROR ### Please RESET the board ###
It is weird, that it seems to still look for a FDT at 0x12000000:
May this be the issue? I used the command:
to install the FDT. It seems counterintuitive, since the $loadaddr variable holds the address 0x11000000, but the output of writing to NAND was:
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: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.
Code- # bootscreen-initramfs-image.bb
- SUMMARY = "Custom initramfs image with Plymouth for boot splash"
- DESCRIPTION = "An initramfs image including Plymouth to show a boot splash screen."
- FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
- # Init script is installed
- SRC_URI += "file://init"
- FILES:${PN} += "/init"
- do_install:append() {
- install -m 0755 ${WORKDIR}/init ${D}/init
- install -d ${D}${datadir}/plymouth/themes/spinner-theme
- cp -r ${WORKDIR}/spinner-theme/* ${D}${datadir}/plymouth/themes/spinner-theme/
- }
- INITRAMFS_SCRIPTS ?= "\
- initramfs-framework-base \
- initramfs-module-setup-live \
- initramfs-module-udev \
- "
- PACKAGE_INSTALL = " \
- ${INITRAMFS_SCRIPTS} \
- ${VIRTUAL-RUNTIME_base-utils} \
- udev \
- base-passwd \
- ${ROOTFS_BOOTSTRAP_INSTALL} \
- busybox \
- e2fsprogs-mke2fs \
- udev \
- plymouth \
- "
- # Do not pollute the initrd image with rootfs features
- IMAGE_FEATURES = ""
- export IMAGE_BASENAME = "bootscreen-initramfs-image"
- #export IMAGE_BASENAME = "${MLPREFIX}bootscreen-initramfs-image"
- IMAGE_NAME_SUFFIX ?= ""
- IMAGE_LINGUAS = ""
- LICENSE = "MIT"
- #IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
- IMAGE_FSTYPES = "cpio.gz"
- inherit core-image
- # Set up Plymouth default configurations
- IMAGE_ROOTFS_SIZE = "16384"
- IMAGE_ROOTFS_EXTRA_SPACE = "0"
- # Add Plymouth configuration and service setup
- do_rootfs[depends] += "plymouth:do_populate_sysroot"
- IMAGE_INSTALL:append = " plymouth plymouth-theme spinner-theme"
- # Plymouth needs systemd and udev for proper functionality in initramfs
- SYSTEMD_PACKAGES = "systemd systemd-udevd"
- # Use the same restriction as initramfs-module-install
- COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|aarch64.*)-(linux.*|freebsd.*)'
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 documentationThanks.
-
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:
CodeIt 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- [Unit]
- Description=Show Plymouth Boot Screen
- DefaultDependencies=no
- Wants=systemd-ask-password-plymouth.path systemd-vconsole-setup.service
- After=systemd-vconsole-setup.service systemd-udev-trigger.service systemd-udevd.service
- Before=systemd-ask-password-plymouth.service basic.target
- ConditionKernelCommandLine=!plymouth.enable=0
- ConditionVirtualization=!container
- IgnoreOnIsolate=true
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?
-
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?
-
is this solution still valid under fsimx6-Y2024.04 for eFus i.MX6 Quad? And does it get rid of the penguins?