Posts by fs-support_PJ

    Hello,


    in the latest fsimx6-V3.1 release we didn´t test the PCIe interface. That´s why it´s commented out. Internally we have tested PCIe with a newer kernel version and it works fine. I would say it also should work with fsimx6-V3.1 release.


    To activate PCIe you have to do the following steps:

    1. Activate &pcie node in device tree
    2. Activate CONFIG_PCI and PCI_IMX6 in kernel menuconfig
    3. Rebuild kernel


    Your F&S Support Team

    How to setup a specific display on F&S boards?


    The displays will be setup in the device tree. Our device trees are configured for our default displays:

    • LVDS (old: CHI MEI G070Y2 / new: J070WVTC0211)
    • LCD (ET070080DH6)

    If you want to setup your specific display, it is mandatory to have the display datasheet. There are all necessary informations for setup. Below you can find a chart explaining timings of a display.


    [IMG:http://processors.wiki.ti.com/images/e/e4/Lcd_datasheet_to_linux.jpg]


    First of all I will explain how to setup a LVDS display.


    LVDS Display:


    First of all you have to open your device tree file (.dts) of your specific board, e.g. armstonea9dl.dts.


    There you will find an entry which looks like below:


    1. At the beginning you have to choose the mapping of the signals. You can choose between spwg and jeida, in the source code (above) you find the explanation what is the difference. You can get the mapping information from the display datasheet.
    2. BPP is bits per pixel, you can take the default value 32.
    3. PIX_FMT is the pixel format. RGB666 means 18 Bit data lines - 6 red, 6 green and 6 blue. E.g. if you have 24 bit data lines then it should be RGB24.
    4. DATA_WIDTH correlate to PIX_FMT if you have 18 bit data lines then setup 18, if you have 24 bit data lines then 24.
    5. The last part is the timing configuration.
      • clock-frequency is the pixel clock of the display in MHz, by default 33,5 MHz.
      • hactive is the horizontal active time (solution), by default 800, because display solution is 800x480.
      • vactive is the vertical active time (solution), by default 480, because display solution is 800x480.
      • hfront-porch is the time between the end of valid data and the beginning of the sync pulse in horizontal direction.
      • hback-porch historically refers to the period of time between the end of the sync pulse and the beginning of valid data in horizontal direction.
      • hsync-len indicating the start of the next line in horizontal direction.
      • vback-porch historically refers to the period of time between the end of the sync pulse and the beginning of valid data in vertical direction.
      • vfront-porch is the time between the end of valid data and the beginning of the sync pulse in vertical direction.
      • vsync-len indicating the start of the next line in vertical direction.
      • hsync-active means if 1 = hsync is active high, 0 means active low.
      • vsync-active means if 1 = hsync is active high, 0 means active low.
      • de-active means if 1 = de is active high, 0 means active low.
      • pixelclk-active means if 1 = pixelclk data on positiv edge, 0 means negative edge.

    Normally in the display datasheet there is a parameter called H/V-SYNC-PERIOD. This parameter is the whole period of the display, you can calculate it.

    HSYNC_PERIOD = hactive + hfront-porch + hback-porch + hsync-len

    VSYNC_PERIOD = vactive + vfront-porch + vback-porch + vsync-len


    If you can´t read out the front-porch, back-porch or syn-len then split it, so that the sum of the single parameters is equal to SYNC_PERIOD.


    After everything is setup then go to the top of your dts file and change it to


    #define CONFIG_ARMSTONEA9_MXCFB0 DISPLAY_LVDS0


    After that you can recompile your device tree


    make armstonea9dl.dtb


    And install it on your board.


    LCD Display:


    For the LCD display there are two possibilities, for the i.MX 6 CPU, you have to open your device tree file (.dts) of your specific board, e.g. armstonea9dl.dts and the LCDIF driver mxc_lcdif.c in drivers/video/fbdev/mxc. If you have an i.MX6SX or i.MX6UL/ULL CPU e.g. efusA9X, you just have to open your device tree file (.dts).


    In the device tree you will find the following entry:


    Code
    1. /*
    2. * Configure LCD settings here (ignored if LCD is not used);
    3. * see drivers/video/fbdev/mxc/mxc_lcdif.c for possible LCD mode strings
    4. */
    5. #define CONFIG_ARMSTONEA9_LCD_BPP 32
    6. #define CONFIG_ARMSTONEA9_LCD_PIX_FMT "RGB666"
    7. #define CONFIG_ARMSTONEA9_LCD_MODE_STR "LCD-ET070080"


    If you have an i.MX 6 CPU (e.g. armstonea9dl), then you have setup the display timings via the MODE_STR, see below.

    1. BPP is bits per pixel, you can take the default value 32.
    2. PIX_FMT is the pixel format. RGB666 means 18 Bit data lines - 6 red, 6 green and 6 blue. E.g. if you have 24 bit data lines then it should be RGB24.
    3. MODE_STR belongs to a string which you can find in the mxc_lcdif.c. Default string is LCD-ET070080. This string implies the display timings.
    • You can have a look in mxc_lcdif.c, if you're lucky there is a string which has the correct timings for your display. If not, you have to add an entry with you specific display timings.
    • If you have to create own display specific timings, then you have to add an entry. The struct fb_videomode has the following parameters:
    1. name is a character pointer which is optional.
    2. refresh is the refresh rate of the display and it is also optional.
    3. xres = hactive is the horizontal active time (solution), by default 800, because display solution is 800x480.
    4. yres = vactive is the vertical active time (solution), by default 480, because display solution is 800x480.
    5. pixclock is the pixel clock of the display in pico seconds. s = 1 / f => = 106 / MHz
    6. left margin = hback-porch historically refers to the period of time between the end of the sync pulse and the beginning of valid data in horizontal direction.
    7. right margin = hfront-porch is the time between the end of valid data and the beginning of the sync pulse in horizontal direction.
    8. upper margin = vback-porch historically refers to the period of time between the end of the sync pulse and the beginning of valid data in vertical direction.
    9. lower margin = vfront-porch is the time between the end of valid data and the beginning of the sync pulse in vertical direction.
    10. hsync_len indicating the start of the next line in horizontal direction.
    11. vsync-len indicating the start of the next line in vertical direction.
    12. sync you can take a look to include/uapi/linux/mxcfb.h for possibilities.
    13. vmode is normally FB_VMODE_NONINTERLACED. You can have a look to include/uapi/linux/fb.h for possibilities.
    14. flag normally 0


    Normally in the display datasheet there is a parameter called H/V-SYNC-PERIOD. This parameter is the whole period of the display, you can calculate it.


    HSYNC_PERIOD = hactive + hfront-porch + hback-porch + hsync-len

    VSYNC_PERIOD = vactive + vfront-porch + vback-porch + vsync-len


    If you can´t read out the front-porch, back-porch or syn-len, then split it, so that the sum of the single parameters is equal to SYNC_PERIOD.


    After everything is setup go to the top of your dts file and change it to


    #define CONFIG_ARMSTONEA9_MXCFB0 DISPLAY_LCD


    After that you can recompile your device tree and your kernel


    make armstonea9dl.dtb

    make uImage


    And install kernel and device tree it on your board.



    If you have an i.MX 6SX or an i.MX 6UL/ULL CPU (e.g. efusa9x) then you have to setup the display timings in device tree, see below.


    The timings are the same like LVDS above.


    1. BPP is bits per pixel, you can take the default value 32.
    2. PIX_FMT is the pixel format. RGB666 means 18 Bit data lines - 6 red, 6 green and 6 blue. E.g. if you have 24 bit data lines then it should be RGB24.
    3. DATA_WIDTH correlate to PIX_FMT if you have 18 bit data lines then setup 18, if you have 24 bit data lines then 24.
    4. The last part is the timing configuration.
    • clock-frequency is the pixel clock of the display in MHz, by default 33,5 MHz.
    • hactive is the horizontal active time (solution), by default 800, because solution of display is 800x480.
    • vactive is the vertical active time (solution), by default 480, because solution of display is 800x480.
    • hfront-porch is the time between the end of valid data and the beginning of the sync pulse in horizontal direction.
    • hback-porch historically refers to the period of time between the end of the sync pulse and the beginning of valid data in horizontal direction.
    • hsync-len indicating the start of the next line in horizontal direction.
    • vback-porch historically refers to the period of time between the end of the sync pulse and the beginning of valid data in vertical direction.
    • vfront-porch is the time between the end of valid data and the beginning of the sync pulse in vertical direction.
    • vsync-len indicating the start of the next line in vertical direction.
    • hsync-active means if 1 = hsync is active high, 0 means active low.
    • vsync-active means if 1 = hsync is active high, 0 means active low.
    • de-active means if 1 = de is active high, 0 means active low.
    • pixelclk-active means if 1 = pixelclk data on positiv edge, 0 means negative edge.


    Normally in the display datasheet there is a parameter called H/V-SYNC-PERIOD. This parameter is the whole period of the display, you can calculate it.


    HSYNC_PERIOD = hactive + hfront-porch + hback-porch + hsync-len

    VSYNC_PERIOD = vactive + vfront-porch + vback-porch + vsync-len


    If you can´t read out the front-porch, back-porch or syn-len then split it, so that the sum of the single parameters is equal to SYNC_PERIOD.


    After everything is setup, then go to the top of your dts file and change it to


    #define CONFIG_EFUSA9X_MXCFB0 DISPLAY_LCD


    After that you can recompile your device tree


    make efusa9x.dtb


    And install it on your board.


    HDMI Display:


    First of all you have to open your device tree file (.dts) of your specific board, e.g. armstonea9dl.dts.


    There you will find an entry which looks like below:

    Code
    1. /* Configure HDMI settings here (ignored if HDMI is not used) */
    2. #define CONFIG_ARMSTONEA9_HDMI_BPP 32
    3. #define CONFIG_ARMSTONEA9_HDMI_PIX_FMT "RGB24"
    4. #define CONFIG_ARMSTONEA9_HDMI_MODE_STR "1920x1080M@60"
    1. BPP is bits per pixel, you can take the default value 32.
    2. PIX_FMT is the pixel format. RGB24 means 24 Bit data lines - 8 red, 8 green and 8 blue.
    3. MODE_STR contains the solution and the refresh rate.

    Normally these parameters are optional, because the HDMI gets the information via edid (Extended Display Identification Data).



    After everything is setup then go to the top of your dts file and change it to


    #define CONFIG_ARMSTONEA9_MXCFB0 DISPLAY_HDMI


    After that you can recompile your device tree


    make armstonea9dl.dtb


    And install it on your board.


    Your F&S Support Team

    Hello,


    ArmStoneA9 has 2 on-Board LEDs which you can toggle. The UBoot command is led [0|1|all] [on|off|toggle|blink].

    Code
    1. led 0 on

    Every UBoot command can also executed by the udpate/install script. You have to modify the install.txt from the release directory/sources/ and compile it with the mkimage tool.


    Your F&S Support Team

    Hello,

    at the moment there is no official support for Chrome/Firefox in Buildroot.


    If you want to use Chrome or Firefox then you have 2 possibilities.


    1. You have to add a package to buildroot, which installs chrome for you.
    2. You can switch to our Yocto release, there you have Chrome and Firefox support.


    Your F&S Support Team

    Dear Ahmed,


    sorry for my late response but we were busy because of the preparation and reworking of the exhibition. I tested you problem and can confirm this. It only occurs with fsimx6ul. On CPUs fsimx6 and fsimx6sx it works. The problem is that the fsimx6ul looking for the file include.gypi in different folders and doesnt find the file there. Thats why the do_fetch task of chromium fails. We need the folder armv7ve which doesnt exist. I have prepared a patch which creates the this folder. You will find the patch in the appendix.


    To apply the patch you need the following steps:


    1. copy the fsimx6ul-chromium.patch to your main yocto directory (same directory were you can find yocto-download).
    2. Switch to this directory and apply the patch with the following command: patch -p1 < fsimx6ul-chromium.patch
    3. Compile your yocto rootfs again


    Like my colleague Mr. Keller said we are currently working on a new release which will use a newer Yocto version (most probably 2.4) which also contains a newer Chromium.


    Your F&S Support Team

    i.MX7ULP FreeRTOS Release V2019.02


    We have uploaded a new FreeRTOS version for all boards and modules based on the i.MX7ULP CPU to our server, i.e. the fsimx7ulp architecture: PicoCoreMX7ULP. This release is running on all platforms of this architecture at the same time.


    This is a maintenance release. The release consists of the following file:


    freertos-bsp-fsimx7ulp-V2019.02.tar.bz2

    This is the main release itself containing all sources, the binary images, the documentation, examples and the toolchain.


    This tar archive is compressed with bzip2. So to see the files, you first have to unpack the archives

    Code
    1. tar xvf freertos-bsp-fsimx7ulp-V2019.02.tar.bz2


    This will create a directory freertos-bsp-fsimx7ulp-V2019.02 that contains all the files of the release.


    Please read the file doc/FreeRTOS_BSP_iMX7ULP_on_FS_Boards.pdf. It lists the meaning of all files and shows how to install and use everything.


    Release Notes freertos-bsp-fsimx7ulp-V2019.02


    First release which supports Cortex-M4 on PicoCoreMX7ULP


    -----------------------------------------------------------------------------------


    The following list shows the most noticable changes in this release. Please note that the source code may also used for other platforms. This is why you will also find references to other CPU types and F&S boards here in the changelog.


    freertos-fsimx7ulp-V2019.02 (25.02.2019)

    Supported boards: PicoCoreMX7ULP

    Not tested: efusA9X, PicoCOMA9X, PicoCoreMX6SX


    • Add Original NXP MCUXpresso SDK_2.4.0_EVKMCIMX7ULP
    • Add driver and freertos examples for PicoCoreMX7ULP
    • Fix RPMsg pingpong double send bug
    • Add driver and freertos examples for i.MX6SX boards
    • Fix imx6sx pingpong example
    • Fix fsimx6sx uart interrupt
    • Fix imx6sx rpmsg examples
    • Improve imx6sx rpmsg bm pingpong example
    • Split imx6sx to different boards and rename picocore7ulp to lowercase
    • Fix imx6sx RPMsg 512MB bug
    • Remove example folder
    • Move not portet examples
    • Add cmake build all support i.MX7ULP
    • Improve i.MX7ulp make all functions
    • Move board specific files for better SDK layout (i.MX6SX + i.MX7ULP)
    • Improve prepare.sh script to support new SDK layout
    • Add picocoremx6sx support
    • Add and modify examples, which did not work because of Soc revision A
    • Improve binary to image conversion
    • Fix qspi examples
    • Add power_mode_switch example
    • Add shell_mem example
    • Fix picocoremx6sx adc build bug
    • Move examples which not tested to no tested folder
    • Remove some unnecessary files


    Toolchain

    • gcc-arm-none-eabi-6-2017-q2-update-linux.tar.bz2


    Documentation

    • Update to version 1.0 of FreeRTOS_BSP_iMX7ULP_on_FS_Boards_eng.pdf



    Your F&S Support Team

    i.MX7ULP Linux Release B2019.02-pre


    After some time of preparation, it is finally available. We have uploaded a new Linux version based on Buildroot for all boards and modules based on the i.MX7ULP CPU to our server, i.e. the fsimx7ulp architecture: PicoCoreMX7ULP. This release is running on all platforms of this architecture at the same time. So you can download the same binaries for U-Boot, Linux kernel and Buildroot root filesystem to any of the i.MX7ULP boards and it will run.


    This is a maintenance pre release. The release consists of the following file:


    fsimx7ulp-B2019.02-pre.tar.bz2

    This is the main release itself containing all sources, the binary images, the documentation and the toolchain.


    This tar archive is compressed with bzip2. So to see the files, you first have to unpack the archives


    Code
    1. tar xvf fsimx7ulp-B2019.02-pre.tar.bz2


    This will create a directory fsimx7ulp-B2019.02-pre that contains all the files of the pre release.


    Please read the file doc/FSiMX7ULP_FirstSteps_eng.txt. It lists the meaning of all files and shows how to install and use everything.


    Release Notes for fsimx7ulp-B2019.02-pre


    First release which supports the board PicoCoreMX7ULP


    -----------------------------------------------------------------------------------


    The following list shows the most noticable changes in this release in more detail since our last regular i.MX7ULP release. Please note that the source code may also used for other platforms. This is why you will also find references to other CPU types and F&S boards here in the changelog.



    u-boot-fsimx7ulp-B2019.02-pre (25.02.2019)
    Supported boards: PicoCoreMX7ULP
    Not tested: -


    • Create own git based on NXP U- Boot imx_v2017.03_4.9.11_1.0.0_ga
    • Add new target FSIMX7ULP for F&S modules
    • Modify UBootEnv for DTS and RNDIS network
    • Improve fsimx7ulp_defconfig ls/load commands and F&S Ident String
    • Make loadaddr be settable at runtime
    • Improve board support file fsimx7ulp.c
    • Add F&S own install/update/recover mechanism
    • Activate fatwrite for fsimx7ulp
    • Add support for qspi
    • Update U-Boot to imx_v2017.03_4.9.88_2.0.0_ga
    • Add PCC clock enable for PTC/D/E/F
    • Add bootaux command
    • Support Micro MT25QU512ABB Serial NOR Flash
    • Improve mfgtools autoboot
    • Improve picocoremx7ulp.dts
    • Improve fsimx7ulp config settings


    linux-fsimx7ulp-B2019.02-pre (25.02.2019)

    Supported Boards: PicoCoreMX7ULP

    Not tested: armStoneA9, armStoneA9r2, efusA9, PicoMODA9, NetDCUA9, QBlissA9, QBlissA9r2, efusA7UL, PicoCOM1.2, efusA9X, PicoCOMA9X

    • Add properly fsl,rx_fifo_trig to i.MX6 UART driver
    • On i.MX6, add support for BT656 and BT1120 output on IPU
    • Add support ADV7391 video encoder
    • Add analog video output to fsimx6, using BT656+ADV7391
    • Improve adv739x driver to allow setting chip type
    • On i.MX6, add support for 4-channel camera input ISL79985/79987
    • Add support for ISL7998X 4x camera MIPI decoder on fsimx6
    • AD PAL/NTSC support for isl7998x_mipi.c, improve driver
    • Add more network features to fsimx6/ul/sx defcnofigs
    • Add bluetooth support to fsimx6sx/ul
    • Add support for PicoCOMA7
    • Use new F&S Tux logo when booting
    • Update kernel from version 4.1.15 to 4.9.88
    • Fix several drivers after merge
    • Add support for picocoremx6ull
    • Add support for picocoremx7ulp
    • Add support for picocoremx6sx
    • Correct distinction between UL and ULL
    • Fix some rPMSG features caused by new RPMSG API
    • Improve picocoremx6sx device tree
    • Add support for Toshiba TC358762 DSI to RGB converter
    • Improve mxsfb driver support i.MX6 and i.MX7
    • Support new F&S Tux logo on fsimx7ulp_defconfig
    • Improve mipi_dsi_northwest driver - get DT disp params
    • Support LCD display on picocoremx7ulp
    • Add support for RTC PCF85063 to fsimx6ul_defconfig
    • Improve picocoremx7ulp device tree
    • Improve picocoremx7ulp_defconfig


    buildroot-fsimx7ulp-B2019.02-pre (20.11.2017)
    Supported Boards: PicoCoreMX7ULP

    Not tested: armStoneA9, armStoneA9r2, efusA9, PicoMODA9, NetDCUA9, QBlissA9, QBlissA9r2, efusA7UL, PicoCOM1.2, efusA9X, PicoCOMA9X, armStoneA5, NetDCUA5, PicoCOMA5


    • Update Buildroot from 2016.05 to 2018.08
    • Fix several errors after merge
    • Update defconfigs to use linux 4.9.88
    • Add package sterling-wlan-fs for F&S boards
    • Add fsimx7ulp_std_defconfig
    • Add erpc python package for AMP-example
    • Update Buildroot to 2018.11
    • Add fsimx7ulp_qt5_defconfig
    • Fix errors after merge
    • Change Kernel load address for i.MX6 CPUs
    • Fix python-erpc package
    • Add fsimx7ulp_min_defconfig
    • Fix invalid pointer in passwd


    Toolchain

    • No changes


    Documentation


    • Update to version 1.1 of AdvicesForLinuxOnPC_eng.pdf
    • Add version 1.0 of FSiMX7ULP_FirstSteps_eng.txt
    • Update to version 1.1 of PicoCoreMX7ULP-GPIO-ReferenceCard_eng.pdf
    • Update to version 1.00 of PicoCoreMX7ULP_Hardware_eng.pdf



    Your F&S Support Team

    F&S Secure Boot Release 2019.02


    we have uploaded a new F&S Secure Boot version for all supported boards with an i.MX6 CPU to our server, i.e. i.MX6S/DL/D/Q, i.MX6SX, i.MX6UL/ULL.


    This is a major release. The release consists of one file:


    fs-secure-boot.2019.02.tar.bz2

    This is the main release itself containing all sources, the binary images and the documentation.


    This tar archiv is compressed with bzip2. So to see the files, you first have to unpack the archives


    Code
    1. tar xvf fs-secure-boot.2019.02.tar.bz2


    This will create a directory fs-secure-boot.2019.02 that contains all the files of the release.


    Please read the file doc/FS_Secure_Boot.pdf. It lists the meaning of all files and shows how to install and use everything.


    The release consists of the following files and directories:


    • Readme.txt (Release notes)
    • setup-fs-secure-boot.sh (Script to unpack fs-secure-boot release)
    • binaries/ (Precompiled secure images)
    • doc/ (software manual)
    • sources/ (source code packages)


    Release Notes for F&S Secure Boot 2019.02


    Here are some highlights of this release.


    1. Support new CPU i.MX6ULL


    This is the first regular release that supports i.MX6ULL CPUs.



    2. Support new CPU revisions


    Through a security vulnerability in the NXP i.MX6 they have changed something in the ROM code. Thereby we can´t use the old User Tool and NBoot for the new revisions so we have to change something in the code to support the new revisions.



    3. Improve encryption


    For the encryption it was necessary that you have to download nboot_for_key.bin on the board to create keys. This is fixed in the new CST >= 2.3.2. So we have removed this and now it is easier to create encrypted keys. We also have removed the encryption with ZMK. We are now only support OTPMK encryption till we have implemented a secure way to use ZMK.



    Your F&S Support Team



    Note:

    You are only able to purchase our F&S Secure Boot release, if you have ordered it. For further information, see https://www.fs-net.de/en/support/secureboot/

    Dear Ahmed,


    in U-Boot the normal sized SD-Card is mmc dev 0. The µSD-Card is mmc dev 1.


    To read the SD-Card in U-Boot you can use the following commands:


    normal sized SD-Card:

    • put in SD-Card
    • command: mmc rescan
    • command: mmc dev 0
    • command: ls mmc 0


    µSD-Card:

    • put in µSD-Card
    • command: mmc rescan
    • command: mmc dev 1
    • command: ls mmc 1


    If you want to boot the rootfs from SD-Card then you have to modify the device-tree. By default the WLAN and EMMC is enabled so no SD-Card Slots are available in Linux. V1 of efusA7UL don´t have WLAN and EMMC.


    1. Navigate to your linux kernel folder
    2. Open file arch/arm/boot/dts/efusa7ul.dts
    3. Comment out the line "#define CONFIG_EFUSA7UL_EMMC" and "#define CONFIG_EFUSA7UL_WLAN" now it should be look like this "//#define CONFIG_EFUSA7UL_EMMC" and "//#define CONFIG_EFUSA7UL_WLAN"
    4. Recompile the device-tree and install it on your board
    5. After that save the rootfs on your SD-Card
    6. Then put in the SD-Card and go to U-Boot
    7. Now you can call "run .rootfs_mmc", mmcblk0 => µSD-Card and mmcblk1 => SD-Card. Maybe you have to modify the variable rootfs for the correct mmcblk device
    8. Boot the system


    Your F&S Support Team

    Hi,


    i have a small c programm which access via ioctl the uart interface and send a string. In the attachment you find the c file and a precompiled test program. Does this program solve your problem?


    Your F&S Support Team

    Files

    • uart_test.zip

      (5.07 kB, downloaded 121 times, last: )

    Hi


    well in our Linux first steps document you will find how you compile a device tree. You can you a look at chapter 9.1.5/6.
    If you want to change the device tree at runtime you have to enable 2 packets in Buildroot, recompile it and install it. These packets are called BR2_PACKAGE_DTC and BR2_PACKAGE_DTC_PROGRAMS. They are located in "target packages->Libraries->Hardware handling"


    But we recommend you to do changes in the device tree directly in the source code instead of modfiying the binary file. It is more common to do the changes directly in the source file and makes from our point of view more sense.


    Your F&S Support Team

    Hi,


    yes that is correct you see the stats of the emmc. You can´t
    see the partition table because there is no partition table installed
    yet. Normally you can boot linux and call the tool fdisk:
    fdisk /dev/mmcblkX

    • o -> create empty DOS partition table
    • n -> add new partition
    • w -> write table to disk and exit

    After that you can create a filesystem on you partition
    mke2fs –t ext4 /dev/mmcblkXpY


    Now the partition table and the filesystem is available und you can access emmc from UBoot.


    Why you don´t see the emmc in the /dev directory is another question. Do you have enabled the define
    #define CONFIG_EFUSA7UL_EMMC
    in the device tree?


    Your F&S Support Team

    Hi,


    GPIO2_IO11(gpio43) is pin 26 of J1 connector in the gpio reference card. So the main problem is that the default mux option for this pin is set to SPI. That´s the reason why you can´t recognize a state change of this pin. If you want to use this pin as GPIO, then you have to disable the SPI interface in device tree. You can do this by changing the following line:
    #define CONFIG_PICOCOMA9X_SPI_A to //#define CONFIG_PICOCOMA9X_SPI_A
    Then you have to recompile the device tree and install it on your board. After that you should be able to toggle the GPIO.


    Your F&S Support Team

    Dear Ahmed,


    the LCD display and the touch controller should be independent. That should not be the problem.


    Do you have a second 3.5" display to test. Maybe there is something broken with the touch controller.


    For the touch controller there are three parameters which you can setup. The touchrate, powdly, filt, setdly.
    touchrate = Defines the touch coordinates acquisition rate. Values between 0 - 15 are allowed. Hint: The touchrate bits are 7:4 so if you want to write a 0x3 then value must be 0x30 for bit 7:4.
    powdly = Defines the bias settling time for each channel’s first conversion. Values between 0 - 15 are allowed.
    filt = Defines the channel filtering algorithm Values between 0 - 3 are allowed.
    setdly = Defines the bias settling time for each channel’s subsequent conversion (i.e. when filtering is enabled). Values between 0 - 15 are allowed.


    You can change these parameters within the device tree.
    e.g.
    touchrate = <0x30>;
    powdly = <0x06>;
    filt = <0x02>;
    setdly = <0x08>;


    For more informations please have a look to the sx8675 datasheet. You can try to change this parameters maybe this will effect the touch behavior.


    Your F&S Support Team

    We decided to create a guide, which explains how to create an QT5-Application and debug it with QT-Creator. QT-Creator is running on your host system and the application will be cross compiled for arm architecture. Afterwards it will be downloaded automatically (via ssh) to your F&S module. Now you can remote debug it from your host system.


    This guide is available on our homepage. Just select your module and choose “Documents”. Then it´s located in the category “module-name” – Linux. The Document called Application Development with QT5.


    Your F&S Support Team

    Hi,


    after examine the situation I can see there is a bug between the naming of the device tree and the GPIO reference card of the armStoneA9R2. So the correct naming is written in the GPIO reference card. We will fix the device-tree naming in the next release. In the meantime you can change your device tree to correspond to the GPIO reference card. That means:

    Reference Card device tree
    UART_B UART2
    UART_D UART1
    UART_E UART3
    UART_C UART5
    UART_A UART4


    So you can change the different uart defines to the correct uart node.


    Example:
    current DT:

    Code
    1. #ifdef CONFIG_ARMSTONEA9R2_UART_A
    2. &uart2 {
    3. ...


    new DT:

    Code
    1. #ifdef CONFIG_ARMSTONEA9R2_UART_B
    2. &uart2 {
    3. ...


    Your F&S Support Team