[coreboot] [RFC] First K8 board to port to v3

[Carl-Daniel Hailfinger]

Hi,

to keep a record of the IRC conversation we had yesterday, here is the
stuff I said (in slightly rewritten form):

Ideal conditions for supporting a board in v3 are:
- documentation freely available
- board available in the market for the next few months
- socketed BIOS
- already supported well in v2.

Chipset choice (availability in the last field means end-user
availability of boards for a recent processor):
- SIS 966 family: Source available, no docs, vendor cooperative, almost
unavailable.
- Nvidia CK804 family: Source available, no docs, no cooperation from
vendor, availability rather limited.
- Nvidia MCP55 family: Source available, no docs, no cooperation from
vendor, readily available.
- AMD 8100 family: Source available, docs available, vendor cooperative,
almost unavailable. (Can be tested in the freely downloadable SimNow.)
- AMD/ATI newer chipsets: No source available, no docs available, vendor
cooperative, readily available. (Given AMD's recent track record for
opening documentation we probably can expect improvements regarding docs
and source).
- VIA K8T890: Source available, docs available slowly with NDA (Rudolf
has them), vendor somewhat cooperative, availability limited.
- VIA K8M890: No source, no docs available yet (Rudolf is working on
this), vendor somewhat cooperative, readily available. (Rumored to be
similar to K8T890.)

Unless things at the chipset front change significantly till the end of
April, we are probably stuck with MCP55.

Board choice:
- Gigabyte M57SLI: Multiple revisions, newer ones (rev 2.x) have
soldered SPI flash behind a IT8716F LPC-to-SPI translation chip.
Availability prognosis is good.
Limitations of the M57SLI (though I can't offer a K8 board supported
better in v2):
Rev. 2.x boards have SPI behind IT8716F, can only map fixed 512 kByte of
ROM into address space.That means we have to rewrite LAR walking
completely to work with SPI chips above 512 kByte because we can't map
them directly and have to read them byte-by-byte. Then again, if we are
willing to live with 512 kByte ROMs on the M57SLI, it should work out
just fine.
Streaming decompression (like in v2) does not solve the LAR walking
problems, because the LAR walk routine expects a memory mapped
LARchive.The rewritten LAR walking will be very ugly in v3: either you
consume horrible amounts of stack space (~1100 bytes more) or you write
a streaming version of strncmp() and wrap most accesses to LAR headers
in functions or you shadow/copy all of ROM directly after RAM is enabled.
Since you can't map the ROM in memory (except for copying/shadowing), so
you have to read it byte-wise and give the decompression routine a
callback function which will fetch the ROM contents byte-wise. That
makes the decompression a lot slower and it needs additional scratch
space. In fact, the additional scratch space requirements can be bigger
than the compressed size of the file in ROM, so there are possibly only
disadvantages of the streaming decompression method over the shadow/copy
method. Of course, the streaming LAR walk and decompression also
increases boot block size a lot.
So if the person doing the K8 port is willing to limit himself to 512
kByte ROMs on the M57SLI, he avoids all those nasty issues.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/