> But then, firmware is weirder than we give it credit for. It's even hard to say exactly what it is. That used to be easy – firmware was software built into hardware (don't mention microcode.)
Maybe this is just my bias as a low-level MCU programmer, but I wonder if this isn't a definition problem more than anything else. To my mind, if your code has problems like this:
> We notice the old devices piling up in a desk drawer, hardware perfectly fine but with ancient firmware that just won't play with modern services.
Then it's not firmware, it's full-fledged software, and ought to be treated as such. Calling a smartphone OS "firmware" is particularly odd to me -- it runs on a general-purposes computer! It takes up gigabytes of storage space! It updates itself over an internet connection that it also manages! -- and I think it gives the wrong idea about the system it's installed on and the nature of the software itself. In particular, anything that needs regular updates is not "firm" in any sense.
It is hard to draw a firm line somewhere between the code in a tiny microcontroller running a battery charger and the operating system running on a general-purpose application processor. Motherboard BIOSes are a bit of a marginal case. But I think there is a useful distinction between "acts like part of the hardware and never needs to be changed" vs. "is the core of the product and when it stops being updated the product quickly becomes useless". Very few people are clamoring to hack on the firmware for their PC's power supply or their car's air conditioner.
The difference between "software" and "firmware" is mostly relative to your view point. It's another level below the stuff you work on yourself.
For example many modem modules these days have fairly powerful ARM SoCs running Linux and they also have another smaller processor running a RTOS or bare metal that does the radio stack. The whole module could be integrated into a larger device itself running Linux too (such as a payment terminal).
The terminal owner will probably consider the entire terminal software as "firmware" (since it's in a device and pretty opaque to them and they likely can't update just some applications like on their PC).
The developpers working on the code in the terminal will probably call what they do software and consider the stuff that goes in the modem module to be "firware" (and probably not differentiated between the Linux based and RTOS based parts of the modem).
The developpers working on the Linux part of the modem will probably consider what they do to be software and the firmware to be the RTOS based stuff that runs on the baseband processor.
I don't know if you're right or wrong, or if there even is such a dichotomy, but I struggle with the same thing with one of our products. It's basically Linux running on an ARM chip, with our stuff on top. We call if "firmware" for what are probably reasons of habit, because all of our other products actually do use what I would call firmware. And when we hire for the team, we specify "embedded programmers". But I dunno, this board (single-core though it might be) would have suited me just fine as a desktop box twenty years ago. It runs a full OS, it runs a web server for the UI, services in the background; it's a reachable server in a teeny-tiny box if you ask me. Writing code for it is much like writing any other Linux app. Is it really "firmware"? Do we really need "embedded programmers"?
I think any firmware that's complicated enough that the manufacturer gets it wrong should be open-source. Especially if the manufacturer is deliberately crippling the product with bad firmware rather than just accidentally through incompetence. And firmware that's too simple to screw over the user is probably too simple to be eligible for copyright protection to begin with.
A motherboard BIOS is not at all a marginal case. BIOS bugs abound, as can be seen by booting Linux on almost any PC and looking through the kernel logs for ACPI table errors and various other workarounds and quirks being activated.
I think you're talking past the parent's point here.
Firmware as I understand it (also as a microcontroller firmware programmer) is about the same as what the parent understands.
I think your metric about "too simple to screw over the user" is sort of weird, when in the context of my work and the parent's work, "screw over the user" might well mean "disabled the oxygen pump on the user's space suit".
It is in that sense that motherboard Bios is a marginal case. It is marginal in the sense that BIOSes are clearly at the margin between embedded microcontroller firmware and full-blown general-purpose-computer operating system. If I have to update the BIOS on my computer every month (or every week) just for it to boot into any operating system, then something is incredibly wrong, even as modern BIOS have become several orders of magnitude more complex today.
Firmware problems don't have to be severe enough to put human lives at risk to be a real problem. There are tons of examples of bad firmware leading to broken power or thermal management leading to crippled performance or battery life or excessive fan noise. WiFi NICs have subsumed large parts of the network driver stack and in doing so have made it impossible to implement effective QoS, leaving users stuck with stupid radio behaviors that hurt the performance of every device operating on the same channel.
None of what I'm proposing would lead to a bios update every month, except in the initial period of fixing the worst of the manufacturer's mistakes. "Firmware" as I'm using it would still be trying to present a stable interface to the rest of the system and not inherently be a moving target of constant feature creep in addition to the bug fixes.
By "marginal", I was thinking more of whether a BIOS is possible to ignore. The vast majority of PC owners never update their BIOS at all. If you buy a motherboard a couple years after its release, there may not be any significant updates from the manufacturer. It's not like the OS where you're downloading updates multiple times a month.
This is separate from the question of whether the BIOS should be open source. I'm inclined to think that it should, especially after the motherboard has been out for a few years.
> The vast majority of PC owners never update their BIOS at all.
I wonder if this is true now that Windows will do it automatically. I have been more than once surprised to see a computer updating its firmware after a Windows reboot.
Pretty much all laptops are getting firmware updates delivered through Windows Update (or a vendor-specific automatic tool), and usually for several components rather than just the motherboard UEFI firmware. And they definitely need those fixes, because the annual cadence of product refreshes means they're shipping from the factory half-baked
The whole "never needs to be changed" thing isn't really useful, though.
I have updated the firmware on my mouse, webcam, docking station, SSD - even a light bulb! We are rapidly reaching a point where the firmware on all but the most trivial devices can be updated, and often has to be in order to fix bugs.
In a past life I was an embedded designer, and I think your observation is spot on. While the libre enthusiast in me would love to be able to inspect and possibly modify bona fide firmware, I do respect that say tweaking the code on a power supply or motor controller is fraught with hazards (you want to use a debugger? while the microcontroller is stopped, your circuit cooks. you want to use printf to a serial port? the additional cycles make your circuit cook ...)
But there are tons of companies abusing the term for software that is actually being continually updated, and/or isn't hardware critical at all (eg Intel ME). The use of "firm" here is entirely prescriptive, for the manufacturer's business desires to lockout end-users, rather than because the code is akin to fixed hardware.
A simple test might actually just be the desire to modify/repair. Nobody wants to really dig into a power supply controller unless it's doing something very broken that needs be fixed. Meanwhile what creates the most e-waste is the ending of software updates, which are most certainly not firmware.
I think we should drop the word firmware. Firmware is just software.
And to be honest, the distinction has never been so much a technical one but more of a ownership one. Firmware is really software that you take for granted and “software” is the software on top that you can maybe configure yourself but that line is so blurry.
Firmware vs software has more meaning when applying for jobs but it kind of comes down to an indication of culture more than technology.
I disagree. The distinction is very valuable when it comes to how you design the system for maintenance.
Firmware is not simply software that you take for granted, its software that is designed and tested prior to release such that updates and maintenance are very rare. Its possible that updating by the user is impossible. Example: I worked on a swarm of environmental sensors that reported via bluetooth. In principle, you could send out a new firmware package over the air, but rewriting their ROM required more current the the coin cell could provide. These devices were meant to be in hard-to-reach places, so updating the firmware on a fleet of them (a few thousand in an average warehouse) was a pretty onerous task, involving recovery, disassembly, and reprogramming using specialized equipment. When we pushed out generation 2 of these devices, we addressed the issue with over-sourcing current, but it was still understood that there was some non-zero possibility that an update could brick the device, necessitating the onerous process to recover. The takeaway: if it really hurts to update, its firmware.
I do get irritated that I have to read quite a ways down a job description before they indicate something like "embedded Linux/Windows/AmigaOS/etc", because when I call myself a firmware developer, I think embedded C on a mirocontroller with at most a simple RTOS.
That is a good point that I didn't touch on in my comment. Although, oddly, a lot more software used to work that way before the internet. Console video games in particular went from "there might be different versions of the cartridge ROM or disc but you won't ever know" to "download the day one patch if you want the game to work and download the next two patches if you want it to work well" practically overnight once they got internet connectivity.
Maybe the real distinction today should be between internet-connected systems and non-internet-connected systems.
> In particular, anything that needs regular updates is not "firm" in any sense.
It's really not about the updates that makes something "firm". Hardware is hard because it's a real physical thing. Software is soft because it's a non-physical thing, a set of instructions. Firmware is firm because it's less physical than hardware, and is more physical than a set of instructions. Firmware is software, in that it's a set of instructions, but additionally it needs to be loaded or flashed or programmed into the hardware, and stored either on-chip or in some ROM or NVRAM nearby, differentiating firmware storage from software storage on disk, tape, or some other peripheral storage. At the time, this made pretty clear sense, but over time, things were made murky by multifacted uses of NVRAM and peripheral storage.
So, "software built into hardware" is a pretty good definition. When you say something isn't firmware, it's software, that seems mistaken. All firmware is software, not all software is firmware. The size doesn't matter. Whether it's an application or a device driver doesn't matter. What defines the "firm" part of firmware is whether it's "built into the hardware". That's it.
So, yeah, you're having a definition problem. If you keep whatever definition that you currently have, then you're gonna have a bad time. If you try to "draw a firm line somewhere between the code in a tiny microcontroller running a battery charger and the operating system running on a general-purpose application processor", with this new definition, the question becomes "where is this code stored?". It doesn't matter how large it is, whether it's 100 lines of code in your battery charger or 1,000,000 LOC for your OS. If it's in on-board storage, it's firmware. If it's in peripheral storage, it's software.
How would you classify the operating system on a Macbook? The entire SSD is just a bunch of flash chips soldered to the motherboard - just like the BIOS flash chip.
Maybe this is just my bias as a low-level MCU programmer, but I wonder if this isn't a definition problem more than anything else. To my mind, if your code has problems like this:
> We notice the old devices piling up in a desk drawer, hardware perfectly fine but with ancient firmware that just won't play with modern services.
Then it's not firmware, it's full-fledged software, and ought to be treated as such. Calling a smartphone OS "firmware" is particularly odd to me -- it runs on a general-purposes computer! It takes up gigabytes of storage space! It updates itself over an internet connection that it also manages! -- and I think it gives the wrong idea about the system it's installed on and the nature of the software itself. In particular, anything that needs regular updates is not "firm" in any sense.
It is hard to draw a firm line somewhere between the code in a tiny microcontroller running a battery charger and the operating system running on a general-purpose application processor. Motherboard BIOSes are a bit of a marginal case. But I think there is a useful distinction between "acts like part of the hardware and never needs to be changed" vs. "is the core of the product and when it stops being updated the product quickly becomes useless". Very few people are clamoring to hack on the firmware for their PC's power supply or their car's air conditioner.