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

This is a discussion on PC104 bus access problem on Arcom Viper (ARM/Intel XScale pxa255) - Embedded ; 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 ...

+ Reply to Thread
Results 1 to 2 of 2

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

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

    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.

  2. Re: PC104 bus access problem on Arcom Viper (ARM/Intel XScale pxa255)

    On Mar 25, 1:21 am, jonfaquit wrote:

    > 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
    >


    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.

+ Reply to Thread