Having used these devices just as storage units, and having had other things to do for a while, it is now the middle of August 2008, and one of the three disks has become filled with backup data at work and is being stored as a backup disk. Another of these devices is the one that has seen the most experimentation and use. I had not yet opened up the cases.
I downloaded the source code distribution tarball for these disks. WD has made that available as is required by the GPL. It reveals a lot of interesting and useful information. I have been looking for additional interfacing possibilities, as these units seem to be very versatile. There is the USB, and there is an internal and active serial port.
I started wondering if there were other interface busses available in this device. The forum has information about a serial connection, but that remains occupied with a console function, much the same as the Picotux devices have. However, there is indications of an I2C bus in the system, and maybe that can be hooked up to. The following sections detail my search for this I2C bus and its eventual discovery.
As per the information from a link on the forum, there is a serial port at J4, pins 1=3.3V, 2=GND, 3=Serial Data into WD, 4=serial data out of WD
Then when I opened the box, I noticed a number of other chips:
| Location | Chip | Apparent function |
| U2 | National Semiconductor 2995M | DDR terminator for DDR SRAM |
| U11 and U4 | NEXSEM NS 2114 | 300 kHz and 600 kHz Synchronous PWM controller |
| U6 | Hynix HY5DU 561622E | The DDR SRAM memory chip itself |
| U13 | TI 2022 77M | TLE 2022 Operational Amplifier |
This is beside the main chip, the Oxford Semiconductor OXE800, the VIA Network controller, and a number of power regulators. A number of positions are empty, there are indications on the PCB for several components that have been omitte.
Now, question is, is any of this of interest as far as interfacing goes? None of the above seem to be so. At least one of the PWM circuits appears to be used for setting the brightness of the LEDs on the front panel. There is also some information available on how to turn on and off at least some of these, thus potentially providing a limited number of output-only bits. However, back to the software side, we see there are references to some kind of I2C bus.
From the kernel source file i2c_oxnas_bitbash.c, we have SCL and SDA on two of the wires in the GPIO_A_DATA, identified here as
I2C_OXNAS_BITBASH_I2C_SDA_OUT
I2C_OXNAS_BITBASH_I2C_SCL_OUT
These are defined in the file i2c-oxnas-bitbash.c as:
#define I2C_OXNAS_BITBASH_I2C_SDA_OUT (1UL << (CONFIG_OXNAS_I2C_SDA)) #define I2C_OXNAS_BITBASH_I2C_SCL_OUT (1UL << (CONFIG_OXNAS_I2C_SCL))
And these CONFIG_OXNAS_I2C_SDA and CONFIG_OXNAS_I2C_SCL are then found in:
./arch/arm/configs/oxnas_testbrd_defconfig:
CONFIG_OXNAS_I2C_SDA=25
CONFIG_OXNAS_I2C_SCL=27
./arch/arm/configs/oxnas_defconfig:
CONFIG_OXNAS_I2C_SDA=2
CONFIG_OXNAS_I2C_SCL=3
./arch/arm/configs/oxnas_wd2nc_defconfig:
CONFIG_OXNAS_I2C_SDA=2
CONFIG_OXNAS_I2C_SCL=3
which puts them at port GPIO A, bits 2 and 3, or bits 25 and 27 in some test device. Presumably it is the oxnas_wd2nc_defconfig that applies here. But really, this in itself just shows that there is some I2C bus out and about.
As there is one, presumably there is some device that is is being used for. Chances are it is something not internal to the OXE800, since anything there would have had a direct access interface to it -- so there might be other clues in the OS.
There's thus the question of where these are to be found, physically. But looking for modules connected, indicates that this is used for something called M41RT00 -- apparently a real-time clock.
------- lsmod gives: ------ Module Size Used by Not tainted power_button 3584 0 nls_cp437 5632 0 usb_storage 32772 0 ehci_oxnas 28712 0 usbcore 114532 3 usb_storage,ehci_oxnas i2c_oxnas_bitbash 2464 0 i2c_algo_bit 8744 1 i2c_oxnas_bitbash m41t00 3972 0 i2c_core 17488 2 i2c_algo_bit,m41t00 wdc_fan 3052 0 wdc_leds 9824 0 ---- end of lsmod ----
The file /vendor/linux-kernel/drivers/i2c/chips/m41t00.c contains the indication that this is a RTC, and there is a reference to a chip with this name for this purpose. Maybe one of the chips listed above has a different function?
At bus address 0x68, that is, the I2C 4+3 bit slave address it uses is 1101 000. This does not collide with any of the chips I'd like to connect, for example, the PCF8591 AD/DA, the DS1621 and other temperature sensors all go on 1001 xxx (0x48-0x4F) and the PCF8574 goes on 0100 xxx (0x20-0x27).
Next question is, which chip would this be? If we can locate the physical chip and figure out which of its pins are the SCL, SDA and GND connections then there we go!
Maybe one of the devices that looked like transistors is one of these? ...
I downloaded the data-sheet for the m41t00. Its slave address is 1101000 (0x68) as expected.
And, this chip is an 8-pin SOIC, and does not look like a transistor. It is supposed to have the following pin assignment:
1 - OSCI 2 - OSCOUT 3 - VBat 4 - VSS 5 - SDA 6 - SCL 7 - FT/OUT 8 - VCC
There should be a 32768 Hz crystal connected between pins 1 and 2. Pin 7 is some multifunction input/output line.
There are 8 addresses in the device as per that data-sheet, so reading register 0 should give us seconds and 10 seconds, while register 1 gives us minutes and 10 minutes both in BCD format.
Let's try!
First, there must be a device-driver for this somewhere. It is likely a module, but doesn't seem to be referenced in /proc/devices, where major numbers are listed. This is usually 89. Try finding and loading i2c-dev and see what happens then:
--------- # cd /lib/modules/2.6.17.4/kernel/drivers/i2c # insmod i2c-dev.ko # grep i2c /proc/devices 89 i2c # ------
OK. Now we have to get the device right. Major number is 89, name would be something along the lines of /dev/i2c-something but what about the minor number?
kernel Documentation/i2c/dev-interface has the following tips: Look in /sys/class/i2c-dev and see what is there. That bus-number will be the minor number and also the device name.
Here we have a reference to one called "i2c-0", thus the device then becomes /dev/i2c-0 as follows:
------ # ls -l /sys/class/i2c-dev total 0 drwxr-xr-x 2 root root 0 Aug 14 18:27 i2c-0 # ls -l /dev/i2* /dev/i2*: No such file or directory # mknod /dev/i2c-0 c 89 0 # ls -l /dev/i2* crw-r--r-- 1 root root 89, 0 Aug 14 18:29 /dev/i2c-0 # chmod 666 /dev/i2c-0 # ls -l /dev/i2* crw-rw-rw- 1 root root 89, 0 Aug 14 18:29 /dev/i2c-0 # ------
The minor number has nothing to do with the device bus address, only with the host interface channel number. This is like what the HP-UX system on the HP9000-300 called "raw" devices, these being freely addressable. Very nice.
The documentation has an example of accessing a device, let's try that on the RTC chip which might be present, and see what happens.
Now, I can open and set ioctl slave address OK, but reading just gives 0xFFFFFFFF which suggests something is amiss. All registers 0-6 which should be various times, are not there?
Errno comes out 1, EPERM - operation not permitted on the read register commands.
Now what ??
Same result on slave address 0x58 which should refer to an unused address -- it is as if there's nothing out there!
Changing the slave address between 0x58 and 0x68 doesn't help. The big question is, since there were vacant spots on the circuit board, maybe this chip has been removed because there is an RTC present somewhere else in the system?
So I go and open the case again.
Another inspection of the PCB reveals vacant spots where a crystal X2 should have been. Two other crystals, X1, and X3 are present however, and no other missing crystals are immediately apparent. This crystal connects to pins 1 and 2 of whatever chip would have been at postion U9. That position, as well as U12, are also missing. both would have been SO-8 packages. U9 Pin 4 is ground; U9 pins 5 and 6 seem to come from somewere else on the board, the traces emerge from vias someplace near the OXE800... which is BGA and thus not feasible to peek underneath... But the fact that U9 is of the correct shape, has a connection according to the data sheet to what would have been a crystal, and has the two digital lines coming in on the two pins known as SDA and SCL; all this makes it a very strong candidate for the missing RTC.
Pins 3 and 7 all connect to some other nonexistent components. Pin 8 is presumably the 3.3V power line.
WD probably omitted this chip because they replaced the RTC function with the NTP (Network Time Protocol) that obtains the date and time from the Internet. I noticed that the start-up time for a unit that is not connected to the Internet is very much longer -- and looking at the serial-port information shows that it is waiting for an NTP server to tell it the time. Thus no need for the chip and associated crystal and battery (and as I later found out, voltage regulator) and the savings on the manufacturing costs. Still, I am very thankful for them leaving the sofware hooks in place however!
So I've tried: connecting U9 pins 4, 5, 6, and 8 to an external DS1621, as follows:
| U9 pin | Function | DS1621 pin |
| 4 | GND | 4,5,6,7 |
| 8 | Vdd | 8 |
| 5 | SDA | 1 |
| 6 | SCL | 2 |
| NC | 3 |
On powering up, it turns out that the pin 8 of U9 is not VCC, as the 3.3V voltage regulator driving this point is likely also omitted. Pin 8 comes up floating, but the two signal lines, SDA and SCL, show 3.3V on them. So I borrowed the 3.3V power from the serial connectior, that I had connected wires for at the same time.
With pins 5,6, and 7 at GND, the DS 1621 has slave address 1001000 = 0x48, so I tried the same SMBUS-based program as I have used earlier with the Picotux...
And lo and behol: YES! We are on!
The freshly powered-on DS1621 is reading 196, which is what it does before its configuration for continual action is run....
I then copied across the ds16 program that I've earlier made for the Picotux using the I2C subsystem there, which is nearly the same as the one here, and it shows the temperature of the device. Heating the DS1621 in my hand makes it report temperatures rising from 24 to 28.5 degrees, then it reports slowly going back down towards 24 degrees, room temperature
Hence, from all the above, it is possible to connect to the I2C bus from within the WD WorldBook -- with proper care for ESD and signals. Now that the signals are known I have made a little circuit board with level-translators for the serial port and the I2C port, so other external devices can be safely connected.
Inside the case, above the disk and controller assembly, there is space for a circuit board, about 4 cm wide and 13 cm long, with three mounting points. The serial level shifter is a standard ST3232 circuit connection, the I2C level translater uses N-channel MOS transistors, as per an application note from Philips discussing level-shifting.
I have assembled and tested this and it works for telling a PCF8574 running on 5V driving 8 LEDs to turn them on or off individually, from the 3.3V controller in the WD book. (and the equivalent, nearly identical arrangement needed for a Picotux.) Pictures and schematics to follow.
Continue to On using the I2C interface
Go back to Initial observations
Go back to Western Digital MyBook World Edition index page
Go up to the index page