If you are working on the driver in my contrib dir, there are probably newer versions of it somewhere, but don't ask me where you could find them or who might have them, I don't even remember where I got that one from.
As far as I know some of the broadcom work was done together with the amd64 port, so good luck getting hold of that, hahaha. Pace uriel On Sat, Sep 27, 2008 at 5:43 PM, Brian L. Stuart <[EMAIL PROTECTED]> wrote: > Okay, I've been taking a crack at the broadcom driver > that's been lying around. It's pretty old and used > the upamalloc call. But upamalloc is now gone and > I don't seem to be able to find the right way to > replace it. After looking at other drivers and at > the old upamalloc code on sourcesdump, I've tried > several way to replace it, but most end up in a panic. > The original code (edited to the relevant lines) > looked like: > > port = upamalloc(bar & ~0x0F, p->mem[0].size, 0); > ctlr->port = port; > ctlr->nic = KADDR(ctlr->port); > > My most recent attempt replaced the upamalloc call > with: > > upareserve(bar & ~0x0F, p->mem[0].size); > pdbmap(MACH(0)->pdb, bar & ~0x0F, 0, p->mem[0].size); > port = bar & ~0x0F; > > There is currently a upaalloc call, and the comment > to it seems to imply that vmap should be used either > in conjunction with upaalloc or by it self. I've > tried a few permutations of that with no luck. > > If someone knows off the top of their head the right > way to replace an old upamalloc call, it would save > me some time, and I could get on to seeing if I can > manage to get the controller to work. > > Thanks in advance, > BLS > >
