Flashrom Splits Into Two For This Firmware/ROM Flashing Utility

[phoronix]

Phoronix: Flashrom Splits Into Two For This Firmware/ROM Flashing Utility

The Flashrom project that serves as an open-source firmware/ROM flashing utility not only for system BIOS/UEFI on motherboards but also capable of flashing firmware for various network / GPU / storage controller cards and other programmable devices has decided to effectively split into two...

https://www.phoronix.com/news/Flashrom-Splits-Into-Two

[dreamcat4]

the programmers am hoping they might eventually support in distant future: xgecu t866ii (original protocol), then t48, t56 (new and different protocol)

For the sake of not having to run wine, etc. And having a really rock solid tool that is dependable... that's what's so great about Flashrom! No messing about in wine, or having to make some windows VM, and then be running a chinese (closed) windows software that includes its own malwares etc. Would be fantastic!

Having said that, its a pretty challenging goal. I dare not bring it up to those flashrom people. For being so unrealistic. They probably already have their hands full in wanting to support other pending new hardware. Whatever that might be (most probably onboard i2c stuff, newer intel and amd chipsets, things like that).

[icon]

Alas Stefan's announcement doesn't quite catch the actual situation. In some areas, e.g. AMD chipset support, flashrom-stable is already more "leading-edge". We didn't split goals. Effectively, we split developers.
There's also the original announcement and some more.

phoronix, in case you read this, it would be nice to adapt the article wrt. flashrom-stable goals.

[icon]

the programmers am hoping they might eventually support in distant future: xgecu t866ii (original protocol), then t48, t56 (new and different protocol)

These are interesting devices. Alas, I never had one on my table. What makes them potentially harder to support is the protocol. Devices that are more than a simple USB-to-SPI bridge often add complexity, may need quirk handling for different firmware versions etc. Do you happen to know if old or new protocols are documented somewhere?

[stormcrow]

.. No messing about in wine, or having to make some windows VM, and then be running a chinese (closed) windows software ...

This is something the ham radio community is having to grapple with as well. Ignoring the repurposing of retired commercial class radios which is a separate matter, there's been a huge dumping of cheap Chinese ham band transceivers into the US market in the past decade. Some have support in various open source projects like Chirp. Others, however, are hung up with closed source, Windows only - and sometimes only specific versions of Windows (I suspect the developers are using pirated versions of Windows) programming software. I have one like that ostensibly from Alinco, but it turns out to be a Chinese mfg rebranded Item. Its control software is arcane and Windows only. Complexity used to not bother me. These days I want stuff that "just works" so I've started advising people that ask to steer clear of these classes of transceivers unless you can verify compatibility with a reputable open source project.

[billyswong]

I don't understand why those laptops need to make the BIOS flashing Windows only through their custom program, when standalone motherboards can load BIOS image in BIOS and thus OS-independent. Anyone know?

[stormcrow]

I don't understand why those laptops need to make the BIOS flashing Windows only through their custom program, when standalone motherboards can load BIOS image in BIOS and thus OS-independent. Anyone know?

You're confusing and conflating "BIOS" (Basic Input Output System) with "(U)EFI" (Unified Extensible Firmware Interface). BIOS is obsolete and was superceeded by Intel's UEFI specification. Outside of the interfaces that were needed to boot MSDOS and initialize Intel CPUs, BIOS didn't have a lot of standardization between the various board firmware providers like Phoenix, American Megatrends, etc. It's unfortunate, and entirely incorrect, people who should know better keep calling PC main board firmware "BIOS" when that hasn't been true for a number of years. The reason old systems have Windows or MSDOS only firmware writers is because BIOS never had a standard interface for upgrading itself from the interface UI. Nearly every PC ran DOS/Windows so that made perfect sense back then. Only a few BIOS providers started using built-in upgrade capability (mostly for servers) when server class PCs were increasingly becoming loaded with Linux instead of Windows Server. And even then many OEMs just created a Linux utility instead for the server class hardware.

UEFI does have a self update specification in place called EFI encapsulation which is entirely independent of any OS other than setting a flag to trigger the upgrade interface on the next boot.

So to recap, old PCs = BIOS, new PCs (and some non-PC systems) = UEFI. BIOS usually requires external firmware utilities for writing images which are inevitably MSDOS or WIndows based (and that should surprise no one). UEFI usually does it all internally. BIOS = type of firmware and loosely a defacto standard, UEFI = type of firmware & formal firmware specification. Generically referring to all PC firmware as "BIOS" is imprecise and almost always incorrect on modern hardware younger than roughly 2013.

Also: Flashrom handles more than just PC main board firmware image writing interfaces.

[rogerx]

This is something the ham radio community is having to grapple with as well. Ignoring the repurposing of retired commercial class radios which is a separate matter, there's been a huge dumping of cheap Chinese ham band transceivers into the US market in the past decade. Some have support in various open source projects like Chirp. Others, however, are hung up with closed source, Windows only - and sometimes only specific versions of Windows (I suspect the developers are using pirated versions of Windows) programming software. I have one like that ostensibly from Alinco, but it turns out to be a Chinese mfg rebranded Item. Its control software is arcane and Windows only. Complexity used to not bother me. These days I want stuff that "just works" so I've started advising people that ask to steer clear of these classes of transceivers unless you can verify compatibility with a reputable open source project.

Good sound reasonable advice to me. Open source or Linux based support should and always should be more stable than proprietary code. As to why the HAM or radio sector constantly relies on closed source Microsoft code has always been beyond my comprehension.

[stormcrow]

Good sound reasonable advice to me. Open source or Linux based support should and always should be more stable than proprietary code. As to why the HAM or radio sector constantly relies on closed source Microsoft code has always been beyond my comprehension.

Ubiquity and familiarity for the most part. Amateur radio has an age problem. Most active hams are of the Baby Boomer generation with progressively smaller representation the younger the generation. While the community was quick to embrace computer technology for the most part, that technology was based on MSDOS/Windows because that's all there was in the late 80s, 90s, and oughts. Unix licenses were ultra expensive, and Linux/FreeBSD weren't usable, yet. Everyone is a creature of habit, even if you're actively walking in a different direction from everyone else. Habit drives what most people do. The recent generations have partly realized that keeping the utility of software at the mercy of Microsoft's (or Apple's) whims isn't necessarily a Good Thing, especially if and when lives could be on the line and the most current forced Windows update broke your USB-serial interface to your radio but you need to transmit data.

Ideology doesn't play as much of a role in this problem as many outside observers might think. There's a lot of hams that draw a (false, IMO) analogy between our commercially built radios (ICOM, Yaesu, Baofeng, etc) having closed source firmware (in onboard ROM in most cases) and using Windows so why care. Others point out that's a bad analogy, and while most radio firmware is indeed closed source with a few notable exceptions, Linux (and other open source projects) are in keeping with the basic tenants of ham radio philosophy - inquiry, home brew, and open exchange. Linux & BSD also aren't at the whims of a single corporate entity which is becoming more and more an issue the more often Windows updates tend to break Things Important with no recourse due to forced updates. I think the later is actually becoming more important than the ideology of software license, privacy, and politics. Simply retaking control over the software you may need to use in an emergency situation is important from a critical infrastructure stability point of view. This is why I use Linux (or BSD). I'm mostly license agnostic and privacy is important, but I don't want to be in a pickle when the last update to Windows bricked my serial interface cable, an API my data transfer program uses, or created a boot loop on my ham radio PC laptop. That's annoying on my gaming desktop, but it can end up fatal in certain emergency situations.

Over time, the MSDOS/Windows based generations have been literally dying out, and the younger generations who are more comfortable with Linux/BSD have taken more of the stage. This gives us another problem with ham radio. Some of the technologies still around from the 90s are based on MSDOS/Windows which gives us a bit of a quandry going forward. Who's going to support them in the future? Will they just die out, be replaced, or will someone step up to build more portable solutions? The answer tends to be a mix of all three with caveats.

[kn00tcn]

~actually, it's GNU/Linux~

what billy was asking is why do pretty much all diy desktop motherboards allow you to update the rom from within the firmware settings before any OS has even loaded (or having any storage devices plugged in), and in the last few years a lot of them allow you to update the firmware without even post'ing on a too new to be supported cpu by simply plugging into a designated usb port

meanwhile laptops or prebuilt/oem boxes have crippled firmware settings and often no way to update without running a proprietary windows tool (i've seen some that dont even give a .bin or .rom file, just a single exe)

it seems like such a low hanging fruit, plus now there's fwupd