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
-
Patrick Georgi