[coreboot] [PREVIEW]sconfig in C

[Patrick Georgi]

Hi,

attached you'll find a couple of files:
- sconfig.py.diff which is a patch against our current sconfig.
The patch makes sconfig's output more predictable, by
* reordering hard coded output so its elements match the order of the
generated output
* sorting registers alphanumerically by key
* sorting headers alphanumerically.
The third part contains a hack as I couldn't convince python that it
should sort src/northbridge/amd/amdk8/root_complex/chip.h _after_
src/northbridge/amd/amdk8/chip.h (and the same for fam10)

This patch makes the output of sconfig more regular, but should
otherwise not affect functionality.

The other files provide an implementation of sconfig in C. This has a
couple of advantages:
1. We do not rely on python any longer
2. We use a commonly used compiler compiler (instead of yapps2)
3. It's faster (by a factor of 20, not that this matters much in
absolute numbers)
4. It's smaller: 511LOC vs. 1035LOC (both excluding the compiler
compiler), with code to drop once the byte-for-byte compatibility with
python-sconfig can go.

sconfig.l and sconfig.y give you (with the help of bison and flex) an
implementation of sconfig in C. I wrote a script that mass generated
static.c files for all mainboards both with the python and the C version
and diffed the results.
With the patch to python-sconfig, these diffs are empty.


There are a couple of things left to do with the C version:
- Hook up to the build system (in a way that flex and bison are optional
dependencies, ie. deliver and by default use prebuilt results)

- Add static.dot generation code. This should be reasonably easy, now
that the parsing and rewiring between the components is done. The
emitter is a separate phase which doesn't change the internal device
tree model.

- Clean up:
-- There are various overly complicated things in the code to precisely
match python-sconfig output where it wouldn't matter except to aid with
the comparison (the order of the structs and includes)
-- It's not so nice to stuff all the C code in sconfig.y. Parser and
processing code should be split more sensibly.
-- Naming: A couple of variables changed meaning over their life time.
That's stable now, so they should be named intuitively.
-- Strict parsing: For example, only accept registers for chips
(python-sconfig doesn't do that properly, either)


Yet, I'd prefer to get the python-sconfig patch in, and the C code as
similar to the current state as possible - It's known to give useful
results. That way, further development provides history, so we can
triage bugs more easily.

For the python patch, I'd need some help by someone with python
knowledge about why it sorts the strings the way it does (the
root_complex hack isn't acceptable for upstream)


Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>