Am 11.09.2010 16:11, schrieb Aurélien: > 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 <[email protected]> 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.
Patrick -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
