• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 1921 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Dynamically disabling serial port

Ron Olson
Intellectual 680 points

We have a need to dynamically disable a serial port, both for output and input.  Our board is an AM3517EVM derivative, running Linux 2.6.37.

When the kernel boots, we read a strap on the board, and based on that strap, we must either allow the port to function, or not.  We need this for security purposes, and we must eliminate all possibility of the port being used for any purpose.  The port happens to be ttyS2 (used for the serial console).

It seems to me that the most secure, and likely the simplest, means of doing this is to patch a low level serial driver, perhaps right above where it deals with the uart.  The patch would simply ignore an outgoing byte, and toss (or never read) any incoming bytes, based on our board strap.

But, so far I haven't found the right place for the patches.  I would have thought the patches would go into either 8250.c, serial_core.c, or omap-serial.c, and maybe they do.

Can anyone point me to a solution for this?

Thanks,
Ron

  • 0
    Guru 31670 points

    Ron,

    Simple method is there. Inside arch/arm/mach-omap2/ most likely in board-am3517evm.c file, you'll be initializing all the serial ports using oma_serial_init() function, If I remember correctly. You can read your strap based inside this function and call the serial init for UART2(ttyS2) if required. I hope this will solve the problem.

  • 0 in reply to Renjith Thomas
    Intellectual 680 points

    Hi Renjith,

    Thank you for your response.  That's a good thought, but I've tried that, and surprisingly, it doesn't disable the port.  That's one reason I decided to disable the port from the lowest level, eliminating whatever the higher level software might be doing.  Even that isn't a sure thing.  I'm concerned that there may not be one centralized point that all port access goes through, making my goal more challenging.

    Ron

  • 0 in reply to Ron Olson
    Guru 31670 points

    Ron,

    It must work as I have tried the same several times as part of boot time optimization. It will not enable the serial driver at all. 

    Also, you can try doing a pinmux settings change so that UART2 will not be physically connected to the output.

  • 0 in reply to Renjith Thomas
    Intellectual 680 points

    Renjith,

    Renjith said:

       It must work as I have tried the same several times . . .

    Maybe it 'must work', but it doesn't, and that's what counts.  There's obviously something important that's different between your configuration and mine.

    Your comment about changing the UART pin's mux settings is a good one, and maybe one I'll try.  But first, I'm going to hunt some more for the code that actually sends the bytes out the uart, and similarly for reading the bytes.  If anyone out there can point me to that exact code, I'm still listening.

    Thanks,
    Ron

  • 0 in reply to Ron Olson
    Guru 31670 points

    Ron,

    I literally mean what I said. It must work! Check omap_serial_init() function carefully. You'll be passing an array of structures where each serial port will be an element in the structure. By commenting off one of the elements of the structure you can easily disable 

    If you want to change the serial driver where read and write happens, I believe you'll end up writing more code as the driver is generic for any of the UART ports. You've to differentiate your port specifically for each and every function.