[flashrom] wiki output

[Stefan Tauner]

i'd like to improve the wiki output.
first of all i'd like to get the voltage printing of chips in. after
that i would like to add support for linked footnotes, because our
tables are long and right now the user has to scroll a lot to read them.
i think those two things are not controversial, so we can discuss them
when i am sending the patches (voltage printing has already been posted
a few weeks ago actually).

the other thing i want to do is to improve the list of supported
mainboards. right now 
- we don't differentiate between revisions (besides
  adding them to the name as string).
- we can't distinguish between not supported at all and untested board
  enable (we use the note field for this).
- we try to link to the vendor... which fails more often than it works
  over the time imho.

i presume the most problematic thing is removal of the urls. basically
i don't care if support for them remains, but i will stop adding them
myself. it is just a waste of time imho because they change so often
or the targets just vanish.
if i can persuade all of you to think that too, it would be even better.
so... i don't see the reason we do this at all (besides the obvious
hypertext argument that one should link as much as possible).
i doubt any user will follow those links to find "his" board. why
should s/he? what's the use case for those links?

carldani replied "identification of supported revisions" (more or less).
this is a bogus argument. the URLs don't do that now, and in most of
the cases they can't (because there is only one single page for
multiple revisions or even models).

anyway, we should not be divided by this particular detail, so now to
the really important stuff.

i'd like to add a ? "icon" to boards with untested board enables (just
like we do everywhere else if we are not sure yet). this would require
extending the "working" field of struct board_info and using OK, NT and
a to-be-defined third macro instead of just 0 and 1 in the table
itself (or, an enum... much preferred solution by me).
quite easy stuff.

then i had the idea to somehow add board revisions more explicitly. just
adding additional columns like it is done for the chip statuses won't
cut it, because we need to fit the names of the revisions in there too.
but maybe it is enough nonetheless: what about
- adding n columns where n is the maximum number of revisions of a
  single board, and
- in each column we print the revision name followed by OK, No, or ?;
  or nothing if there are less revisions

to support this we would need to expand the existing struct and macros,
but it is doable imho.

other ideas are welcome.

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner