On Mon, 11 Aug 2008, Ulf Jordan wrote:
On Mon, 11 Aug 2008, Jordan Crouse wrote:
This adds a lot of extra .data space.
I will try to make a quantitative comparison on the growth of e.g. coreinfo and coreinfo+coreboot-v3 with both the original patch and the scheme outlined above.
Here is a comparison of the sizes of libpayload.a, coreinfo.elf, and normal/payoad/segment{0,1} in a coreboot-v3 image for three cases: before the ACS support (r3498), with the ACS support from this thread (r3501), and the attached patch, having *_acs_map in .bss and initialized in initscr() (r3501+patch). All tests were done against coreboot-v3 r743 in QEMU. All sizes in bytes. LAR entries are given as compressed/uncompressed (as read from the coreinfo LAR screen).
| libpayload.a | coreinfo.elf | segment0 | segment1 | ------------+--------------+--------------+----------+-------------+ r3498 | 75044 | 39196 | 1/184080 | 15034/34720 | ------------+--------------+--------------+----------+-------------+ r3501 | 77534 | 41212 | 1/184080 | 15305/36736 | ------------+--------------+--------------+----------+-------------+ r3501+patch | 76504 | 40028 | 1/185648 | 15433/35552 | ------------+--------------+--------------+----------+-------------+
So the ACS implementation in svn incresed the uncompressed size of coreinfo segment1 by 2016 bytes, while the compressed size only increased by 271 bytes.
As compared to the non-ACS case, the patched ACS implementation increases the uncompressed size of coreinfo segment1 by 832 bytes, while the compressed size increased by 399 bytes.
So uncompressed is bigger and compressed is smaller in this case, but I'm sure it is possible to come up with something better. The question is if it's worth the work, since the *total* size added by the current ACS implementation after compression is only 271 bytes (Thank you, LZMA!). Are payloads compressed in coreboot-v2 too?
While doing this investigation I also found a mistake in console_acs_map. ACS_PI: '{' should map onto '\343'. I will send a separate patch for correcting this bug.
/ulf