VIA has produced a wide range of chipsets, including southbridges and single-chip solutions, many of which feature their own versions of IDE and SATA controllers. In addition to these integrated solutions, VIA also released a few standalone SATA controllers. Since the introduction of SATA, VIA has experimented with various design approaches, often without a consistent pattern. This inconsistency is reflected in the varying levels of support across operating systems and within their drivers themselves.

Nevertheless, NetBSD offers fairly good support for most of these controllers through the viaide(4) driver. However, a few models exhibited incomplete or missing functionality, falling behind in certain areas compared to their support in other BSD variants or Linux.

In recent months, I’ve worked on improving support for several VIA controllers with previously incomplete functionality.

Adding VT8261 support

This began in January with the addition of support for the VT8261 integrated SATA/IDE controller, followed by a few minor refinements later on.

VT8261 is a southbridge paired with the VN1000 northbridge, a platform that saw very limited adoption. Some VIA development boards, such as the VT8591B, occasionally surface, especially following the dissolution of Centaur Technology. Another example is the Taiwan-only Acer VN1000-AM motherboard.

Functionally, VT8261 is similar to the earlier VT8251, offering four SATA ports over two channels (primary and secondary) and one PATA channel. PATA port is present on development boards but absent from the Acer board. The PCI IDs for the SATA and PATA controllers are distinct. The PATA controller uses the typical 0x0571 PCI ID, which means identification must rely on the ISA bus. The SATA controller uses PCI ID 0x9000 in IDE mode and 0x9040 in RAID mode. To support all four SATA ports, the SATA controller must be initialized using via_chip_map(), though there are some caveats I will explain later in the section on VT8251 support improvements.

Improved VX800 support

Next, I focused on improving support for the VIA VX800 chipset, which shares the same PCI ID with the CX700, CX700M, CX700M2, and VX700 chipsets. All of these are single-chip solutions that integrate both the northbridge and southbridge into a single package, referred to by VIA as a Media System Processor (MSP).

This chipset differs from others in that it supports two SATA ports on one channel and one PATA port on the second channel, both sharing the same PCI ID (0x5324 in IDE mode, 0x0581 in RAID mode). The initial implementation reused initialization code from the VT6421(A/L), which incidentally worked for the SATA ports, but failed to detect PATA drives. It also produced errors, as this chipset doesn’t use BAR(5) to map SATA registers in comparison to VT6421 and few other older VIA SATA controllers.

Getting this chipset fully functional took significant effort. I experimented with several more complex approaches that handled SATA and PATA channel initialization separately. However, the final solution was suggested to me to simply use via_chip_map() again. For this controller, it turned out to work right out of the box for both channels.

VIA V-RAID improvements

Most VIA SATA controllers support software RAID, known as VIA V-RAID, and typically include management firmware. This mode is enabled by switching the controller to RAID mode in the BIOS. Almost all VIA SATA controllers support this feature, provided the BIOS includes a RAID option. On add-in cards like the VT6421, RAID mode is always active if a firmware chip is installed. The IDE-only VT6410 controller also supports V-RAID.

NetBSD provides support for VIA V-RAID through the ataraid(4) driver. However, V-RAID is rarely used today, as RAIDframe is the preferred method for creating software RAID in NetBSD. Unlike vendor-specific implementations, RAIDframe is controller-independent. Still, NetBSD continues to provide both options, and ataraid(4) remains compatible with VIA’s implementation.

While working on VX800, I began testing V-RAID and quickly encountered an issue: the driver was indexing disks by channel. On controllers that have two disks per channel (CX700/VX700/VX800/VT8251/VT8261/VX900/VX11/VT6410), this led to overwriting one disk entry and triggered a separate ataraid(4) bug that caused a crash when RAID disks were missing.

To resolve this, I modified the code to use the disk index stored in the V-RAID metadata instead. This ensures consistent indexing that matches what the firmware assigns. As a result, I also fixed the crash issue, improving error handling for missing RAID disks, which works for other vendor RAID formats as well.

Finally, I added the check for the VT6421 controller’s RAID capability, enabling ataraid(4) on this hardware.

Further improvements, such as support for spare disks, may be needed in the future, but these are currently a low priority.

VT8237S UDMA mode fix

The VT8237S is another classic VIA southbridge, featuring two SATA ports, each on its own channel, and two PATA ports across separate channels. SATA functionality is properly supported in both IDE and RAID modes, using PCI IDs 0x5372 and 0x7372 respectively.

However, the PATA controller shares the common 0x0571 PCI ID, so identifying its UDMA capability requires checking the ISA bus. By default, NetBSD disables UDMA if the ISA bus is not recognized. The fix was straightforward: adding the VT8237S to the identification list, which allows PATA drives to operate at full speed. This fix is likely needed for OpenBSD as well.

VT6415 IDE support implementation

The VIA VT6415 controller is quite different from other VIA storage controllers. It is a single-channel (one-port) PCIe IDE controller. A related variant, the VT6330, combines this controller with a FireWire interface. It was used in some motherboards to provide a legacy PATA interface, as well as in at least one known standalone PCI card.

Unlike other VIA controllers, the VT6415 uses an undocumented and non-standard register layout, which made support more complex than it might initially seem. It required introducing a new flag to handle single-channel operation, since all other VIA controllers have two channels, as well as another flag to simulate the channel enable bit, whose location is still unknown.

While working on VT6415 support, I also implemented several general improvements, including a more accurate RAID capability check and better controller identification logic.

Bringing up RAID Mode on VX900

The VIA VX900 is one of the latest VIA Media System Processors (MSPs), followed only by the VX11, not counting the Zhaoxin derivatives and the unreleased Centaur CNS platform. Both the VX900 and VX11 appear to use the same PCI IDs for their SATA controllers.

Unlike earlier chipsets, the VX900 supports only two SATA ports, each on its own channel, and has no PATA support. IDE mode (PCI ID 0x9001) has been supported in NetBSD for some time. However, very few motherboards support RAID mode (PCI ID 0x9041). One exception is the ECS VX900-I , which I managed to track down.

The RAID firmware on this board differs from earlier implementations in that it does not include an option to configure RAID volumes. Instead, it requires separate software, likely Windows-based. However, it does detect and boot from preconfigured arrays correctly.

Adding support for this controller was straightforward, but having access to real hardware allowed me to confirm the PCI ID and verify RAID functionality directly.

VT8251 IDE/RAID mode functionality

I saved work on the VT8251 southbridge for last, and with good reason. Alongside the rare VT8261, it is one of only two VIA southbridges that support four SATA ports across two channels. In addition, it provides two PATA ports, comes in two revisions (CD and CE) with subtle behavioral differences, and operates in three modes: IDE, RAID, and AHCI.

The VT8251 was likely the final VIA southbridge to be paired not only with VIA platforms, but also with Intel and AMD systems. As a result, it saw moderate adoption in early AMD K8 and Intel Core 2 Duo motherboards, and was also used in a few VIA CPU-based boards, most notably the VIA EPIA-SN.

From old bug report, I already knew there were issues in IDE and RAID modes. AHCI mode appears to work reliably, but it is handled by a separate driver, ahcisata(4). I initially tested the controller on an ASUS A8V-VM (Socket 939, AMD Athlon64), which uses the older CD revision. This board reported PCI ID 0x3349 in all three modes (IDE, RAID, and AHCI), which surprised me at first since other IDs had been reported elsewhere.

Further investigation revealed that the newer CE revision uses different PCI IDs for each mode: 0x5287 for IDE, 0x6287 for AHCI, and 0x3349 (same as CD) for RAID mode. The PATA controller still uses the standard 0x0571 PCI ID. However, some buggy BIOSes appear to misassign 0x5287 to the PATA controller. If such systems are still in use, handling them properly would be difficult, although likely possible by checking whether the controller is attached as function 1.

I later found an MSI MS-7318 motherboard that uses the CE revision, and in this case, the board was equipped with even less common VT8251L-marked southbridge. This allowed me to test both hardware revisions directly.

Initial testing confirmed that the previously reported issues were still present. Only the first SATA port was detecting a hard disk. BAR(5) was using a “32-bit non-prefetchable memory” type instead of an I/O address, which caused failures when mapping the controller registers. If no drive was attached to the first port, a bogus device would appear. Connecting drives to the other ports could lead to timeouts or other errors.

The first attempt to simply use the via_chip_map() function brought partial improvement. The bogus device no longer appeared, and most ports were able to detect drives. However, new issues were observed. For example, connecting certain drives to the fourth port could cause timeouts. Using any port on the second channel (ports 3 or 4) would cause PATA drives to disappear, regardless of which channel they were on. These behaviors occurred consistently across both the CD and CE revisions.

Interestingly, the same hardware worked without issue under OpenBSD, which uses a very similar driver. At one point I considered committing the partial fix, since it slightly improved the situation. However, after further investigation, I identified the root cause. Some registers are shared between the SATA and IDE controllers, and NetBSD’s ATA channel setup code was writing to an offset that only made sense for the PATA controller. On the SATA controller, that offset had a different function, which led to these problems.

To fix this, I switched SATA controller initialization to use the dedicated SATA channel setup path. This resolved the issues for VT8251 and also applies to VT8261, which is affected in the same way. I included VX900 as well, since it could potentially be impacted even though it does not include a PATA controller.

With these changes, all drives could finally be detected and used reliably in both IDE and RAID modes.

For AHCI support, the CE revision needed to be added to the quirk list. The CD revision had also been misidentified as a VT8237R in AHCI mode, so I corrected the name to reflect its actual configuration.

VT6410 add-in cards and missing enable bits

The VIA VT6410 is an older IDE-only controller, supporting two PATA ports (up to four drives total). It is the only VIA PATA controller known to support RAID functionality. While it was sometimes integrated directly onto motherboards, standalone PCI cards based on this controller were also available. Onboard versions typically included BIOS support with RAID firmware, while add-in cards were often ROM-less, even though they still reported themselves as RAID-capable.

During work on the VT6415, I looked into OpenBSD and Linux implementations, which treat both VT6410 and VT6415 as lacking functional channel enable bits at register offset 0x40. To handle this, those drivers simulate the presence of the bits to ensure proper configuration. However, the underlying reasons for the missing bits differ between the two controllers.

The VT6415 is a single-channel PCIe IDE controller that appears to use a different and undocumented register layout compared to most other VIA controllers. It lacks the standard enable bits, or they may be located elsewhere. Fortunately, the channel is enabled by default, and simulating the bits is enough to convince the driver to proceed with configuration.

The VT6410, on the other hand, uses a more traditional register structure. Although documentation is unavailable, comparing PCI register dumps reveals that it does include the enable bits in the expected location. However, on add-in PCI cards, these bits are set to 00, effectively disabling the channels. On soldered versions found on motherboards, they are set correctly to 11.

Simply simulating the bits, as done for VT6415, gives the appearance that the channels are being configured. In reality, however, no drives are attached because the hardware remains disabled. The correct fix was to explicitly set the enable bits to 11, which properly activates the channels and allows drives to be detected and initialized.

Final notes

This concludes my major work on VIA IDE/SATA controllers for the time being. It has been an interesting and rewarding personal experience. I believe these improvements bring NetBSD on par with other major operating systems and even fix a few issues that others have missed so far.

There are still a few things left to improve, such as setting proper link speed for SATA ports (at least as I currently understand it), testing resume support, and refining certain RAID features. However, given the largely obsolete nature of this hardware today, these tasks may be of lower priority. That said, at least the basic support is now in place.

Most of the changes have been applied or will be applied to the NetBSD 10 and 9 branches. They should be available in the next point releases, or can be tested now using the latest branch builds from https://nycdn.netbsd.org/ for those who are impatient.

I did not test the VT8237A at all during this work, as I do not have the hardware. However, it is quite similar to other VT8237 variants (R and S), so I do not expect any surprises in functionality. It should work as expected.

The VX855 chipset was also untested. I expect it to work, but it differs from other VIA solutions by having two PATA channels, with one sometimes repurposed for a SATA port via an IDE–SATA bridge.

One more major task on my list is adding VT6421A controller support on cardbus(4) someday. This is a bit more complex to implement correctly, so, as usual, no promises on when or if that will happen.

I would like to give special credit to the https://dmesgd.nycbug.org/, https://linux-hardware.org/ and https://bsd-hardware.info/ projects, which were extremely helpful in gathering information on hardware I do not personally own.

I encourage everyone to check these sites and contribute their hardware data if possible. It really makes a difference. I also plan to contribute more actively myself.

It would be great to see a community project focused on collecting PCI register dumps. Just an idea for anyone interested. This kind of resource would offer valuable insight and could reduce the need to obtain physical hardware for testing.

Another project worth mentioning is https://theretroweb.com/, which has been very useful for identifying motherboards and cards using specific hardware and locating its documentation. For datasheets and legacy documentation, https://bitsavers.trailing-edge.com/ has been absolutely essential, particularly for VIA-related material. Finally, https://pci-ids.ucw.cz/ is also an important resource for documenting and easily looking up PCI IDs. Please consider supporting these projects and contributing your own hardware where possible.

Of course, special thanks go to the NetBSD project and its developers for reviewing my code and providing valuable advice.