Interesting. Does this mean larger models could be ran on less memory? It looks like it uses 15-20x less memory. Could a 671B DeepSeek R1 be ran in just ~40-50GB of memory? It sounds like it'd be 1/3 as fast though (<1tk/sec).
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.
- 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.
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.
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.
I created an offline version of YouTube (for Mac). I use Downie to download videos I'm interested in (usually videos download in 10-30 seconds). Then I go to the web app and click play. Using a shell command, it launches IINA and starts playing the video.
I have a mark watched and delete button so that YT's algorithm still works to surface interesting videos.
Having offline videos allows me to watch videos like I couldn't before (even on a stable 1Gbps connection). I can fast-forward instantaneously and there are no ads. Subtitles are also downloaded and a thumbnail.
Another nice feature inherent of offline video is if you want to grab your laptop and go somewhere (I'll sometimes go to the park and eat), you don't have to worry about your video stopping because you don't have internet/need to tether.
The whole app is contained in one executable file (you'll need Ruby) and stores its data in the JSON files that Downie provides.
I tried pulling the video from the Safari web client as it gave a giant data: uri in the <video> element that I thought I could save but couldn't figure it out.
Adding video support is rather easy, it is just something I never felt the need to do given my preference for audio - which I can listen to while working on the farm etc. - over video. I can have a look at adding it if there is enough demand.
I had a look at including video and it turns out I was premature in saying it would be easy. Currently librespot-python does not support video so only for that reason it is a no-go. If support ever arrives it might become possible but given that Spotify-video is burdened with Widevine DRM it might mean Spodcast would need to integrate a (headless) browser in the process to decrypt the video. So, for now, no video. For the future, maybe but don't hold your breath.
I'm working on a Hacker News client that I've named HackiNews [1]. It's inspired by HckrNews [2]. I've made it simply to scratch my own itch but with others in mind.
I wanted more granularity in the score that I filtered out. I also wanted night mode (automatically switches with system chosen theme) especially in the comments section.
I have the code available here on GitHub [3] but it's not documented for use as I've only spent a couple days on it.
