Commit Graph

19 Commits

Author SHA1 Message Date
Weongyo Jeong
b3974c00b5 Integrate the NDIS USB support code to CURRENT.
Now the NDISulator supports NDIS USB drivers that it've tested with
devices as follows:

  - Anygate XM-142 (Conexant)
  - Netgear WG111v2 (Realtek)
  - U-Khan UW-2054u (Marvell)
  - Shuttle XPC Accessory PN20 (Realtek)
  - ipTIME G054U2 (Ralink)
  - UNiCORN WL-54G (ZyDAS)
  - ZyXEL G-200v2 (ZyDAS)

All of them succeeded to attach and worked though there are still some
problems that it's expected to be solved.

To use NDIS USB support, you should rebuild and install ndiscvt(8) and
if you encounter a problem to attach please set `hw.ndisusb.halt' to
0 then retry.

I expect no changes of the NDIS code for PCI, PCMCIA devices.

Obtained from:  //depot/projects/ndisusb/...
2008-12-27 08:03:32 +00:00
Weongyo Jeong
8759b840e6 handle .INF files for PCMCIA correctly that specify multiple entries in
their [Manufacturer] sections and prevent a case that NDIS_PCI_DEV_TABLE
definition was always emitted that it's only emitted once if a .INF file
is for PCI.
2008-06-18 06:35:37 +00:00
Andrew Thompson
a0a16e977c If the .inf file did not have a Default entry for the registry key then write
out a blank value and close the brackets on the ndis_regvals array.
2008-04-15 04:44:32 +00:00
Bill Paul
d001b3ba20 Update ndiscvt to handle .INF files that specify multiple entries in
their [Manufacturer] sections.
2005-05-15 19:46:14 +00:00
Bill Paul
ef7012e1fc Re-staticize a few functions I un-staticized for debugging purposes
on amd64 and accidentally forgot to put back. (Have I mentioned that
gdb on amd64 needs work? It does. Boy howdy.)
2005-02-16 18:37:14 +00:00
Bill Paul
d8f2dda739 Add support for Windows/x86-64 binaries to Project Evil.
Ville-Pertti Keinonen (will at exomi dot comohmygodnospampleasekthx)
deserves a big thanks for submitting initial patches to make it
work. I have mangled his contributions appropriately.

The main gotcha with Windows/x86-64 is that Microsoft uses a different
calling convention than everyone else. The standard ABI requires using
6 registers for argument passing, with other arguments on the stack.
Microsoft uses only 4 registers, and requires the caller to leave room
on the stack for the register arguments incase the callee needs to
spill them. Unlike x86, where Microsoft uses a mix of _cdecl, _stdcall
and _fastcall, all routines on Windows/x86-64 uses the same convention.
This unfortunately means that all the functions we export to the
driver require an intermediate translation wrapper. Similarly, we have
to wrap all calls back into the driver binary itself.

The original patches provided macros to wrap every single routine at
compile time, providing a secondary jump table with a customized
wrapper for each exported routine. I decided to use a different approach:
the call wrapper for each function is created from a template at
runtime, and the routine to jump to is patched into the wrapper as
it is created. The subr_pe module has been modified to patch in the
wrapped function instead of the original. (On x86, the wrapping
routine is a no-op.)

There are some minor API differences that had to be accounted for:

- KeAcquireSpinLock() is a real function on amd64, not a macro wrapper
  around KfAcquireSpinLock()
- NdisFreeBuffer() is actually IoFreeMdl(). I had to change the whole
  NDIS_BUFFER API a bit to accomodate this.

Bugs fixed along the way:
- IoAllocateMdl() always returned NULL
- kern_windrv.c:windrv_unload() wasn't releasing private driver object
  extensions correctly (found thanks to memguard)

This has only been tested with the driver for the Broadcom 802.11g
chipset, which was the only Windows/x86-64 driver I could find.
2005-02-16 05:41:18 +00:00
Bill Paul
d329ad6035 Add preliminary support for PCMCIA devices in addition to PCI/cardbus.
if_ndis.c has been split into if_ndis_pci.c and if_ndis_pccard.c.
The ndiscvt(8) utility should be able to parse device info for PCMCIA
devices now. The ndis_alloc_amem() has moved from kern_ndis.c to
if_ndis_pccard.c so that kern_ndis.c no longer depends on pccard.

NOTE: this stuff is not guaranteed to work 100% correctly yet. So
far I have been able to load/init my PCMCIA Cisco Aironet 340 card,
but it crashes in the interrupt handler. The existing support for
PCI/cardbus devices should still work as before.
2004-03-07 02:49:06 +00:00
Bill Paul
307ca1d625 Some Windows .INF files are deliberately sabotaged to prevent them from
loading on a particular version of Windows. For example, a .INF file
for a Windows 2000 driver may have an empty [foo.NT.5.1] section which
will be ingored on Win2K (whose .INF parser won't look for sections
decorated with .NT.5.1) in favor of a [foo] section. Likewise, a
WinXP file will have an empty [foo] section which will be ignored in
favor of [foo.NT.5.1].

The problem is, we can handle both Win2K and WinXP drivers, and we
don't want to exclude either one.

As a workaround, we try to pretend we are WinXP by default and search
for sections decorated with .NT.5.1, but if we don't turn up any records,
we assume that maybe we're being fooled by a sabotaged .INF file and
make one more pass looking for undecorated sections instead.

This allows us to parse the .INF files for both the Win2K and the WinXP
Centrino wireless drivers.

I'd give anything for 5 minutes alone in a room with whoever wrote
Microsoft's .INF file parser. Just 5 minutes. That's all.
2004-01-27 09:05:52 +00:00
Bill Paul
e7e7d5e91e Deal with keys with descriptions that have empty fields in some of
their lines.

Properly discard PCMCIA device declarations. I plan to support
PCMCIA cards, but they don't work yet, and it appears some .INF files
declare both PCI and PCMCIA device instances.
2004-01-23 22:28:22 +00:00
Bill Paul
93335315ad Yet another inf file handling tweak: when checking for Ndi\Params\foo
keys, don't just do a substring match on "Ndi\Params". Instead, check
explicitly for strings that begin with "Ndi\Params". Why? Because it's
possible to create your own keys with different paths, like
"PROSetNdi\NdiExt\Params" which is what Intel does in their PRO/1000
driver's .INF file.
2004-01-13 00:29:17 +00:00
Bill Paul
0a9e1a08a1 Tweak ndiscvt to support yet another flavor of .INF files (look for
the NTx86 section decoration).

subr_ndis.c: correct the behavior of ndis_query_resources(): if the
caller doesn't provide enough space to return the resources, tell it
how much it needs to provide and return an error.

subr_hal.c & subr_ntoskrnl.c: implement/stub a bunch of new routines;

ntoskrnl:

KefAcquireSpinLockAtDpcLevel
KefReleaseSpinLockFromDpcLevel
MmMapLockedPages
InterlockedDecrement
InterlockedIncrement
IoFreeMdl
KeInitializeSpinLock

HAL:

KfReleaseSpinLock
KeGetCurrentIrql
KfAcquireSpinLock

Lastly, correct spelling of "_aullshr" in the ntoskrnl functable.
2004-01-03 02:25:21 +00:00
Bill Paul
ade996adb6 Handle WinNT .inf files with a $windows nt$ signature but no .NT decorated
AddReg sections.

Also insert extra newline after emitting device name overrides.
2004-01-02 21:13:21 +00:00
Bill Paul
f07cc658a4 Clean up ndiscvt a bit (leaving out the -i flag didn't work) and add
copyrights to the inf parser files.

Add a -n flag to ndiscvt to allow the user to override the default
device name of NDIS devices. Instead of "ndis0, ndis1, etc..."
you can have "foo0, foo1, etc..." This allows you to have more than
one kind of NDIS device in the kernel at the same time.

Convert from printf() to device_printf() in if_ndis.c, kern_ndis.c
and subr_ndis.c.

Create UMA zones for ndis_packet and ndis_buffer structs allocated
on transmit. The zones are created and destroyed in the modevent
handler in kern_ndis.c.

printf() and UMA changes submitted by green@freebsd.org
2004-01-02 04:31:06 +00:00
Bill Paul
826fe1a9d3 Remember to use stringcvt() to expand %foo% strings in registry values in
dump_defaultinfo().

Noticed by: green@freebsd.org
2003-12-30 00:30:45 +00:00
Bill Paul
a22ec80ece Deal with the duplicate sysctl leaf problem. A .inf file may contain
definitions for more than one device (usually differentiated by
the PCI subvendor/subdevice ID). Each device also has its own tree
of registry keys. In some cases, each device has the same keys, but
sometimes each device has a unique tree but with overlap. Originally,
I just had ndiscvt(8) dump out all the keys it could find, and we
would try to apply them to every device we could find. Now, each key
has an index number that matches it to a device in the device ID list.
This lets us create just the keys that apply to a particular device.

I also added an extra field to the device list to hold the subvendor
and subdevice ID.

Some devices are generic, i.e. there is no subsystem definition. If
we have a device that doesn't match a specific subsystem value and
we have a generic entry, we use the generic entry.
2003-12-18 03:51:21 +00:00
Bill Paul
153a70182b Support yet another variant of WinXP .INF files. 2003-12-13 08:48:35 +00:00
Bill Paul
c7253f4fea Attempt to handle WinXP .INF files. Also, in dump_regvals(), handle
the case where there's an entry in the manufacturer's device list but
no corresponding installation section (and hence no AddReg assignments),
i.e. if dev = find_assign(sname, "AddReg"); returns NULL, then
don't try to dereference dev.

There is a fundamental problem with the handling of .INF files that
contain definitions for multiple devices: right now we dump all the
AddReg sections that we find, but don't distinguish what device they
belong to. This often results in duplicate keys.
2003-12-12 03:40:05 +00:00
Bill Paul
da1ddac9f4 Fix handling of .INF files with more than one PCI ID defined. 2003-12-11 23:37:56 +00:00
Bill Paul
d934c8b0de Commit the ndiscvt(8) utility too. (Missed it in the last import.) 2003-12-11 22:38:14 +00:00