Re: problems with NDIS driver and convertion for a Marvel Yukon Gigabit chip

> > On Fri, 11 Nov 2005 05:42:07 +0000 (GMT)
> > wpaul_at_FreeBSD.ORG (Bill Paul) wrote:
> > 
> > > > Ran into a few problems with ndisgen today.
> > > > 
> > > > I have to edit every instance of the following out to get it to
> > > > convert.
> > > > Magic Packet = "Magic Packet"
> > > > Pattern Match = "Pattern Match"
> > > > Mag Pack Patt Match = "Magic Packet & Pattern Match"
> > > > Link Change = "Link Change"
> > > > 
> > > > 
> > > > Upon loading the driver I get...
> > > > no match for ExUnregisterCallback
> > > > no match for ZwPowerInformation
> > > > no match for ExRegisterCallback
> > > > no match for ExCreateCallback
> > > > no match for ZwUnmapViewOfSection
> > > > no match for ZwMapViewOfSection
> > > > no match for ZwOpenSection
> > > > no match for wcslen
> > > > 
> > > > Any chance of getting this working or any suggestions?
> > > > 
> > > 
> > > Ok, had I read the subject line of your mail fully I'd have known
> > > what driver it was. I'm a dolt and I've clearly had too long of a
> > > day.
> > > 
> > > Here are the problems:
> > > 
> > > - I don't know exactly what driver image you have. Unless you
> > >   provide the URL for where you got it to put a copy somewhere,
> > >   I can't really analyze it.
> > 
> > http://marvell.com/drivers/driverDisplay.do?dId=118&pId=6
> > 
> > IIRC the installer dumps it Program Files/Marvell  It is where I
> > grabbed the .sys and .
> 
> I can probably unscramble it with Wine. I've had pretty good luck
> with it with other driver distribution.
>  
> > > - The .inf parser is not perfect. It's actually much stricter
> > >   about syntax than Windows is. Stuff that works ok for Windows
> > >   may be flagged as a syntax error by ndiscvt. If someone wants
> > >   to help fix this, they're welcome to. (No kernel hacking
> > >   required.)
> > 
> > Cool, any suggested reads?
> 
> The Microsoft MSDN site is the canonical source for documentation,
> such as it is. I would start with something like:
> 
> http://www.microsoft.com/whdc/archive/W2inf.mspx
> 
> The .INF syntax is very subtle: it's evolved a lot over time and
> you can use it to produce many strange effects. For example, it's
> possible to create a .INF file that can figure out if you're on
> a Win98, Win2K or WinXP system and install a different driver for
> each one. Another major source of complication is registry key
> specifications. NDIS drivers tend to specify only a few keys that
> need to be created at install time, but it's possible to create
> large numbers of them for various purposes. I've seen a Conexant
> modem driver that uses its .INF file to store a bunch of special
> keys containing some kind of binary patch tables that are used by
> the driver at runtime. There's also different patch tables for
> different chipsets.
> 
> > > - I have no earthy idea why Marvell is referencing these functions
> > >   in their driver. They're totally outside the NDIS spec. I'd be
> > >   rather surprised that such a driver was able to get WHQL
> > >   certification. (Assuming it did.)
> 
> Some investigation shows that they're probably using ExRegisterCallback()
> and its ilk to obtain notification about power state events. And I
> think they're using ZwMapViewOfSection() to basically do 'vtophys(),'
> i.e. map a physical address to a virtual one, probably so they can
> access some card resident RAM that's mapped into the host. (Actually,
> ZwMapViewOfSection() lets you read from the \Devices\PhysicalMemory
> device, so really it's the equivalent of grovelling around in /dev/mem.)
> 
> I'm unsure why they're doing this. I was under the impression you
> were supposed to have a MiniportPnpEvent() method to handle power
> event notifications. As for the physical/virtual address translation
> thing, they could have used NdisMMapIoSpace() or maybe even
> MmMapIoSpace() instead. Who knows.
> 
> > > - This is Marvell. Given the rotten treatment I've had from them
> > >   in the past, I'm not inclined to do them any favors now, so I'm
> > >   not exactly inclined to fix this anytime soon.
> > 
> > Fun, what happened, if I may ask?
> 
> Back when the patches to support the Yukon with sk(4) were first
> merged in, and people were having problems with multicast, I asked
> one of my SysKonnect contacts (who had now been assimilated by Marvell)
> for the Yukon manuals so I could fix it. They told me that I would
> need to sign both an NDA, and a software license agreement. I thought
> this was strange since I wasn't licensing them my software and they
> weren't licensing me theirs, but I told them I wanted official
> recognition of the fact that this was an open source project and
> that's what they came up with. I said "ok, send me both documents so
> I can read them." They sent me the NDA, but not the software license
> agreement. I wanted both before I would sign anything, and kept
> prodding my contact to send the license agreement, but he kept begging
> off and promising to talk with the right people.
> 
> Finally after about a month of this, I finally got an e-mail from
> someone else telling me that they had decided they were going to produce
> their own binary driver (actually, they had been working on it all
> along) and because of that they saw no need to give me the manuals
> now. But they did offer me some free sample cards.
> 
> I told them I was terminating any further involvement with SysKonnect
> and Marvell and they could keep their cards.
> 
> I still have the e-mails from them archived somewhere.
> 
> Some time later (I'm not sure how long, maybe a month or two), I was
> contacted via e-mail by a SysKonnect/Marvell engineer in Germany who
> wanted to know if we could make the sk(4) driver optional so that their
> customers could use their binary only driver without having to recompile
> the kernel. I told him flatly that I wasn't on speaking terms with his
> company anymore and that he was out of luck.
> 
> I was startled to receive a phone call from him shortly after. He was
> rather taken aback and curious to know why I had become so unhappy
> with his company, so I explain to him how his Marvell overlords had
> stonewalled me earlier. He was very surprised and disappointed. He
> seemed like a nice fellow and I told him while I had nothing against
> him personally, but I was not about to make Marvell's life easier when
> they had made mine so miserable.
> 
> During our conversation, I found out that he had been tasked with
> developing the Yukon driver for FreeBSD. Then it was my turn to be
> taken aback, when he admitted to me that he hadn't actually read
> the Yukon manual: instead, he had been provided with an API library
> for communicating with the card and was essentially producing a
> wrapper for that library to interface it with FreeBSD. Now, this
> technique is not new: Broadcom and other vendors have been using it
> for a long time. But even so, I would like to think that library or
> no, the engineers writing the drivers are actually familiar with the
> hardware.
> 
> So you can understand why I'm not in any hurry to do anything nice
> for them.

some months ago, using some local contacts, i managed to get from them the
driver for the newer Yukon, after a long delay of QA. I tried it and it bombed.

So after some exchanges, it seems that QA did not check it under SMP, even
if the testing host was a dual cpu.
They promised to have a newer in a few weeks, it's been now more than a few
months.

	danny