Re: Hardware TPM is not necessarily needed
> You have to read it in that historical context.
Oooh, oooh, Sir, please, Sir, Sir
> Where do you think the term "firmware" came from?
It was coined to refer to the microcode, when that was placed into a "writable control store" - i.e. NOT (necessarily) any form of read-only memory, in fact quite the opposite: prior to microcode the instruction decoding was all done in literal hardware (ref stories of people digging out soldering irons and modifying the wiring to add new opcodes into their department's computer).
Being a bit simplistic[1], the progress was from arranging the logic gates to make bits in an opcode directly influence the registers/ALU/Fetch&Store units, to using (parts of) the opcode to drive a hard-wired lookup table (e.g. a ROM hand built from a diode array) so that opcodes could be built up from "macros" which triggered multiple actions in sequence, to replacing that array with writable memory which now contained the microcode "firmware". And that memory was volatile (i.e. it was RAM) *not* EPROM, because the latter still did not exist. Not all machines used microcode, of course: if you have a fixed definition for the opcodes, wired into a some form of ROM (on a big board or two or three...) then you can sell a load of identical machines and then sell some software that'll run on all of them. And then we get the stories of departmental machines being attacked with soldering irons to manually add the decoding for the fancy-schamcy new MULTIPLY opcode that the manufacturer had put into their latest box...
So, if you had any, your firmware was a volatile piece of code, loaded into the machine each time it was powered up (or you could decide to load something new between power cycles), literally sitting between your hardware (registers, ALU etc) and your software. Machines with easy-to-change microcode are always around, usually in CPU design research departments these days, but changing the firmware to suit your current end-user workload is not unknown: the Xerox Alto, then Dandelion/Dorado/etc, machines provided different microcode to support different development environments, so you loaded up microcode to run some LISP, then loaded up different microcode and worked in/on Smalltalk.
Microprocessors came along and simultaneously made computers incredibly widely available as well as winding the history of the Electronic Brain backwards: MPUs basically recapitulated CPU design, going back to simple hardwired opcode decoding through to hardwired LUTs and, nowadays, back to loadable microcode. The first complete Microcomputers similarly recapitulated their bigger brothers: early on, you had to toggle *all* the opcodes into the front panel, then you just had to toggle in *just* - only just - enough to kick some reader hardware into life so the Monitor program could be loaded. But, by sheer luck[2], at that point MPUs were able to make use of ROMs to hold the entire Monitor (not an OS yet, just the Monitor), then prices fell, capacity increased and you got all those marvellous 1980s machines, with bucket loads of ROM containing BASIC!
And then there was the floppy disc - if you were rich, you could have one of these and instead of filling the memory map with Basic-in-ROM you filled it with RAM - but you still had a wee bit of ROM containing the Monitor, which was still doing its job of providing *just* enough code to get the external reader working.
> The history is that a BIOS was in a ROM
Ah, no. The BIOS was first stored on the first few tracks of the floppy disc and was loaded in when you gave the correct commands to the Monitor (a bit like toggling in the opcodes but shorter and much easier to remember) . The BIOS then provided a _B_asic _I_nput _O_utput _S_ystem which allowed the various programs that made up "the Disc Operating System" - e.g. CP/M - to have a consistent interface to whatever hardware your box contained. As you changed the hardware you changed the files on the floppy to keep the BIOS up to date.
It wasn't until all the bits came together - cheap-enough xROMs, cheap-enough floppies and, most importantly, mass production of identical units - that the idea of putting the BIOS into ROM was really feasible. Sure, some people had burnt *their* BIOS for *their* kit into xROMs but that was all onesy-twosy and, in general, you expected the BIOS to be on the floppy. And once the BIOS was in ROM, the PC could have User i/o right on power up, which meant that you could have extra functionality; add in some battery-backed non-volatile RAM and instead of editing files on the floppy to allow for changes to the hardware you could do it all on the mainboard. Tada - the BIOS in ROM worked! As time passed, more and more functionality was added into the BIOS settings - and more and more people got used to the idea that the BIOS was something to do with altering how the machine behaved, instead of something that allowed the DOS to have a consistent view of hardware.
As with so many things, once people stopped learning about anything other than the computers they had right in front of them, the word "firmware" was mutated. Very few people were aware of microcode and now the vast majority of individual systems became built on top of microprocessors which did not even support firmware! But the word was floating around and randos grabbed at it and, well, here we are today:
With people very confused about where the term "firmware" came from and trying to shoe-horn in a new reason why it is somehow neither software nor hardware.
[1] no doubt jake or similar could correct, or put some meat on, my quick'n'dirty description
[2] well, not really, the same developments that made the MPU possible also made the PROM, EPROM and EEPROM possible, just a few years later.
