On 12.06.2009 19:16, Richard Smith wrote:
Carl-Daniel Hailfinger wrote:
We already support three external programmers [...]
Nice. Guess that road is started.
Indeed.
The libflashrom idea [...]
Isn't a lot of that already on its way with the refactoring you have been doing? Perhaps you could do it in stages?
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.
[...] I haven't had a chance to use flashrom in my daily routine yet because I use the cheetah and 4232H support only just started working. After I use it I can report back.
Please do.
(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? Will 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?
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...
Regards, Carl-Daniel