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