I've got a board based on the Vortex86DX CPU which is an x86 based microcontroller. It has five 16550A UARTS, four (COM1-COM4) of which are at the usual i/o port addresses (0x3f8, 0x2f8, 0x3e8, 0x2e8) but the fifth (COM9) is at 0x010, irq 9. http://www.dmp.com.tw/tech/vortex86dx/ The problem is that I can't get the fifth one (COM9) to work in Linux. COM9 works correctly in a stand-alone DOS application when accessed at i/o port 0x010, but I can't even detect it from Linux. What I've done so far: * added COM9 to /drivers/tty/serial/8250/ (hacked existing driver to probe at 0x010) * enabled DEBUG_AUTOCONF in /drivers/tty/serial/8250/8250.c so I can see when and which addresses are being probed. * editted /arch/x86/kernel/setup.c because i/o port 0x010 overlapped an existing region reserved for dma1 which caused request_region() to fail. Datasheet for CPU confirmed different reserved i/o port regions. Result: the kernel failed to probe the UART at address 0x010 with the error "IER test failed". I used an i/o port probing utility to manually read/write port 0x010 but I could not detect any 16550A registers in the 0x010 to 0x017 region. It appears there is nothing there. I tried to write and read back data from the scratch register (offset +7), but it did nothing. My same tests pass on the other four UART addresses. The datasheet for the CPU doesn't say much about COM9. ftp://ftp.dmp.com.tw/DMP_Vortex86_Series_Software_Programming_Reference_091216.pdf On page 156 it mentions an "On-Chip Device Control Register" on the Southbridge which has a bit for doing "something" with COM9, but it doesn't say what it does. AFAIK the DOS application does not configure the Southbridge. I wrote a utility to read and write the Southbridge registers but I still failed to detect the UART. Am I on the right path? What else should I try? Would Linux block my ability to manually probe these i/o ports? thanks, Aras Vaichas -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
