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

_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to