Problems/Questions with armStoneA9-SKIT

  • Hello,


    some weeks ago we bought a F&S armStoneA9 starter kit with graphics lcd (looks like ET070080 , 800x480 18bit color).
    The last weeks I brought up the build system on an Ubuntu 13.10 with crosstool-ng and glibc 2.16 instead of the prebuild binaries from f+s for fedora. After some problems it works now so that i can load the own compiled kernel and rootfs via tftp/nfs.


    But what i can't get to work (neither with the original nand SW nor the self compiled SW) is the LCD and the touchscreen.
    After/during boot sequence four penguins with f+s logo are displayed in the left corner and that's it.
    I tried e.g. adding something like mxcfb0:dev=lcd,LCD-ET070080,if=RGB666 on the kernel command line (found the infos in mxc_lcdif.c) but it didn't work obviously.
    The only mysterious thing I see in dmesg is:
    atmel_mxt_ts 2-004a: __mxt_read_reg: i2c transfer failed (-5)
    atmel_mxt_ts: probe of 2-004a failed with error -5


    It seems that the touchscreen controller isn't found/probed? Is that maybe a problem?


    Moreover I see differences between the manual and reality:
    Manual says :
    Configure input for: default-event0 sx8655 Touchscreen
    When starting Linux for the first time you need to calibrate your touch with:
    mount -o remount,rw /
    ts_calibrate
    after that you can test with:
    ts_test
    To use the touch with Xserver you need to reboot after the calibration or restart with:
    /etc/init.d/S35x11 stop
    /etc/init.d/S35x11 start


    The SW in the delivered device (which is V1.2) is already mounted rw. So the missing/nonworking shutdown always forces a ubifs recovery. Moreover no output for default-event0 or touchscreen is seen.
    The script S35x11 also doesn't exist, neither in the nand SW nor in the buildroot sources for V1.2 under board/f+s/common as you can see in the build output:
    >>> Executing post-build script /opt/f+s/buildroot-f+s/board/f+s/QBlissA9/final_script_std
    >>> Doing final F+S QBlissA9 setup for standard configuration
    >>> Doing final F+S (common) setup for standard configuration
    /bin/cp: der Aufruf von stat für »board/f+s/common/inittab“ ist nicht möglich: Datei oder Verzeichnis nicht gefunden
    /bin/cp: der Aufruf von stat für »board/f+s/common/mdev.conf“ ist nicht möglich: Datei oder Verzeichnis nicht gefunden
    /bin/cp: der Aufruf von stat für »board/f+s/common/S35x11“ ist nicht möglich: Datei oder Verzeichnis nicht gefunden


    The framebuffer examples mentioned in first steps manual '8.8 DirectFB' also doesn't exist in the delivered SW.
    I had to enable them in buildroot config to try them. The output is always on the HDMI video output.


    So what should be the default behavior when the LCD is connected and if it should turn on automatically what is wrong here?

  • Quote from "hkurzhals"

    The last weeks I brought up the build system on an Ubuntu 13.10 with crosstool-ng and glibc 2.16 instead of the prebuild binaries from f+s for fedora.


    The toolchain binaries are not especially for Fedora. They will also work with Ubuntu. However they are built for a 32-bit environment. So if you are working on a 64-bit Ubuntu, you have to install some additional 32-bit libraries to get the cross-toolchain running. Just call "ldd arm-linux-gcc" to see what libraries are missing and then install the appropriate packages.


    Quote

    But what i can't get to work (neither with the original nand SW nor the self compiled SW) is the LCD and the touchscreen.
    After/during boot sequence four penguins with f+s logo are displayed in the left corner and that's it.


    The four penguins tell you two things. First that you have a quad core CPU, one penguin per core. And second that the display *is* already working.


    Quote

    I tried e.g. adding something like mxcfb0:dev=lcd,LCD-ET070080,if=RGB666 on the kernel command line (found the infos in mxc_lcdif.c) but it didn't work obviously.
    The only mysterious thing I see in dmesg is:
    atmel_mxt_ts 2-004a: __mxt_read_reg: i2c transfer failed (-5)
    atmel_mxt_ts: probe of 2-004a failed with error -5


    It seems that the touchscreen controller isn't found/probed? Is that maybe a problem?


    No. We have drivers for different touches enabled by default and of course if some type of touch is not connected, it will output some error messages when it is probed.



    OK, sorry, the documentation for our imx6 boards was compiled using the documentation for our Vybrid boards as a base. Unfortunately some of the original stuff got through. This part is one of this. We are currently improving the whole i.MX6 stuff and try to make it more similar to our other boards. When we are done, also the documentation will be reworked.


    Quote

    The SW in the delivered device (which is V1.2) is already mounted rw. So the missing/nonworking shutdown always forces a ubifs recovery.


    For shutdown you can call "halt" twice (!) and then it is working. But of course this is one of the points that we will check in our revised version to come.


    By the way if you want to start with the root filesystem in read-only mode, you just have to add "ro" on the command line (maybe replace rw with ro if rw is present). So just modify the bootargs variable in U-Boot.


    Quote

    The framebuffer examples mentioned in first steps manual '8.8 DirectFB' also doesn't exist in the delivered SW.
    I had to enable them in buildroot config to try them. The output is always on the HDMI video output.


    So what should be the default behavior when the LCD is connected and if it should turn on automatically what is wrong here?


    In fact the armStoneA9 has three (!) different displays activated by default. One for HDMI, one for LVDS and one for digital RGB. And even more, these displays are configured to have an overlay for videos. So in fact we have about six framebuffer devices: /dev/fb0 and /dev/fb1 for HDMI, /dev/fb2 and /dev/fb3 for LVDS and /dev/fb4 and /dev/fb5 for digital RGB. If you want to start a graphical application, you exactly have to tell where this application should do its output. How this is done depends on the application. For example if you are calling some DirectFB program, then you can give the framebuffer device on the command line:


    Code
    1. df_dok --dfb:fbdev=/dev/fb2


    Or if you want to start the X-Server on /dev/fb2, you have to replace all occurences of /dev/fb0 in file /etc/X11/xorg.conf with /dev/fb2. Then call


    Code
    1. startx


    If you only have one display connected, then I would recommend removing the other two displays. This can be done in the Linux kernel in file arch/arm/mach-mx6/board-mx6q_armstoneA9.c in array armstonea9_fb_data[]. Just keep the one that you need: "hdmi"=HDMI, "ldb"=LVDS, "lcd"=digital RGB. Then this display will be shown on /dev/fb0 and everything should work with the default settings.


    In fact we are also considering to only activate one display by default in the future. Most people will only connect a single display, so having three displays active is wasted bus load and wasted energy.


    Your F&S Support Team

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

  • Thanks for your fast response,


    I tried to use the display as mentioned with df_*** --dfb:fbdev=/dev/fb2 but it also didn't work (no lcd display output).
    Then I used fbset to see what frame buffers are used:
    ****************************************************************
    # fbset -fb /dev/fb0 -s
    mode "1280x1024-60"
    # D: 108.003 MHz, H: 63.983 kHz, V: 60.021 Hz
    geometry 1280 1024 1280 3072 32
    timings 9259 248 48 38 1 112 3
    hsync high
    vsync high
    rgba 8/16,8/8,8/0,8/24
    endmode


    # fbset -fb /dev/fb1 -s
    mode "240x320-60"
    # D: 4.608 MHz, H: 19.200 kHz, V: 60.000 Hz
    geometry 240 320 240 960 16
    timings 217013 0 0 0 0 0 0
    rgba 5/11,6/5,5/0,0/0
    endmode


    # fbset -fb /dev/fb2 -s
    mode "800x480-54"
    # D: 30.000 MHz, H: 28.409 kHz, V: 54.113 Hz
    geometry 800 480 800 960 32
    timings 33333 88 40 33 10 128 2
    rgba 8/16,8/8,8/0,8/24
    endmode


    # fbset -fb /dev/fb3 -s
    mode "800x480-49"
    # D: 27.000 MHz, H: 25.568 kHz, V: 48.701 Hz
    geometry 800 480 800 1440 32
    timings 37037 152 40 33 10 64 2
    rgba 8/16,8/8,8/0,8/24
    endmode


    # fbset -fb /dev/fb4 -s
    mode "240x320-60"
    # D: 4.608 MHz, H: 19.200 kHz, V: 60.000 Hz
    geometry 240 320 240 960 16
    timings 217013 0 0 0 0 0 0
    rgba 5/11,6/5,5/0,0/0
    endmode


    # fbset -fb /dev/fb5 -s
    open /dev/fb5: No such file or directory
    ****************************************************************



    So I only can see 5 frame buffers (or devices) and it worked with fb3. Does that mean the lvds overlay is used (the display is connected to the lcd connector, not the lvds connector) or is that the normal lcd rgb frame buffer which is at fb3 instead of fb4 as mentioned?
    What is the difference between fb2 and fb3 here, fb2 = lvds main disp and fb3 = lcd rgb disp without overlay for lvds?
    Do I understand it right that the overlays are always the 240x320 fb/devices here?


    Thanks for your help