NASync LED controller

I have a UGreen NASync device running FreeBSD 14.3-RELEASE.
The device has multiple hard drive LEDs can be programmed, they just blink if the OS doesn't send any instructions so I want to try that.

On Linux, there's a community tool for managing LEDs on the NASync that does exactly what I want.

Their README.md shows instructions how to read and write the LED status using commandline utilities without compiling their tool (I wansn't able to compile it due to a dependency on <linux/i2c.h> and <linux/i2c-dev.h>, which of course are not present on FreeBSD)

In the instructions, they talk to a "SMBus I801 adapter at efa0" on address 0x3a, excerpt from their README.md:
Code:
### START Copied from https://github.com/meyergru/ugreen_dxp8800_leds_controller ###

$ i2cdetect -l
i2c-0   i2c             Synopsys DesignWare I2C adapter         I2C adapter
i2c-1   smbus           SMBus I801 adapter at efa0              SMBus adapter
i2c-2   i2c             Synopsys DesignWare I2C adapter         I2C adapter

$ i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         08 -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: 30 -- -- -- -- 35 UU UU -- -- 3a -- -- -- -- --
40: -- -- -- -- 44 -- -- -- -- -- -- -- -- -- -- --
50: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

### END Copied from https://github.com/meyergru/ugreen_dxp8800_leds_controller ###

On FreeBSD, I also see one SMBus when I use the smb(4) kernel module.
Code:
kernel: ichsmb0: <Intel Alder Lake SMBus controller> port 0xefa0-0xefbf mem 0x603d1a8000-0x603d1a80ff irq 16 at device 31.4 on pci0
kernel: smbus0: <System Management Bus> on ichsmb0
kernel: smb0: <SMBus generic I/O> on smbus0
I also see two I2C when I load the iic(4) kernel module.
Code:
kernel: ig4iic0: <Intel Alder Lake-P I2C Controller-0> at device 21.0 on pci0
kernel: ig4iic0: Using MSI
kernel: iicbus0: <Philips I2C bus (ACPI-hinted)> on ig4iic0
kernel: ig4iic1: <Intel Alder Lake-P I2C Controller-1> at device 21.1 on pci0
kernel: ig4iic1: Using MSI
kernel: iicbus1: <Philips I2C bus (ACPI-hinted)> on ig4iic1
kernel: iicbus1: <unknown card> at addr 0x40

kernel: iic0: <I2C generic I/O> on iicbus0
kernel: iic1: <I2C generic I/O> on iicbus1

However, I don't detect the same 0x3a device on SMBus.
Code:
# smbmsg -f /dev/smb0 -p
Probing for devices on /dev/smb0:
Device @0x10: w
Device @0x74: rw
Device @0x88: rw
Device @0x94: rw
Device @0xa4: r

I also tried the two other SMBus-es, using the iicsmb(4) module:
Code:
kernel: iicsmb0: <SMBus over I2C bridge> on iicbus0
kernel: iicsmb1: <SMBus over I2C bridge>
kernel:  on iicbus1
kernel: smbus1: <System Management Bus> on iicsmb0
kernel: smb1: <SMBus generic I/O> on smbus1
kernel: smbus2: <System Management Bus>
kernel:  on iicsmb1
kernel: smb2: <SMBus generic I/O> on smbus2
But these busses don't help me much further either.
Code:
# smbmsg -f /dev/smb1 -p
Probing for devices on /dev/smb1:
# smbmsg -f /dev/smb2 -p
Probing for devices on /dev/smb2:
Device @0x80: r
Device @0x84: r
Device @0x98: r
Device @0x9c: r
Probing smb1 takes a long time but exits with error code 0 without more output. smb2 probing is instant. Still no expected value of 0x3a.

Also blindly sending the command to read the Power LED information (0x81) doesn't work:
Code:
# smbmsg -f /dev/smb0 -s 0x3a -c 0x81 -i 0x0b
smbmsg: Error performing SMBus IO: Device not configured
# smbmsg -f /dev/smb1 -s 0x3a -c 0x81 -i 0x0b
smbmsg: Error performing SMBus IO: Resource temporarily unavailable
# smbmsg -f /dev/smb2 -s 0x3a -c 0x81 -i 0x0b
smbmsg: Error performing SMBus IO: Device not configured

At this point I feel stuck. Am I using the correct modules and tools to do the equivalent of the instructions on Linux? What other things can I try?
 
No idea but some hardware will use a GPIO pin to enable other chips / subsystems. I'm wondering if the LED controller behind address 3A needs to be enabled.
 
There is a difference between the "SMBus I801 adapter at efa0" and the "Intel Alder Lake SMBus controller". Have you checked that the Synopsis Designware stuff show up and has drivers attached at all (in your dmesg output)?
 
Why are you not using sysutils/i2c-tools on FreeBSD to probe? That would be stop #1 for me.
SMB is just extensions to I2C right?

Like Tingo says, You should be able to isolate the /dev/iic* device if it is working.
For example boot up box with LED controller disconnected note the /dev/iic* devices present.
Reboot with LED Controller connected and note the changes, if any. Or look at dmesg.

Does the Designware driver even work on AMD64? They are mostly ARM stuff.
 
There is a difference between the "SMBus I801 adapter at efa0" and the "Intel Alder Lake SMBus controller". Have you checked that the Synopsis Designware stuff show up and has drivers attached at all (in your dmesg output)?
You're right, I don't see I801 anywhere in dmesg, but I see efa0; <Intel Alder Lake SMBus controller> port 0xefa0-0xefbf.

So am I talking to the wrong SMBus, or do I have the wrong kernel module, or both? I did try a few different ones, but this was the only combination I found that showed anything.

I don't see the Synopsys DesignWare I2C adapter anywhere in my dmesg either, instead I have:
Code:
iicbus0: <Philips I2C bus (ACPI-hinted)> on ig4iic0
iicbus1: <Philips I2C bus (ACPI-hinted)> on ig4iic1
iicbus1: <unknown card> at addr 0x40
 
Why are you not using sysutils/i2c-tools on FreeBSD to probe? That would be stop #1 for me.
SMB is just extensions to I2C right?

Like Tingo says, You should be able to isolate the /dev/iic* device if it is working.
For example boot up box with LED controller disconnected note the /dev/iic* devices present.
Reboot with LED Controller connected and note the changes, if any. Or look at dmesg.

Does the Designware driver even work on AMD64? They are mostly ARM stuff.
I tried sysutils/i2c-tools, but the description says
Only DIMM SPD decoding tool is ported at the moment.
so I don't know how to try anything useful with it.

I'm not sure I can easily disconnect the LED controller, it's was not accessible when I disassembled the device. I worked from the assumption that since there are 3 devices showing up in Linux and 3 devices in FreeBSD, they should be the same devices.

The Designware I2C adapter that showed up in the Linux tool is not used anywhere in the Linux guide, so I don't think it's related to the LEDs. Only the SMBus is used (SMBus I801 adapter at efa0).
 
I would be scanning this bus looking for 3a.
dmesg lines related to iicbus1:
Code:
iicsmb1: <SMBus over I2C bridge> on iicbus1
smbus2: <System Management Bus> on iicsmb1
smb2: <SMBus generic I/O> on smbus2
probing:
Code:
# smbmsg -f /dev/smb2 -p
Probing for devices on /dev/smb2:
Device @0x80: r
Device @0x84: r
Device @0x98: r
Device @0x9c: r

The LED stuff uses smb messages (I think, from the Linux guide), but I can also scan the same bus using i2c(8), when having the iic(4) driver loaded.

dmesg:
Code:
iic1: <I2C generic I/O> on iicbus1
probe:
Code:
# i2c -f /dev/iic1 -s -v
dev: /dev/iic1, addr: 0x39, r/w: r, offset: 0x00, width: 8, count: 1
Hardware may not support START/STOP scanning; trying less-reliable read method.
Scanning I2C devices on /dev/iic1:
40 42 4c 4e
 
I don't think you can scan the top level node of the bus though.
I would be willing to guess this is the controller. <unknown card>.

Back to yanking cord of LED controller Another good thing to look at.. Does that message still show up for iicbus1 0x40
Chasing the bus.
 
try address 0x74
Code:
# smbmsg -f /dev/smb0 -s 0x74 -c 0x81 -i 0x0b
0xb4
I would have expected an answer consisting of 11 ( -i 0x0b) bytes but I got one byte, so that's not it. Trying the other rw addresses is even worse.
Code:
# smbmsg -f /dev/smb0 -s 0x88 -c 0x81 -i 0x0b
smbmsg: Error performing SMBus IO: Input/output error
# smbmsg -f /dev/smb0 -s 0x94 -c 0x81 -i 0x0b
smbmsg: Error performing SMBus IO: Input/output error
dmesg:
Code:
kernel: ichsmb0: block read wrong length: 0

I do get an answer from the readonly address
Code:
# smbmsg -f /dev/smb0 -s 0xa4 -c 0x81 -i 0x0b
0x12 0x03 0x04 0x00 0x40 0x42 0x00 0x00 0x00 0x00 0xb0
But that answer is not from a LED; those answers have the last two bytes as checksum (must match the literal sum of the other bytes)
 
We do have a driver:
I have that module loaded already. Unloading it automatically loads it again and writes the following to dmesg:
Code:
kernel: iic0: detached
kernel: iicbus0: detached
kernel: ig4iic0: detached
kernel: pci0: <serial bus> at device 21.0 (no driver attached)
kernel: iic1: detached
kernel: iicbus1: detached
kernel: ig4iic1: detached
kernel: pci0: <serial bus> at device 21.1 (no driver attached)
kernel: ig4iic0: <Intel Alder Lake-P I2C Controller-0> mem 0x84200000-0x84200fff irq 27 at device 21.0 on pci0
kernel: ig4iic0: Using MSI
kernel: iicbus0: <Philips I2C bus (ACPI-hinted)> on ig4iic0
kernel: iic0: <I2C generic I/O> on iicbus0
kernel: ig4iic1: <Intel Alder Lake-P I2C Controller-1> mem 0x84201000-0x84201fff irq 40 at device 21.1 on pci0
kernel: ig4iic1: Using MSI
kernel: iicbus1: <Philips I2C bus (ACPI-hinted)> on ig4iic1
kernel: iicbus1: <unknown card> at addr 0x40
kernel: iic1: <I2C generic I/O> on iicbus1
There's no /dev/ig* but there is /dev/iic[01], and using iicsmb(4) I can try to talk to those as smb devices. But Synopsys DesignWare I2C were the two I was not interested in, I want to talk to the "SMBus I801 adapter at efa0"

i2c -s -f /dev/iic*SomeDevice
-s = scan
Ah that's not sysutils/i2c-tools, i2c(8) is part of base. I already posted the output of that in #8. iic1 and smb2 are both backed by iicbus1, but using i2c(4) or smbmsg(4) return different addresses.

But again, I think this is one of the Synopsys Designware I2C devices, I want to talk to the SMBus I801 adapter.

Code:
# smbmsg -f /dev/smb2 -p
Probing for devices on /dev/smb2:
Device @0x80: r
Device @0x84: r
Device @0x98: r
Device @0x9c: r
# i2c -f /dev/iic1 -s -v
dev: /dev/iic1, addr: 0x39, r/w: r, offset: 0x00, width: 8, count: 1
Hardware may not support START/STOP scanning; trying less-reliable read method.
Scanning I2C devices on /dev/iic1:
40 42 4c 4e

(running i2c -f /dev/iic0 -s -v just hangs after the Scanning I2C devices line)
 
jornane, as covacat said, 0x74 is your device.
FreeBSD and Linux use different conventions when talking about I2C addresses, 8-bit and 7-bit.
If you do the math, 0x74 == 0x3a << 1 (or 0x3a * 2).
 
Back
Top