On 03.01.2019 12:23, Richard Hughes wrote:
First, happy new year and I hope you all had a great
Thanks, you too.
As some of
you know, I've been working with 3mdeb for the last few months, with
the aim of using libflashrom in fwupd to be able to flash firmware
using the LVFS on various embedded systems. This /could/ include
flashrom-compatible consumer hardware in the future, although I've not
worked out all the details on how something like coreboot-on-thinkpad
could be distributed automatically. Anyway, I digress.
The fwupd project has to build in all kinds of odd targets, e.g. for
odd endians, odd instruction sets,
Ah yes, that's why we avoided autotools and hacked our own makefile
logic. Autotools break too often even for the trivial case (various
Linux distributions on x86).
and in odd ways, e.g. installing
with a prefix of /app for projects like flatpak. We also have other
"robustness" guarantees and therefore have a comprehensive set of CI
tests which enable a lot of warning flags and run linting and static
analysis code like Coverity. This might explain my ongoing effort to
fix up seemingly benign warnings.
The warning fixes are much appreciated. That's the reason why we worked
pretty early on llvm/clang support for flashrom, and clang found quite a
few bugs in the codebase. There are some places where some gcc versions
are stupid and cause spurious warnings for certain valid compile
options, so eliminating all warnings is not going to be possible with
all gcc versions.
Rather than hack the hell out of Makefile (which I
started to do
initially) I ported the codebase to use the meson build-system. Meson
is a(nother) next-generation build system used by a lot of open source
projects ranging from low level libraries to desktop software. As part
Mh. We investigated CMake quite some time ago and decided against it.
Not because of direct CMake problems (IIRC CMake worked really well),
but because a sufficiently recent CMake was not available on all
supported platforms, most notably old RHEL versions. Back then, forcing
users to install build tools not available on their platform of choice
was frowned upon. Is Meson available by default on the oldest supported
RHEL version? If not, we'll have to recheck if the RHEL versions with a
too ancient CMake have since been retired.
of the port, I also copied the CONFIG_ logic from the
Option Current Value Possible Values Description
------ ------------- --------------- -----------
config_atahpt false [true, false] Highpoint
(HPT) ATA/RAID controllers
config_atapromise false [true, false] Promise ATA
config_atavia true [true, false] VIA VT6421A
The Meson build files look really nice. Thanks for adding support for
it. Would you mind pointing me to the part of the logic which takes care
of all the special cases? I didn't see it at first glance, but I
probably looked in the wrong place.
Is the Meson build intended to replace the current Makefile system or is
it intended to handle some currently unsupported special cases only?
At the moment I'm using the meson port so I can
include flashrom as a
subproject to fwupd (as distros are not yet shipping libflashrom as a
proper shared library) but 3mdeb is some way from being finished with
libflashrom. I wondered if my work would be useful already to anyone
else building flashrom on weird embedded architectures, or of it would
be interesting to upstream with further work.
I'm always happy if people try to port flashrom to new architectures. In
the past, supporting new architectures with MMIO-based interfaces
usually led to a chase down the rabbit hole until we could find someone
who knew the memory ordering rules and associated Linux kernel
interfaces of the architecture well enough (thanks Segher!).
If you're aware of any architecture or platform or delivery mechanism
where the current Makefile doesn't work, I'd appreciate a pointer so I
can fix the current solution until we have a new solution working on all
The single commit which
just adds 5 files can be found here:
Correct me if I'm wrong, but it looks like the build logic in your
current tree errors out if someone tries to build the internal
programmer on non-x86 platforms. IIRC flashrom currently builds fine at
least on MIPS (Loongson-2F internal programmer support).
The current Makefile supports the following (sometimes exotic) cases:
- native build on Linux (different libpci versions need different
- native build for Debian/KFreeBSD
- native build on Windows
- native build on Mac OS X
- native builds on all the BSDs (Free, Open, Net, Dragonfly)
- standalone build against libpayload
- cross-builds on Linux for DOS
- cross-builds on Linux for Windows
- cross-builds on Linux for Mac OS X
- static builds
- and probably a bunch of others I forgot
Yes, the number of people completely understanding the Makefile is lower
than we'd like. I'm all for cleaning this up if we can find a solution
which works well enough on all supported platforms.
Thanks again for your work.