Contributed by marco on from the UltraSparcIII-support-for-all dept.
Within the first couple of days Jason fixed a problem with schizo(4)s iommu code that gave us a working Fibre Channel disk controller. Not much later I found out that Sun had removed a feature from the UltraSPARC III that we used in our TLB flushing code and added a workaround. That made it possible to go multiuser on the Blade 2000. But we still had some horrid hacks (such as disabling the caches) and we joked that the 900MHz Blade 2000 ran at about the same speed as a 140MHz Ultra 1. We cleaned things up a bit and committed most of the code, disabled by a HORRID_III_HACK define. Shortly after that I discovered that enabling the I-cache worked and gained us quite a bit of performance. But the D-cache had to stay disabled. And that's the state I left things when I got on my bike for a tour through beautiful British Columbia.
Shipping a Blade 2000 to Europe proved to be very costly, so I didn't have any hardware to hack on when I came home. I had enough other things to work on, but it frustrated me immensely that we were going to ship 4.0 without UltraSPARC III support. Fortunately about a week ago someone lent me a Sun Fire v210 (thanks Toine!). Finally I had hardware to hack on, but the v210 had its own problems. The onboard bge(4)s didn't work, and the putting a NIC in the machine's PCI slot didn't work either. On top of that the machine didn't even boot a kernel with 1GB of memory. Luckily Theo already had found out that if you took out half of the memory the machine booted fine. And url(4) gave me working net.
I fixed some bugs in schizo(4)'s interrupt handling code, and suddenly dc(4) in the machine's PCI slot worked too. Then I tweaked the HARRID_III_HACK a bit such that it would only disable the D-cache if we were actually running on an UltraSPARC III. This gave us a GENERIC kernel that works on UltraSPARC I, II and III. Now if I only could fix the onboard bge(4)s, I could claim we really supported the v210.
I started digging through OpenSolaris and Linux code, and found some clues that suggested that Sun tried to economize by not fitting the normal EEPROM which would contain things such as MAC addresses. Instead the MAC addresses are stored in the Open Firmware PROM. Unfortunately the missing EEPROM made some checks in our bge(4) fail and the driver wouldn't fully attach. Skipping those checks for onboard Sun chips resulted in working onboard ethernet.
So 4.0 will likely ship with preliminary UlstraSPARC III support. The D-cache is still disabled for these machines, but even without the data cache, these machines are among the fastest sparc64 machines that we currently support. There are some other limitations (vgafb(4) crashes the blade 1000/2000 due to some wierd schizo(4) hardware bug so those machines are serial console only, the v210/v240 only works if only memory bank 0 is filled). The support is included in recent snapshots, so I'd like to encourage people with the opportunity to try OpenBSD on UltraSPARC III machines to do so.
(Comments are closed)