Hacker News Reader

Comment by jimmyswimmy | Hacker News Reader

As an EE I love the idea of open firmware. I wish more companies would provide it - akin to the old TVs and other equipment that came with [full!] schematics inside. It would let me truly understand and modify the items that I purchased.

There is definitely a cost to it to the companies, which I fully expect to be passed down to me, but not in the form of a license agreement - in the form of an increase in base price.

The problem for companies is multifold. A big one is that the firmware is the piece that not only interacts with but also protects the hardware. If you are easily able to change the firmware, you are easily able to destroy the hardware, and if that's under warranty, companies are going to be concerned. They're also going to worry about IP; certainly I build products that lean on the work from previous projects. I would kind of hate handing that over to potential competitors. But some of that 'hate' depends on the fact that my competitors don't give their firmware code out either. Maybe I would love it if I could see how they implement things. Maybe it would push us all to deliver better things. Another impact - open firmware would definitely change sales models for equipment.

I imagine that if I had to start delivering open firmware for designs, I'd need to push some of the software control over product limitations into hardware. That might cost more, but is better anyway. Usually. And I'd try hard to figure out a way to install a 'unverified firmware' hardware flag, maybe an efuse blown in a hard-to-replace component, so that we could know who broke things.

But I do like the idea. I want the firmware for my ${everything}.

View on HN

What cost?

Competition? That isn't definite.

Support overhead? I don't buy it.

> If you are easily able to change the firmware, you are easily able to destroy the hardware, and if that's under warranty, companies are going to be concerned.

...so void the warrantee when flashing 3rd-party firmware.

How often, in reality, are people going to fry their hardware? It's not as if 99.99999% of 3rd-party firmware users are writing that firmware themselves! Hardware damage should be expected as an extreme edge case, not a broad looming risk.

---

If we are going to put this much effort into speculating cost, we should put equal effort into speculating value.

Open firmware is significantly likely to reduce the costs of compatibility and edge-case support. It is also likely to increase the value of the product by making it auditable and maintainable. It also factors out the cost of anti-user-maintenance efforts like DRM.

Most importantly, open firmware can stabilize the value of a product, increasing its resale price and delaying price decline. Unfortunately, this is the point that many companies consider negative, because they don't want to compete with themselves.

What do you mean that isn't definite? I'm very in favor of open firmware, but there have been multiple examples of clones popping up whenever firmware is public and open source.

Can hardware be protected (and defended in court) if copycats just copy a device wholesale?

If they construct a new device but reuse the firmware, it's sort is the point of having open firmware.

Open-source firmware wouldn't exactly be the same thing as public domain firmware. And even if a product's firmware isn't getting the benefit of copyright protection, the product as a whole can still be protected by patents and trademarks.

Exactly firmware shouldn't protect the hardware that should be done in hardware as firmware can go wrong.

> Most importantly, open firmware can stabilize the value of a product, increasing its resale price and delaying price decline. Unfortunately, this is the point that many companies consider negative, because they don't want to compete with themselves.

Can you share some examples of this?

Linksys got GPL'd when they released the WRT54G which spawned off OpenWRT, ddwrt, and friends. This blunder on their part sparked a boon of open source firmware development, which ultimately made the WRT54G very popular. Compatibility with open source firmware is a hard requirement for any new router purchases that I make

The GPL code release also only happened because of GPL enforcement, some of the history is written about here:

https://sfconservancy.org/copyleft-compliance/enforcement-st...

Several years back, I put Tomato firmware on an old WRT54G when all my old 802.11N devices were constantly crashing.

It was 100% worth the bandwidth downgrade. I practically never had to touch that router again.

I hope to never buy a router without DD-WRT (or equivalent free software) support again.

> A big one is that the firmware is the piece that not only interacts with but also protects the hardware. If you are easily able to change the firmware, you are easily able to destroy the hardware, and if that's under warranty, companies are going to be concerned.

Is that justifiable, though? I bricked a router some time ago messing around with ddwrt. I thought about soldering on a TTL serial adapter, to recover it, but didn't end up getting around to it, but never in my wildest dreams did I think of asking Netgear to replace the 8-year-old product I broke through my actions. I do know at least one person who is reckless with "no questions asked" warranties, and would ask for a refund with a straight face after trying to use a router to reduce spaghetti sauce spattering when he microwaved his dinner, but these people can't be that common...

One area where it does seem slightly more justifiable is FCC-certified radio devices. If the transmitter power level is restricted by law, I'd prefer that end users/modifiers of the firmware be considered legally responsible for the consequences of their own actions, but I understand that pragmatically it's a lot easier to ask OEMs to lock down firmware after getting certified in a test lab than to monitor a million end users.

>I do know at least one person who is reckless with "no questions asked" warranties, and would ask for a refund with a straight face after trying to use a router to reduce spaghetti sauce spattering when he microwaved his dinner, but these people can't be that common...

There's common, and then there's common-enough-to-be-costly. REI had a notorious lifetime-return policy that they ended relatively recently because of abuse. How common was the abuse? No idea. I don't know many people who would Return Every Item (as the joke went), but it was common enough that there was always some really beat-up climbing shoes at their member garage sales.

And anyway, there's (at least) 2 kinds of costly: cost of returns, and cost to reputation when unqualified people brick their device, then tell all their friends that their router/refrigerator/laptop stopped working.

> I don't know many people who would Return Every Item (as the joke went), but it was common enough that there was always some really beat-up climbing shoes at their member garage sales.

I think you chose an idiosyncratic case here. There must be a significant number of their customers who go there to get fully outfitted for a single, relatively short trip.

If you depend only on shame to keep most people below the age of, say, 30 from returning a rent check's worth of camping gear after a single use, well... as you stated REI no longer allows that. (IIRC that happened shortly after the 2008 downturn).

It happened at least after 2013, because I went skiing with a guy who made it a point to return everything he'd ever bought from REI because of a court case he read about. It was a sort of super-boycott.

I chose an extreme case, because the cost is clear, and the consequences are very visible. Obviously, a company's peculiar financial situation will determine the acceptable return-and-refund/replace rate. Every company will have a financially acceptable return rate, and will look for easy fixes to keep their actual rate below that. Barring replace/refund for user modifications is a way to lower the refund/replace rate, without actually decreasing the number of items that get returned. There's still a cost to inspecting devices for user modifications, and that cost may in turn lower the acceptable refund/replace rate, but it does mean the product development people have to spend fewer resources eliminating potential sources of failure

None of this is to say that I think firmware shouldn't be field editable. Just that barring those sorts of things is low-hanging fruit and (in general) pretty easy to sniff out if the device is just bricked, not permanently damaged. I think manufactures could instead enable firmware updating after cutting a particular trace, to the same effect. Thus, the would-be hacker must knowingly physically damage the product in a way that clearly voids the warranty, and then they're free to modify to their heart's content.

I was messing around with an I2C controlled lithium battery charger on a raspi last night (long irrelevant story) and found out it does NOT support "fast charge" (probably not enough thermal monitoring?) but it does support larger capacity batteries that coincidentally permit higher currents. So the short version is I can charge a battery twice as fast by lying to the charge controller that it's twice as large. On average, probably 99% of people can get away with that, the problem is 1% set the battery on fire or otherwise burn out the battery.

No matter how smart you make the controller you can't outsmart the user; to the battery charge controller, a 1 aH battery being treated as a 2 aH battery behaves like a 2 aH battery that's at 50% capacity due to age or whatever issues.

I would imagine, as long as I can keep it cool, I could install a 50 mAH micro battery and tell the charge controller its a 2 aH battery and it would charge very fast indeed. Perhaps only once, but it would be very fast. I suppose the worst case scenario is some kind of virus/cyberattack reprograms the FW to believe the battery is either 65536 mAH or 1 mAH, either way the battery would appear "dead" to end users.

Another common problem is marketing and mgmt may be a LITTLE over optimistic about a feature; imagine if your IoT cigar humidor (made up idea; probably does exist LOL) has a hardware barometric sensor on the I2C. I2C is famous for dodgy hardware being able to 'jam' the bus. Ah no problem nobody needs a baro on a humidor anyway, we'll just delete it from the marketing materials and remove it from the firmware, no need to e-cycle otherwise good first batch of boards. Well if someone uploads custom firmware and the baro is polled every hour and it randomly jams the I2C once every hundred polls, "must be a thermal issue the CPU crashes" nobody might ever understand the problem. I mean, its gotta be a hardware bug worthy of a return, everyone knows if the code compiles and passes unit tests and works for a couple minutes, it must be good, right? But if the I2C protocol is interrupted due to a wifi interrupt in the middle of whatever it crashes the whole bus so randomly every couple weeks it locks up.

Some big expenses are not brick fails but "it burst into flames while on an aircraft" or "everyone knows the hardware locks up randomly every couple weeks" causing all kinds of crazy bad PR.

Then there's interference with marketing models. Well, technically the hardware for rev1 and rev2 are the same, its just rev2 has more features because we eradicated bugs, so please pay us again, don't just download new FW.

Nit: it's Ah (A•h) and not aH, because Ampere (the A) is from Henri Ampere, and the h is just the inanimate hour.

A proper SI interpretation of aH would be atto-Henry, where Henry is the unit of inductance (from James Henry), and atto is 1e-18.

> If you are easily able to change the firmware, you are easily able to destroy the hardware, and if that's under warranty, companies are going to be concerned.

I don't think this reasoning makes any sense. The company can just declare that replacing or altering the firmware voids the warranty.

> I would kind of hate handing that over to potential competitors.

But you do that the instant that your product ships. I've shipped a lot of firmware in products, and it's very common to find my firmware reverse engineered and available within a month or so of the product being released.

> I don't think this reasoning makes any sense. The company can just declare that replacing or altering the firmware voids the warranty.

It's still a cost, though. People are still going to file tickets for warranty replacements, it won't be until the company receives the broken item that they'll detect the firmware replacement (if they even can, what if the hardware damage broke the ability to check?), people return items to the store they bought them from where they can't even check...

It's honestly a whole mess that will absolutely wind up costing the company money in support and returns. You can argue that it's still worth the cost, but just declaring that altering the firmware voids the warranty doesn't stop people from trying, which costs money.

Yes, it is a cost. I would argue that it's a reasonable cost of doing business, personally, but it is a cost.

>The company can just declare that replacing or altering the firmware voids the warranty

How can they know/figure it out? (They can't/or it's prohibitively expensive/difficult).

>it's very common to find my firmware reverse engineered and available within a month or so of the product being released.

Sure, but it's hidden from 99.99% of your user base

> How can they know/figure it out?

Sony's answer for Xperia phones used to be that you'd unlock the bootloader with a key you got from them by entering the serial number/IMEI. As part of that, they warn that using custom ROMs that damage the phone - by overclocking, for example - would void the warranty.

It's a reasonable compromise, in my opinion.

Do they still do this?

Lenovo does

> How can they know/figure it out?

That's not a difficult problem, technically. There are a number of ways it can be done. Anything from comparing checksums to eFuses.

> Sure, but it's hidden from 99.99% of your user base

Yes. My point is that avoiding open sourcing firmware because of the risk of piracy or reverse-engineering doesn't make sense because pirates and/or interested engineers will do it directly from the devices anyway.

>pirates and/or interested engineers will do it directly from the devices anyway

But they don't need to make it too easy by giving the source on a silver platter.

Prusa (makers of the Prusa 3d printers) set it up so that you had to physically break part of your printer before you could flash custom firmware.

You could also just blow a fuse; we do actually have ways to do write-once memory for this kind of thing

Could you describe a rough implementation, with the assumption that the vendor can still provide firmware updates?

Sure. The vendor firmware contains an option in the settings, "unlock flashing". Enabling this (after a confirmation) will blow the "user modified fuse". When the system boots, the bootloader checks that fuse; if it's blown, then the bootloader will boot any firmware. If not, only boot images signed with the vendor's public key are allowed to boot. When the vendor gets a warranty claim, they check if that fuse is blown; if the fuse is blown and the damage could be software induced, they take that into account (IANAL, but they might not be able to immediately legally refuse it, but they can at least ask pointed questions about what exactly happened; YMMV).

Disclaimer: I didn't come up with this, I'm just summarizing approximately how I understand some Android devices to already work. This also makes me view this system as somewhat battle tested.

You have it in any unlockable Android phone.

In short - write the manufacturer public key in ROM and a fuse selects if signature check is enforce.

You can't read a blown fuse when the entire MCU is toast, though.

> If you are easily able to change the firmware, you are easily able to destroy the hardware,

For a recent and popular example of this, look at Hector Martin's experiments in implementing sound for Asahi Linux [1], which led to the destruction of his Macbook speakers and a warranty replacement.

(the end result is a good Linux sound driver for that hardware that correctly implements power limiting [2])

[1] Account since deleted but used to be at https://twitter.com/marcan42/status/1569595321168334848 if anyone knows an archive

[2] https://mas.to/@marcan@treehouse.systems/110122332896112809

>I wish more companies would provide it - akin to the old TVs and other equipment that came with [full!] schematics inside. It would let me truly understand and modify the items that I purchased.

I had forgotten about that thing with the wiring diagrams; I loved that.

That was the only thing that enabled me to repair a 1940s pinball machine that was essentially a relay-driven mechanical computer. Without those prints the machine would have surely been a loss due to the insane complexity and lack of interested/trained people that know how to work on such devices.

One wonders now how many lost pieces of equipment that could help to save from the recycling bin nowadays.

I imagine there's upstream issues too, with NDA's for hardware interfaces, and obviously proprietary OS like VxWorks, MS ThreadX, etc.

I was about to say that a lot of this is completely ignoring the few network vendors/chip vendors that have completely locked down hardware/chips that you're buying from them and effectively acting like a value added reseller for companies like broadcom.

> If you are easily able to change the firmware, you are easily able to destroy the hardware

How could custom software destroy a phone, a computer, a TV, a printer?

> if that's under warranty

Just void it.

A lot of consumer electronics, like phones and laptops, are powered via USB-C these days. It is capable of supplying a wide range of voltages, and the device will negotiate a voltage with the charger. This requires a PD controller on both sides - which is configured via firmware. Imagine your device was designed to charge at 9V, but custom firmware makes it request 48V instead.

Display panels these days use firmware to drive the panel itself. Instead of a pixel simply being on or off, it is driven with a voltage waveform which specifies how long which voltage should be applied and in what order. This allows things like "overdrive" to reach a faster response time. I would not be surprised if a corrupt waveform would cause physical damage, as the pixel would be driven way beyond its design specifications.

An inkjet printer could have the print head move all the way to one side and keep driving the motor. If the motor driver does not have proper temperature protection, it could result in the printer catching fire. A laser printer could have the firmware turn on the fuser's heating element until it catches fire.

> How could custom software destroy a phone, a computer, a TV, a printer?

The problem with your question is that you replaced the word "firmware" with the word "software" when the distinction between the two is the answer to the question.

I don't see the problem at all. Firmware is software.

I can see how defective software could damage industrial machinery but I'm having trouble imagining how some TV could possibly be damaged by software. Many consumer devices don't even have moving parts.

It is very tempting (and very easy) to think about firmware as simply software that you can update willy-nilly and at will, and things will always go back when things go bad. But there is a reason that most embedded firmware engineers are on their org's hardware team, and not software team. If I push a change that requires a JTAG to reverse, then from the customer's point of view, it is damaged.

The bootloader that allows you to revert back to prior firmware, is itself firmware. If that gets broken by a firmware update, then your device is effectively damaged.

> Firmware is software. [...] but I'm having trouble imagining how some TV could possibly be damaged by software.

It's not very hard to imagine. For instance, most embedded chips have several "general purpose" I/O (GPIO) pins, which can be configured as an input or as an output; their usage depends on how the chip was wired into the circuit, and very often, they're shared with "alternate functions" like a serial bus. Configure them incorrectly (as an output when they should be an input, for instance), and you can easily create a short circuit, burning that pin or even the whole chip.

Is that particular risk common? I would generally hope that I/O pins put out few enough milliwatts that they can be shorted safely.

Yep! Most microcontrollers will sustain permanent damage if you short an output pin for any significant time. You could probably design a microcontroller that didn't do this, but it would require putting a big resistor in line with the pin (decreasing responsiveness and max power output) and/or adding a lot of circuitry and increased cost to defend against a risk that's not a big deal when the chip is being programmed by a competent embedded engineering team.

A lot of circuitry? I would have thought a handful of (integrated) transistors could make it happen.

Transistors that can handle a lot of current or voltage will need to be much larger than most of the logic transistors on a chip, so even though they may appear to be few in number on the schematic, they can add up to significant die area for a small part like a microcontroller.

They need to control the transistor that actually does the output, so they shouldn't need to be very big themselves.

This is a layer below the digital circuit abstraction in the territory of analog circuits and device physics.

The extra current is a physical thing and you need more material to temporarily withstand it, and more circuit to detect and control it. Since it's an uncontrolled switching event, it'll probably ring unless you add even more components to absorb and control that. Then that could exceed the physical limits and trigger a parasitic circuit that doesn't have an off switch, so you need yet another circuit to detect and shut it off somewhere else.

It can be a lot of work for the board designer to make it reliable and compatible, assuming the other chip it's talking to can also handle the extra current. It's cheaper and more reliable to type GPIO1DIR=OUT or whatever. Sort of like when you drive a car, it's easier to choose to drive in the correct lane than it is for the car to enforce it on you and protect you if you do it anyway.

> The extra current is a physical thing and you need more material to temporarily withstand it, and more circuit to detect and control it.

Supposedly most of the chips can already temporarily withstand extra current. But the point of a current-limiting circuit is that you don't have extra.

> uncontrolled switching event

I'm not suggesting turning it off entirely, unless that's much much easier.

> it'll probably ring unless you add even more components to absorb and control that

If it fluctuates some when overloaded, that still sounds better than frying itself. But I'd expect an integrated implementation to keep pretty tight bounds.

> that could exceed the physical limits and trigger a parasitic circuit

What physical limits? You've lost me at this point.

> It can be a lot of work for the board designer

I was suggesting building it into the chip.

The current limiter is analog and dissipates a lot of heat compared to digital and also uses more passive devices, so it must be bigger.

Digital CMOS is triggered to switch between fully on and fully off. You can't really hold it in between. If you do, you get undefined behavior.

The ringing can have an initial spike that fries stuff.

CMOS can break down and the current will flow through a different path away from the gate where the gate can't turn it off. Called latch-up.

It is in the chip. The protection circuit can add a lot of parasitic elements to the pin interface that you have to account for when you design the board.

> The current limiter is analog and dissipates a lot of heat compared to digital and also uses more passive devices, so it must be bigger.

Controlling the voltage put into the output transistor shouldn't use much power or output much heat, should it? The output transistor will heat up based on voltage loss, but it needs to be able to handle a notable amount of that even when it's not shorted.

> Digital CMOS is triggered to switch between fully on and fully off. You can't really hold it in between. If you do, you get undefined behavior.

The pins are already tri-state. The logic to output +V, or output 0V, or neither already exists. So it won't fight itself.

> The ringing can have an initial spike that fries stuff.

How can you make a transistor's output spike higher than it does with the existing digital drive method?

Turning off the transistor is only the last step and the previous steps like detection take up space. Digital CMOS is bi-state and the pin is tri-state, therefore you can conclude that there are additional components involved to achieve the third state. Spiking can be caused by suddenly shutting off current through a parasitic inductance because it sort of has inertia and can't stop immediately.

> the previous steps like detection take up space

Yes but I'm missing why they would need significant amounts of space or power compared to the big transistor that's actually dealing with the current.

> Digital CMOS is bi-state and the pin is tri-state, therefore you can conclude that there are additional components involved to achieve the third state.

Yeah, so less to add and less to worry about compensating for because it's already handled.

> Spiking can be caused by suddenly shutting off current through a parasitic inductance because it sort of has inertia and can't stop immediately.

It already abruptly turns on and off. How does an extra trigger condition make that worse?

Or in other words, how are we not already in the worst case, with nowhere to go but up? (Since if we're just controlling the transistor better we won't be adding any more inductance than the pin already has.)

It depends on the design, but think of it this way. Digital if the smallest you can go. The protection circuit is not strictly digital, therefore it is bigger.

It's not already handled because you still need a circuit that detects the condition and switches to tri-state, if that's even how it's implemented.

Ringing and spikes come from electrical mismatch. If the protection changes the electrical properties of the pin, it may have to do more work to damp out the new mismatch. "Abrupt" isn't a single thing with a universal solution.

We're not just controlling transistors, but also sensing, shunting, clamping, damping, etc. And we're starting from the best case so we have nowhere to go but down.

You'll have to look up the rest yourself.

I know it's "bigger". But the protection circuit should be working on a thousandth the power as the output transistor, and the chip has a zillion logic transistors already, so I'm saying the chip should be negligibly bigger.

It should always be tri state. Never allow the positive and negative output transistors to get power at the same time. If that particular detail wasn't already implemented, it'll take like two logic gates more. Which is absolutely nothing compared to the rest of the chip.

And again, don't change the electrical properties! Tap like a microamp for monitoring, on a pin that outputs milliamps.

It doesn't matter that there is no universal solution to "abrupt" because we already have an acceptable setup and it's not changing.

Sensing can be done with no real impact on output characteristics. Additional shunting and clamping is not necessary. If the damping only happens by controlling the output transitor, then it's no different from how the circuit already works.

And no we're not starting in the best case. We're starting with a transistor where the design goal was to have as fast a slew as feasible. If it already doesn't overshoot dangerously, then using the same or slower slew shouldn't be hard to avoid overshoot, all else equal.

Most of your objections come down to "if you change X you might cause problems" when I'm saying not to change X.

You're describing magic and contradicting yourself. Tri-state means everything is off, so one transistor can't also be on at the same time. Damping dissipates heat, so damping by controlling the output transistor requires a bigger output transistor.

Down below the digital level, you can't isolate decisions from each other and nothing is free.

> tri-state means everything is off, so one transistor can't also be on at the same time.

I'm using tri-state to mean it has three distinct states. The output transistors are not sharing a control wire to make them one on, one off. If that's wrong use, I'm sorry.

The point I'm making is that it's easy to make it so the output transistors don't fight, even if the one that's enabled gets a halfsies voltage, because the other one won't also get a halfsies voltage, it will get a pure digital off.

> Damping dissipates heat, so damping by controlling the output transistor requires a bigger output transistor. Damping the output transistor also changes the electrical characteristics of the pin.

I'm assuming it's already kind of heat resistant because it only sometimes fails when shorted with no limiter at all. And if you damp it enough you won't make much heat. But fine, let's ignore that. You already brought up just turning it off at a certain point. If that's what's needed, so be it, because that won't change the characteristics.

No magic needed to keep the characteristics the same if you're just turning it off the way it normally turns off.

But I still don't understand how a transistor with an input that damps it is supposed to cause voltage spikes in excess of the same transistor with an input that doesn't damp it and always switches with maximum aggression, with only the control logic changing.

At this level, we're creating the concept of a digital state, so we can't use that result to solve problems, it's circular reasoning.

If damping makes heat, how can damping it enough make less heat? Why are you assuming that it's heat resistant if this is the level where you design the amount of heat resistance it has? Who did that work? Nobody, you have to do it yourself.

There is no control logic. It's analog. Logic is digital. Digital doesn't exist until we're done.

Sorry, but I've done all I can. Good luck in your search.

This is naive. There are tons of firmware changes that will render hardware unusable until the board is re-flashed (which you may not be able to do at that point), and even without moving parts the capability to damage components. Simple example, often firmware is the only thing that will stop your hardware from cooking itself if it is capable of doing so. Or if you mess with battery management you could conceivably get a fire. Or you mess with power distribution and send the wrong voltages, parts are fried. Or, etc. etc.

You're really not trying hard to think of any possible answers, are you?

In most devices over a certain level of complexity, there's firmware involved in thermal management. Messing that up can easily lead to premature failure of the hardware, and in some cases very quick failure.

Even for a TV which may not have much of a thermal concern for its processor (though I wouldn't bet on it with today's smart TVs), you can still expect there to be some screen burn-in mitigation.

> You're really not trying hard to think of any possible answers, are you?

I asked a question because I don't know. I assumed you did. I'm trying to learn something.

You're being passive-aggressively unimaginative and unwilling to seek out information for yourself, in a manner that is a common form of trolling. Even if trolling is not your intent, you should know that the idea of learning by asserting something wrong online and waiting to be corrected may make for a good joke but is not a polite and productive way to have online conversations.

I'm not being "passive-aggressively" anything. I asked a simple question. You're the one who started some firmware/software semantics argument instead of actually answering what I asked. I didn't assert anything either, other than that firmware is software. I continue to assert that now.

If you think I'm trolling, then simply don't reply. I've learned plenty from the other posts. I'd rather not create hardship for dang by continuing this thread.

Here's one moving part: speakers. It's becoming more common in the chase for good audio performance from small speakers to have a driver which can easily burn out the speakers, when given the wrong audio signal on normal volume. The firmware needs to actively model the power dissipation and temperature in the speaker and limit the signal if it could damage the speaker.

Just tell the voltage regulator to output 12v instead of 3.3.

> I'm having trouble imagining how some TV could possibly be damaged by software

Modern OLEDs perform image manipulation to avoid burn-in. Your XDA Developers firmware is going to end up with your screen being garbage in a year.

Android firmware routinely allows processor overclocking, a great way to damage components in devices that have tight thermal requirements.

Those are two. Arguing that firmware can't damage the hardware that it controls shows a decided lack of imagination.

One example is flash memory which can only do a certain number of writes (in the order of 10,000-100,000 writes).

You could have a firmware that saves everything to flash all the time and eventually causes the flash to become defective. It'd be easy to burn a flash out in less than a day.

There was an early 8-bit home computer where you could reprogram the video controller chip to drive the TV/display out of its operating range (timings/video frequencies, etc.) where left too long (how long? I don't know---I'm a software engineer, not hardware or electrical) could damage the TV/display.

Go back further, and you get to harddrive races, back when harddrives were washing machine sized devices, and if you get the heads going back and forth fast enough, they start shaking and could "walk" across the room. That doesn't sound like it's good for the harddrives.

You could definitely brick it, in addition to all the stuff everyone else mentioned.

The firmware is what stops you frying components. A good example is that MacOS has software which prevents the speakers from being over driven resulting in physical damage. There are other problematic things like overwriting flash memory which might result in the device not functioning properly.

Most of the time it would be extremely difficult to work out if the user caused the damage or if there was a bug or manufacturing fault. So they just give you a replacement anyway. It would be possible to create extra checks and void flags to try to detect this but that's just extra cost to the product for a feature almost no one cares about.

Another example: Your CPU has software that throttles its performance as it heats up, and eventually shuts it down. Remove that safety with custom firmware and you can make it overheat. Same thing goes for hard drives, SSDs, network interface cards, and so on.

I'm not sure vendors can void warranties in all countries. If you make a product that advertises itself supporting custom firmwares, then your hardware should be capabale of doing so would likely be how it is viewed in my country.

Just one example: the firmware for some piece of hardware could control the DC biasing of the device. Set the bias incorrectly and now you're drawing more current than is safe for the hardware and drastically reduce the lifetime.

What is EE?

Electrical Engineer, most likely.

Got it, thanks.

Reply on news.ycombinator.com