Carl-Daniel Hailfinger wrote:
Well, since
1. OFW uses its own flasher, so it won't benefit from libflashrom
2. any emergency flasher in coreboot needs to be small (a one-chip-only
solution) and flashrom is 114k stripped
I don't see any benefit in libflashrom.
Its only a benefit if you see value in having multiple front ends if
flashrom is flexable enough that its the the only user interface then
libflashrom dosen't help you much.
The goal of a libflashrom would be so that commercial
manufacturers/hobbyist makers of device programmers have a nice clean
way of using the underlying flashrom plumbing for whatever user
interface they want to provide.
(is the cheetah stuff at a testable level yet?)
I concentrated on FT4232H support for now. Both Cheetah and FT4232H have
one big problem: Compilation and linking. Do we link against libftdi or
not?W ill symbol resolution be done by the linker automatically or do we
use dlopen() and dlsym()? Should we use compile time flags instead? How
should we modify our makefiles for that?
My vote would be for a compile time option including the ability to link
static. The cheetah appears to make that difficult since they only
provide an .so. I don't think its too much to to make users who want to
use flashrom with external support recompile with that support enabled.
I'm more thinking about the future where the feature set would grow
based on the features of a specific programmer or something that a
non-coreboot user would need.
I'd say we wait for such feature set extensions before trying to design
an API. Most attempts in the past to create future-proof APIs were
thwarted either by new features or crappy hardware...
This is what I mean about being serious about supporting external
programmers. Setting up the stage to become the "the" plumbing for open
source programmers. Perhaps thats too far outside of the coreboot scope
but if thats the case then external programmer support will just be
something that a few of us with specific needs are driving rather than
something that can develop into a life of its own.
--
Richard A. Smith
[email protected]
--
coreboot mailing list: [email protected]
http://www.coreboot.org/mailman/listinfo/coreboot
