Date: Fri, 10 Sep 2004 12:52:07 -0700 (PDT) From: "Richard Lynch" <ceo@l-i-e.com> To: freebsd-questions@lists.freebsd.org Subject: Re: Broadcom 440x NIC not recognized on boot Message-ID: <1333.67.167.52.21.1094845927.squirrel@www.l-i-e.com> In-Reply-To: <b2807d04040910033546339787@mail.gmail.com> References: <1093.67.167.52.21.1094522790.squirrel@www.l-i-e.com> <b2807d0404090620006d55e892@mail.gmail.com> <1325.67.167.52.21.1094527694.squirrel@www.l-i-e.com> <10027.66.243.145.85.1094788839.squirrel@www.l-i-e.com> <b2807d04040910033546339787@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Subhro wrote:
>> #1. How do I test that bfe (man bfe) is built-in to the kernel versus
>> loaded as a module?
>>
> Check the config file. I believe the GENERIC kernel has it built in.
This is gonna sound stupid, but I spent a good 10 minutes using locate and
find and whatnot trying to find something like "kernel.conf" and failed...
Now that I'm reading up on kernel config, I want to confirm what may be a
misconception...
Sometimes, when one talks about a "config" file, one is talking about
editing /etc/*.conf, and start/stop a service, or, in extreme cases,
re-booting.
Are there run-time options to the kernel in such a file?
Or are all kernel-configuration options done at compile-time?
I can understand that the latter might be necessary, given the way the
boot process works, but I'm not 100% sure I'm not missing an easy text
file to edit rather than a re-compile of a kernel...
And, I'd just as soon not re-compile the kernel if I can determine that
BFE driver is already in it, of course, as that will simply waste my time.
And, knowing me, screw up the machine completely :-)
>> #2. Is it possible that building bfe into the kernel will magically make
>> it "better", or is being loaded as a module ALWAYS the same?
>>
>
> Of course it will always be better to have it built into the kernel
> than to load it as a module. The primary advantage is the speed at
> which the kernel can speak to a module is much less compared to the
> speed at which it can speak to another part of itself.
I expressed myself poorly.
Is it possible that having XYZ compiled in the kernel will get a device
recognized at boot, when having XYZ as a module does *NOT* get that same
device recognized?
I am reasonably certain that BFE is already in there somewhere before I
try to kldload it...
>> #3. Exactly *HOW* does the boot process figure out what gear is what?
>>
> Every device has a special identification code which is unique for a
> device throughout the world. While booting the kernel basically probes
> the available devices "without" knowing what is what. The device
> replies with that code and the kernel comes to know what device it is
> by analysing the code returned.
>
>> #3a. Rather involved question...
>> My current hypothesis.
>> It would seem to be comparing 0x14e4 (?) and "knows" that that is
>> Broadcom.
>> It then sees 0x4324 and does *NOT* recognize that as a BCM440x device.
>> It's possible that Broadcom gave their laptop version of this device a
>> new
>> device ID. (It's a relatively new-to-the-market laptop)
>
> No its not possible. If you use a particular chip you cant reburn the
> device identification in the CHIP. That is possible just once during
> the manufacture and is hardwired.
Perhaps what I should have asked is:
Given that this device has a different device identification, but that
Windows identifies it as a BCM 440x, and that bfe supports the BCM 4401,
and the BFE docs indicate that that driver should work for the BCM 440x
"series", am I reasonable to expect that if I could just add a line of
code somewhere with the new device identification, it has a strong
possibility of working?
I understand that a new device with a similar model number may have such a
different instruction set and API.
I also know that sometimes all devices in a given series use the same
driver, even if they have "different" model numbers (or even different
manufacturers using the same CHIP).
What I'm not completely clear on is:
Does a different device ID pretty much guarantee that the same driver
won't work, or do drivers often work for a bunch of chips with different
IDs that really aren't all that different in API?
>> Therefore, I'd like to edit some source code file somewhere, copying the
>> line about the 4401, and re-compile, install, re-boot, and PRAY.
>> How dangerous would this be?
>> How likely that I am gonna blow up my NIC?
>> How likely that I blow up the whole laptop?
>>
> It is very unlikely you will blow anything up. The max what can happen
> is, the device wont work. In worst case you may trash its firmware.
> But I have *never* seen a firmware blow up that way. But yes that IS
> possible.
>
>> Errr. Exactly where would I start to look for the file I want to
>> change?
>>
>> Here's what I tried:
>> I've found the if_bfe.c file, in /usr/src/sys/dev/bfe/
>> Added some printf statements in the probe function
>> (to print out the t->vid and t->did values as it searched),
>> re-compiled /usr/src/sys/modules/,
>> copied the resulting if_bfe.ko (mtime was 'now') to /boot/kernel
>> copied same to /boot/modules
>> (I think I put that there with make; make install days ago)
>>
>> And, when I booted, I rather expected dmesg to get output from my printf
>> statements...
>>
>> It didn't, so obviously I don't really understand what's going on here.
>> (Well, I knew that, but...)
> It is difficult to say what you ecatly did. Maybe if you paste the
> snippets under consideration I can try to help you out.
That is difficult to do -- With no NIC, and no common readable/writable
hard drive partition (NTFS/UFS2?) between the networked OS and the
non-networked (yet) OS...
I'll burn another CD of what I've changed and post it, after another
series of the re-boots that requires...
Meanwhile, my off-the-cuff recollection:
function ???-probe-???(dev device){
var t dev;
for (t = walk_through_pci_bus()){
+ printf("get_vendor_id(dev) %c\n", get_vendor_id(dev));
+ printf("t->vid %c\n", t->vid);
+ printf("get_device_id(dev) %c\n", get_device_id(dev));
+ printf("t->did %c\n", t->did);
if (t->vid == get_vendor_id(dev) && t->did == get_device_id(dev)){
copy(get_vendor_name(dev),???);
return(0);
}
return(NXIO);
}
}
I wanted to be sure I was back-tracking from the right place and that this
whole pci device identification system worked the way I thought it did.
I apparently failed, since my code didn't printf anything...
>> The Hardware section in the docs directory of my installation referred
>> me
>> to a "Hardware Changes" (?) in my installation... Since that was what I
>> was looking for in the first place, I was rather at a loss to find the
>> document referred to... Any idea what I should have been reading?
>>
> Sorry I was unable to understand your query. Could you please reframe?
I will try to find the exact reference and burn that to CD as well.
I think I was in /usr/share/doc/en-ISO8861-1/hardware.htm, or some path
similar to that.
>> I'm okay with vi and editing source code, but it's been decades since
>> I've
>> really written C code...
>>
> C is the heartbeat of any *nix system :-D
I feel like a plumber doing heart surgery, but I'll give it my best shot. :-)
>> Still, I'd really like to get this card working, and I'll submit a patch
>> if we get it...
>>
> Same with me. I really want to see everything, I repeat "EVERYTHING"
> work under FreeBSD. But unfortunately not everything works the way you
> want it to :-(. But we can always fight it out :-D.
>> Like Music?
>> http://l-i-e.com/artists.htm
>>
> Kinda good collection. Could you have some trance?
Perhaps you would enjoy my friend's work:
http://www.divanation.com
If not, give some of these try:
http://cdbaby.com/found?allsearch=trance
:-)
--
Like Music?
http://l-i-e.com/artists.htm
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1333.67.167.52.21.1094845927.squirrel>