[flashrom] Using libflashrom from fwupd

[David Hendricks]

On Tue, Aug 15, 2017 at 4:55 AM, Richard Hughes <hughsient at gmail.com> wrote:

> Hi all,
>
> I'm the maintainer of fwupd, which is a daemon for doing firmware
> updates in Linux. Using fwupd about 200,000 people update firmware
> every month. At the moment I have an out-of-tree patch to use the
> flashrom CLI for updating coreboot on Purism laptops, which exec's a
> flashrom binary with the correct arguments and then screen scrapes the
> output. This is less than ideal. I saw the appearance of a libflashrom
> in the staging branch and got very excited. I'm assuming the long term
> goal here is to install a shared with stable API/ABI library and a
> pkg-config file. If so, please keep reading.
>
> One thing that is really important for fwupd is progress completion;
> as flashing the firmware is an inherently scary thing to do users do
> like to see a progress bar move from 0% to 100% in a gradual way as
> it's very re-assuring. This is even more important for the GUI, where
> people that just see a spinner don't know if the process is going to
> take 10 seconds, or 10 minutes.
>

Agreed! Especially since a lot of users have large chips, slow programmers,
or sometimes both. Simple read operations can take a worryingly long time
on some common hardware these days.


>
> Would it be possible to have a process callback for
> flashrom_image_read(), flashrom_image_write() and
> flashrom_image_verify()? It'd need to have some kind of callback
> userdata too, for instance:
>
> int flashrom_image_verify(struct flashrom_flashctx *, const void
> *buffer, size_t buffer_len, flashrom_progress_callback callback_fn,
> void *callback_user_data);
>
> and also:
>
> typedef void(flashrom_progress_callback)(uint64 completed, unit64
> total, void *user_data)
>

The short answer is yes. Nico also briefly mentioned an idea on IRC to use
a mechanism similar to flashrom_set_log_callback() to avoid complicating
function signatures for the read, write, and verify functions.


>
> I'm not familiar at all with flashrom internals, but could try to
> produce a patch if required -- although to propagate the progress
> through operations would mean patching a lot of chip->read() callbacks
> which probably requires a more experienced hand. Ideas welcome,
> thanks.
>
> Richard.
>
> _______________________________________________
> flashrom mailing list
> flashrom at flashrom.org
> https://mail.coreboot.org/mailman/listinfo/flashrom
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/flashrom/attachments/20170816/a27f351f/attachment.html>