On Thursday 19 November 2009 12:16:46 Oncaphillis wrote:
> On 11/19/2009 12:09 PM, Michael Buesch wrote:
> > On Thursday 19 November 2009 12:07:30 Oncaphillis wrote:
> >
> >> So I'm at a loss here, but if someone comes up with a bright
> >> idea to test or needs more informations I'm willing to test
> >> the resulting code on my machine.
> >>
> > Erm, no. Can you please answer the questions that you didn't answer, yet?
> > Especially the request for the original vendor driver.
> >
> >
> oh sorry. I did that, but the mail only went to larry -- stupid me -- the
> device didn't come with a CD/DVD and I killed Windows XP right away.
Ok, very nice. -.-
There are two major problems with not having an sprom:
- We don't have the calibration data for the radio amplifiers.
That could possibly be solved by providing a sane default set of data
for a device type.
- We don't have a MAC address for the card. This one is _very_ hard to
solve properly. Several solutions come to mind, which are not
really clean solutions:
1) We generate a random MAC. This would change on every reboot and break udev.
The problem with this is obvious.
2) We generate the MAC by hashing some device-specific PCI config space
values.
I don't know if there are any device specific serial numbers or something
similiar in PCI config space (or somewhere else).
So the problem with this is that I don't know _what_ to hash.
3) We use the firmware loader to get an sprom image and have a userspace
script
take care of the generation of the image.
The problem is the major inconvenience.
--
Greetings, Michael.
_______________________________________________
Bcm43xx-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
