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
Signed-off-by: Aurelien Guillaume <aurelien(a)iwi.me>