Posts by fs-support_PJ

    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 103 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

    Hi,

    • If i2cdetect is not working then there is something wrong with the HW connection, because i2cdetect works independent from device tree entrys and drivers. So you don´t have to enable a driver and/or do a device tree entry to get the i2cdetect to work.
    • If you are enable the define CONFIG_ARMSTONEA9_CAPTOUCH_FT5x06 it doesn´t belong to the file edt-ft5x06.c. It belongs to the file ft5x06_ts.c. So if you are doing changes in the file edt-ft5x06.c it will not have an effect because this file will not be used. I also guess that the driver edt-ft5x06.c is not active in our default configuration.

    So first of all check your HW connections and try the i2cdetect command till it works.
    Hint: if you call

    Code
    1. i2cdetect 0

    it means i2c1.

    Code
    1. i2cdetect 1

    means i2c2.
    Then enable the edt-ft5x06.c driver in menuconfig and do the correct device tree entry for the edt-ft5x06 driver. After that you can test it if it works.
    In the edt-ft5x06 driver there is no support for M12 type. Only support for M06 and M09 (as you have already said). If you can´t apply the patch you can do it manually. At the moment I don´t think that we have a driver which is supporting M12 type.


    Your F&S Support Team

    Hi,


    you have commented out UART_D and this is the debug interface, so that´s the reason why you don´t see anything at the debug port.


    Pins 4, 6, 8, 10 SPI_B
    Pins 18, 20 UART_B
    Pin 19 UART_A_RTSCTS


    To get these pins as GPIO you have to comment out the following defines:
    //#define CONFIG_ARMSTONEA9R2_SPI_B
    //#define CONFIG_ARMSTONEA9R2_UART_B
    //#define CONFIG_ARMSTONEA9R2_UART_A_RTSCTS


    Your F&S Support Team

    To modify the UBoot environment from the userspace you need the tools fw_printenv and fw_setenv. You can bring these programs in 2 different ways to the remote target system. Either by Buildroot or by UBoot.


    Steps for Buildroot:

    • You have to activate the package u-boot tools, rebuild your rootfs and install it on your system. The package is located in Target packages/Hardware handling
    • After you have started your remote target system, the tools fw_printenv and fw_setenv are located in /usr/slib. You also have a file called fw_env.config which you have to modify.
    • Comment out all lines in the file fw_env.config. Then add the following line:
      Code
      1. /dev/mtd4 0x0000 0x4000 0x20000 0x2


    Steps for UBoot:

    • The tools fw_printenv is integrated in UBoot. To build these tool in UBoot you have to setup the following command:
      Code
      1. make env


    • After that the compiled files are located in tools/env.
    • There you find the file fw_printenv. To create fw_setenv you can copy the file fw_printenv to fw_setenv. Both are available in one executable. You also can create a link to fw_printenv.
    • Afterwards you have to modify the file fw_env.config which is also located in tools/env. Comment out all lines in this file. Then add the following line:
      Code
      1. /dev/mtd4 0x0000 0x4000 0x20000 0x2


    • For further information have a look at the topic fw_printenv and fw_setenv from Userspace
    • Now you can transfer these 3 files to your remote target system. You must copy fw_env.config to /etc.

    Now you are able to read the UBoot environment from userspace. Execute the fw_printenv tool to display the UBoot environment.


    If you want to modify these variables you have to remount the UBootEnv partition (default: mtd4). By default the UBootEnv partition is read-only mounted. To remount this partition you have 2 possibilites:

    • The easiest way is to modify the variable mtdparts in UBoot. There you have to change the string ...(UBootEnv)ro,... to ...(UBootEnv),... Just remove the ro so the partition will be mounted read/writeable. For further information have a look at the topic What needs to be contained in UBOOT to start/access nand0 (SOM Flash) After that you can start your system and the partition is read/writeable mounted.
    • If you want to do this without a reboot you can create a kernel module which is mounting this partition as read/writeable. There is an existing GitHub project which do this. The project called mtdRW. You have to modify the source file because all mtd partition will be mounted as read/writeable, but we only need UBootEnv as read/writeable. You also have to modify the Makefile, there is a string called KERNEL_DIR which must point to your linux kernel directory. After that you can compile the module with the command make. Now you can transfer the kernel object mtdRW.ko to your remote target system. To load this module you can use the command insmod mtdRW.ko

    Now you can use the fw_setenv command to modify some UBoot environment variables. Example:

    Code
    1. fw_printenv serverip
    2. 10.0.0.122
    3. fw_setenv serverip 10.0.0.120
    4. fw_printenv serverip
    5. 10.0.0.120


    Your F&S Support Team