7 Replies Latest reply on Feb 19, 2016 3:08 PM by shopen

    Unbind console from ttyMFD2 to reuse it



      I'd like to use the ttyMFD2 interface for an external device. Normally the boot output is provided over that interface.

      How can I unbind it and reuse it for my own purposes? I only want to use SSH over ttyGS0 as my console.


      I have change the UBoot commandline parameter "bootargs_console" from "console=ttyMFD2" to "none". But

      the result was that the ttyGS0 Interface wasn't accessible anymore. So I couldn't do anything.


      It is not possible to change "bootargs_console" back to "console=ttyMFD2" as "=" is not allowed as value.

      So I tried "console=ttyMFD2". But that's the same as ""bootargs_console=none".


      And futhermore the flashing with the phone Tool isn't possible anymore.


      What to do now?

        • 1. Re: Unbind console from ttyMFD2 to reuse it

          Hello Christoph.P,


          Several users have already tried to accomplish this, you can disable the console output by taking out console=ttyMFD2 earlyprintk=ttyMFD2,keep from the kernel boot options and the quiet option should turn off the kernel messages to console: fw_setenv bootargs_console quiet.

          Even though you can disable the console output that way serial-getty@ttyMFD2.service will anyways run and disabling it seems to have no effect so you will have to delete it from /lib/systemd/system and reboot.


          In order to enable serial port on boot you have to make the following modifications:


          echo mode1 > /sys/kernel/debug/gpio_debug/gpio135/current_pinmux
          echo mode1 > /sys/kernel/debug/gpio_debug/gpio134/current_pinmux


          Anyway, even though those modifications should enable you to use ttyMFD2 the users also report that the port throws garbage data when trying to send data. I suggest you to check Using ttyMFD2 in linux userspace the user found a solution using a pull up resistor, it might help you, let us know.



          • 2. Re: Unbind console from ttyMFD2 to reuse it

            Will disabling the kernel output with bootargs_console quiet prevent the flashing tool from flashing?

            I'm worried about potentially bricking my Edison.

            • 3. Re: Unbind console from ttyMFD2 to reuse it

              It shouldn't, the port used to flash Edison is ttyGS0. This is the same port detected by the host OS as a flash drive, so as long as this port is available you should be able to flash your board using Flash Tool Lite/flashall.sh.



              • 4. Re: Unbind console from ttyMFD2 to reuse it

                Doh! Right! I mixed up which was which. Thanks Peter.

                • 5. Re: Unbind console from ttyMFD2 to reuse it

                  I masked serial-getty@ttyMFD2.service and did the fw_setenv bootargs_console quiet as advised, and the kernel hangs on booting.

                  I haven't even gotten to activating UART2 for use with sensors. I see from the forums that some people have had hanging problems too, but it seems like this has worked for others too. Any ideas? Is it related to using the mini-breakout board?

                  • 6. Re: Unbind console from ttyMFD2 to reuse it

                    I was looking into the system services on /lib/systemd/system/ to see if I could find which service is related to the console output on Edison. I thought that it might be the reason why your Edison is getting stuck on boot, and then I found the service called serial-getty@.service. This looks like the service that controls it, you can try disabling it to see if there's any difference. Why don't you check it out?



                    • 7. Re: Unbind console from ttyMFD2 to reuse it

                      I don't know why, but this (changing the kernel boot options) would not work for me. 

                      The sensor spewing data would interfere with the boot sequence, or the kernel spewing messages would stop the sensor (which takes the letter 's' to stop).

                      We ended up going with a hardware solution which was very effective: Using a GPIO to turn the level-shifter on when the system was ready to communicate with the sensors.