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

[bari]

AMD 690G would make a lot of sense if all the docs are available.

The 690G has integrated graphics along with great graphics driver 
support for Linux from AMD.

Mainboards are readily available in volume from several vendors.

The 690G chipset will also be available for years to come.

Plenty of  eager community talent available to port Coreboot.

Why aren't all the docs out yet?

-Bari

Carl-Daniel Hailfinger wrote:
> 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
>
>