[coreboot] cbfstool2 0.9

[Patrick Georgi]

Hi,

at http://www.coresystems.de/~patrick/cbfstool2-0.9.tar.bz2 you can find
a copy of my current work on improving the CBFS toolchain.

It's a drop-in replacement for cbfstool as provided in the coreboot
tree, with the following differences:
- no more mmap, nor fork/exec, improving portability
- locking a file to a specific location in the flash image works
- bootblock size is determined from the file size, the command line
argument is ignored (but expected for compatibility purposes)

Some parts of the code are clean rewrites, from the cbfstool README,
with tests using cbfstool, the cbfs_file handling (creation, splitting,
iterating) in particular.
Other parts of the code are mostly unchanged, like the ELF parsers that
handle stages and payloads.

I figured that it's more work to get rid of mmap and fork/exec and
implement working fixed-address files in the existing code base without
introducing lots of hacks then re-implementing parts of it.
I also tried to document a couple of the finer points, I hope I caught
all the important things.

There are a couple of things left to do:
1. The CodingStyle must be followed, right now it follows my own (with
>160 characters per lines, for example)
2. Licensing information is missing in lots of source files. Given that
some of them contain GPLv2 references, and the nature of that license,
all of the tarball is distributed under GPLv2. Still, I'll have to clean
it up.
3. There's no integration into the coreboot build system yet.
4. Some commands aren't implemented yet. This is not really a problem,
given that they touch functionality that is rather fragile in cbfstool.
Deleting files comes to mind.

It's supposed to be a drop-in replacement, meaning that I re-implemented
the behaviour of the CLI. It's hand-threaded spaghetti code now, and I'd
love to replace the command line format with something more getopt
compatible eventually.
I also didn't bother to free() all malloc()ed memory regions given that
the code survives a couple of milliseconds, before it ends itself.

One battle at a time.

Still, I think it's good enough to get some public exposure, maybe some
watchful eyes at code and behaviour.
The big new feature of this code is the capability to lock files to
fixed locations, which we'll need for a variety of things: I'm currently
working on moving the ROM stage (that does CAR and raminit) into CBFS,
and this project came into existence because I needed some way to put
code at defined places without cbfstool blowing up. Certain EC roms,
romstraps, and other auxilliary data of devices also must be located at
pre-defined places to make hardware happy.


Regards,
Patrick