I really love it that my Librem 15v4 laptop has an open source coreboot firmware, as well as a friendly procedure to build it from source, but I’m held back from actually making changes to it (even a straightforward experiment like making my own boot logo) by the fear of bricking the device. From what I understand if I make a mistake I have to use special reflashing hardware directly on the motherboard to get it running again. This seems like a pain.
Some motherboards have two BIOS chips to prevent this from happening. When a new firmware fails it’s possible to go back to the previous working one. It would be great if Librems had this too!
I’d be surprised no other people feel this way. You’d probably get more active coreboot development, too.
i have this feature … on an $800 proprietary AMD-AM4 motherboard … having something like this on a mobile libre motherboard would be indeed something …
I’m not sure how this would translate to more coreboot development, since the devices are already fully functional and upstreamed when shipped. While it might allow for more hobbyist tweaking, the additional cost (board layout change + 2nd flash chip) and implementation complexity means there’s no impetus to do so
I think the point being made was that someone in the community would be reluctant to experiment with changes / whatever due to the risk of bricking the device.
Is anything ever “fully functional”? The road to hell is paved with good extensions …
Rather than a 2nd flash chip, can you get away with a single flash chip that has twice the capacity and use low half / high half?
Thank you. Yes, I think part of the reason why it is good for things to be open source is experimentation, custom extensions, and scratching your own itch. Sure, it is ‘fully functional’ but that doesn’t mean nothing can be improved.
I also thought about that—it depends on the level of reliability needed, and this would only need to protect against programmer errors, not deliberate sabotage, so a software solution like that would be good enough!
Maybe: the first instructions read out some input (for example, a dipswitch) and decide based on that to which half to branch. This area is never overwritten while flashing.
while I appreciate why people might want something like this, there’s just no cost-effective way for it to be implemented for a small company like Purism
Fair enough!
to be clear i really appreciate you being frank about this it is 100 magnitudes better than making vague false promises as large company’s marketing department would undoubtedly do
The road to hell is paved with good extensions …
