[coreboot] libpayload, coreinfo: ACS support

Jordan Crouse jordan.crouse at amd.com
Mon Aug 11 22:29:17 CEST 2008

On 11/08/08 22:11 +0200, Ulf Jordan wrote:
> On Mon, 11 Aug 2008, Jordan Crouse wrote:
> > On 10/08/08 16:42 +0200, Ulf Jordan wrote:
> >> Add support for line drawing characters and the alternate character set.
> >> This enables using the ACS_ curses macros with libpayload.
> >>
> >> The translation from ACS_ macros (or characters with attribute A_ALTCHARSET)
> >> is done using one acs map for the video console, one for serial console
> >> (xterm/vt100/vt220), and one fallback, from which an ASCII substitute is
> >> taken if the device specific map doesn't contain an entry (ie NUL).
> >>
> >> coreinfo is also adapted to take advantage of the symbolic ACS_ constants.
> >>
> >> Signed-off-by: Ulf Jordan <jordan at chalmers.se>
> >
> > This adds a lot of extra .data space.
> Yes, this patch is a bit clumsy.
> There are several ways to make it less hard on .data space. One way would 
> be to have all *_acs_maps in .bss, and initialize them at runtime in 
> initscr() from the much shorter acsc strings (about 64 bytes per map).
> 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.
> > What do we lose if we don't support alternate character sets?
> (First a side note: this is not general support for different character 
> sets, but support for *the* special graphics/"alternate character set".)
> Well, my motivation for implementing ACS support is twofold:
> 1. Let curses applications continue to use ACS_HLINE when drawing lines 
> etc (in the current code this could at least partially be supported by 
> initializing acs_map with the magic characters '\304' and so on). 
> Consequently, less porting to do when compiling a curses application 
> against libpayload, and the code stays more readable. The patch also adds 
> fallback ASCII characters for the entire set, not just the line drawing 
> part.
> 2. Better fidelity between what is seen on VGA console and serial console. 
> After applying the ACS and companion color patch, the serial output in 
> xterm looks close to identical to the QEMU VGA (there is still some 
> misalignment due to outputing characters in C0, but that is for a later 
> patch).
> I do recognize that sometimes one wants to have very simple serial output, 
> and sometimes one wants eye candy.
> > Mabye we can make this conditional in the kconfig.
> Yes, good idea. I think it would be nice to be able to switch between 
> "pure ASCII+cursor positioning" and "all bells and whistles" over serial.

Okay - great explanation.  For what its worth, I wasn't trying to pick on
you specifically.  The advantage of libpayload is that it doesn't need to
support everything and the kitchen sink - only what our customers (the
payload writers need).  We shouldn't support features just for giggles.

That said, we also want serial curses to Just Work (TM) so that the same
payload writers don't need to be aware of it.  This is double important
to us since serial is more often the primary console.

So, long story short, I accept your excellent summary, and I'll check in
the patch as is.  We can work on reducing the .data load later.


Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.

More information about the coreboot mailing list