Posts by BrenkeM

    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

    Hello,


    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]:

    Code
    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


    [2]:

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


    [3]:


    [4]:

    Code
    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".


    [5]:

    Hello,


    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:

    BR2_TARGET_ROOTFS_UBIFS_LEBSIZE

    BR2_TARGET_ROOTFS_UBIFS_MINIOSIZE

    BR2_TARGET_ROOTFS_UBIFS_MAXLEBCNT


    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?



    [1]:

    # df -h

    Filesystem Size Used Available Use% Mounted on

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


    [2]:


    $ du -b output/images/rootfs.ubifs

    7110656 output/images/rootfs.ubifs


    [3]:

    https://bootlin.com/blog/creating-flashing-ubi-ubifs-images/

    Hello,


    I would like to test all four ADC channels (ADC_D, ADC_C, ADC_B, ADC_A) of the efusA9X module. So far I checked the adc example and the device tree. According to the example the ADC will be handled via device files (/dev/mvf_adc.?). But I could not find these in the sysfs. [1] and [2] shows some device tree nodes. [2] tells me that the ADCs are already in use for some other functions. But [1] does not create the missing decive files in the sysfs.


    What I am missing is a example of a device tree node to inform the kernel about the ADCs. Is there already an example for this or how do I get the device files into the sysfs?


    [1]:


    [2]:

    I was playing around with the sysfs and found in the hardware monitoring class the information under [1]. The defined critical temerature for the "imx_thermal_zone" is set to 85°C, which corresponds with my measurings.


    But its not possible to define the critical CPU temperature by my self (see [2]). Who is definig this temperature and how can it be set?



    [2]:
    # echo 95000 > temp1_crit
    -sh: can't create temp1_crit: Permission denied



    [1]:
    /sys/class/hwmon/hwmon1:


    # cat name
    imx_thermal_zone


    # cat temp1_input
    47212


    # cat temp1_crit
    85000

    Hello FuS Support Team,


    according the current documentation and example programs does not support a FreeRTOS ethernet communication on the Cortex-M4.
    According [1] NXP, ethernet is supported on FreeRTOS (Cortex-M4). FreeRTOS it self includes a TCP/IP stack, see [2].


    Is the support for ethernet on the Cortex-M4 planned for the next release or are there any examples so far?



    [1]:
    https://www.nxp.com/webapp/con…8RW1-16#auvp-overview-tab


    [2]:
    https://www.freertos.org/FreeR…eRTOS_Plus_TCP/index.html

    Hello FuS Support Team,


    I performed some thermal measurings on the efusa9x and noticed that the CPU is reducing its clock speed from ~1GHz to ~200MHz at ~85°C.
    On the other site I also noticed that the CPU is performing a restart at ~105..110°C.


    Can you please conform this measurings and tell us how to define the temperature when the CPU is reducing the clock speed to cool down.



    Thanks.

    [1] shows the only change from my side regarding on modul nand flash in the F+S uboot sou res. I made a test and yes: If UBootEnv is 'rw' the bootloader is not able to access the nand flash. If I change the mode back to 'ro' my bootloader is working and can access the nand flash.


    Can you confirm this behavior on your side to?



    [1] in include/configs/fsimx6sx.h:
    /* Define MTD partition info */
    #if CONFIG_SYS_MAX_NAND_DEVICE > 1
    #define MTDIDS_DEFAULT "nand0=gpmi-nand0,nand1=gpmi-nand1"
    #define MTDPART_DEFAULT "nand0,0"
    #define MTDPARTS_PART1 "fsnand1:256k(NBoot)ro\\\\;fsnand0:768k@256k(UserDef)"
    #else
    #define MTDIDS_DEFAULT "nand0=gpmi-nand"
    #define MTDPART_DEFAULT "nand0,1"
    #define MTDPARTS_PART1 "gpmi-nand:256k(NBoot)ro,768k(UserDef)"
    #endif
    //#define MTDPARTS_PART2 "256k(Refresh)ro,768k(UBoot)ro,256k(UBootEnv)ro"
    #define MTDPARTS_PART2 "256k(Refresh)ro,768k(UBoot)ro,256k(UBootEnv)rw"
    #define MTDPARTS_PART3 "8m(Kernel)ro,1792k(FDT)ro"
    #define MTDPARTS_PART4 "-(TargetFS)"
    #define MTDPARTS_STD "setenv mtdparts mtdparts=" MTDPARTS_PART1 "," MTDPARTS_PART2 "," MTDPARTS_PART3 "," MTDPARTS_PART4
    #define MTDPARTS_UBIONLY "setenv mtdparts mtdparts=" MTDPARTS_PART1 "," MTDPARTS_PART2 "," MTDPARTS_PART4

    Yes. It is only a modified version of the original F+S uboot image. I tried not to change any FLASH related options (only make UBootEnv rw). But my image only access the nand flash when I use the enviroment on the original uboot image from F+S.


    As you can see in [1] there is no difference in variable mtdparts. The command "mtdparts" shows the same behavior as you can see in [2].


    [1]:
    myUBOOT:
    mtdparts=mtdparts=gpmi-nand:256k(NBoot)ro,768k(UserDef),256k(Refresh)ro,768k(UBoot)ro,256k(UBootEnv)rw,8m(Kernel)ro,1792k(FDT)ro,-(TargetFS)


    F+S UBOOT:
    mtdparts=mtdparts=gpmi-nand:256k(NBoot)ro,768k(UserDef),256k(Refresh)ro,768k(UBoot)ro,256k(UBootEnv)ro,8m(Kernel)ro,1792k(FDT)ro,-(TargetFS)



    [2]:

    Hello gentleman,


    I made some changes in uboot. But nothing regarding the flash nand memory (to my way of thinking). But afterwards I can not access the nand flash any more. I also checked the original uboot from F+S and compared the sourced and enviroment variables. My modified UBootEnv can be seen under [1].


    I also noticed that some variables are not there anymore (see [2]). But when I set them and try to work with the nand flash they disappear and I get the following error:
    unexpected character 'r' at the end of partition

    What variables needs to be set to access the nand flash memory?



    Thanks so far.



    [2]:
    mtddevnum=0
    partition=nand0,0



    [1]:

    The source of the UART baud rate problem was the stty command of the used busybox- tools (v1.24.2).


    A work a round to fix the problem was to install the coreutils including stty that smoothly did the job.
    buildroot:
    -> Target packages
    -> Show packages that are also provided by busybox
    -> coreutils


    Furthermore, I initiated a bug report @ [1] to get the busybox tools fixed.


    [1]:
    https://bugs.busybox.net/show_bug.cgi?id=10456




    ------------------------------------------------------
    P.s.: How can I close this issue?

    I also checked the supported baud rates in my setting up to 4 Mbps:


    Hi,


    I also checked the UART CLOCK SPEED for all serial interfaces on the SKIT:

    Code
    1. # cat /sys/class/tty/ttymxc0/uartclk
    2. 80000000
    3. # cat /sys/class/tty/ttymxc2/uartclk
    4. 80000000
    5. # cat /sys/class/tty/ttymxc4/uartclk
    6. 80000000
    7. # cat /sys/class/tty/ttymxc5/uartclk
    8. 80000000


    All activated UARTs, from the F+S image, works with 80 MHz.

    Thanks for the reply.


    I checked to set the baud rate in a C program. As shown below the baud rate of 1 Mbps worked fine with a externel USB Adapter (FTDI Chip):

    Code
    1. char *portname = "/dev/ttyUSB0";
    2. set_interface(fd, B1000000);



    But with the internel UART_C the same program runs without any errors but sets the baud rate falsely to "0" (see line 2. in RESULT).

    Code
    1. char *portname = "/dev/ttymxc4";
    2. set_interface(fd, B1000000);


    Result for internel UART_C:

    Code
    1. # stty -F /dev/ttymxc4
    2. speed 0 baud; line = 0;
    3. intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
    4. eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
    5. werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 1;
    6. -brkint -icrnl -imaxbel
    7. -opost
    8. -isig -icanon -iexten -echo


    Therefore, it is also unknown for me who generates this error (stty: invalid argument '1000000').



    Where can I find the base clock part in the sources and more informations about its configuration?
    Or what can I try to do....to investigate this error?

    Hello,


    I tried to set the baud rate of a UARTs to 1 Mbps on the SKIT:

    Code
    1. # stty -F /dev/ttymxc4 1000000
    2. stty: invalid argument '1000000'


    I checked "/dev/ttymxc0", "/dev/ttymxc2", "/dev/ttymxc4" and "/dev/ttymxc5". No one accept the configuration of 1 Mbps. But 921600 bps and slower is working fine.


    According to the "i.MX 6SoloX Applications Processor Reference Manual" chapter "1.4 Features", all UART interfaces supports up to 4 Mbps.

    Code
    1. Six UARTs operating up to 4.0 Mbps each, …


    Can any one hint me to the part that limits the UART baud rate?

    Status so far:


    Multicast works:

    Code
    1. // aktivate all multicast addresses
    2. writel(0xffffffff, &fec->eth->gaddr1);
    3. writel(0xffffffff, &fec->eth->gaddr2);


    Than I spend some time by "try and error" with all bits of the gaddr register. The bit to control if a LLDP frame will be rejected or accepted are is the following:

    Code
    1. // Set multicast address filter
    2. // multicast for LLDP: 01:80:c2:00:00:0e
    3. writel(0x00000000, &fec->eth->gaddr1);
    4. writel(0x00000008, &fec->eth->gaddr2);


    Furthermore, I checked https://community.st.com/thread/24942 to calculate the correct Hash for fec with the LLDP multicast address { 0x01, 0x80, 0xc2, 0x00, 0x00, 0x0e }. It seems to be 0x1E.


    But I do not know how to split/convert this hash for gaddr1 and gadd2 in "drivers/net/fec_mxc.c". According to [1] the hash results in hash_high: 0x0
    and hash_low: 0x40000000.


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


    Regarding the ethernet interface switching:


    In my case LLDP frames are present on FEC0 and FEC1. But those on FEC1 are the wrong ones...and will misconfigure the system. So if FEC0 is defined and a TIMEOUT on FEC0 occurs the board switch to FEC1...gets the wrong LLDP frame and breaks the system.


    But I will try "ethrotate".



    Thanks so far.