Posts by fs-support_PG

    Hello,


    could you test the following command?


    Code
    1. echo "ci_hdrc.1" > /sys/bus/platform/drivers/ci_hdrc/unbind


    i think echo 'usb1' > /sys/bus/usb/drivers/usb/unbind does not unload the whole usb stack. there is still a hub device left, which seems to claim the vbus control.


    Your F&S Support Team

    Hello,


    did you test the regulator implementation?


    using the regulator gpio implementation would not mean direct control. The driver would control the USB power with a linux regulator device and not the USB_OTG_PWR pin.

    The USB_OTG_PWR pin is mainly used for OTG use cases where the USB port has to support HOST and DEVICE functionally. This means that the VBUS power is mainly connected to the USB ID state and if it is set to "host" the power will not go down.

    Changes are, that if the driver gets unloaded and the power is driven by a linux regulator, the regulator will get freed and the power will go down.




    Your F&S Support Team

    Hello,


    as you can see from the Device Tree the the VBUS power is controlled via hardware by the USB_OTG_PWR pin, not the GPIO pin:


    https://github.com/FSEmbedded/…oot/dts/efusa9x.dts#L1825

    https://github.com/FSEmbedded/…sa9x.dts#L1200C7-L1200C11

    https://github.com/FSEmbedded/…boot/dts/efusa9x.dts#L513


    The pinmux is not at GPIO, so you cannot control it with the GPIO commands.

    I am nor sure, why the USB_OTG_PWR keeps the power when unloading the driver.

    However, you can try to switch to the GPIO implementation by commenting/uncommenting the respective lines in the device tree I posted.


    Your F&S Support Team

    Hello,


    We added an example on how to use the etnaviv driver with an efusa9 some releases ago.

    Hower, this might differ a little, depending on which display and board type is used.


    to activate the etnaviv driver, there are several steps, that need to be done.


    1. Use the fsimx6_etnaviv_defconfig

    https://github.com/FSEmbedded/…/fsimx6_etnaviv_defconfig

    2. Make some adjustments to the Device Tree: See

    https://github.com/FSEmbedded/…t/dts/efusa9q-etnaviv.dts

    3. Make some adjustments to the Buildroot defconfig

    https://github.com/FSEmbedded/…iv_experimental_defconfig


    However the Buildroot has not been fully tested with the B2024.04 release, so there could be some issues here.

    Mostly, you need to make sure that the Mesa driver has the etnaviv config activated.


    Your log indicates, that the main issue seems to be your display.

    There is an example in the device tree on how to use a LVDS display. Maybe you can try to adapt this to your Device Tree?

    https://github.com/FSEmbedded/…s/efusa9q-etnaviv.dts#L52

    https://github.com/FSEmbedded/…s/efusa9q-etnaviv.dts#L98


    Your F&S Support Team

    Did you try this?


    Code
    1. killall weston
    2. echo 0 > /sys/class/graphics/fb2/blank
    3. echo 16 >/sys/class/graphics/fb2/bits_per_pixel
    4. weston --tty=1 --device=/dev/fb0,/dev/fb2 --clone-mode &

    from https://community.nxp.com/t5/i…put-messed-up/m-p/1778606


    Maybe also with fb0?


    I don' see the IPU warnings as an acute issue. These may occur on high system load and maybe loading both displays causes a lot of load.

    If they do not occur regular, i think you can ignore them for nor.


    You can also try to reduce the resolution of your HDMI display if possible. This should cause less load.


    Code
    1. # Get available modes
    2. cat /sys/class/graphics/fb2/modes
    3. echo <yourMode> > /sys/class/graphics/fb2/mode


    You can also contact us directly by mail if you need support via meeting.


    Your F&S Support Team

    Hello,


    we did not notice any color change, when enabling the clone-mode on any display.

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

    Is this done correctly?


    Your F&S Support Team

    Hello,


    please test the following:


    Set fb0 to lvds and fb1 to hdmi in your device tree

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


    Boot your board and run the following commands:

    Code
    1. killall weston
    2. echo 0 > /sys/class/graphics/fb2/blank
    3. weston --tty=1 --device=/dev/fb0,/dev/fb2 --clone-mode &


    This should open a weston instance, that mirrors the framebuffer from /dev/fb0 to /dev/fb1.

    It worked in our tests with fsimx6-Y2024.04


    Your F&S Support Team

    Hello,


    I think the main issue here is, that NXPs i.MX6 i GPU Vivante driver does not support DRM, but only the deprecated framebuffer-backend.

    And I don't think the will support DRM for i.MX6 in the future.

    https://github.com/nxp-imx/met…/imx-base-extend.inc#L107


    One approach would be, to switch to the open source Etnaviv driver, which supports the DRM backend.


    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?


    Your F&S Support Team

    I can confrim, that it does not work without the HW fix on the BBDSI. It does not get any link



    With the fix it loads it gets the connection and loads the driver


    Code
    1. root@fsimx8mp:~# lspci
    2. 00:00.0 PCI bridge: Synopsys, Inc. DWC_usb3 / PCIe bridge (rev 01)
    3. 01:00.0 SATA controller: ASMedia Technology Inc. ASM1061/ASM1062 Serial ATA Controller (rev 02)


    We added the capacities on the BBDSI on these lanes:



    Could you check your fix again?