![[Prev]](../../../jdc/graphics/prev.png "Previous")
![[==]](../../../jdc/graphics/blank.png){kind=spacer}
![[Up]](../../../jdc/graphics/go_up.png "Up")
04 September 2026: Looking at the V245 (with a U45 and SB2500-S side trip)
After looking at the missing drivers for the U45, I thought that it made sense to look at the similar era Fire V245. The V245 has no pcf8584-compatible I²C controller, but one Fire/MI2C controller connecting all the I²C devices. It also has a LSI SAS1064 controller with Integrated RAID (IR) support for the internal disks.
At attach time, the SAS1064 controller printed:
[ 1.000000] mpt2: Unknown async event: 0xb000000
and we had no way to view the RAID mirror that I had set up at the OFW prompt. Searching online and from comments that we did support IR on amd64, I looked at our code. The initial problem was easy - we failed to byte swap this message when printing the error, so it was really 0x0b. According to the LSI Fusion MPT 2.0 documentation, 0x0b is the value for a message from the IR subsystem. Adding the IR definitions and parsing them meant that we can now see:
[ 1.000000] mpt2: Integrated RAID Event: volume 0 status: optimal, enabled
in the normal case, or:
[ 1.000000] mpt2: Integrated RAID Event: volume 0 status: degraded, enabled, resyncing
when I caused a rebuild by removing and re-inserting one disk of the pair whilst looking for which GPIO's showed the disk indicator lights. In order to access the IR information, we also need to add the bio device to the kernel configuration and devices.
Finding all the monitoring devices was somewhat more complicated. From the ADT7462 driver, I could only see 4 measured temperatures and 5 measured voltages, where I also expected to see measured fan speeds. As an aside, the GPIO functionality of the chip is enabled on the V245, with 3 pins configured as input and 1 as output, but I still don't know what they are connected to. That left the other unknown devices on the I²C bus to try. Like the U45, there is an LM95221 at address 0x2b, and I guessed that there might be a second ADT7462 at address 0x2e. However, testing for that caused one of the power distribution board fans to report as failed. At least I knew what was connected to this device! Looking at the register dump showed that it was a ADT7475 chip, which is already supported by the dbcool driver, and only needed a small change to the match list. Other likely candidates for information were the EEPROM's and GPIO's for the PSU's (with the EEPROM's incorrectly named as at34c02 like on the U45) plus unknown devices at addresses 0x22, 0x40 and 0x5e.
The devices at addresses 0x22 and 0x40 seemed like PCA9555 chips based on the contents of their first 4 registers. The chip at address 0x5e had registers fron 0x00 to 0x3c and didn't match any documented device. On the V240, removing disks caused pins on a PCA9555 to change state. Trying this on the V245 showed that the PCA9555 at address 0x22 was connected to the disk status indicator. (This is where I inadvertently caused a RAID rebuild, but at least I got to see a different IR message!) Also easy to test was turning the locator on and off, altering the virtual keyswitch, and turning the PSU's on and off. Registers on the chip at address 0x5e represented the keyswitch and the locator LED, and the PCF8574 GPIO's at addresses 0x3e and 0x3f were the PSU status indicators. When a PSU is switched on or off, 3 pins on the status indicators change, and the ALOM reports three AC and DC statuses, but I didn't know which is which, so settled for reporting a single indicator. Whilst looking further, I added the known information and then realised that I had the disk names showing in reverse order. The PCA9555/PCA9556 driver needed additions for displaying indicators in sysmon, but that was easy to take from the PCF8574 driver.
![[IMG_3147]](IMG_3147-small.jpeg "Sun Blade 2500 Silver. 03 September 2026.")
Around this time, I received a Sun Blade 2500 Silver, which has a SUNW,i2c-auxfan1 device that we didn't support. Looking at this and comparing values with those reported by Solaris, I could see that the fan speeds were reported in two of the chip registers. It was then relatively straightforward to add a driver, configuration glue and man page. The OFW changes fan speeds when the machine is powered on It wasn't obvious to me how to do that, although it might be only the CPU and system fans that change speed. Whilst comparing with Solaris output, I noticed that we showed the other fan speeds as 4x faster. With an addition to the dbcool driver, we can now set the fan divisor via a property and the fan speeds are correctly shown in envstat:
Current CritMax WarnMax WarnMin CritMin Unit
[auxfan0]
dimm-fan: 4188 RPM
[dbcool0]
local: 42.500 70.000 0.000 degC
CPU0: 68.500 90.000 -5.000 degC
CPU1: 68.750 90.000 -5.000 degC
cpu0-fan: 4218 RPM
cpu1-fan: 3668 RPM
[dbcool1]
local: 39.000 70.000 0.000 degC
sys-in: 33.250 47.000 -2.000 degC
sys-out: 47.000 72.000 -2.000 degC
Intake: 2376 RPM
Outtake: 1776 RPM
Whilst watching the register contents on the V245, I noticed that some of the values on the chip at address 0x5e were changing, but not at the time that I was doing something like removing and re-inserting the disks, or turning the PSU's on and off. I had had to guess at the fan divisor value for the auxfan driver, and working on this plus looking at the ADM1031 chip documentation for fan speed calculations gave me the clue that the changing values on the chip at address 0x5e were showing the fan speeds for the front fans.
With some more experimenting, I saw that the LED's for the disk fault and remove can be controlled by altering the values of other pins on the PCA9555 at address 0x22, and that some other front panel LED's can be lit by writing to the same register as the one controlling the locator LED on the chip at 0x5e. I started to write a driver for the chip at address 0x5e, but then I noticed that OpenBSD have an LED driver for the V245. This gave me the hint that the env-monitor device showed the same information as the I²C device at 0x5e, so I changed to writing a driver for env-monitor instead. Whilst looking at this, I realised that the env-monitor on the U45 reported some of the values from the ADT7462 and LM95221 chips, and also found the U45 front IO board temperature (register 0x0d) which I hadn't been able to find elsewhere. On the V245, I could see the 6 fan speeds (registers 0x0e to 0x13) and control some of the front LED's (register 0x06). The divisor for the fans appears to be the same as on the ADM1031. The next block of registers (0x14 to 0x19) all read 0xff, so I wondered if these were for the additional fans on the V215.
I uploaded a dmesg to NYC*BUG dmesgd and noticed that there was also a NetBSD dmesg for the V245 (and V215) from Ken Wellsch. Ken had also included envstat output and I saw from that that one of the fans in his power distribution board had failed. This led to an exchange of messages, where we discovered how to report the 12 front fan speeds for the V215 (with a different divisor) and where the disk status GPIO was on the I²C bus (at address 0x12). A nice side-affect was that Ken discoved that the fan fault had been a slightly loose cable all along. Ken was a great help, including spotting my error when we couldn't find how to control the fault and remove LED's on the V215.
![[IMG_3145]](IMG_3145-small.jpeg "Sun Fire V245 with LED's lit. 03 September 2026.")
With all the data collected, I could write a driver for the env-monitor chips and make it handle the differences between the U45 and the V215/V245. When checking for keyswitch values, I noticed that a different register changed value and realised that this was the front I/O board temperature. Also, by testing, I found that the other front panel LED's are controlled by register 0x07 and that changing the state on any LED requires setting the relevant bit in the mask register (which is hinted at in the OpenBSD driver). Also, whilst looking for temperature sensor matches versus the monitoring chips, I came to the conclusion that the remote1 and remote2 sensors on the ADT7462 chip are the CPU temperatures minus 30. This offset can be adjusted with another patch.
The final piece for the monitoring was the front fan tray fault LED's. I tried testing by writing values to the other registers but no LED's lit up. Looking again at the registers, I noticed that register 0x30 contained 0x3f. This is 6 bits set, and there are 6 fan trays. As a final resort, I opened the fan tray cover and removed fan 0. The ALOM reported a fan fault and the register changed to 0x3e. Similarly, removing fan 4 resulted in the register reading 0x2f. With this information added, the output from envstat and sysctl on my V245 now looks like:
Current CritMax WarnMax WarnMin CritMin Unit
[adt7462sm0]
MB.T_AMB: 45.500 85.000 65.000 0.000 degC
MB.P0.T_CORE: 75.250 101.000 91.000 0.000 degC
MB.P1.T_CORE: 76.000 101.000 91.000 0.000 degC
MB.T_FIRE: 49.250 100.000 95.000 0.000 degC
MB.P0.V_CORE: 1.443 1.989 0.250 V
MB.P1.V_CORE: 1.459 1.989 V
MB.V_+3V3: 3.285 4.386 V
MB.BAT.V_BAT: 3.136 3.978 1.997 V
MB.V_+12V: 12.062 15.938 V
[dbcool0]
PDB.T_DISK: 35.000 degC
PDB.T_PS0: 32.750 degC
PDB.T_PS1: 32.250 degC
Vcc: 3.369 V
PDB.HDDFB.FT6.F0: 10629 8000 RPM
PDB.HDDFB.FT6.F1: 10887 8000 RPM
[envmon0]
FT0.F0: 5113 2022 RPM
FT1.F0: 4963 2022 RPM
FT2.F0: 5037 2022 RPM
FT3.F0: 5357 2022 RPM
FT4.F0: 5273 2022 RPM
FT5.F0: 4891 2022 RPM
fan fault: 0 0 0 0 0 none
FIOB.T_AMB: 28.000 degC
keyswitch normal/diag: TRUE
keyswitch locked: FALSE
[lm95221ts0]
local: 47.750 degC
MB.T_REMOTE: 43.125 degC
MB.T_1064: 74.000 degC
[pcagpio1]
HDD 0 present: TRUE
HDD 1 present: TRUE
HDD 2 present: TRUE
HDD 3 present: TRUE
[pcf8574io0]
PSU 0 input power: TRUE
[pcf8574io1]
PSU 1 input power: TRUE
hw.led.locator = 0 hw.led.service = 0 hw.led.service_flash = 0 hw.led.power = 1 hw.led.top_fan_fault = 0 hw.led.top_fan_fault_flash = 0 hw.led.psu_fault = 0 hw.led.psu_fault_flash = 0 hw.led.cpu_overtemp = 0 hw.led.cpu_overtemp_flash = 0 hw.led.hdd0_fault = 0 hw.led.hdd0_remove = 0 hw.led.hdd1_fault = 0 hw.led.hdd1_remove = 0 hw.led.hdd2_fault = 0 hw.led.hdd2_remove = 0 hw.led.hdd3_fault = 0 hw.led.hdd3_remove = 0
With the final piece (for now?) done, I committed the envmon driver, configuration, and manual page.,
-^- More notes -^-