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.
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 aurelien@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.
Patrick
Aurélien wrote:
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.
See http://stuge.se/physrd.c for a fairly generic tool to do this.
//Peter
On Tue, Sep 28, 2010 at 8:22 PM, Peter Stuge peter@stuge.se wrote:
Aurélien wrote:
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.
See http://stuge.se/physrd.c for a fairly generic tool to do this.
You're right, splitting the feature in two tools seems much more correct. This way we can extract the ROM image, then extract the specific payload.
Thanks :)
Aurélien wrote:
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.
See http://stuge.se/physrd.c for a fairly generic tool to do this.
You're right, splitting the feature in two tools seems much more correct. This way we can extract the ROM image, then extract the specific payload.
Well, for that purpose it's much better to simply use flashrom.
//Peter
On Tue, Sep 28, 2010 at 9:55 PM, Peter Stuge peter@stuge.se wrote:
Aurélien wrote:
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.
See http://stuge.se/physrd.c for a fairly generic tool to do this.
You're right, splitting the feature in two tools seems much more correct. This way we can extract the ROM image, then extract the specific payload.
Well, for that purpose it's much better to simply use flashrom.
Probably, but flashrom takes slighly more time due to various calibration routines (I could not find a way to disable those, but I didn't try very hard), and is less integrable that just reading like this. I don't need much portability between mainboards anyways.
In the general case however, you are right, the flashrom method seems much more robust.
[adding flashrom@flashrom.org to CC]
On 28.09.2010 22:16, Aurélien wrote:
On Tue, Sep 28, 2010 at 9:55 PM, Peter Stuge peter@stuge.se wrote:
Aurélien wrote:
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.
See http://stuge.se/physrd.c for a fairly generic tool to do this.
You're right, splitting the feature in two tools seems much more correct. This way we can extract the ROM image, then extract the specific payload.
Well, for that purpose it's much better to simply use flashrom.
Probably, but flashrom takes slighly more time due to various calibration routines (I could not find a way to disable those, but I didn't try very hard),
If you already have a known-good delay function with microsecond precision, you could use that instead of waiting for flashrom to calibrate its own delay loop.
and is less integrable that just reading like this. I don't need much portability between mainboards anyways.
Yes, libflashrom is still not completely done. Most of the parts are there, and we even have a bunch of different frontends, but the exported interface needs to be decided upon before we start offering libflashrom
In the general case however, you are right, the flashrom method seems much more robust.
Thanks!
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
flashrom takes slighly more time due to various calibration routines (I could not find a way to disable those, but I didn't try very hard),
If you already have a known-good delay function with microsecond precision, you could use that instead of waiting for flashrom to calibrate its own delay loop.
I'd suggest a setting which makes flashrom skip all parallel flash chips, to remove any need for calibration.
(To be more precise, the deciding factor is whether the chip is on the local bus, or if there are some bus master(s) in between, but that's generally equivalent to parallel vs. all others.)
//Peter
On 29.09.2010 01:32, Peter Stuge wrote:
Carl-Daniel Hailfinger wrote:
flashrom takes slighly more time due to various calibration routines (I could not find a way to disable those, but I didn't try very hard),
If you already have a known-good delay function with microsecond precision, you could use that instead of waiting for flashrom to calibrate its own delay loop.
I'd suggest a setting which makes flashrom skip all parallel flash chips, to remove any need for calibration.
That would break some Winbond LPC flash chips which require a few milliseconds of delay between JEDEC toggle reads on erase. And we also noticed that some SPI chips will react badly (corruption) to a too tight RDSR instruction schedule.
flashrom on libpayload uses the libpayload-provided delay functions and skips calibration. Given that LPC/FWH/SPI flash chips usually tolerate longer than expected delays without problem, you could hook up programmer_delay to udelay and save a second or so for calibration if you don't need parallel flash.
(To be more precise, the deciding factor is whether the chip is on the local bus, or if there are some bus master(s) in between, but that's generally equivalent to parallel vs. all others.)
Network cards with parallel flash would be classified as "local bus"?
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
I'd suggest a setting which makes flashrom skip all parallel flash chips, to remove any need for calibration.
That would break some Winbond LPC flash chips which require a few milliseconds of delay between JEDEC toggle reads on erase. And we also noticed that some SPI chips will react badly (corruption) to a too tight RDSR instruction schedule.
Yay. I guess they would be disabled too, unless calibration has run.
Given that LPC/FWH/SPI flash chips usually tolerate longer than expected delays without problem, you could hook up programmer_delay to udelay and save a second or so for calibration if you don't need parallel flash.
That sounds good!
(To be more precise, the deciding factor is whether the chip is on the local bus, or if there are some bus master(s) in between, but that's generally equivalent to parallel vs. all others.)
Network cards with parallel flash would be classified as "local bus"?
I believe bridges can make things more complicated. The assumption is that any bus master will always ensure correct timing for the bus where the chip is connected. You mentioned that there are exceptions, to that, but I think it'll hold in general. A bridge in a PCI chip that decodes into ROM may or may not ensure correct timing. I think it would have to be set on a per-chip basis.
//Peter
-
Aurélien -
Carl-Daniel Hailfinger -
Patrick Georgi -
Peter Stuge