Hacker News Reader

Comment by ericboehs | Hacker News Reader

Can you brick your cable if you unplug it during the upgrade?

Any reasonable manufacturer will rotate firmware images and have the bootloader fall back to the most recent validated image. Though I imagine this could happen if this practice becomes common enough that you get it on some 5$ gas station charging cable kinda thing.

A reasonable manufacturer looks at its bottom line and doesn't waste his engineering hours and BOM costs (double the flash memory!) on silly features like that. Either that or there are many unreasonable manufacturers out there.

"Double the flash memory" !!

- How much do you think the NOR flash costs inside this cable?

- How big do you think the firmware actually is?

- 16MB Winbond NOR flash is like $0.70 with no price breaks (for me, I am not Apple making 1 million units) - there's no way they need 1MB for two slots, much less 16MB.

- These cables retail for $49.

Two firmware boot slots is standard practice because it is essentially free to provide in any higher-end consumer electronic device: especially one that is explicitly designed to be unplugged easily.

How many support claims are saved on this $49 cable because mid-update bricking does not occur?

Cost (reputational as well as CSR hours and the actual replacement units) of a bunch of warranty claims for bricked units is a factor too.

In practice pretty much every embedded device I've worked on that has supported in-field firmware updates has had either double buffering and/or a recovery mode to limit the possibility of bricking.

For the products where every last penny really needs to get squeezed out of the BOM (toys, low-end appliances, ...) the ability to do in-field firmware upgrades itself is IME often one of the first things to go.

A reasonable manufacturer who is releasing something that updates automatically with no warning to the user nor any indication an update is happening to alert the user that they should not disturb it to avoid bricking looks at the potential cost of a class action suit from people whose devices get accidentally bricked, the potential cost of regulators order the devices recalled as defective, and the potential damage to the reputation. This will almost certainly be more than what they'd save by not providing some way to automatically recover from an interrupted update.

BTW, they don't have to double the flash memory. They just have to provide enough extra memory for a fallback updater that the boot code can load if the main firmware is corrupt. All the fallback updater has to handle is telling the computer it needs firmware and then installing the firmware the computer provides.

That's what I was about to ask. It says that the cable should update itself transparently, but there can always be a chance of corruption. Maybe the cable keeps the old FW and only boots the new one if it is signed.

Presumably there is space for two copies of the firmware, and once the new one decompresses and checksums correctly you update the firmware-start pointer.

Sounds like the firmware is actually stored in RAM and loaded when you plug in the cable.

Really that shouldn't be called firmware (the actual firmware would be the fixed code that receives second-stage code from the host), but "software" doesn't fit that either. Maybe "controllerware" or something like that.

This is how CPU/GPU microcode is loaded too, though… Is that not firmware?

What I always understood firmware to be is: a ROM that gives a CPU something to do when power is applied, as RAM is blank on power on and things like storage devices can't just put stuff in RAM without being directed by the CPU (which doesn't have code to do that at power on unless provided by a ROM).

Depending on the scope of the device (from multipurpose PC down to single-purpose things like microwaves, gas pumps, hard drives, LCD controllers) the firmware may just allow an operating system to be loaded or actually be all the code the appliance needs for its CPU.

If the CPU is embedded in a peripheral, then:

- it has to have some small ROM that does nothing but wait for an image to come in from a bus (USB, etc.) and then execute. The sound chip in Nintendo's Super NES is an example, on power on/reset it has a 64 byte boot ROM that does nothing but wait for data to come in from the main 65816 CPU and then runs that code when received.

- the host has to have some way of externally programming the peripheral's RAM directly and resetting the peripheral's CPU but not the peripheral's RAM. I suppose JTAG could be used for this.

My opinion: CPU microcode isn't firmware - CPU microcode sets the configuration of internal connections/parameters in the CPU. It's kind of like a settings file. But: I think recent microcodes do actually include code (see Xucode) but that code is meant to be the behavior of advanced instructions and not designed to be something that tells the CPU what to do from the moment it's powered on.

There are plenty of things that have firmware, but run it out of RAM. FPGAs do this, and some microcontrollers. Dialog, now Renasas, has microcontrollers that run their firmware out of RAM.

Commonly there is a hardware peripheral that pulls the firmware from a couple of places (could be an onboard ROM, could be jtag, or other) and loads it in to RAM.

Driver?

Reply on news.ycombinator.com