Hi Patrick (et al),
Yes I am having trouble sending. Booting up with an older build, I can send using a program I wrote to another device with no issues. The exact same program on the newer build will receive just fine, but will only send if I start a separate process that heavily utilizes the cpu (very repeatable) to capture imagery from a usb camera and compress it to jpeg. I don’t need that second process running with the earlier build.
What is the name of the OMAP-specific module? Is it a module loaded via udev or some other startup script?
Your newer kernel uses the name "ttyO0" because it has an OMAP-specific module for the UART (hence the "O"). I get the same "UART: undefined" result from setserial, but my UART works as expected. You should not try to set the UART type.
Unless I'm missing something, I think everything looks OK. Do you have a problem sending/receiving data with the UART?
I have two gumstixs, one which is working properly running an older kernel, one that is not working properly built from a newer kernel. Both kernels were built from the main branch of the gumstix source tree. I am booting both from sd cards, and swapping sd cards in the gumstix results in the a swap of problematic gumstix.
The issue belongs to the UARTS on my gumstix. I installed setserial to help figure out the problem and have the following output:
/dev/ttyS0, UART: 16654, Port: 0x0000, IRQ:72
/dev/ttyO0, UART: undefined, Port: 0x0000, IRQ: 72
You’ll probably notice the device names are not the same. This is one of the weird things I found when I updated. I don’t know how to change the ttyO0 to ttyS0, not that I think that is the problem. Trying to specify the UART type on the bad gumstix results in :
$setserial /dev/ttyO0 uart 16654
Cannot set serial info: Invalid argument
While that exact same command (on the other gumstix using ttyS0) works without error.
I’m at a loss as to what else to try. I think it must have something to do with improper kernel modules (user space doesn’t show any difference with lsmod).