Am 11.09.2010 16:11, schrieb Aurélien:
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(a)iwi.me>
I'll take care of
that patch soonish, just quick (because it's late here
and I'm tired), so it's not forgotten: The writing code should open the
target file with "wb" to prevent CRLF mangling on windows.