A medium range trail/offgrid camera is perfect for this application. All the other solutions in the space are sdcard only, or dependent on some variant of LTE/5G.
I don't think most people really understand the compute complexity required for LTE and 5G terminals. It's telling that pretty much every discrete-ish full-speed LTE or 5G modem I've lain eyes upon is actually an embedded SBC running its own OS, with attendant power requirements.
The companies do that because by far the largest market for LTE/5G modems is smartphones.
They could make a more cut-down modem chip, but why would they? They already make hundreds of millions on smartphone SoCs. Just rebadge that silicon as modem ICs, no one cares that an LTE stick runs full Android.
Without limitations on authority and control, I worry more that the world will devolve into a multilateral legal hellscape, even moreso than exists today. Given how much is dependent on software, you are going to have the governments of pretty much any country with multinational exposure trying this in the next 10 years if recent UK and EU developments are any indicator.
The early MacOS era as well as pretty much the entire classic Mac OS era was infamous for being a more-or-less do it yourself environment for adding bits the OS didn't have or did sub-optimally for given use cases.
The wisdom of such a freewheeling ecosystem in today's era is maybe debatable, but given how user-hostile the mainline OS and software vendors can be, I say there's still plenty of room for that ecosystem and it should be preserved.
The old OS was awesome in that way. As extensions loaded the would appear in sequence at the bottom of the screen when a driver failed the boot would lock-up and one could reboot with extensions off change the boot order or remove the driver from the system folder. Very easy to mess with.
bios flashes are typically preflashed prior to soldering to boards -- some vendors route jtag or spi contacts, but you're more likely to need a vampire/pogo clip on for the TSOP or equivalent chip, or have fun with resoldering the bios flash if you're needing to recover from this.
It's not impossible to do in the field, but you can't really count on vendors surfacing that interface usually.
I've worked with automated EEPROM/Flash programmers (earlier versions of this line: https://www.bpmmicro.com/device-programmers/automated-progra...), and used pre-programming services from distributors, like Digi-Key, but that was the exception. It's almost exclusively faster, cheaper, and easier to load firmware from a test fixture. You need to test the assembly anyway, and it's much easier to update a test procedure, when a new firmware is developed, than to update and track inventory of pre-programmed devices, especially when different firmware versions are needed for different hardware variations.
Pogo pins are only really needed for mass production, especially for reducing repetitive stress injuries. For one-off updates, if a header isn't populated, it's easy to hold an unsoldered header in place, for long enough to flash an update.
the prior art in this area is going to be PCI&USB passthrough implemented in qemu and xen, with related but separate in-guest or 'in-host' virtual devices representing the bridged device.
Some related work in the SR-IOV & iommu space makes this a lot easier to implement as well. I would be very surprised if zero new security edge cases get discovered in the next five years or so however. Regardless, I'd look forward to seeing the results of RedoxOS's work here, as this would be a practical alternate implementation of driver domains like you see used in Xen and Qubes.
I agree, as we get even further away from the 90s and 2000s and data gets more valuable, having mechanisms like this to access old systems is vital now that it's getting harder to make "missing link" type machines that have parallel/scsi/ATA/FW/etc. to dump old data
It doesn't, but platforms basically do everything they can to claim the various common-carrier liability shields in DMCA-like laws. In the U.S. that means they forward the takedown request to whomever generated the content, and in theory should allow that generator to comply, or publish a counterclaim.
The whole system falls on the floor though when the common carriers aren't, and have low quality processes that don't actually enable the counterclaim half of this process.
Don't be fooled. These so called low quality processes are designed by large corporations in order to abuse their positions and retain control over all content being shown. The providers have no interest in providing legal protections to their small content creators. They want to focus on pleasing the big players.
Yes, it does appear to be purposely so. The wisdom of this is debatable, but consider: for a shipped app, these keys would all be embedded in a binary regardless, wouldn't they?
