Posts by BrenkeM

    I checked out the BUILDROOT symboles and noticed that the i.MX platform (imx6sl/imx6sx) ---> has only a GPU but no VPU. According [1], the i.MX 6SoloX Processor contains a Vivante GC400T GPU, which is not a VPU. Regarding this information, I configured the BUILDROOT system according [2] and the Linux Kernel according [3].




    I wand to accelerate video decoding via ffmpeg using the internel imx6 VPU on the efusA9X module. Currently ffmpeg is running on our headless system and does all decoding in software (CPU). But I want wo enable hardware acceleration using the internel VPU. Is there any detailed instructions how to achive this? I currently researched the following links:

    libimxvpuapi - frontend for i.MX hardware video codecs:

    i.MX 6Dual/6Quad VPU Application Programming Interface Linux Reference Manual:…_API_RM_L3.0.35_1.1.0.pdf

    To adapt the buildroot configuration for using the mainline kernel I changed the following parts:

    - changed linux folder (linux-fsimx6sx) to git repo of mainline kernel

    - prepair the changes under [1]

    - build image and load according uboot procedure under [0]


    Starting and running system completely in RAM (from UBOOT)


    Sometime it would be nice to only run the current release of a F+S module with a mainline kernel, for example to check if bugs where fixed in newer versions or to develop patches for pushing them to the mainline source code later.

    What do we need to do, to build and run the current buildroot fsimx6sx-B2019.11 release with the current mainline kernel (5.18.0) from

    To simplify the procedure above, I recommend to prepare a cpio image:

    Then you can (for example on a efusA9X module) run the following commands in the uboot shell:

    1. tftpboot . zImage
    2. tftpboot ${fdtaddr} efusa9x.dtb
    3. tftpboot 83000000 rootfs.cpio.uboot
    4. setenv bootargs "console=ttymxc0,115200 login_tty=ttymxc0,115200 root=/dev/ram0 ramdisk_size=0x${filesize} rootfstype=cpio rw"
    5. bootz 81000000 83000000 82000000

    To run a system without any ROM completely in RAM, on a efusa9x module, I tried the following steps, but failed to load the ROOTFS in the RAM from the LINUX kernel.

    Following the steps here to configured a minimal system and started it from RAM:…o_boot_imx_using_ramdisk/

    The used buildroot configuration for the filesystem is the following:

    And starting the system with the following UBOOT commands leads to the error under [1]:



    Additional I tried to define the ROOTFS by its address and size like mentioned here:

    1. tftpboot . ${bootfile}
    2. tftpboot ${fdtaddr} ${bootfdt}
    3. tftpboot 83000000 rootfs.ext2.gz.uboot
    4. #setenv initrd_size ${filesize}
    5. #setenv bootargs 'console=ttymxc0,115200 login_tty=ttymxc0,115200 root=/dev/ram rw'
    6. setenv bootargs "console=ttymxc0,115200 login_tty=ttymxc0,115200 root=/dev/ram0 rd_start=83000000 rd_size=${filesize} rootfstype=ext2 rw"
    7. bootz 81000000 83000000 82000000

    But this results in the same error as in [1].

    How can I successfully let the kernel find the root filesystem?

    Hi, do you build your LINUX system with Buildroot or Yocto?

    For buildroot simple set the following option to include the ssh server into your build:

    Afterwards, build the image again and load it to the system, than you should check the following directory on your embedded system:

    1. $ ls /etc/init.d/
    2. rcK … S50dropbear … rcS

    To patch the kernel we can simple follow one of the tutorials online (see [1]).

    But for the kernel version 4.9.88 we can not find a matching rt patch. But a older one is working nice for this issue, see [2].

    This will patch the kernel ready for compilation, but it is recommended to adjust the realtime priorities, see [3] for this. Otherwise a realtime application can sporadically block your system.

    I also attached both patches for every one how wants to use it.





    To handle application in the Linux userspace in hard realtime the current LINUX kernel 4.9.88 must be patched.

    This is because LINUX does not include all realtime patches from the PREEMT RT version (which is the preferred realtime implementation from LINUX Kernel developers). Newer kernel will less differ from a fully PREEMPT RT kernel version.

    So, how do we have to patch the Kernel from the efusA9X release to gain full realtime support?

    To use the ads1118 ADC IC via an SPI interface with the current efusA9X kernel (4.9.88) it is necessarry to add a driver to the kernel space.

    After some research I found a kernel driver implementation under [1]. I collected all information (code+docs) and implemented them into the current kernel with the attached patch under [2]. After adding the node to the device tree (convertig spidev to adc node (see [3])), I testing the driver successfully for a half day.

    @F+S: I request to implement this patch to your kernel sources.

    Best regards.




    I also would like to request that the adc nodes in the device tree will be configurable through macros like other hardware too.

    Please patch also the device tree also on your (F+S) side.

    P.s.: Sorry but I need to rename the patch file because the website is not accepting a file suffix like "patch":

    $ mv 0001-add_adc_node_control.patch.txt 0001-add_adc_node_control.patch


    I just want to share my investigation regarding the ADCs and how I got it working:

    [1] provides a overview about the ADCs numbers, channels and devicefiles. The kernel support can be enabled via [2] and [3] provides a overview about the devicefiles in the filesystem. To calculate the voltage on the pin, see [4]. Furthermore, I contacted F+S to produce efusA9X modules with the missing parts. Until the production will be adjusted please take a look at the attached picture and [5], which provides the information what resistor network IC is missing and where it needs to be placed. Hopefully the efusA9X module will be updated soon.

    @F+S: Please check if everything here is correct and please tell us know when the production was adjusted.


    1. ADC# | channels| pin | /sys/bus/iio/devices/iio\:
    2. ----------------------------------------------------------------------------
    3. adc1 | ADC_A | 44 | device0/in_voltage0_raw
    4. adc1 | ADC_B | 42 | device0/in_voltage1_raw
    5. adc2 | ADC_C | 40 | device1/in_voltage0_raw
    6. adc2 | ADC_D | 38 | device1/in_voltage1_raw


    1. Device Drivers --->
    2. Industrial I/O support --->
    3. Analog to digital converters --->
    4. Freescale vf610 ADC driver



    1. Multiply the value of "/sys/bus/iio/devices/iio:device0/in_voltage_scale" with the value of "/sys/bus/iio/devices/iio:device{0,1}/in_voltage{0,1}_raw".



    I noticed that if I strip down the "fsimx6sx_min_defconfig" I am limited of the filesystem size to 7110656 bytes, when I am using buildroot.

    So for example I create a system and load it to check the disk free space: I see that I only use 5.1 MB (see [1]). But the created and loaded ubifs image is bigger than this (~7 MB, see [2]).

    Does this have to so with the options:




    I also checked the docu under [3], but could not find a suitable answer. For example how can I create a ubifs image that takes only 3 or 4 MB of space?


    # df -h

    Filesystem Size Used Available Use% Mounted on

    ubi0:rootfs 214.1M 5.1M 209.1M 2% /


    $ du -b output/images/rootfs.ubifs

    7110656 output/images/rootfs.ubifs