[coreboot] libpayload, coreinfo: ACS support

[Ulf Jordan]

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
-------------- next part --------------
Store *_acs_map in .bss, and initialize at runtime from acsc strings.

Signed-off-by: Ulf Jordan <jordan at chalmers.se>

Index: libpayload/curses/tinycurses.c
===================================================================
--- libpayload/curses/tinycurses.c	(revision 3501)
+++ libpayload/curses/tinycurses.c	(arbetskopia)
@@ -88,70 +88,8 @@
 // cchar_t *_nc_wacs;
 SCREEN *SP;
 chtype acs_map[128];
+chtype fallback_acs_map[128], serial_acs_map[128], console_acs_map[128];
 
-/* See terminfo(5). */
-chtype fallback_acs_map[128] =
-	{
-	' ',	' ',	' ',	' ',	' ',	' ',	' ',	' ',
-	' ',	' ',	' ',	' ',	' ',	' ',	' ',	' ',
-	' ',	' ',	' ',	' ',	' ',	' ',	' ',	' ',
-	' ',	' ',	' ',	' ',	' ',	' ',	' ',	' ',
-	' ',	' ',	' ',	' ',	' ',	' ',	' ',	' ',
-	' ',	' ',	' ',	'>',	'<',	'^',	'v',	' ',
-	'#',	' ',	' ',	' ',	' ',	' ',	' ',	' ',
-	' ',	' ',	' ',	' ',	' ',	' ',	' ',	' ',
-	' ',	' ',	' ',	' ',	' ',	' ',	' ',	' ',
-	' ',	' ',	' ',	' ',	' ',	' ',	' ',	' ',
-	' ',	' ',	' ',	' ',	' ',	' ',	' ',	' ',
-	' ',	' ',	' ',	' ',	' ',	' ',	' ',	' ',
-	'+',	':',	' ',	' ',	' ',	' ',	'\\',   '#',
-	'#',	'#',	'+',	'+',	'+',	'+',	'+',	'~',
-	'-',	'-',	'-',	'_',	'+',	'+',	'+',	'+',
-	'|',	'<',	'>',	'*',	'!',	'f',	'o',	' ',
-	};
-
-/* See acsc of vt100. */
-chtype serial_acs_map[128] =
-	{
-	0,	0,	0,	0,	0,	0,	0,	0,
-	0,	0,	0,	0,	0,	0,	0,	0,
-	0,	0,	0,	0,	0,	0,	0,	0,
-	0,	0,	0,	0,	0,	0,	0,	0,
-	0,	0,	0,	0,	0,	0,	0,	0,
-	0,	0,	0,	0,	0,	0,	0,	0,
-	0,	0,	0,	0,	0,	0,	0,	0,
-	0,	0,	0,	0,	0,	0,	0,	0,
-	0,	0,	0,	0,	0,	0,	0,	0,
-	0,	0,	0,	0,	0,	0,	0,	0,
-	0,	0,	0,	0,	0,	0,	0,	0,
-	0,	0,	0,	0,	0,	0,	0,	0,
-	'`',	'a',	0,	0,	0,	0,	'f',	'g',
-	0,	0,	'j',	'k',	'l',	'm',	'n',	'o',
-	'p',	'q',	'r',	's',	't',	'u',	'v',	'w',
-	'x',	'y',	'z',	'{',	'|',	'}',	'~',	0,
-	};
-
-/* See acsc of linux. */
-chtype console_acs_map[128] =
-	{
-	0,	0,	0,	0,	0,	0,	0,	0,
-	0,	0,	0,	0,	0,	0,	0,	0,
-	0,	0,	0,	0,	0,	0,	0,	0,
-	0,	0,	0,	0,	0,	0,	0,	0,
-	0,	0,	0,	0,	0,	0,	0,	0,
-	0,	0,	0,	'\020', '\021', '\030', '\031',	0,
-	'\333',	0,	0,	0,	0,	0,	0,	0,
-	0,	0,	0,	0,	0,	0,	0,	0,
-	0,	0,	0,	0,	0,	0,	0,	0,
-	0,	0,	0,	0,	0,	0,	0,	0,
-	0,	0,	0,	0,	0,	0,	0,	0,
-	0,	0,	0,	0,	0,	0,	0,	0,
-	'\004',	'\261',	0,	0,	0,	0,	'\370',	'\361',
-	'\260',	'\316',	'\331',	'\277',	'\332',	'\300',	'\305',	'~',
-	'\304',	'\304',	'\304',	'_',	'\303', '\264', '\301',	'\302',
-	'\263',	'\363',	'\362',	'\342',	'\330',	'\234',	'\376',	0,
-	};
-
 // FIXME: Ugly (and insecure!) hack!
 char sprintf_tmp[1024];
 
@@ -274,6 +212,13 @@
 // void idcok (WINDOW *, bool) {}
 // int idlok (WINDOW *, bool) {}
 void immedok(WINDOW *win, bool flag) { win->_immed = flag; }
+void init_acs_map(chtype *acs_map, char *acsc)
+{
+	u8 key, value;
+
+	while ((key = *acsc++) && (value = *acsc++))
+		acs_map[key & 0x7f] = (u8)value;
+}
 /** Note: Must _not_ be called twice! */
 WINDOW *initscr(void)
 {
@@ -285,6 +230,24 @@
 	for (i = 0; i < 128; i++)
 	  acs_map[i] = (chtype) i | A_ALTCHARSET;
 
+	/* See acsc of vt100. */
+	init_acs_map(serial_acs_map,
+		     "``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~");
+
+	/* See acsc of linux. */
+	init_acs_map(console_acs_map,
+		     "+\020,\021-\030.\0310\333`\004a\261f\370g\361h\260"
+		     "i\316j\331k\277l\332m\300n\305o~p\304q\304r\304s_t\303"
+		     "u\264v\301w\302x\263y\363z\362{\343|\330}\234~\376");
+
+	/* The fallback map defaults to a blank for unknown characters. */
+	for (i = 0; i < 128; i++)
+	  fallback_acs_map[i] = ' ';
+	/* See terminfo(5). */
+	init_acs_map(fallback_acs_map,
+		     "+>,<-^.v0#`+a:f\\g#h#i#j+k+l+m+n+o~p-q-r-s_t+u+v+w+"
+		     "x|y<z>{*|!}f~o");
+
 	if (curses_flags & F_ENABLE_SERIAL) {
 		serial_clear();
 	}