Connecting a character LCD to the board from WD MyBook Live on AppliedMicro APM82181
Good day! The purpose of this work was to expand the capabilities of the available card from NAS Western Digital MyBook Live.
According to its characteristics, this board is not very bad:
The content of the article:
')
1. Connecting the console
2. Boot without disk
3. Compile in LEDE
4. Port management (via LuCI and console)
5. Connection to the I2C bus
6. Connecting the PCF8574 port extender
The rest is in the next part ...
Additions and comments are welcome. Go!
To work with the board, a local console connection is required (although most of the post-boot operations can also be performed via SSH). This is done simply, there is enough information on the Internet, for example, here is the WD MyBook Live UART Port .
Connection is made to the RS232 port of the computer through an RS232-UART adapter, since On the board, logic levels are within 3.3V. The default speed is 115200 baud.
The message “Apollo-3G - APM82181 Board, 2 * SATA, 1 * USB” is slightly incorrect, since there is no USB, and SATA is only one. This seems to be due to the fact that the loader is common for MyBook Live and the DUO model with two disks.
If you do not press anything in the console, it will attempt to boot from the hard disk. In our case, it is not there, so by pressing any button the download is stopped.
In the u-boot bootloader there are many possibilities for working with equipment.
The list of commands can be seen by typing help. Learn more about the bootloader here . When loading the console, you can see that u-boot offers the option of mounting the nfs file system "Type run flash_nfs to mount root filesystem over NFS". In this case, we will use another option - loading the RAM image from the TFTP server.
A server, for example TFTPD32 ( Official site ), is raised on the computer, then we set up the board. We set the local IP address and the TFTP server address (of your computer). They must be from the same subnet:
View the file names that will be requested from the TFTP server:
Note that the fdt_file variable contains the name of the device tree file, and the bootfile contains the name of the RAM disk image file with the operating system.
Names can be changed to more convenient ones like addresses with the setenv command. After setting, it is desirable to save the new values ​​of the variables in the ROM:
Thus, after a reboot or power failure, the settings will be saved. After that, we place two necessary files (if you don’t have them, then create them in the next section) on the TFTP server and type the command run net_nfs.
As you can see, two files are loaded as a result. They are placed in the specified places of RAM, the kernel is unpacked and loaded. As a result, we have a working system, in this case LEDE:
We will use LEDE as the source of the operating system for our board. This is a fork of OpenWRT and it supports the MyBook Live board. Download here: apm82181-lede . We download packages as written in the instructions:
Run the configurator:
We select “AppliedMicro APM821xx” as the system (“Target System”), “Devices which boot from SATA (NAS)” as the subsystem (“Subtarget”), “Western Digital My Book Live” . The final image (“Target Images”) must necessarily be marked ramdisk.
Packages choose at their discretion. If you save the settings in the configurator and exit it, you can start the compilation with the make command.
After the process is completed, if it has passed without errors, the necessary files can be picked up and put on the TFTP server:
So we went through the boot-up process.
I did not manage to find the scheme of this board on the Internet and in general the scheme of any device based on the APM82181 processor. Therefore, we will perform partial reverse engineering (reverse engineering), that is, guess about the connections on the board and check it. The developers of LEDE apparently partially did this, because the connected ports can be seen in the device tree or view information from the kernel:
As you can see, one port is used to enter the button, the rest to the output for control. It is clear that editing the device tree file (the file with the .dts extension) can free any function in the operating system from the functions, but this may affect the functionality of the board's functional blocks. Is that except the LED. Ports connected to this indicator can be used for their own purposes. Ports marked with a question mark, just connected to it. And LED control is available, for example, from the console.
By default, after the LEDE is loaded, the LED is green. This is how you can turn it off:
And turn blue:
If LEDE was built with a LuCI web shell, then the LEDs can be controlled from the browser.
In the System menu, go to the LED Configuration, and configure which events each specific LED color is triggered. For example, this is how a green LED will flash on incoming and outgoing network packets:
It is clear that if you use the LED ports for your needs, then the service that controls the LED (/etc/init.d/led) will not be needed and the driver too. And management can be made from a script like this:
So, it is possible to use at least three ports. I would certainly like to have more resources. You can put a port expander on these ports, connect it to the I2C software port. Then you can dial a virtually unlimited number of ports, but with low speed.
There was a number of empty seats on the board, there was a desire to check if something was diluted, which might be useful to us.
For example, near the processor, there is a footprint marked U12 for a chip with 8 legs:
Making sure that on all contacts no more than 3.3V, a digital analyzer was connected.
During the OS boot no signals were detected. Then a description of the I2C bus was added to the device tree, since it was originally missing:
It is clear that in the LEDE configuration it is also necessary to enable support for I2C in the core (kmod-i2c-core).
After compiling, updating the file on the TFTP server and rebooting, the device / dev / i2c-0 appeared.
Sending characters with the echo command:
Thus, the hardware I2C bus was detected, which greatly expanded the I / O capabilities of this board.
Judging by the location of the signals on the U12 (5 - GND, 7 - SDA, 8 - SCL), it is possible assumed ADM1032ARMZ - temperature sensor.
It's time to connect something to the I2C bus. In stocks there was a liquid-crystal indicator of 216 familiarity, each 8x5 pixels. Made in China based on HD44780 clone controller and PCF8574 port extender.
According to the description, it allows power and signal levels of both 5 and 3.3V, but the test revealed a very low image contrast with 3.3V power. Since the power supply of 5V would also lead to signal levels from 0 to 5 V, and the board is rated at 3.3, we had to make a primitive signal level converter. The I2C bus is bidirectional, a confirmation signal must come from the device, so at least there should be a bi-directional converter on the SDA lines. Very good options for schemes are described here: Coordination of logical levels of 5V and 3.3V devices . In our case was used
True transistor is different, selected from similar - BSS123.
Thus, the LCD indicator is powered by 5V (taken on the board from the SATA power connector), the power converter comes to both power supplies - 3.3 and 5V.
Now add a port extender to LEDE. We enable kernel support (Kernel modules - Other modules - kmod-gpio-pcf857x ... PCX857x, PCA967x and MAX732X I2C GPIO expanders), recompile, upload to the server, reboot.
We are looking for a driver:
We connect (0x27 - the address of our expander on the I2C bus):
Check the appearance of ports:
As you can see, a gpiochip488 port group appeared on the I2C bus with the address 0x27. Now you can add ports that will also be represented by the system, as well as those located on the processor, despite the fact that they work through the port expander:
... and so on until 495, since we have an 8-port expander available. Check their availability:
Let's set the direction of work for the conclusion:
If you need to enter, you must give the command "in". Well, check how the output works, for example, by measuring the output state with a tester or a digital analyzer. In the case of the HD447880 connected to the LCD expander, you can use the fact that the third bit of the expander controls the backlight of the indicator:
The first command turns on the backlight, the second one turns it off. In order for devices to be added during the boot process, you can include them in the device tree:
The lines after the i2cled tag replace the echo pcf8574 0x27> / sys / bus / i2c / devices / i2c-0 / new_device command.
So, the ability to transparently use I / O ports connected via an extender to the I2C bus has appeared and is being implemented in practice.
For the first part, probably enough. In the second part, unless of course there is an obvious antagonism in the comments, we will get to using the indicator to display the state of the system:
For this, the HD44780 driver was used and improved. The LCD4Linux package was connected, in which a new display driver was also written, which controls the display of the commands of the VT100 terminal, because the existing drivers did not fit.
Appearance:
According to its characteristics, this board is not very bad:
Processor: APM82181From the interfaces in the presence of SATA, a network of 100 Mbps, serial port (UART, not soldered), a place for debugging connector JTAG. There was a label with the number 4061-705086-003 REV on the board. Ah. On the other side, the number 4060-705086 is etched.
Frequency: 800 MHz
Platform: PowerPC 44x
RAM: 256 MB
ROM: 512 kV
The content of the article:
')
1. Connecting the console
2. Boot without disk
3. Compile in LEDE
4. Port management (via LuCI and console)
5. Connection to the I2C bus
6. Connecting the PCF8574 port extender
The rest is in the next part ...
Additions and comments are welcome. Go!
1. Connecting the console
To work with the board, a local console connection is required (although most of the post-boot operations can also be performed via SSH). This is done simply, there is enough information on the Internet, for example, here is the WD MyBook Live UART Port .
Wiring contacts:
Connection is made to the RS232 port of the computer through an RS232-UART adapter, since On the board, logic levels are within 3.3V. The default speed is 115200 baud.
After connecting and powering up the console, you can see messages from the u-boot bootloader:
U-Boot 2009.08-svn65645 (Oct 08 2012 - 14:36:50), Build: 0.2.5 CPU: AMCC PowerPC UNKNOWN (PVR=12c41c83) at 800 MHz (PLB=200, OPB=100, EBC=100 MHz) Bootstrap Option E - Boot ROM Location NOR/SRAM (8 bits) 32 kB I-Cache 32 kB D-Cache Board: Apollo-3G - APM82181 Board, 2*SATA, 1*USB I2C: ready DRAM: Auto calibration 256 MB FLASH: 512 kB DTT: 1 FAILED INIT Net: PHY EC1 Register: 0x2c8c ppc_4xx_eth0 Type run flash_nfs to mount root filesystem over NFS Hit any key to stop autoboot: 0 The message “Apollo-3G - APM82181 Board, 2 * SATA, 1 * USB” is slightly incorrect, since there is no USB, and SATA is only one. This seems to be due to the fact that the loader is common for MyBook Live and the DUO model with two disks.
If you do not press anything in the console, it will attempt to boot from the hard disk. In our case, it is not there, so by pressing any button the download is stopped.
2. Boot without disk
In the u-boot bootloader there are many possibilities for working with equipment.
For example, you can see all the colors of the three-color LED.
Turning off the LED (in the loader is lit in blue):
Test the three colors of the LED alternately:
ledtestoff Test the three colors of the LED alternately:
ledtest The list of commands can be seen by typing help. Learn more about the bootloader here . When loading the console, you can see that u-boot offers the option of mounting the nfs file system "Type run flash_nfs to mount root filesystem over NFS". In this case, we will use another option - loading the RAM image from the TFTP server.
A server, for example TFTPD32 ( Official site ), is raised on the computer, then we set up the board. We set the local IP address and the TFTP server address (of your computer). They must be from the same subnet:
setenv ipaddr '192.168.1.1' setenv serverip '192.168.1.10' View the file names that will be requested from the TFTP server:
=> printenv fdt_file bootfile fdt_file=apollo3g.dtb bootfile=uImage Note that the fdt_file variable contains the name of the device tree file, and the bootfile contains the name of the RAM disk image file with the operating system.
Names can be changed to more convenient ones like addresses with the setenv command. After setting, it is desirable to save the new values ​​of the variables in the ROM:
=> saveenv Saving Environment to Flash... Un-Protected 1 sectors Un-Protected 1 sectors Erasing Flash... . done Erased 1 sectors Writing to Flash... done Protected 1 sectors Protected 1 sectors Thus, after a reboot or power failure, the settings will be saved. After that, we place two necessary files (if you don’t have them, then create them in the next section) on the TFTP server and type the command run net_nfs.
=> run net_nfs
Waiting for PHY auto negotiation to complete.. done ENET Speed is 100 Mbps - FULL duplex connection (EMAC0) Using ppc_4xx_eth0 device TFTP from server 192.168.1.10; our IP address is 192.168.1.1 Filename 'uImage'. Load address: 0x1000000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# # done Bytes transferred = 6680079 (65ee0f hex) Using ppc_4xx_eth0 device TFTP from server 192.168.1.10; our IP address is 192.168.1.1 Filename 'apollo3g.dtb'. Load address: 0x1800000 Loading: ## done Bytes transferred = 16384 (4000 hex) ## Booting kernel from Legacy Image at 01000000 ... Image Name: POWERPC LEDE Linux-4.4.21 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 6680015 Bytes = 6.4 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 01800000 Booting using the fdt blob at 0x1800000 Uncompressing Kernel Image ... OK Loading Device Tree to 00ff9000, end 00ffffff ... OK As you can see, two files are loaded as a result. They are placed in the specified places of RAM, the kernel is unpacked and loaded. As a result, we have a working system, in this case LEDE:
root@lede: uname -a Linux lede 4.4.21 #0 Fri Nov 18 03:27:44 UTC 2016 ppc GNU/Linux 3. Compile in LEDE
We will use LEDE as the source of the operating system for our board. This is a fork of OpenWRT and it supports the MyBook Live board. Download here: apm82181-lede . We download packages as written in the instructions:
./scripts/feeds update -a ./scripts/feeds install -a Run the configurator:
make menuconfig We select “AppliedMicro APM821xx” as the system (“Target System”), “Devices which boot from SATA (NAS)” as the subsystem (“Subtarget”), “Western Digital My Book Live” . The final image (“Target Images”) must necessarily be marked ramdisk.
Packages choose at their discretion. If you save the settings in the configurator and exit it, you can start the compilation with the make command.
After the process is completed, if it has passed without errors, the necessary files can be picked up and put on the TFTP server:
- bin / targets / apm821xx / sata / lede-apm821xx-sata-MyBookLiveSingle-initramfs-kernel.bin file is renamed to uImage
- file build_dir / target-powerpc_464fp_musl-1.1.15 / linux-apm821xx_sata / tmp / lede-apm821xx-sata-MyBookLiveSingle-initramfs-kernel.bin.dtb is renamed to apollo3g.dtb
So we went through the boot-up process.
4. Port management (via LuCI and console)
I did not manage to find the scheme of this board on the Internet and in general the scheme of any device based on the APM82181 processor. Therefore, we will perform partial reverse engineering (reverse engineering), that is, guess about the connections on the board and check it. The developers of LEDE apparently partially did this, because the connected ports can be seen in the device tree or view information from the kernel:
I / O ports
root@lede: cat /sys/kernel/debug/gpio GPIOs 496-503, platform/4e0100000.gpio1, 4e0100000.gpio1: gpio-498 ( |Reset button ) in hi GPIOs 504-511, platform/4e0000000.gpio0, 4e0000000.gpio0: gpio-504 ( |enable EMAC PHY ) out hi gpio-505 ( |Enable Reset Button,) out lo gpio-506 ( |Power USB Core ) out hi gpio-507 ( |Power Drive Port 1 ) out hi gpio-508 ( |? ) out lo gpio-509 ( |? ) out hi gpio-510 ( |? ) out lo gpio-511 ( |Power Drive Port 0 ) out hi As you can see, one port is used to enter the button, the rest to the output for control. It is clear that editing the device tree file (the file with the .dts extension) can free any function in the operating system from the functions, but this may affect the functionality of the board's functional blocks. Is that except the LED. Ports connected to this indicator can be used for their own purposes. Ports marked with a question mark, just connected to it. And LED control is available, for example, from the console.
By default, after the LEDE is loaded, the LED is green. This is how you can turn it off:
echo 0 > /sys/class/leds/mbl\:green\:power/brightness And turn blue:
echo 1 > /sys/class/leds/mbl\:blue\:power/brightness If LEDE was built with a LuCI web shell, then the LEDs can be controlled from the browser.
Go to the IP address of the network card
In the System menu, go to the LED Configuration, and configure which events each specific LED color is triggered. For example, this is how a green LED will flash on incoming and outgoing network packets:
Network activity
It is clear that if you use the LED ports for your needs, then the service that controls the LED (/etc/init.d/led) will not be needed and the driver too. And management can be made from a script like this:
echo 1 > /sys/class/gpio/gpio508/value 5. Connection to the I2C bus
So, it is possible to use at least three ports. I would certainly like to have more resources. You can put a port expander on these ports, connect it to the I2C software port. Then you can dial a virtually unlimited number of ports, but with low speed.
There was a number of empty seats on the board, there was a desire to check if something was diluted, which might be useful to us.
For example, near the processor, there is a footprint marked U12 for a chip with 8 legs:
Soldered plume
Making sure that on all contacts no more than 3.3V, a digital analyzer was connected.
During the OS boot no signals were detected. Then a description of the I2C bus was added to the device tree, since it was originally missing:
IIC0: i2c@ef600700 { compatible = "ibm,iic"; reg = <0xef600700 0x00000014>; interrupt-parent = <&UIC0>; interrupts = <0x2 0x4>; fast-mode; #address-cells = <1>; #size-cells = <0>; }; It is clear that in the LEDE configuration it is also necessary to enable support for I2C in the core (kmod-i2c-core).
After compiling, updating the file on the TFTP server and rebooting, the device / dev / i2c-0 appeared.
root@lede: dmesg | grep i2c [ 4.816060] i2c /dev entries driver [ 4.819878] ibm-iic 4ef600700.i2c: using standard (100 kHz) mode Sending characters with the echo command:
root@lede: echo 11 > /dev/i2c-0 ash: write error: Remote I/O error A signal was detected by a digital analyzer:
Thus, the hardware I2C bus was detected, which greatly expanded the I / O capabilities of this board.
Judging by the location of the signals on the U12 (5 - GND, 7 - SDA, 8 - SCL), it is possible assumed ADM1032ARMZ - temperature sensor.
6. Connecting the PCF8574 port extender
It's time to connect something to the I2C bus. In stocks there was a liquid-crystal indicator of 216 familiarity, each 8x5 pixels. Made in China based on HD44780 clone controller and PCF8574 port extender.
LCD HD44780 16x2 I2C
According to the description, it allows power and signal levels of both 5 and 3.3V, but the test revealed a very low image contrast with 3.3V power. Since the power supply of 5V would also lead to signal levels from 0 to 5 V, and the board is rated at 3.3, we had to make a primitive signal level converter. The I2C bus is bidirectional, a confirmation signal must come from the device, so at least there should be a bi-directional converter on the SDA lines. Very good options for schemes are described here: Coordination of logical levels of 5V and 3.3V devices . In our case was used
insulated gate field effect transistor
True transistor is different, selected from similar - BSS123.
Assembled on breadboard:
Thus, the LCD indicator is powered by 5V (taken on the board from the SATA power connector), the power converter comes to both power supplies - 3.3 and 5V.
Now add a port extender to LEDE. We enable kernel support (Kernel modules - Other modules - kmod-gpio-pcf857x ... PCX857x, PCA967x and MAX732X I2C GPIO expanders), recompile, upload to the server, reboot.
We are looking for a driver:
root@lede: lsmod |grep pcf gpio_pcf857x 6128 0 We connect (0x27 - the address of our expander on the I2C bus):
root@lede: echo pcf8574 0x27 > /sys/bus/i2c/devices/i2c-0/new_device [ 218.957888] pcf857x 0-0027: probed [ 218.961321] i2c i2c-0: new_device: Instantiated device pcf8574 at 0x27 Check the appearance of ports:
root@lede: ls -l /sys/class/gpio/ --w------- 1 root root 4096 Jan 1 1970 export lrwxrwxrwx 1 root root 0 Nov 25 04:04 gpiochip488 -> ../../devices/platform/plb/plb:opb/4ef600700.i2c/i2c-0/0-0027/gpio/gpiochip488 lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip496 -> ../../devices_platform/plb/plb:opb/4e0100000.gpio1/gpio/gpiochip496 lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip504 -> ../../devices/platform/plb/plb:opb/4e0000000.gpio0/gpio/gpiochip504 --w------- 1 root root 4096 Jan 1 1970 unexport As you can see, a gpiochip488 port group appeared on the I2C bus with the address 0x27. Now you can add ports that will also be represented by the system, as well as those located on the processor, despite the fact that they work through the port expander:
root@lede: echo 488 > /sys/class/gpio/export root@lede: echo 489 > /sys/class/gpio/export root@lede: echo 490 > /sys/class/gpio/export root@lede: echo 491 > /sys/class/gpio/export ... and so on until 495, since we have an 8-port expander available. Check their availability:
root@lede: ls -l /sys/class/gpio/gpio??? lrwxrwxrwx 1 root root 0 Nov 25 04:17 /sys/class/gpio/gpio488 -> ../../devices/platform/plb/plb:opb/4ef600700.i2c/i2c-0/0-0027/gpio/gpio488 lrwxrwxrwx 1 root root 0 Nov 25 04:17 /sys/class/gpio/gpio489 -> ../../devices/platform/plb/plb:opb/4ef600700.i2c/i2c-0/0-0027/gpio/gpio489 lrwxrwxrwx 1 root root 0 Nov 25 04:17 /sys/class/gpio/gpio490 -> ../../devices/platform/plb/plb:opb/4ef600700.i2c/i2c-0/0-0027/gpio/gpio490 lrwxrwxrwx 1 root root 0 Nov 25 04:17 /sys/class/gpio/gpio491 -> ../../devices/platform/plb/plb:opb/4ef600700.i2c/i2c-0/0-0027/gpio/gpio491 Let's set the direction of work for the conclusion:
root@lede: echo out > /sys/class/gpio/gpio488/direction root@lede: echo out > /sys/class/gpio/gpio489/direction root@lede: echo out > /sys/class/gpio/gpio490/direction root@lede: echo out > /sys/class/gpio/gpio491/direction If you need to enter, you must give the command "in". Well, check how the output works, for example, by measuring the output state with a tester or a digital analyzer. In the case of the HD447880 connected to the LCD expander, you can use the fact that the third bit of the expander controls the backlight of the indicator:
root@lede: echo 1 > /sys/class/gpio/gpio491/value root@lede: echo 0 > /sys/class/gpio/gpio491/value The first command turns on the backlight, the second one turns it off. In order for devices to be added during the boot process, you can include them in the device tree:
IIC0: i2c@ef600700 { compatible = "ibm,iic"; reg = <0xef600700 0x00000014>; interrupt-parent = <&UIC0>; interrupts = <0x2 0x4>; fast-mode; #address-cells = <1>; #size-cells = <0>; /* Boot ROM is at 0x52-0x53, do not touch */ /* Unknown chip at 0x6e, not sure what it is */ i2cled: led@27{ #gpio-cells = <2>; compatible = "nxp,pcf8574"; reg = <0x27>; gpio-controller; }; }; The lines after the i2cled tag replace the echo pcf8574 0x27> / sys / bus / i2c / devices / i2c-0 / new_device command.
So, the ability to transparently use I / O ports connected via an extender to the I2C bus has appeared and is being implemented in practice.
For the first part, probably enough. In the second part, unless of course there is an obvious antagonism in the comments, we will get to using the indicator to display the state of the system:
For this, the HD44780 driver was used and improved. The LCD4Linux package was connected, in which a new display driver was also written, which controls the display of the commands of the VT100 terminal, because the existing drivers did not fit.
Source: https://habr.com/ru/post/315912/
All Articles