parport does not work in diection "in"

Hi again

I had a huge lot of problems with one of these cards some years back, tried looking back over things I did to get it working and came up with these snippets. I seem to remember the 9815 was notorious.
Might assist, are not a solution per se.

Data sheet for the card
www.asix.com.tw/FrootAttach/datasheet/MC...5_Datasheet_v200.pdf

Another bit I seem to recall was that the card is supposed to be PnP which causes some problems on its own.
It may not be initialised properly under linux running EMC.
This manifests itself with registers shown as disabled, but I seem to recall that the below actually assisted when I was trying to force it into a mode which allowed running as input on pins 2-9

/sbin/insmod /lib/modules/CORRECT_KERNEL_HERE-rtai/kernel/drivers/parport/parport_pc.ko
/sbin/rmmod ppdev
/sbin/rmmod lp
/sbin/rmmod parport_pc

Thirdly, this C program was written by Jeff or Jon or possibly Chris, whilst it should not be necessary to force the card into EPP mode to get it to work in input mode, I seem to recall that only after I had compiled and used the program, did I get the card to work.

Finally, try moving the card to another slot, preferably swapping it with another card.
The computer allocates the port addresses and interrupts dynamically and sometimes something as simple as this works.
I can't figure out why your addresses are all so close to each other, I have always had at least a 0x200 separation between port addresses in the cards I have tried in the past.

Just some thoughts, one of them might do something.

grandixximo wrote:

Same goes for the 0x378 parport, it does not work as in, even after changing BIOS settings to SPP.

Now, that is expected. SPP is the original output-only printer port, so it would be expected that
input won't work. PS/2 or Bidir is the lowest mode that supports input on the data lines.

The ports both work as "out" on address 1020 for the flyer and 1030 for the hardwired.

It maybe that the hardwired port does not have mode control register, or maybe they are NOT ABOVE the port address?

Well, your tests confirm the data register addresses. But, the mode control registers could
be anywhere. Apparently they could be below the data port addr, or maybe the mode
control regs are BOTH in the same range of 8 addresses.

Jon

ArcEye wrote:

Thirdly, this C program was written by Jeff or Jon or possibly Chris, whilst it should not be necessary to force the card into EPP mode to get it to work in input mode, I seem to recall that only after I had compiled and used the program, did I get the card to work.

//cause standard PCI parallel port card to go to EPP mode

That code is effectively equivalent to my pcisetup program, which is on my web site.
It is not the version written by me, however. But, it assumes the ECR register is at
base address + 0x402, which we have pretty well established is not the case for
your board. I think we need to make up a new version of this program which
allows you to type in the ECR address directly, and maybe gives some diagnostic
results afterward.

Finally, try moving the card to another slot, preferably swapping it with another card.
The computer allocates the port addresses and interrupts dynamically and sometimes something as simple as this works.
I can't figure out why your addresses are all so close to each other, I have always had at least a 0x200 separation between port addresses in the cards I have tried in the past.

That may help, especially if it causes the parport board to be enumerated before/after some
other PCI card. If there is no other PCI card in the system, it is less likely to help.

Jon

Maybe i should have told you guys before, my PC it's not a normal PC, it's a Mini-ITX, i have only one PCI, maybe that is why the address are so near??

The 0x378 parport does not work as "in" even if set as bi-directional or EPP in the bios

after running parpot-pc.ko

on lspci-v i get

04:00.0 Class 9815: NetMos Technology PCI 9815 Multi-I/O Controller (rev 01)
Subsystem: LSI Logic / Symbios Logic Device 0020
Flags: medium devsel
I/O ports at 1870
I/O ports at 1000
I/O ports at 1460
I/O ports at 1468
I/O ports at 14d0
I/O ports at 90b00000
Kernel modules: parport_pc

04:00.1 Class 9815: NetMos Technology PCI 9815 Multi-I/O Controller (rev 01)
Subsystem: LSI Logic / Symbios Logic Device 0020
Flags: medium devsel
I/O ports at 1010
I/O ports at 1020
I/O ports at 1470
I/O ports at 1478
I/O ports at <ignored>
I/O ports at 1030
Kernel modules: parport_pc

04:00.2 Class 9815: NetMos Technology PCI 9815 Multi-I/O Controller (rev 01)
Subsystem: LSI Logic / Symbios Logic Device 0020
Flags: medium devsel
I/O ports at 1040
I/O ports at 1050
I/O ports at 1480
I/O ports at 1488
I/O ports at 1060
I/O ports at 90b00010
Kernel modules: parport_pc

04:00.3 Class 9815: NetMos Technology PCI 9815 Multi-I/O Controller (rev 01)
Subsystem: LSI Logic / Symbios Logic Device 0020
Flags: medium devsel
I/O ports at 1070
I/O ports at 1080
I/O ports at 1490
I/O ports at 1498
I/O ports at <ignored>
I/O ports at 1090
Kernel modules: parport_pc

04:00.4 Class 9815: NetMos Technology PCI 9815 Multi-I/O Controller (rev 01)
Subsystem: LSI Logic / Symbios Logic Device 0020
Flags: medium devsel
I/O ports at 10a0
I/O ports at 10b0
I/O ports at 14a0
I/O ports at 14a8
I/O ports at 10c0
I/O ports at 90b00020
Kernel modules: parport_pc

04:00.5 Class 9815: NetMos Technology PCI 9815 Multi-I/O Controller (rev 01)
Subsystem: LSI Logic / Symbios Logic Device 0020
Flags: medium devsel
I/O ports at 10d0
I/O ports at 10e0
I/O ports at 14b0
I/O ports at 14b8
I/O ports at <ignored>
I/O ports at 10f0
Kernel modules: parport_pc

04:00.6 Class 9815: NetMos Technology PCI 9815 Multi-I/O Controller (rev 01)
Subsystem: LSI Logic / Symbios Logic Device 0020
Flags: medium devsel
I/O ports at 1400
I/O ports at 1410
I/O ports at 14c0
I/O ports at 14c8
I/O ports at 1420
I/O ports at 90b00030
Kernel modules: parport_pc

04:00.7 Class 9815: NetMos Technology PCI 9815 Multi-I/O Controller (rev 01)
Subsystem: LSI Logic / Symbios Logic Device 0020
Flags: medium devsel
I/O ports at 1430
I/O ports at 1440
I/O ports at 14e0
I/O ports at 14e8
I/O ports at <ignored>
I/O ports at 1450
Kernel modules: parport_pc


and nothing works no more

grandixximo wrote:

Maybe i should have told you guys before, my PC it's not a normal PC, it's a Mini-ITX, i have only one PCI, maybe that is why the address are so near??

The 0x378 parport does not work as "in" even if set as bi-directional or EPP in the bios

after running parpot-pc.ko

on lspci-v i get

04:00.0 Class 9815: NetMos Technology PCI 9815 Multi-I/O Controller (rev 01)
. . . .


and nothing works no more

AIeeeeee, WAYY too many parallel ports, I lost count. One of the terrible curses of the PC architecture
is the very limited I/O space and the insanely limited number of interrupt vectors. I remember the days
of the PDP-11, where you had the entire memory space available for I/O devices, and room for
almost 1000 interrupt vectors, when you needed to do special systems with a lot of I/O.

Do you REALLY have that many ports, or has the BIOS gone crazy? You say only one PCI
port, so the BIOS was confused, or else the memory area where it writes this info
must have gotten scrambled by the parport-pc (or other) module. That is just a region in
very low memory where it leaves a snapshot of the PnP configuration before booting the
OS.

Jon

i wrote this as suggested that it may help

/sbin/insmod /lib/modules/CORRECT_KERNEL_HERE-rtai/kernel/drivers/parport/parport_pc.ko

and then i got that strange many ports in lspci -vv

but everything returned to normal once i restarted the PC.

normal meaning i cannot use port 378 nor 1030 as IN...

I cannot possibly have that many parport physically on my PC, as you say there are not enough I/O

Have you come to any resolution on the port direction issues?


Ray

No it's still like that, i have make my I/O suffice in the manner that they come, i cannot change the port as i like, but the way they are it's not bad

Do you have the same problem?

What PC are you using?

I haven't really dig deep on the issue, but i'd be happy if someone found a solution...

The problem I am having is a little different.

The machine is based on an Intel Atom D510 motherboard, with the following:
a netmos based PCI parallel port card
PMDX 132 BOB board with GeckoG202s
PMDX 122 BOB card

The problem I was having was erratic stepping. I had not gotten to checking the inputs from the 122 to the PCI parallel card.
I found that when the second PP was plugged in, the supply voltage on the 122 was loaded down to about half, with a lot of ripple. That is supplied from the 132, so the 132 was effected, which effected the Geckos.
More troubleshooting exposed that I had not picked the correct i/o address for the PCI card. I started out using the address with the 16bit, but ended up using one of the 8bit locations.

A while back I had discovered that when you configure the second & third PP for IN with the StepConf wizard, the HAL file sets them as OUT. I tried setting them to OUT in StepConf, and the HAL file showed them as IN.

So now the 132 power supply is not being loaded down. I will test the inputs to he 122/second PP tonight.

One more weird anomaly I found, when I tried to plug the second PCI PP to the 132 (before I found the addressing issue), nothing worked, except the E-stop, on pin 10. I would expect no response, not a response from one pin. I duplicated the experiment with the first PP with the same result. No stepping from the drivers, but the E-stop input functioned correctly.

I still have a bunch of issues to sort out, and learning to do.

Like what StepConf puts into the following variables in the HAL file:
setp stepgen.0.position-scale [ASIS_0] SCALE
setp stepgen.0.steplen 1
setp stepgen.0.stepspace 0
setp stepgen.0.dirhold 35000
setp stepgen.0.dirsetup 16000

I would expect those variables to be single digit of >=1.

More things to learn!

I hope this was not too long winded!

Ray