1 4 5 6 7 8 Previous Next 114 Replies Latest reply on Jul 31, 2017 12:40 PM by 0andriy Go to original post
      • 90. Re: Newer Kernel on Edison (OpenWrt)
        FerryT

        :-) You don't see how intimidating making modifications to the kernel is to most of us 'ordinary' people.

         

        The first time I built a kernel first time right was when I built yours. Normally there is always something wrong: build-deps, wrong compiler version, whatever. And you know what happens when you make modifications, compiler errors and finally a non-booting kernel, very difficult to debug.

         

        The only modification we dared to apply to the edison 3.10.14 kernel was increase a buffer size (low risk). And I'm proud to say, I fixed an error in the hsu driver myself (ehmm, it's more of a hack). You might care to have a quick look as the issue may be present in the vanilla kernel as well (and non only in the hsu): HSU: reset TX buffer after DMA · htot/edison-linux@a36792f · GitHub This solves interchar gaps on transmit.

         

        The problem is caused by the use of a circular buffer for DMA, DMA don't like that.

        • 91. Re: Newer Kernel on Edison (OpenWrt)
          FerryT

          I like the approach in meta-acpi, I think what I saw to enable RX/TX was just 2 lines (+ included file that does the hard work).

           

          Do I understand correctly that with DT you can have overlay fragments that you can load into the kernel from user space and cause unbinding/binding of the changed hardware without reboot? Similar to hotplugging?

           

          So where is Edison heading, ACPI or DT?

          • 92. Re: Newer Kernel on Edison (OpenWrt)
            0andriy

            With DT something like you described is possible (though I dunno any limitations there).

            Edison as being x86 platform is heading towards ACPI. Though there not much time I have to do this. Needs volunteers for U-Boot to achieve that.

             

            Wrt ACPI there is a discussion right now in the mailing list how to load / unload additional SSDT tables and if that functionaly has ever been tested.

            • 93. Re: Newer Kernel on Edison (OpenWrt)
              FerryT

              Yes, I just the mailing lists and saw DT is mostly arm and ACPI mostly x86.

               

              So, are the u-boot modifications something that can be broken down into small steps?

              • 94. Re: Newer Kernel on Edison (OpenWrt)
                0andriy

                FerryT

                (We may create a separate thread about this)

                The first smallest step is to enable ACPI table generation and create a main and mandatory table, i.e. FADT.

                • 95. Re: Newer Kernel on Edison (OpenWrt)
                  FerryT

                  Alright, let me figure what ACPI table generation means and why u-boot needs to do that. Then I'll create a separate thread.

                   

                  On the current pinmux state: as I understand the current (platform) approach lets the driver set the pinmux when modprobed. So the driver takes the pin when loaded. I guess that when another driver has already taken the pin, modprobe will fail. And if everything behaves nicely, unloading the driver will release the pin again?

                   

                  If so, in many cases the 'dynamic'  changing of pinmux is already possible, elegantly even, but maybe not very fine grained. For instance if there would be 3 hsu uarts muxed with gpios, loading the hsu driver would take 6 gpios, or maybe 12 if rts/cts pins are taken too. Or may be not, if the pins are taken on opening the port.

                   

                  I will translate the tables in the Edison HW guide into a block diagram of the internal pinmux and pinconctrol (yeah, hw engineer can't read tables, need schematic)  and post that here or on github. And around a bit, to see how it works. I already found that via debugfs you get quite detailed info on the state of pins.

                  • 96. Re: Newer Kernel on Edison (OpenWrt)
                    0andriy

                    Because there is no ACPI tables provided by firmware! U-Boot has to provide them instead.

                     

                    Yes, you can't request same pins for two devices simultaneously. That's by definition of pin muxing.

                    Releasing and acquiring pins in case of built-in pin muxing table is out of my knowledge right now. I need to check the code to answer. So, better you do it yourself to get deeper understanding.

                     

                    UART by the way is specific case. You need to split pin groups to have different settings for Tx/Rx vs. Tx/Rx/CTS/RTS. It's not supported by pincontrol right now (all four pins are in UART group always).

                     

                    If you wish to translate, though I found them quite convenient. Numbers are the same for GPIO lines (so, no need to map them again in newer kernel)

                    • 97. Re: Newer Kernel on Edison (OpenWrt)
                      FerryT

                      I haven't read to much yet, but as I understand, u-boot loads the compiled acpi tables into memory and passes them to the kernel (found example here at the end LEG/Engineering/Kernel/ACPI/AcpiOnArndaleUboot - Linaro Wiki ). As I get it, this should already be in your version of u-boot. And Mika's meta-acpi layer selects and compiles the acpi tables and places the binaries in the deploy directory. So it seems everything is in place. Except the ACPI table itself.

                       

                      What worries me, is that on the supported platforms you need to dump the acpi from the kernel and decompile to get a starting point. But on edison I fear we need start from scratch.

                      • 98. Re: Newer Kernel on Edison (OpenWrt)
                        0andriy

                        Yes, there is no fear — new interesting adventure is about to begin!

                        So, and what a least we need is FADT table as a first (already big) step.

                        • 99. Re: Newer Kernel on Edison (OpenWrt)
                          FerryT

                          No, I was wrong. FADT is (or can be) generated by u-boot. Reason is bios/system firmware/u-boot as bios needs to fill in some run time data. From u-boot/README.x86 at master · qemu/u-boot · GitHub :

                           

                          Current ACPI support in U-Boot is basically complete. More optional features

                          can be added in the future. The status as of today is:

                           

                          * Support generating RSDT, XSDT, FACS, FADT, MADT, MCFG tables.

                          * Support one static DSDT table only, compiled by Intel ACPI compiler.

                          * Support S0/S3/S4/S5, reboot and shutdown from OS.

                           

                          So, you are right (of course), we need to add that support to u-boot. We can of course use baytrail or minnowmax as example.

                          • 100. Re: Newer Kernel on Edison (OpenWrt)
                            FerryT

                            So I have set my anger aside on the discontinuation of the Edison and will put a statement in a new thread on the subject as soon as I can write sentences on this that will be able to pass the moderators.

                             

                            In the meanwhile I have decided to continue working on the Morty based Edison distribution using 0andriy's u-boot and kernel, and possibly upgrade (when I feel like it) mraa and upm to the latest version while porting those to the new kernel.

                             

                            Why? Because I like the Edison and because it is imho the most significant breakthrough Intel has achieved in years for industrial markets (hnghh, grumble, swallowing words reserved for another thread....).

                             

                            To the point: I am trying to get serial communication going with linux 4.11, without mraa, that would be on port /dev/ttyS1. As I understand, pinmuxes on the edison should already be set to uart by default, or at least when the port is opened. I believe external multiplexers still need to be set. Now looking at:

                            root@edison:~# cat /sys/kernel/debug/pinctrl/pinctrl-merrifield/pinmux-pins | grep -i uart

                            pin 115 (GP124_UART_0_CTS): (MUX UNCLAIMED) (GPIO UNCLAIMED)

                            pin 116 (GP125_UART_0_RTS): (MUX UNCLAIMED) (GPIO UNCLAIMED)

                            pin 117 (GP126_UART_0_RX): (MUX UNCLAIMED) (GPIO UNCLAIMED)

                            pin 118 (GP127_UART_0_TX): (MUX UNCLAIMED) (GPIO UNCLAIMED)

                            pin 119 (GP128_UART_1_CTS): (MUX UNCLAIMED) (GPIO UNCLAIMED)

                            pin 120 (GP129_UART_1_RTS): (MUX UNCLAIMED) (GPIO UNCLAIMED)

                            pin 121 (GP130_UART_1_RX): (MUX UNCLAIMED) (GPIO UNCLAIMED)

                            pin 122 (GP131_UART_1_TX): (MUX UNCLAIMED) (GPIO UNCLAIMED)

                            pin 123 (GP132_UART_2_CTS): (MUX UNCLAIMED) (GPIO UNCLAIMED)

                            pin 124 (GP133_UART_2_RTS): (MUX UNCLAIMED) (GPIO UNCLAIMED)

                            pin 125 (GP134_UART_2_RX): (MUX UNCLAIMED) (GPIO UNCLAIMED)

                            pin 126 (GP135_UART_2_TX): (MUX UNCLAIMED) (GPIO UNCLAIMED)

                             

                            This can't really be true as I have the console on UART_2, so it looks like pinmux-pins might not be exact.

                             

                            Now in the past we had a simple little program to write and read to the serial port on the edison arduino board, with TX looped back to RX. Before we ran that we needed to run a shell script to set internal and external muxes, port direction, level etc. In the following I disabled the lines I think we don't need with ## (# is just comments):

                            # allow access to uart pins

                            #  0  130 RX input pullup

                            #  1  131 TX output pullup

                            #  2  128 CTS

                            #  4  129 RTS

                             

                            # 0 - RX 

                            ##echo 130 > /sys/class/gpio/export # rx (input) 

                            echo 248 > /sys/class/gpio/export # output enable 

                            echo 216 > /sys/class/gpio/export # pullup enable 

                             

                            # 1 - TX 

                            ##echo 131 > /sys/class/gpio/export # tx (output) 

                            echo 249 > /sys/class/gpio/export # output enable 

                            echo 217 > /sys/class/gpio/export # pullup enable

                             

                            # CTS

                            ##echo 128 > /sys/class/gpio/export

                            echo 250 > /sys/class/gpio/export

                            echo 218 > /sys/class/gpio/export # pullup enable

                             

                            # RTS

                            ##echo 129 > /sys/class/gpio/export

                            echo 252 > /sys/class/gpio/export

                            echo 220 > /sys/class/gpio/export # pullup enable

                             

                            # TRI_STATE_ALL signal is controlled by GPIO 214

                            ##echo 214 > /sys/class/gpio/export

                            ##echo low > /sys/class/gpio/gpio214/direction

                             

                            # RX

                            echo low > /sys/class/gpio/gpio248/direction 

                            echo in > /sys/class/gpio/gpio216/direction 

                            ##echo mode1 > /sys/kernel/debug/gpio_debug/gpio130/current_pinmux # mode1 is used to set the UART interface in Edison 

                            ##echo in > /sys/class/gpio/gpio130/direction 

                             

                            # TX

                            echo high > /sys/class/gpio/gpio249/direction 

                            echo in > /sys/class/gpio/gpio217/direction 

                            ##echo mode1 > /sys/kernel/debug/gpio_debug/gpio131/current_pinmux # mode1 is used to set the UART interface in Edison 

                            ##echo out > /sys/class/gpio/gpio131/direction 

                             

                            # CTS

                            echo low > /sys/class/gpio/gpio250/direction 

                            echo in > /sys/class/gpio/gpio218/direction 

                            ##echo mode1 > /sys/kernel/debug/gpio_debug/gpio128/current_pinmux # mode1 is used to set the UART interface in Edison 

                            ##echo in > /sys/class/gpio/gpio128/direction 

                             

                            # RTS

                            echo high > /sys/class/gpio/gpio252/direction 

                            echo in > /sys/class/gpio/gpio220/direction 

                            ##echo mode1 > /sys/kernel/debug/gpio_debug/gpio129/current_pinmux # mode1 is used to set the UART interface in Edison 

                            ##echo out > /sys/class/gpio/gpio129/direction 

                             

                            # TRI_STATE_ALL signal is controlled by GPIO 214

                            ##echo high > /sys/class/gpio/gpio214/direction

                             

                            The problem is, is doesn't work. I noted the following:

                            1. Doing `echo 131 > /sys/class/gpio/export` # tx (output)  claims the pin for gpio, so I disabled that, same for the other 3 pins
                            2. Doing `echo 214 > /sys/class/gpio/export` gives an error. That is very strange as the pin does exist (pin 214 (GP63): (MUX UNCLAIMED) (GPIO UNCLAIMED)). Nevertheless it is only used for the TRI_STATE_ALL signal, and I think serial comm should work without.
                            3. I removed the echo mode1 lines, as the /sys/kernel/debug/gpio_debug does not exist anymore obviously.
                            4. Running `screen /dev/ttyS1 115200` on the edison does not work and neither does our simple little test program. The program connects to the port without error, transmits some bytes, but receives nothing. Moreover, while running, `cat /sys/kernel/debug/pinctrl/pinctrl-merrifield/pinmux-pins | grep -i uart` does not show any muxes being claimed. But again, that might mean nothing.

                             

                            I know 0andriy has something similar working, so the fault must be with me. What do I need to more (else) to configure /dev/ttyS1 on the Edison Arduino board?

                            • 101. Re: Newer Kernel on Edison (OpenWrt)
                              FerryT

                              Hmm, it probably has something to do with:

                              root@edison:~# cat /sys/kernel/debug/pinctrl/pinctrl-merrifield/pins | grep -i i2c

                              pin 101 (GP19_I2C_1_SCL) not available

                              pin 102 (GP20_I2C_1_SDA) not available

                              pin 103 (GP21_I2C_2_SCL) not available

                              pin 104 (GP22_I2C_2_SDA) not available

                              pin 105 (GP17_I2C_3_SCL_HDMI) not available

                              pin 106 (GP18_I2C_3_SDA_HDMI) not available

                              pin 107 (GP23_I2C_4_SCL) not available

                              pin 108 (GP24_I2C_4_SDA) not available

                              pin 109 (GP25_I2C_5_SCL) not available

                              pin 110 (GP26_I2C_5_SDA) not available

                              pin 111 (GP27_I2C_6_SCL) not available

                              pin 112 (GP28_I2C_6_SDA) not available

                              pin 113 (GP29_I2C_7_SCL) not available

                              pin 114 (GP30_I2C_7_SDA) not available

                              pin 180 (I2C_0_SCL) not available

                              pin 181 (I2C_0_SDA) not available

                               

                              As I understand I2C_1 and I2C_6 should be available (with only I2C_1 working).

                              I guess I need to modprobe a driver. Any tips?

                              • 102. Re: Newer Kernel on Edison (OpenWrt)
                                FerryT

                                Nope, from:

                                root@edison:~# journalctl -b | grep -i pca

                                Jun 25 15:05:00 edison kernel[2250]: [    1.106618] pca953x 1-0020: 1-0020 supply vcc not found, using dummy regulator

                                Jun 25 15:05:00 edison kernel[2250]: [    1.106767] pca953x 1-0020: failed reading register

                                Jun 25 15:05:00 edison kernel[2250]: [    1.111780] pca953x: probe of 1-0020 failed with error -121

                                Jun 25 15:05:00 edison kernel[2250]: [    1.111999] pca953x 1-0021: 1-0021 supply vcc not found, using dummy regulator

                                Jun 25 15:05:00 edison kernel[2250]: [    1.113056] pca953x 1-0022: 1-0022 supply vcc not found, using dummy regulator

                                Jun 25 15:05:00 edison kernel[2250]: [    1.114257] pca953x 1-0023: 1-0023 supply vcc not found, using dummy regulator

                                 

                                So actually 1-0020 failed, explaining TRI-STATE-ALL can be addressed.

                                 

                                Strange thing: 1-0020 and 1-0021 are in reality PCAL9535AHF and 1-0022 and 1-0023 are PCAL9555AHF.

                                So syslog says: pca953x, but:

                                root@edison:~# cat /sys/class/i2c-adapter/i2c-1/1-0020/modalias

                                i2c:pcal9555a

                                 

                                Anyway, to get ttyS1 working I don't need 1-0020. Afaik with the above script, direction etc should be set as needed. Still ttyS1 doesn't work.

                                • 103. Re: Newer Kernel on Edison (OpenWrt)
                                  0andriy

                                  FerryT wrote:

                                  ...

                                  To the point: I am trying to get serial communication going with linux 4.11, without mraa, that would be on port /dev/ttyS1. As I understand, pinmuxes on the edison should already be set to uart by default, or at least when the port is opened. I believe external multiplexers still need to be set. Now looking at:

                                  pin 119 (GP128_UART_1_CTS): (MUX UNCLAIMED) (GPIO UNCLAIMED)

                                  pin 120 (GP129_UART_1_RTS): (MUX UNCLAIMED) (GPIO UNCLAIMED)

                                  pin 121 (GP130_UART_1_RX): (MUX UNCLAIMED) (GPIO UNCLAIMED)

                                  pin 122 (GP131_UART_1_TX): (MUX UNCLAIMED) (GPIO UNCLAIMED)

                                  This can't really be true as I have the console on UART_2, so it looks like pinmux-pins might not be exact.

                                  ...

                                  The problem is, is doesn't work. I noted the following:

                                  1. Doing `echo 131 > /sys/class/gpio/export` # tx (output) claims the pin for gpio, so I disabled that, same for the other 3 pins
                                  2. Doing `echo 214 > /sys/class/gpio/export` gives an error. That is very strange as the pin does exist (pin 214 (GP63): (MUX UNCLAIMED) (GPIO UNCLAIMED)). Nevertheless it is only used for the TRI_STATE_ALL signal, and I think serial comm should work without.
                                  3. I removed the echo mode1 lines, as the /sys/kernel/debug/gpio_debug does not exist anymore obviously.
                                  4. Running `screen /dev/ttyS1 115200` on the edison does not work and neither does our simple little test program. The program connects to the port with
                                  5. out error, transmits some bytes, but receives nothing. Moreover, while running, `cat /sys/kernel/debug/pinctrl/pinctrl-merrifield/pinmux-pins | grep -i uart` does not show any muxes being claimed. But again, that might mean nothing.

                                  1. You have not to switch them to the mode 0 (effectively GPIO). By default firmware sets them to mode 1 (UART). You may check modes somewhere in /sys/kernel/debug/gpio.

                                  2. You mixed GPIO pins with pins inside SoC. There are different lists! Pins, available as GPIOs are listed in the mapping (somewhere under /sys/kernel/debug/pinctrl/pinctrl-merrifield/*map* (IIRC).  Btw, pin 214 available as GPIO 53 (since a good chosen name). In one of the following message you mentioned problems with GPIO expander enumeration. That's a culprit.

                                  4. I tested UART1 with Sparkfun base board + UART board, works perfectly. So, the issue is indeed in the expanders.

                                  5. See 1.

                                   

                                  Now, about an error you have seen. I saw few times such an error and IIRC it was related to the default speed of the I2C host and other settings. So, what I would recommend is to investigate SDA hold and other timings. I copied them from some of old kernel patches and they might be (slightly) wrong. (Check structures in i2c-designware-pci.c) There were also patches regarding algo og choosing those values, so, please check as well, perhaps calculated values might work better.

                                  • 104. Re: Newer Kernel on Edison (OpenWrt)
                                    FerryT

                                    Strangely only 1-0020 gives and error, the other 3 are detected fine (screenshot). I believe I only need 1-0023 to set the direction of the level translators correctly, and that gpiochip248 gives pins 248..254. And 1-0021 for pullup/downs (gpiochip216)

                                    I am not touching GP130, GP131, or pin 121, pin122 now, only:

                                    # 0 - RX 
                                    # rx (input) is muxed with GP130, pin 121, level translator direction must be set on 248
                                    echo 248 > /sys/class/gpio/export
                                    echo low > /sys/class/gpio/gpio248/direction # set to input
                                    echo 216 > /sys/class/gpio/export
                                    echo in > /sys/class/gpio/gpio216/direction # no pullup

                                    # 1 - TX 
                                    # tx (output) is muxed with GP131, pin 122, level translator direction must be set on 249
                                    echo 249 > /sys/class/gpio/export
                                    echo high > /sys/class/gpio/gpio249/direction # set to output
                                    echo 217 > /sys/class/gpio/export 
                                    echo in > /sys/class/gpio/gpio217/direction # no pullup

                                     

                                    I think this all there is to do right?

                                    1 4 5 6 7 8 Previous Next