| VIA P4PM800Pro and new source. |
[Sep. 6th, 2005|10:22 am]
Luc Verhaegen
|
| [ | mood |
| |  indifferent | ] |
| [ | music |
| | Kaiser Chiefs - Everyday i love you less and less. | ] |
VIA made another press release recently; the "release" of VIA P4PM800Pro. The slightly more desktop oriented version of the "VN800". But VIA wants you, or mainly its investors, to believe that this one is truly different from the VN800. The list of unichrome based northbridges for intel then becomes:
PM800, PN800, PM880, P4M800 and now the P4M800Pro. Add CN400 and VN800 to that mix, and there's a slight chance for confusion there. Luckily the info at http://www.via.com.tw/en/products/chipsets/ is there to help everyone figure out which is which and what the differences are supposed to be...
New source has been made available. A quick peek reveals the following:
- The VN800 and P4M800Pro are apparently also known as CN700 (download page) and CN900 (source). I'm not surprised.
- The VN800 and P4M800Pro unichromes are indeed a new pci id: the VT3314 which has 0x1106:0x3344. This makes the VIA unichrome naming scheme totally bogus, in as far as it wasn't already. Initially, the driver named the different devices like the whole northbridge chip, namely CLE266, KM400 and K8M800. Marketingwise, the CLE266 unichrome was first named castlerock. With the advent of the KM400, this became unichrome. At some point, when the K8M800 actually came into existence, the unichrome implementation there was named Unichrome Pro. When the CN400 and the untrackable P?M8??s were released, they became Unichrome Pro A, while the K8M800 was demoted to Unichrome Pro B. I've come to accept that sort of logic as something cultural, something inherently taiwanese. Where this new unichrome will sit, i don't know, I'll just end up using VT3xxx; VT3122 for CLE266, VT3205 for KM400, VT3204 for K8M800, VT3259 for CN400 and the P?M8??s and now VT3314. This is quite abstract, but it'll probably be the only thing that will ever make sense in this typical VIA mess.
- There seem to be a VT3259 and a VT3259Lite, the difference being that one does support TV-out and capture and the Lite doesn't. But this is according to the comment there. My gut tells me that it means that it'll only support a single TV-encoder (through one DVP port) instead of two (through the other DVP port). I expect that the one that's multiplexed on the AGP bus is kept and the other dropped. This "Lite"ness can be detected through a bit slightly beyond the standard pci config header of the device sitting at 00:00:02... Quite amazing, since the unichrome usually is the AGP device at 01:00:00. I somehow expect CN400 to be the normal version and P?M8?? to be Lite although i'm not sure if i should expect such a logical division.
- Finally the long promised MIT disclaimer change has been largely pushed through, although the 12 headers in include/close/ still carry it. How VIA can still claim that it has fully free drivers, when its source clearly marks certain bits as closed, is beyond me. The libddmpeg blob is still sitting there.
Overal there's a reasonable amount of changes here, but, as has been the case for ages now, nothing can be immediately backported to the unichrome.sf.net driver. Tweezer work as usual, on an as needed basis, when the hardware is available. |
|
Nope completely lost now.