Posts by fs-support_HK

    Ah OK, now I understand.


    Yes, the LCD controllers are different on efusA9 (i.MX6DL/Q) and efusA7UL (i.MX6UL/ULL). So unfortunately the settings must also be done differently. The efusA7UL can have all parameters in the device tree. The efusA9 needs a setting in mxc_lcdif.c and just references it with the modestr entry, which is given with the CONFIG_EFUSA9_LCD_MODE_STR macro. So from a first view everything seems correct.


    But I'm not fully sure if the timings are really identical. Because in your data sheet, the back porch part always includes the sync time itself. But in our timings thy sync times are additional values. (The 20 and 10 at the end of the first parameter line in the array entry). In your case, the sync times actually do not matter, so using the default 20 for HSYNC and 10 for VSYNC should be OK. But then I think you need to subtract them from the back porch values, so you only have to set 68 - 20 = 48 for the Horizontal Back Porch and 18 - 10 = 8 as Vertical Back Porch.


    The SYNC polarities should be OK. If nothing is given in the value after the timings (line 4 above), then HSYNC and VSYNC are active low. Also the data is latched on the rising edge of the pixel clock, which is also the default case. So this matches your data sheet. DE is not used at all, so its polarity does not matter.


    Your F&S Support Team


    PS: Sorry for the late answer, but we were all on Embedded World 2019 in Nürnberg last week.

    Wir unterstützen leider von Haus aus keine Version, wo Linux echtzeitfähig wird. Nur Echtzeit auf dem Cortex-M4.


    Sinngemäß gilt für den Preempt-RT-Patch ähnliches wie für Xenomai. Man muss einen Patch finden, der möglichst nah an unserer Kernel-Version ist und dann schauen, wie er sich dann konkret mit unseren Kernel-Sources verhält. Dabei wird es sicher wieder zu Konflikten kommen, die man dann einzeln auflösen muss. Mit jeder neuen Kernel-Version geht das Spiel dann von Neuem los.


    Ihr F&S Support-Team

    Ich denke Sie unterschätzen den Aufwand gehörig.


    Der erste Schritt ist das Suchen eines möglichst ähnlichen Patches. Vielleicht gibt es einen Patch von NXP, der auf den NXP-Kernel 4.1.15 passt. Das wäre schon mal gut, dann haben wir vergleichsweise wenige Stellen, wo der Patch fehlschlägt. Wenn es nur einen Patch für den Mainline-Kernel gibt, sind es sicher deutlich mehr Stellen. Das können hunderte Stellen sein.


    Dann muss man den Patch in Buildroot eintragen und zu Compilieren versuchen. Für jede Stelle, wo der Patch fehlschlägt, muss man nun im Detail schauen, warum. Wenn der Code im Kernel anders aussieht, muss man nachvollziehen, was dort anders abläuft und sich dann überlegen, wie das nun mit der Xenomai-Anpassung aussehen muss. Je nach Anzahl der Fehlschläge, kann das Tage oder gar Wochen dauern.


    Am Ende hat man dann einen abgewandelten Patch, der von Buildroot fehlerfrei auf unseren Kernel angewendet werden kann und sauber compiliert. Dann muss man aber noch viele Tests machen, ob Xenomai nun auch noch fehlerfrei arbeitet, sprich ob Ihre Änderungen keine Fehler erzeugt haben. Eventuell gibt es von Xenomai ein Test-Kit, mit dem man alle relevanten Tests durchführen kann. Falls nun funktionale Fehler auftreten, muss man diese z.B. durch Debuggen lokalisieren (was bei Echtzeit nicht einfach ist) und korrigieren, sprich den Patch nachbessern.


    Erst wenn das alles läuft, hat man ein funktionierendes Xenomai. Für genau diesen Kernel. Wir werden aber demnächst auf Kernel 4.9 hochgehen und danach vermutlich auf Kernel 4.14, da beginnt das ganze Spiel dann wieder von neuem.


    Was ich nicht verstehe, Sie benutzen schon eine efusA9X, da ist der Cortex-M4 doch schon mit drin. Warum nutzen Sie nicht einfach FreeRTOS dort auf dem M4? Das haben wir am Laufen, da können wir helfen, das funktioniert.


    In Zukunft wird das immer mehr so laufen. Fast jeder i.MX7 und jeder i.MX8 hat (mindestens) einen Cortex-M für Real-Time mit eingebaut. Sprich die anderen Real-Time-Lösungen werden auf NXP-Prozessoren zunehmend uninteressant werden und weniger unterstützt werden. Auch andere SoC-Hersteller machen das künftig so, z.B. gerade heute gelesen bringt nun auch STM eine CPU mit 2x Cortex-A7 für Linux und zusätzlichem Cortex-M4 als RT-Kern raus. Das ist also keine Insellösung von NXP mehr, wie man vor vier Jahren vielleicht noch hätte vermuten konnte, als es nur den NXP/Freescale Vybrid mit dieser Architektur gab, nein, das wird künftig immer mehr so aussehen. Man hat gemerkt, dass die ganzen anderen Lösungen nicht sauber funktionieren, z.B. weil keine saubere Daten- und Hardwaretrennung zwischen Linux und dem RT-OS möglich ist. Durch den eigenen Kern und entsprechende Hardware (Resource Domain Controller) kann dies aber in den NXP-Prozessoren garantiert werden.


    Ihr F&S Support Team

    Yes. It is rather simple to disable RTS/CTS. This port is UART_B in our device tree, which in turn is the CPU UART port 1. So in armstonea9r2dl.dts (or armstonea9r2q.dts, depending on your CPU type), in section UART, comment the line


    Code
    1. #define CONFIG_ARMSTONEA9R2_UART_B_RTSCTS


    by inserting two slashes // at the beginning. That's all. Now recompile the device tree and download it to the board.


    If there are problems accessing the pins as GPIO, it might need an additional step. Most pads are automatically configured as GPIO if not configured as something else, but unfortunately not all pins. So in rare cases it might be necessary to specify the pad setting explicitly as GPIO. From the common part of the device tree, armstonea9qdl.dtsi, you can see in the IOMUXC section, that UART_B (UART1) uses pads EIM_D19 and EIM_D20 for RTS and CTS (and yes, in this sequence, despite the names that NXP has totally mixed up and where RTS is CTS and vice versa). Now we need similar lines in the node hoggrp-1 a little further above that configure these pads as GPIO:


    Code
    1. MX6QDL_PAD_EIM_D19__GPIO3_IO19 0x4001b0a8
    2. MX6QDL_PAD_EIM_D20__GPIO3_IO20 0x4001b0a8

    Your F&S Support Team

    Fast alle Real-Time-Lösungen zu Linux sind Add-Ons, wo man den Teil, der für Real-Time gedacht ist, in einer eigenen Real-Time-Sprache schreiben muss. Man kann also nicht einfach nur ein Linux-Programm verwenden und dann hoffen, dass es künftig in Echtzeit abläuft. Sondern man muss wirklich auf deutlich andere Art und Weise den Echtzeitteil implemenieren. Unter Xenomai und RT-Linux heißt der Netzwerkteil dann z.B. RTnet. Insofern ist der Unterschied im Vergleich zu einer Nutzung von FreeRTOS für den Netzwerkteil auch nicht sonderlich groß.


    Die einzige Lösung, die wirklich Linux zu einem Echtzeit-OS macht, ist der Preempt-RT-Patch. Aber die damit erzielbaren Antwortzeiten liegen um Größenordnungen höher als bei den "echten" RT-Betriebssystemen.


    Wir selbst unterstützen nur die Variante mit FreeRTOS auf dem Cortex-M-Core einiger unserer Boards (efusA9X, PicoCOMA9X, PicoCoreM6SX, PicoCoreMX7ULP, künftige i.MX8-Boards).


    Ihr F&S Support Team

    Do you use the provided Null Modem cable or do you have your own solution? Do you have a second efusA9 board to do some comparison tests? Have you tried Putty or TeraTerm as alternative to DCUTerm? Do these terminal programs show correct data? Or can you try a different PC? You do not need Linux or the development software on this PC, just a terminal program.


    If nothing helps and the error persists on this efusA9 board, then you have to send it as RMA to F&S and we will check what is wrong.


    Your F&S Support Team

    A common way to implement this is to set a value to the edge file in the gpio entry in sysfs and then using select() or poll() to react on the signal change. I have attached a generic example with functions to configure a gpio and do the poll.


    Your F&S Support Team


    gpio-poll.c.txt

    In the default configuration, these images are written to regular MTD partitions, which means they are available as regular MTD devices in Linux. You can list all MTD devides with

    Code
    1. cat /proc/mtd


    A typical output would be:

    Code
    1. dev: size erasesize name
    2. mtd0: 00040000 00020000 "NBoot"
    3. mtd1: 000c0000 00020000 "UserDef"
    4. mtd2: 00040000 00020000 "Refresh"
    5. mtd3: 000c0000 00020000 "UBoot"
    6. mtd4: 00040000 00020000 "UBootEnv"
    7. mtd5: 00800000 00020000 "Kernel"
    8. mtd6: 001c0000 00020000 "FDT"
    9. mtd7: 0f400000 00020000 "TargetFS"


    There you'll see that the kernel is on mtd5 and the device tree on mtd6. More detailled information about these devices can be found in /sys/class/mtd/mtd<n> where <n> is 5 or 6 in this case. And you can read and write data via /dev/mtd<n>.


    Remark:

    The Kernel and FDT partitions are marked as read-only in U-Boot so that they are not overwritten unintentionally. So if you want to write data to them in Linux, you have to remove the read-only flag in U-Boot first.


    Your F&S Support Team

    Xenomai haben wir nie ausprobiert. Wir können also nicht sagen, ob es funktioniert. Da bei Xenomai ein Patch in den Kernel eingebaut werden muss, ist es sogar sehr wahrscheinlich, dass es manuelle Änderungen am Kernel oder dem Patch erfordert, weil er sonst vermutlich nicht sauber auf unsere modifizierten Kernel-Sources anzuwenden geht. Die Konfiguration hierzu passiert in Buildroot unter "Kernel" -> "Linux Kernel Extensions" -> "Adeos/Xenomai Real-time patch". Zudem wird es dann vermutlich eine angepasste Kernel-Konfiguration brauchen, bei der das entsprechende Kernel-Modul aktiviert wird.


    Das alles wird nicht so ganz einfach sein...


    Was wollen Sie denn in Echtzeit erreichen? Normalerweise empfehlen wir unseren Kunden bei Echtzeit-Bedarf die Boards mit asymmetrischem Multiprocessing, wo dann ein Cortex-M4 unter FreeRTOS die Echtzeit-Aufgaben übernimmt, so dass man am Linux gar nichts ändern muss. Zum Beispiel unsere efusA9X.


    Ihr F&S Support Team

    In most cases, the USB to Serial converter is bad. These devices tend to be slightly off the baud rate and then the connection does not work. We have measured this many times, the baud rate of the board itself is exactly on spot.


    So try another USB to serial converter or use a PCI card with "real" serial ports.


    Your F&S Support Team

    We are currently working towards the next release. This will have buildroot-2018.11, Linux kernel 4.9.88 and a rather recent U-Boot (updating U-Boot is our current task). We hope to get this released by the end of the month.


    Your F&S Support Team

    Just an additional hint:


    MMC slots may be numbered differently in U-Boot and Linux. In U-Boot they are numbered in the sequence of initialization. We always start with the normal sized SD slot, then the Micro-SD slot and finally the eMMC. The intention is that the update and install scripts will look at mmc 0 by default, so this port is the port that is used for updates if you do not configure something else. And installation is done the easiest from a normal sized SD card, or from Micro-SD slot if there is no normal sized slot. On the other hand a non-removable eMMC is most probably not meaningful for a first time software installation in your production. This is why we add it as last device.


    Of course IDs can be differently if a slot type does not exist. So if an efusA7UL has WLAN and eMMC, then no regular SD card port is available. Then eMMC is actually mmc 0 in U-Boot. So in U-Boot the devices are always numbered starting with 0 without any gap.


    In Linux, the ports are named after the hardware index of the unit. On i.MX6, this is actually one less than the hardware number because hardware numbers start with 1 but Linux mmc device numbers start with 0. So if the slot is handled by MMC hardware port 3 of the i.MX6, then it will get the Linux device name mmcblk2. The initialization sequence does not matter and it will get this number even if there is no mmcblk0 and no mmcblk1.


    So you have to take care that you use the right number (device ID) in U-Boot and Linux, and, as I said, these numbers may differ.


    If you do not want this naming scheme in Linux, you can change this in the device tree by modifying the device aliases.


    Your F&S Support Team

    OK, then you have downloaded a wrong NBoot file that was not suited for your board. You have to take care that you use the correct NBoot for your CPU architecture:


    • i.MX6 Solo/DualLite/Quad: nbootimx6_<version>.bin

      This is efusA9, armStoneA9, armStoneA9r2, PicoMODA9, QBlissA9, QBlissA9r2, NetDCUA9


    • i.MX6 SoloX : nbootimx6sx_<version>.bin

      This is efusA9X, PicoCOMA9X, PicoCoreMX6SX


    • i.MX6 UltraLite/ULL: nbootimx6ul_<version>.bin

      This is efusA7UL, PicoCOM1.2, PicoCOMA7, PicoCoreMX6UL


    Also note that you need to use binary mode to download such a file. In DcuTerm use "File" -> "Transmit Binary File...", in TeraTerm use "File" -> "Send file..." and check the "Binary" checkbox.


    Also as a general rule, do not downgrade NBoot. So for example if version VN35 is installed when shipped, do not downgrade to a version before VN35. There may be a hardware option installed on the board that was not supported by an earlier version of NBoot so that in the worst case the older version does not start, making the board unusable as in your case.


    So either send us the board to reinstall NBoot or use MfgTool yourself now to install NBoot again. Do you have instructions on how to do this?


    Your F&S Support Team

    What did you do? How did you remove NBoot?


    If you use our starterkit baseboard, the LEDs may show if some voltage is missing. Other than that your can check if there is display output or some other signal that toggles during the boot process or when your application is running,


    The <0> is not a specific signal. A board may show nothing at all but still responds to MfgTool.


    If you can not get the module running again, send it to us as RMA.


    Your F&S Support Team

    When using the EDT1 display adapter, the backlight of the LCD is controlled by an LED driver chip that is connected via I2C to the CPU. In newer software versions like on armStoneA9 we have integrated this as a backlight driver unit, but on armStoneA5 with the Vybrid kernel, this is only visible as the LED controller chip itself and has to be set manually.


    Go to the LED controller chip with

    Code
    1. cd /sys/bus/i2c/devices/3-0060/


    There you will find settings for 4 LEDs. The backlight brightness is controlled by led1. Each LED can be set to four values:


    0: fully off

    1: fully on

    2: controlled by individual PWM

    3: controlled by group PWM


    Our default setting is 1, i.e. fully on. You can show this by calling

    Code
    1. cat led1_output


    So the idea is to switch to PWM mode 2. But to avoid a sudden drop in brightness (the default PWM value is 0), set the brightness before switching the mode. Or simply set the PWM brigthness also to fully on, then switch the mode and then set the final brightness.

    Code
    1. echo 255 > led1_pwm
    2. echo 2 > led1_output

    From now on you can set any value between 0 and 255 to led1_pwm to control the brightness. Example:

    Code
    1. echo 60 > led1_pwm

    Your F&S Support Team