Moschip 9901, tests good to BoB but will not talk to Mesa 7i90, is there a way?

Update: by removing parport, parport_pc, lp, and parport_serial with rmmod I am able to get the .hal address pushed through and it now shows ioaddr=0x3010 and iaddr_hi=0x3410 (or whatever else I set the values to in .hal).

Still board not found though.

I did again verify with the modules removed that 2portin test shows an active parallel port. The modules reload with a restart so I am not breaking the system (yet).

Maybe useful???

I noted that the error changes on LinuxCNC startup whether or not the 7i90 is physically plugged in.
(it does default back to the wrong addr_hi value without blowing out the parport drivers, but I'll work that out in if matters later)

If the board is plugged in I get an "invalid cookie, got 0x81818181, expected 0x55AACAFE"

If the 7i90 is not connected I get an "error reading hm2 cookie"

That made me curious what 0x81818181 is in binary...

100000011000000110000001100000011000000110000001

Am I looking at a heartbeat of some kind? Maybe my ribbon cable is off some how? (genuine mesa part, swapped with other working daughter board cables to observe, no change...) Can someone tell me if I can discover a pin mapping error with just a 4 channel oscilloscope or a logic analyzer?  

Logic analyzer to tell me what a volt meter could have done, or even logic and reason if I were a reasonable person

Strobe is is pulled high when LinuxCNC initializes the port, D0 is high, D1-D6 are pulled low, D7 is again high... see the pattern? 10000001 and repeat.


Not sure what to look at next, I'm open to suggestions.

My guess is that the port is not in EPP mode and neither LinuxCNC's
nor Mesaflash's standard hardware PP mode setting works.

I agree with your assessment, the question then would be, what can be done about it?

I did try booting to Windows-7 and looked for any settings available but found none.
I tried to rmmod away the services holding the port, which did free up the addr_hi parameter.
I have not yet learned how to configure the kernel to define the "mode" of the pcie card on boot, but I suspect it is the correct time to implement EPP before any other process' have an opportunity to lock it into another "mode". It makes sense that if the kernel is looking for an interrupt, it has set it up that way and is keeping it that way.

Can you be of assistance with configuring the parport driver module? How do I remove the IRQ during boot?

I hope that if I can assign the default (0x0378) port address to the pcie card and set the *_only_* available mode to EPP, there may be a chance it will communicate.

How about "known good" cards? Is there ANY ryme or reason to what works? Has anyone been successful using a PCIe parallel port card with a 7i43 or 7i90hd? What card did they use, which kernel, which PC,etc.

Typically you cannot set PCI/PCIE card IO addresses below 0x1000 or so as
that area is reserved for motherboard devices.

When I did compatibility testing, (many ears ago) The OXSemi PCI cards worked
but I have not tested any PCIE cards.

I doubt the interrupt has anything to do with the interface issues. You might look at the 9901 data sheet to see how EPP mode is enabled

I ordered a pair of PEX1P pcie cards, we'll give these a try first.
$25 =< value of a half hour of my time. I put 4 days into trying ( unsuccessfully ) to sort this Linux driver crap out. 

If the PEX1P's don't plug and play in the first boot or two, I am considering picking up an industrial pcie RS422/485 card to try.
If it doesn't play well RS422 with the 7i90hd's, I am sure I could get it to at least read in the data from some panasonic servo drivers.
I just cant let these Linux driver issues eat up any more of my time, have to be a master systems engineer to do simple things on Linux.

If the PEX1P's and the RS422 card are neither plug and play events, I'm tossing the 7i90hd's in a bin until I can pick up some *_cheap_* Rpi4/Rpi400's to run SPI as that seems to be a (the only?) supported format/combination beyond a PC with an integrated parallel port.
Might just toss them immediately if the PEX1P's are no joy. A 4 port ethernet card is $20 and an two additional 7i92tm would be sufficient and easy. 

I guess the silver lining is that I do now know my way around Debian in a far more intimate way which will help to move away from the simplicity and safety of Windows-7 as it gets less and less secure to hold onto. And I can see that my time is worth more than inexpensive hardware can save me.
Hind sight is 20/20. Will report back the outcome of the PEX1P's when they arrive.

I went to learn about "how" EPP mode is enabled because you suggested it... and I'm a sucker for punishment it appears.

What I found lead me to look closer into the IEEE1284 standard.
It was interesting:
"IEEE-1284 requires that bi-directional device communication is always initiated in Nibble Mode. If the host receives no reply in this mode, it will assume that the device is a legacy printer, and enter Compatibility Mode. Otherwise, the best mode that is supported on both sides of the connection is negotiated between the host and client devices by exchanging standardized Nibble Mode messages."

"The EPP protocol and current implementations provide a high degree of coupling between the peripheral driver and the peripheral. What this means is the software driver is always able to determine and control the state of communication to the peripheral at any given time. Intermixing of read and write operations as well as block transfers are readily done. This type of coupling is ideal for many register-oriented or real-time controlled peripherals such as network adapters, data acquisition, portable hard drives, and other devices."

That lead me down another rabbit hole of messing with rmmod to remove only some of the modules (parport,parport_pc,ppdev,lp,parport_serial)
to free up whatever is assigning the odd 0x3000 upper address. Removing ppdev was what freed it up, but broke the parport_serial module.
(Parport_serial is the module Linux uses for the MOSChip 9901 *_with_* two serial ports.
Different configurations of the card have different modules, 4xRS232, 1xRS232 + 1xLPT, 1xLPT + 0 serial, etc)

Which lead me back again to the /proc/sys/dev/parport/parport1/base-addr where the 12304 and 12288 are stored (0x3010 0x3000).
These values are gathered by the kernel during boot and cannot be modified in the base-addr file.
I understand that the "addr_hi=" value is only used by EPP, which would explain why only the EPP mode is broken. 
That is why I can test the port against a BoB successfully, but any communication with the 7i90hd fails.  

The bad port addressing to the parport_serial module I suspect is why the card will not enter EPP mode. 
It tries to talk to the 7i90hd with wonky addressing and the 7i90hd never hears anything to respond to. (my static logic analyzer 10000001)

Is it possible to configure the upper address to 0x3410 before the parport_serial module (driver) is loaded, if some combination of the register values inside the MOSChip/BIOS are passing the value to the kernel as 0x3000 during boot?

Where *_exactly_* do the vaues originate from?
(pcie slot 2+MOSChip=0x2010:0x2000, pcie slot 1+MOSChip=0x3010:0x3000)

Another day lost and I'm feeling a fool over $20 worth of junk pcie boards.
Yah, yah, I'm learning how computers work so it has some value right?

Look here: github.com/torvalds/linux/blob/master/dr...t/parport_pc.c#L2677 but this probably won't help.

I have received the PEX1P's and am able to make them work.
There is some odd behavior that has lead to more deep dive troubleshooting that may have revealed the root issue.

The odd behavior is that mesaflash will not recognize the 7i90's without first having run halrun successfully and only then attempting mesaflash.
After running halrun, mesaflash continues to work until the PC is rebooted.
Each card individually is functional with mesaflash only after halrun has connected to the specific board.

halrun, loadrt hostmot2, loadrt hm2_7i90 ioaddr=0x2010 ioaddr_hi=0x2410 epp_wide=0 config=""     // for parport1
halrun, loadrt hostmot2, loadrt hm2_7i90 ioaddr=0x4010 ioaddr_hi=0x4410 epp_wide=0 config=""     // for parport2
sudo mesaflash --device 7I90HD --epp --addr 0x2010 --readhmid      // or 0x4010 respectively
 
With this behavior repeatable I set out to monitor every piece of the puzzle I am aware of, lspci -vvv, dmesg, lsmod,
/proc/sys/dev/parport/parport(n), ptest.xml and look for changes between the functional and nonfunctional states.
(if anyone knows more sources of info I am happy to look)
The only change I am able to observe between when mesaflash will find the 7i90's and when it will not is that in the /proc/sys/dev/parport/parport(n)/active file the value goes from "none" to populated with "ppdev0 (or 1)" which I suppose is logical.

So, I looked very closely over the rest of the available data from the functional PEX1P cards compared to the nonfunctional SD-PEX50030 cards.

There is a difference in that the PEX1P uses parport & parport_pc modules as it is solely a parallel port card.
The SD-PEX50030 uses parport & parport_pc & parport_serial as it is a single parallel port with additional RS232 ports. 
The clue I think is that dmesg shows the mode of the cards as PEX1P= (prog-if 02 [ECP]) and SD-PEX50030= (prog-if 03 [IEEE1284]).

That made me look over again the IEEE 1284 /2000 specification. If I am understanding correctly, the standard is indicating that the PEX1P is beginning in ECP mode which then goes into nibble mode to establish communication with the 7i90's from there it can establish the use of EPP. 
The SD-50030 begins in IEEE1284 "compatibility" mode from where it then changes to nibble mode to establish communication with the 7i90's to establish the use of EPP. 

Both starting conditions ECP and IEEE1284 "compatibility" mode are acceptable to the IEEE1284 standard of protocol.

So why doesn't the SD-50030 get to EPP mode? I went and looked at the LinuxCNC code that sets EPP mode, what I found may (to my novice eyes) be the root issue? 

epp_boards.c;
385#     // set up the parport for EPP
386#     if(board->base_hi) {
387#          outb(0x94, board->base_hi + ECP_CONTROL_HIGH_OFFSET); // select EPP mode in ECR
388#     }

As far as I can tell, both the Mesa 7i90 and LinuxCNC expect the initial contact between the host and peripheral to be done in ECP mode. 
The condition of the signal/flash/hold lines (etc) on the parallel port are in different states depending on the mode. The IEEE1284 "compatibility" mode which is meant to talk to a legacy printer is not the expected state of communication protocol to be in when the host is attempting to establish a successful nibble, as LinuxCNC expects the port to transmit in ECP mode and the 7i90 expects to receive an ECP transmission.

I am not a programmer. Can a programmer look at this and tell me if it jives?
Would the solution possibly be to have LinuxCNC check the starting condition of the port ( as stated in the device-id that is sent during boot ) to first set the port to [ECP] mode if in [IEEE1284] then proceed with setting into EPP? OR could the solution be to set up the 7i90 to be able to initially respond to a transmission in "compatibility" mode the same as an initial transmission in ECP mode?  

As the older PC's running native parallel ports begin to die off there will be a number of people looking to put a pcie card into a new PC to keep their 7i90 based machines up and running, so it may be worth fixing this fault preemptively.

I have a working setup... Dell 7010 + PEX1P + 7i90hd, it has the halrun/mesaflash issue but that is serviceable if one knows the condition exists.