[SeaBIOS] [RFC PATCH] Add support for Intel Quark UART.

[Kevin O'Connor]

On Fri, Nov 29, 2013 at 04:59:32PM +0000, David Woodhouse wrote:
> On Fri, 2013-11-29 at 11:40 -0500, Kevin O'Connor wrote:
> > On Fri, Nov 29, 2013 at 02:02:02PM +0000, David Woodhouse wrote:
> > > This provides basic debug output on the Quark system, assuming that
> > > *something* (i.e. coreboot or UEFI) has set it up in advance for us.
> > > 
> > > Signed-off-by: David Woodhouse <David.Woodhouse at intel.com>
> > > ---
> > > I looked briefly at making this part of the CONFIG_DEBUG_SERIAL code,
> > > and making that generic enough to handle I/O access *or* MMIO access
> > > depending on what's present... but in fact that's probably overkill.
> > > 
> > > This isn't really limited to Quark; it would work with any 16550 device
> > > wired up as MMIO32. But we can expand it as required, I think. No point
> > > in starting off with the same functionality as the 5000-odd lines of the
> > > Linux kernel's 8250_pci.c.
> > > 
> > > What do I need to do if called in 32-bit segmented mode? I'm guessing
> > > that's not going to work right now...
> > 
> > Do you need debug output from 16bit mode or 32bit segmented mode?  The
> > post and boot phases are all 32bit code so typical boot time debugging
> > shouldn't be impacted.  Gerd's cbmem debugging code uses this
> > approach.
> 
> I can live with that. Perhaps I should make it work in 16-bit mode but
> *only* if the appropriate BAR has been put in a memory hole below 1MiB.

That should be okay, but would it ever actually be mapped below 1Meg?
Where would it be mapped to: 0xa0000-0xc0000?

BTW, how does this "Quark" support compare with the PCI Oxford serial
code that Google has been maintaining?
http://git.chromium.org/gitweb/?p=chromiumos/third_party/seabios.git;a=commit;h=9b39499125f22627aaedaaaadabfde787c50d51c

-Kevin