Software or Firmware

EEPhil

Number 28
* Humax call it "software", an engineer (ie me) would prefer to call it firmware.
Just an observation. But another engineer (ie me) couldn't care whether it is called software or firmware. Joe Public has probably heard of software and may be confused by the term firmware.
 
Just an observation. But another engineer (ie me) couldn't care whether it is called software or firmware. Joe Public has probably heard of software and may be confused by the term firmware.
It's like when you buy a mattress, isn't it? Is there mediumware too? Supersoftware?
 
Once upon a time there was just hardware. When hardware was eventually used to make a programmable computer, the term software was coined because the programming vanishes when the power is turned off. Firmware is the middle ground - alterable, but in persistent memory that does not require reloading each power-up.

From an engineering point of view, the distinction is important because firmware tends to be used to define low-level functionality of a hardware-firmware combination that is intrinsic to the design of the unit, and should not be open to user modification (only re-issued as a result of design modification). It used to be the preserve of the hardware engineering team rather than the software department.

Matters are far more confused these days. Persistent memory is cheap and can be made available in sufficient quantity to hold the entire programming stack in ready-to-run form, so where exactly is the division between firmware and software? If we keep to the definition that firmware doesn't have to be relocated to run, the entire functional programming of a set-top box is firmware. On the other hand, some of the actual hardware contains RAM areas to define its functionality at the lowest level (Field Programmable Logic Arrays and the like, which are reconfigurable logic devices) and has to be 'booted' each power-up by loading the RAM area from external persistent memory - so that is definitely "firmware-ish" but doesn't pass the non-relocation test.

Nonetheless, I do think the distinction between firmware and software is important for communication. It's all very well saying Joe Public doesn't understand and doesn't care, but if they are not exposed to the difference they are not given the chance to understand. When it comes to technical discussion, we need it to distinguish between code that can be changed and code that can't (or shouldn't be) - which is probably the most convenient distinction.
 
When it comes to technical discussion, we need it to distinguish between code that can be changed and code that can't (or shouldn't be) - which is probably the most convenient distinction.
If you can't or shouldn't change it - how can you have customised firmware? :D
 
By changing it. I noticed that possible flaw in BH's argument as well. But he did say "shouldn't" but someone did (thank goodness).
 
I view software as being something the user might install and/or mess around with.
Firmware effectively has a "No user serviceable parts inside" sticker on the outside. Ie: enter at your peril :cautious:
 
I view firmware as software provided by the firm that made the device. This, unfortunately, is a flawed argument, as it then forces me to call Windows firmware - when bloatware may be more accurate.
Perhaps a better version would be firmware = software provided by the firm and located in a (erasable?, programmable?) read-only memory device.
Certainly agree with:
Firmware effectively has a "No user serviceable parts inside" sticker on the outside. ie: enter at your peril
 
I view firmware as software provided by the firm that made the device. This, unfortunately, is a flawed argument, as it then forces me to call Windows firmware
Only if it's on a Microsoft device. On anything else it's software.
 
If you can't or shouldn't change it - how can you have customised firmware? :D
By changing it. I noticed that possible flaw in BH's argument as well. But he did say "shouldn't" but someone did (thank goodness).
I view software as being something the user might install and/or mess around with.
Firmware effectively has a "No user serviceable parts inside" sticker on the outside. Ie: enter at your peril :cautious:
The "software" Humax implanted in the HDR-FOX is not designed to be user-alterable except by a specific method of applying Humax-originated updates. This was hijacked by reverse-engineering the update process in order to apply customisation, by means not within the capability of a normal user - ie "hacked" - and at risk of rendering the unit non-functional if incorrectly designed. Installing the custom firmware then opens the way for us less skilled ("normal") users to run software according to our own choice (the WebIF and packages).

So EEPhil is in the minority then. We seem to be agreed that there is a distinction between firmware and software (even if the exact boundary is slightly blurred), and the difference is relevant to ordinary users (providing they are educated to understand it), therefore Humax should have been referring to "firmware" not "software" in their documentation. Talking about "software" when a source should use "firmware" doesn't help educate the public.
 
So EEPhil is in the minority then.
Not for the first time. Doesn't make the minority view wrong.:p
We seem to be agreed that there is a distinction between firmware and software (even if the exact boundary is slightly blurred), and the difference is relevant to ordinary users, therefore Humax should have been referring to "firmware" not "software" in their documentation.
Software is an all encompassing term - which includes firmware. So to use the term software, when you think it should be firmware, maybe lazy and not to your exacting standards, but isn't wrong.
 
Is it? We'll agree to differ on that.
I certainly appear to have got it wrong regarding the origin of the term firmware. It's got nothing to do with the firm!
One definition I've seen places firmware in the area between software and hardware. Probably known in my undergraduate days as microcode. Definition might have been expanded to include embedded software. Whether a microcode program is software. :dunno:
 
Is not the BIOS in most computers 'firmware'?
By my understanding, yes. The overall package could not function in any way without it, it has to be in place at power-up, and it is not user-alterable.

Having thought about it today, I think I can convince even the most sceptical of firmware as a separate entity (even if the exact boundary between firmware and software remains debatable):

Most electronics hardware today is designed using software tools - CAD, simulation, description languages which compile to produce logic definitions. I think anyone can accept that, once implemented, the hardware contains no software, even if it was designed using software.

Suppose the most efficient or effective way to design and implement the required functionality of the hardware is for it to execute instruction codes embedded in memory - apart from anything else, this is an effective strategy for de-risking design changes or corrections later in the design cycle than the hardware design freeze pre-manufacture. The hardware is still hardware, but memory accesses and the consequences thereof are an integral part of its design. The only distinction is that code is being executed from some kind of modifiable store - even if "modification" requires removal and replacement of a write-once ROM chip.

Now suppose the function of the ROM chip is replaced by a custom chip, designed (using software tools) to have the identical electrical and functional characteristics as the ROM chip - except instead of being implemented by programming the fuses of a ROM it is implemented purely as logic gates. Although designed using software, there is now nothing in the hardware which corresponds with a programmed element, but the hardware still operates identically. The programming is an intrinsic part of the hardware design, and that's firmware.

One definition I've seen places firmware in the area between software and hardware.
That is one way of looking at it. Firmware is generally needed in order for hardware to run software. The firmware designers generally need an intimate knowledge of the hardware, less so the software designers operating at a greater level of abstraction. For that reason, firmware design is generally within the hardware design department.

Probably known in my undergraduate days as microcode.
Microcode is a specific type of firmware. In the days before single-chip processors, a processor was constructed from simple logic elements, and the easiest way to do that was to build a very simple processor with just enough functionality that it could be programmed to emulate a more sophisticated processor - by running many simple instructions very quickly (which in those days was still very slow). In particular, the instruction word was very wide so that it had fields to directly control the source and destination of data, the arithmetic process to be done on it, any conditional test on the result, and the jump address to be executed if the condition is met. So, for example, in 48 bits might be encoded "fetch data from registers 16 and 31, subtract them, store the result in register 8, transfer execution to address 319 if the result was zero (continue if not)". Some might recognise this strategy as developing into RISC.

The point is that this microcode is used to implement the more familiar (and compact) instructions of macrocode (machine code), so that (say) a subroutine call is only one macro instruction, but may require many micro instructions to decode it and perform all the functions required by it (fetch the target address of the subroutine call from the next program memory locations by incrementing the macro program counter that indexes them, copy the macro program counter register to memory indexed by the stack pointer register, increment the stack pointer register, load the macro program counter register with the new value). The code implementing the functions to perform a "call" instruction is microcode, which ran at a few MHz and therefore the macro code ran at maybe 1 instruction per microsecond if you were lucky. I cut my professional design teeth on this stuff.

To speed things up, more sophisticated processor design implemented more of the functionality directly in hardware (made possible by increased integration shrinking everything), but then more sophistication was implemented in microcode... and then speeded up by integrating more of it directly in hardware... etc. I have no idea how much of an Intel Xeon processor (or whatever) is implemented in hardware or as microcode - it's irrelevant to the user, all that matters is what happens at the pins of the chip (or, in my early design career, at the contacts of the circuit board connector). If an instruction takes more than one clock cycle to execute though, you can be pretty sure there is some microcode coordinating it.

So what's the difference between microcode and firmware? Microcode is firmware, but so is the programming of programmable logic such as PLAs, FPGAs etc - devices which do not run code to implement a program but use embedded memory to directly control the flow of logic levels between logic gates and registers; programmable analogue arrays which implement a variety of amplifier, filter, etc functions on an analogue signal using standard hardware; any code embedded into single chip controllers such as run your washing machine or the electronic dashboard instrument panel in your car; etc etc. These are not microcode, but they are firmware (embedded within the device to define its functionality, set by design, and not normally alterable by the end-user). Thus "firmware" has a wider definition than "microcode".

As mentioned above, firmware is typically closely tied to the hardware and is the preserve of the hardware design engineers (although the softies may well also have input), but it has an important distinction from hardware or software even from the end-user point of view: hardware can't be changed without getting out a soldering iron to make circuit modifications; firmware has the possibility of being altered post-manufacture by a formal update process to implement design corrections or changes; software is free to remove, change, modify, or add to at will. Humax's "software" update process (which started this discussion) supplies an image file for the user to apply by a specific procedure, as a complete unit, on a take-it-or-leave-it basis (or automatically with no choice at all), and it's essential to the operation of the equipment rather than loaded post-power-up. It's firmware, and erroneously calling it "software" does nothing to promote public understanding.

Hard: not alterable except by hammer and chisel [fig.];
Soft: easily reshaped;
Firm: malleable, but with resistance.
 
Last edited:
I use the distinction that software has to be loaded from peripheral storage before it can be run. Firmware is permanently held in the memory location from where it is run even though there will often be a copy of it held on peripheral storage from where it can be reloaded and from where a new version my be installed. Boot-loaders are by definition firmware as they contain the code needed to load the rest of the code for the device to start doing its job. As Humax PVRs continue to function with the disk removed then it is evident the functional code is held in permanent memory which persists even if you turn off the power. Therefore it is firmware.
 
There are (as usual) boundary cases to explore (like a platypus - classified as a mammal but lays eggs). For example: some programmable gate arrays are purely hardware in operation, but use programmable switches to steer logic signals around the chip to different functional units, and thereby have functionality that is not present at manufacture but is created from a blank canvas by the application of a definition file to set up the switches. So far, so good - clearly firmware.

The problem is that some such devices do not contain persistent memory to retain the switch configuration, and have to be booted from external memory before they acquire the intended functionality. What's more, the functionality can be redefined on the fly so that one moment the chip is (say) a hardware accelerator for cryptographic algorithms, and the next moment it can be (say) a shader in a graphics pipeline. It would not surprise me if there is similar technology in our FOXes.

If the code used to configure these devices is not stored in a dedicated area of persistent memory, but instead comes from a file on disk, is this firmware or software? A case like this strains any simple definition of what constitutes software or firmware. Personally I would still like to classify it as firmware, because it is still tightly bound to the operation of the hardware and isn't a set of instructions to be executed (it defines the hardware rather than being run by the hardware), but microcode would be the opposite (run by the hardware rather than defining it). It is also not such a great leap of the imagination to envisage the switch configuration being used to create a processor and the pre-programmed memory array containing a set of instructions - what then: firmware of software? Still firmware in my book, but any precise definition of the boundary between firmware and software would need to distinguish cases such as this.

However, for Joe Public, it still needs simplicity: firmware is something built in by the manufacturer that defines the unit's fundamental operation, and is fixed until the manufacturer issues an update for it.
 
Nobody mentioned wetware.
You mean the soft bit of squidgy stuff in front of the keyboard?

Firmware is now as much at risk as any other software.
As we know, having cracked the Humax firmware update process for HD-FOX, HDR-FOX, and FOXSAT-HDR. All that's needed to defeat malicious attacks from foreign agencies is a hardware jumper to enable or disable writes to firmware - then the attacker would need physical access to the hardware.
 
Back
Top