Posts by RSchubert

    Yes, it's working with the "reg_ldb_bl" now. I can control the pwm backlight on pin 32 now.

    It seems the lbd-backlight will be disabled when no LDB interface is used and lcd-backlight will be disabled when no LCD interface is used.

    That makes sense but seems different to the 3.1 release.


    Thanks for your help.

    With this device tree I don't even get a sysfs directory for backlight (/sys/class/backlight is empty).

    I'm using the RGB LCD port.


    Code
    1. backlight_lcd {
    2.     compatible = "pwm-backlight";
    3.     power-supply = <&reg_lcd_bl>;
    4.     pwms = <&pwm1 0 500000 PWM_POLARITY_INVERTED>;
    5.     brightness-levels = <1 0 60 63 66 69 73 77 82 87 93 100 107 114 121 128 135 142 149 156 163 170 177 184 191 198 205 215 225 235 245 255>;
    6.     default-brightness-level = <31>;
    7.     fb-names = "lcd";
    8. };

    I tried "#pwm-cells = <3>;". The result is that the backlight is off instead on like before. The brightness again cannot be controlled. When using "pwm-cells = <3>;" without the # the ruslt is that the backlight always is on but cannot be controlled.

    If I change backlight control in device tree back to pwm3, I can control pwm1 (pwmchip0) in sysfs. Depending on the values duty_cycle/period I can dim my backlight correctly. But writing values to backlight/brightness in sysfs will not affect an pwm output on pwm3 now (4 pin backlight connector pin 3 to pin 4 always is 3.3V no matter what brightness I set).

    Yes, I'm using pwm1 (connector pin 32) instead of pwm3. That was working on Buildroot release 3.1.

    I guess pwm1 is on /sys/class/pwm/pwmchicp0. I cannot export channel 0 on pwmchicp0 ("Device or resource busy") because it is used by the backlight.

    I can control pwmchip1 / pwmchip2 / pwmchip3 in sysfs and view the result on oscillator.

    As written before, there is a kernel message while booting.

    Code
    1. ldb-bl: disabling

    Maybe that's the cause of the problem but I don't know what is disabling the ldb-bl.

    armstoneA9. PWM in general is working. I can control the PWM period on all other PWM ports/pins by writing the values to the sysfs. That's not possible on PWM0 because it's used/blocked by the backlight control. Writing values to /sys/class/backlight/backlight_ldb/brightness has no effect.

    Dear Support Team,


    I'm still dealing with the non working PWM1 backlight on pin 32 :(. What does the following kernel message mean?


    Code
    1. ldb-bl: disabling

    Here my device tree part:

    Code
    1. /* LVDS backlight PWM on LVDS connector and backlight connector */
    2. backlight_ldb { compatible = "pwm-backlight"; power-supply = <&reg_ldb_bl>; pwms = <&pwm1 0 500000 PWM_POLARITY_INVERTED>; brightness-levels = <1 0 60 63 66 69 73 77 82 87 93 100 107 114 121 128 135 142 149 156 163 170 177 184 191 198 205 215 225 235 245 255>; default-brightness-level = <31>; fb-names = "ldb0", "ldb1";
    3. };

    Is there anybody who can confirm working or not working backlight PWM?

    Thanks in advance.

    Thanks.


    Resetting the UBootEnv fixed the kernel size problem and the audio clock patch fixed the errors.


    Now I'm still dealing with the non working PWM1 backlight on pin 32. What does the following kernel message mean?

    Code
    1. ldb-bl: disabling

    Here my device tree part:

    Code
    1. /* LVDS backlight PWM on LVDS connector and backlight connector */
    2. backlight_ldb {
    3.     compatible = "pwm-backlight";
    4.     power-supply = <&reg_ldb_bl>;
    5.     pwms = <&pwm1 0 500000 PWM_POLARITY_INVERTED>;
    6.     brightness-levels = <1 0 60 63 66 69 73 77 82 87 93 100 107 114 121 128 135 142 149 156 163 170 177 184 191 198 205 215 225 235 245 255>;
    7.     default-brightness-level = <31>;
    8.     fb-names = "ldb0", "ldb1";
    9. };

    Thanks for answering but the SX8674IWLTRT is not available anywhere - has a MOQ of 30000 pcs and delivery times of at least 18 weeks. Definitely not usable for us. Thought about supporting Texas Instrumenst or Microchip resistive controllers with I2C in furture? The kernel drivers are available.

    Dear F&S support team,


    in armstoneA9 device tree the Semtech SX86xx resitive touch controllers are supported. It seems these are not available anymore (EOL). The SX8657/SX8658 are not marked as EOL but also not available for buying. Do you know of any substitude?


    Thanks in advance

    Dear F&S support team,


    I'm configuring an own kernel based on the fsimx6-B2020.04 release. It is working with a few errors (explained later below).

    While trying to find out if these errors also are in the precompiled binaries of this release I found out that these are not working for me on armstoneA9.


    uboot-fsimx6-B2020.04.nb0

    armstonea9dl-B2020.04.dtb

    zImage-fsimx6-B2020.04


    The boot process stops at "Starting kernel..."


    Any idea?

    Hint: My kernel is 3.7 MB uImage - the precompiled is 5.7 MB zImage.



    And here the errors when running my own kernel based on the B2020.04 release:


    The concern is about the lines:

    Code
    1. clk: failed to reparent cko to ssi1: -22
    2. clk: failed to reparent cko2_sel to cko2: -22
    3. clk: couldn't set ssi1_sel clk rate to 24576000 (-22), current rate: 786432000
    4. clk: failed to reparent cko to ssi1: -22
    5. clk: failed to reparent cko2_sel to cko2: -22
    6. clk: couldn't set ssi1_sel clk rate to 24576000 (-22), current rate: 786432000

    and line

    Code
    1. ldb-bl: disabling

    So far everything is running on the device (RGB display / analog touchscreen).

    The backlight on PWM1 (Pin 32) is not running for now (maybe ldb-bl: disabling) ?


    Thanks in advance for any hint.

    Hi,


    I'm sorry - my mistake. It seems I already added the package to the last version of Buildroot myself.

    open62541 (not open62514) is a library for supporting OPC-UA standards.


    Kind regards.

    Dear support team,


    can somebody tell me if there is support for TLS (Thread Local Storage) in toolchain fs-toolchain-8.3-armv7ahf ?

    If yes, are there any known issues?


    The reason for my question is, that I have some TLS related bugs when using libvncserver (on armStoneA9with fsimx6-B2019.08 release).

    The problem is, that the Tight encoding palette stucture (static TLS PALETTE palette;) is getting corrupted (maybe while multithreading).


    I also created an issue on libvncserver github: https://github.com/LibVNC/libvncserver/issues/363


    Any idea?

    Thanks in advance.

    Dear support team,


    can you say if iMX6 RS485 is working on the new 4.9.88 kernel?

    On the previous 4.1.15 release RS485 was not working out of the box. So I made some changes to drivers/tty/serial/imx.c to get it working (but without DMA). You can find it in this forum some threads below (RS485 while booting from March 2018). It seems you have made some changes to the original serial driver from kernel 4.9.88. In mainline kernel the RS485 seems not to be working well even in later kernel versions (4.20 and maybe even later). In your driver I'm missing the test for "linux,rs485-enabled-at-boot-time" what can be set in the device tree. That's important because otherwise the RS485 may be "disturbed" by the armstone while booting because it's blocking the write enable line until the driver will be setup for RS485 in the application. So what is the reliable state of RS485 in the new driver? Is DMA working now also when sending more than 8 bytes?


    Thanks in advance.

    Kind regards.

    Thanks for your answer.


    When enabling FT5x06 driver in kernel the device will be found and /dev/input/event0 will be created.
    cat /dev/input/event0 will display no results - surely because the driver does not support the M12 touch.


    When trying to use the EDT-FT50x6 driver that supports the M12 device I'm not successful. There is no /dev/input device created.
    Here my changes inside the device tree (inspired by efusa9x.dts):


    Thanks for any idea.