Posts by fs-support_PG

    Hello,


    maybe the time between the frames is to long, so the CPU goes into idle mode and maybe it takes to long to recover from idle mode to render the next frame.

    USB and dd may keep the CPU to go into idle mode.


    Could you try to disable the CPU idle mode entirely, and see if it has influence on the performance?


    Go to U-Boot and set the following environment variable and boot:

    Code
    1. setenv extra cpuidle.off=1
    2. boot



    In Linux you could also try to disable the memory bus frequency scaler. Maybe this has also an effect on the performance.

    Code
    1. echo 0 > /sys/bus/platform/drivers/imx_busfreq/busfreq/enable


    Your F&S Support Team

    Some Customers reported an error while downloading the sources with setup-yocto.


    Quote

    Repo command failed due to the following `SyncError` errors:

    GitCommandError: 'update-ref --no-deref HEAD 577d041a39a02e152461919698745368144720d5' on poky failed

    stderr: fatal: update_ref failed for ref 'HEAD': cannot update ref 'HEAD': trying to write non-commit object 577d041a39a02e152461919698745368144720d5 to branch 'HEAD'


    If this error occurs for you please change the following line in the file fsimx6-Y2024.04/fs-release-manifest.xml


    Code
    1. <!-- Update poky to 4.0.16 -->
    2. <project name="poky" path="yocto-fus/sources/poky" remote="yocto" revision="577d041a39a02e152461919698745368144720d5" upstream="kirkstone"/>

    to

    Code
    1. <!-- Update poky to 4.0.16 -->
    2. <project name="poky" path="yocto-fus/sources/poky" remote="yocto" revision="54af8c5e80ebf63707ef4e51cc9d374f716da603" upstream="kirkstone"/>


    This will only change the way the git commit is referenced. The source code stays the same.


    Your F&S Support Team

    Some Customers reported an error while downloading the sources with ./setup-yocto.


    Repo command failed due to the following `SyncError` errors:

    GitCommandError: 'update-ref --no-deref HEAD 577d041a39a02e152461919698745368144720d5' on poky failed

    stderr: fatal: update_ref failed for ref 'HEAD': cannot update ref 'HEAD': trying to write non-commit object 577d041a39a02e152461919698745368144720d5 to branch 'HEAD'


    If this error occurs for you please change the following line in the file fsimx6ul-Y2024.03/fs-release-manifest.xml


    Code
    1. <!-- Update poky to 4.0.16 -->
    2. <project name="poky" path="yocto-fus/sources/poky" remote="yocto" revision="577d041a39a02e152461919698745368144720d5" upstream="kirkstone"/>

    to

    Code
    1. <!-- Update poky to 4.0.16 -->
    2. <project name="poky" path="yocto-fus/sources/poky" remote="yocto" revision="54af8c5e80ebf63707ef4e51cc9d374f716da603" upstream="kirkstone"/>


    This will only change the way the git commit is referenced. The source code stays the same.


    Your F&S Support Team

    Hello,


    The uvc driver seems to provide some module parameters.

    https://github.com/torvalds/li…sb/uvc/uvc_driver.c#L2624

    Did you try to set some of them? Maybe the UVC_QUIRK_FIX_BANDWIDTH?

    Code
    1. modprobe uvcvideo quirks=0x80


    I found some commands online to increase the debug output of uvcvideo. Did you try already try to apply them?

    Code
    1. echo 0xffff > /sys/module/uvcvideo/parameters/trace
    2. echo 0 > /sys/module/uvcvideo/parameters/trace



    Your F&S Support Team

    Hello,


    The U-Boot is placed in a fixed RAW partition, so Nboot does not care about the partition table.

    The fsim6ul U-Boot however needs the partition table to load Linux so you will have to make sure that GPT support is available here.


    We have not tested it so far though.


    Your F&S Support Team

    Hello,


    yes, for fsimx6ul the U-boot is expected the User Partition. This has historical reasons, because early eMMC chips had smaller boot partitions, which may not be sufficient for future Bootloader sizes. It is more complicated to update the partition layout with the old fsimx6 Nboot than with fsimx8mm, so we stayed at this layout for fsimx6ul and are currently not planning to change it.


    When building for fsimx6ul the Uboot should be automatically put into the u-boot partition of the sysimage:


    https://github.com/FSEmbedded/…machine/fsimx6ul.conf#L27

    https://github.com/FSEmbedded/…fus-uboot-bootpart.wks.in


    So it should be no problem to update the sysimage if it was build with the correct machine config in>octo.


    Which release do you use?


    Your F&S Support Team

    Hello,


    Quote

    However, I can not find this type on your website anymore, probably changed again.

    This is a customer specific Variant, so it is not listed on the website.

    Quote

    From my understanding this basically means that the serial port /dev/ttyLP1 (UARTB) is not available on PicoCore imx93 pcbs with Wi-Fi module? Right?

    Yes this is correct. The WLAN chip will drive the RX Pin of the UART so it might come to short circuits if both is connected.


    Your F&S Support Team

    Hello,


    you do not build Weston, right? Could you try to build the mainline version and add it to your image and test if it works there?


    Please make sure to add

    Code
    1. BR2_PACKAGE_WESTON=y
    2. BR2_PACKAGE_WESTON_DRM=y
    3. BR2_PACKAGE_WESTON_DEFAULT_DRM=y

    and remove

    Code
    1. BR2_PACKAGE_WESTON_IMX_FBDEV=y

    from your defconfig, and also remove


    Code
    1. use-g2d=1

    form your weston.ini.


    Also make sure that these mesa configs are active:

    Code
    1. BR2_PACKAGE_MESA3D=y
    2. BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_ETNAVIV=y
    3. BR2_PACKAGE_MESA3D_OPENGL_ES=y
    4. BR2_PACKAGE_MESA3D_OPENGL_EGL=y



    Your F&S Support Team

    Hello,


    could you try using the PLL2 for your LVDS display?

    HDMI also uses PLL5 for pixel clock generation. SO driving two different resolutions from a singe clock might me problematic.


    Please try these changes and play around with different resolutions.


    If this still does not work, I can again offer an online meeting next week. Please contact F&S support via mail for this.


    Your F&S Support Team

    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