I have read this question/answer, but I still do not understand why some network cards work perfectly well without any additional firmware, whereas others need to load firmware to work.

As a specific example, I have had repaeted problems with Broadcom 10Gb network cards not working, because firware was missing. On the other hand, Intel 10Gb work perfectly well without any additional firmware.

I assume that Intel cards already have the firmware inside the chip, but others need to load it. Is this correct ? Why don't all manufacturers ship the hw with the firmware already on the chip.

NOTE: I am not discussing whether or not firmware is binary/proprietary or free/open source. I am asking why I need to load it, and why its not contained in the device already.


Only the vendors themselves know the real answer but here are some guesses.

I would assume that it's simply because it would make the device more expensive. By requiring the OS to inject firmware at run time they get to avoid the need for non-volatile memory like ROM or Flash on the device.

Secondarily, I would assume the vendors might also feel that the devices get firmware upgrades more consistently this way, because, if the firmware is onboard, almost nobody ever goes to the trouble of the complicated process of reflashing firmware using oddball vendor-supplied utilities.

  • Economic reasons are indeed a likely cause. So-called winmodems and GDI printers are similar examples, simplifying the hardware by moving part of the functions into the driver. – outlyer May 10 '15 at 18:13

When you mention 'contained in the device already' I am assuming you are referring to a method for device driver and firmware to allow a scenario of an operating system to query a device with a predetermined (possibly sanctioned API by the IEEE or other governing body) to then respond with a response of 'here is my device driver memory chip location address' at which time the operating system loads the assembly code at the specified memory address?

Wouldn't that be nice? Perhaps you should also include a method of securing said firmware using cryptographic encryption/decryption, signatures and third party signature validation to ensure that my newly purchased devices firmware hasn't been tampered with by an oppressive regime that is currently in power replacing the original firmware prior to loading the device into my new cars extendable automated driving feature because they hastily wrote some code which has now introduced a bug into the proximity sensors on the left side of the vehicle of with a miscalculation of three feet endangering myself and my family.

After all with physical access to the device the use of jtag and other disassembly code tools haven't allowed for this type of firmware modification in the past.

But in the questions defense the use of loadable firmware from a website and verification of its checksum isn't much of a solution either.

You pose an interesting question that I don't feel qualified to answer. :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.