Hi,
If someone is interested by the feature, here's a patch to extract a raw component (other types need decoding functions, which I did not write) from a coreboot ROM.
My particular use-case it that I want to embed a chunk of data (own S/N, P/N and things like that in my coreboot rom, so that this data is really tied to the hardware and survives compact flash changes, etc). It was suggested that I use DMI for this, and indeed it seems interesting, but my Alix.2 board has currently no DMI support, and the current embedding method supposes a recompilation of the rom. Hence, this method of extraction at run-time.
I found that using dd on /dev/mem to extract the running rom works well, at the condition of not having STRICT_DEVMEM in the kernel, and reading the whole image in one block. On my board:
# dd if=/dev/mem of=/tmp/dump.bin bs=512K count=1 skip=8191 # cbfstool /tmp/dump.bin extract boardata boarddata.bin
fills boarddata.bin with the contents of the boarddata cbfs component. Of course you can use any rom image instead of the one extracted from RAM.
I tried to make a patch which reads from /dev/mem directly in 2 ways: - mmap()ing /dev/mem, but it seemed that it would be too specific a modification to be accepted. - modifying the loadfile code to extensively use lseek to navigate in the file, reading it like starting at the end, and deducing the size from the CBFS header. This method works well for files, but does not for /dev/mem. So it's relatively useless. I think the problem is due to a bug/feature in /dev/mem implementation.
Signed-off-by: Aurelien Guillaume aurelien@iwi.me
Best regards.