PC104 bus access problem on Arcom Viper (ARM/Intel XScale pxa255)

Mar 25, 2008 1 Replies

I have a standard PC104 rs232 serial card stacked on my Arcom Viper PC104 SBC (single-board-computer) via the PC104 bus. Problem is I am unable to access it like a normal serial port even though I configure a serial device using setserial.



What I know:



- the Intel XScale PXA255 locates the second PCMCIA slot @ physical address 0x30000000



- the linux kernel source maps the above physical address to virtual address 0xf1000000 in arch/arm/mach-pxa/viper.c



- the Arcom Viper (physically) attaches the PC104 bus to the second PCMCIA slot and we know that PC104 is really an ISA bus



- my PC104 serial card can select from irqs 3-7 and all the standard COM ports up to COM8 (0x3f8, 0x2f8, ..., 0x2a0) via jumpers



- this platform (ARM) maps ISA irqs to different processor irqs. for example, on bootup I'll see indicators which map ISA irq 7 to irq 108



What I thought would work: - a simple setserial command with the virtual address of the PC104 bus + selected_port_on_serial_card with the mapped_irq on a standard ttyS# device would allow me to use that device just like a normal serial port. for example, if jumpers on the serial card selected port



0x2a8 (COM6) and (ISA) irq 7 (which maps to cpu irq 108), I would use:

# setserial /dev/ttyS1 port 0xf10002a8 irq 108 uart 16550a



This command returns instantly and the settings are in fact reflected, but it's not really communicating with the port. A simple `echo 123 > / dev/ttyS1` seems to hang for about 10 seconds before returning to the shell.



What am I doing wrong? I have verified that the mapping takes place during kernel init (arch/arm/mach-pxa/viper.c and generic.c). But if Iwere to cat /proc/iomem the whole 0x30000000 block is excluded as if it isn't mapped.



I think that if I can get the (physical) 0x30000000 range to show up in /proc/iomem, that my other problems would be solved. How can I get it to show up? Perhaps making a module (which I've never done)?



Thanks for any help.


I got it to work but the problem was the .iotype of the uart_port was set to UPIO_PORT. changing it to UPIO_MEM fixed half the problem. The other half of the problem is that now since .iotype is UPIO_MEM, I had to set uart_port.mapbase (serial_struct.iomem_base) to the PHYSICAL address of the port (0x3000002a8) and disregard .iobase. Some simple changes to the source code of setserial was all that was needed [e.g., ability to specify iomem_base and iotype of the serial_struct].

I didn't think there would be a problem using UPIO_PORT as there's practically no distinction between an io address and memory address on ARM as far as how you access it (with some exceptions), because an iotype of UPIO_PORT works on another (ARM) computer, but that computer is also running kernel 2.4. as compared to 2.6 on this viper computer.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required