IBM eServer z990 improvements in firmware simulation

IBM Journal of Research and Development, May-Jul 2004 by Stetter, M, Buttlar, J von, Chan, P T, Decker, D, Et al

* Power-on reset (firmware load) tests.

* Basic initialization, i.e., channel emulator/control unit emulator.

* Basic initialization with multiple channel subsystems (MCSS) [7].

* Shared/dedicated HiperSockets channels.

* Linux initial program load (IPL): Linux booting tests.

* HiperSockets firmware interaction with Linux booting.

* From the command line: ifconfig hsiO:0 10.1.1.1 up or ifconfig hsiO:0 down

* Tests multipath channel (MPC) handshake.

* Tests the system of control tables.

* With a simple shell script program, the "up" and "down" commands such as those in the preceding example can be "chained" to exercise multiple control table changes.

* A simple ping command such asking -c 100 -I asi.-0 10.1.1.4 tests data transfer and its control by configuration tables held in the background, including MCSS tests.

* ping -b -I hsi0 10.1.1.255 tests broadcast data transfer, ping -I hsi0 2240.0.7 tests multicast data transfer, and ping -f -b -I hsi0 -s 4096 10.1.1.255 is a broadcast transfer of large packets (4096 bytes).

* More tests can be created by programming to the standard socket interface.

* Interaction tests: While one logical partition is sending out data packets for transmission, another partition is adding or deleting devices. This tests the locking mechanisms that are implemented to avoid race conditions.

* Dynamic configuration changes: E.g., rebooting Linux while other partitions are still transmitting data.

* Error recovery: Critical entries in control tables are intentionally changed to invalid, invoking system recovery.

* Testing HiperSockets first error data capture (FEDC) [8]; i.e., gathering the HiperSockets data in case of an error.

* Testing the full FEDC path, including FEDC data analysis tools.

* Special functional features such as multicast routing and Virtual Local Area Network (VLAN).

* HiperSockets firmware interaction with surrounding firmware:

* Configure on/off.

* Re-IPL of Linux.

* Shut down Linux.

Since Linux standard functions and components can be used, these tests are easy to program and do not require a special test environment or test-case syntax; thanks to CECSIM, they can be performed before a real system is available. After testing with Linux on CECSIM, only subtle errors such as critical timing conditions or errors in the interaction with other operating systems (z/VM*, z/OS*) remained to be solved by tests on the real system (estimated to be 20% of the overall problem count), since most of the basic kinds of errors had previously been eliminated. The advantages for faster system qualification and enhanced quality are evident.

OSA-Exprees simulation

Open Systems Adapter-Express (OSA-Express, [9]) is one type of zSeries I/O channel that provides a network interface to the system. The firmware is executed in an embedded environment running on a RISC-based processor. It utilizes a real-time operating system (OS Open) to support various services such as queuing, threading, and timers. OS Open provides a scalable runtime and development environment for embedded systems running on PowerPC* processors.

 

BNET TalkbackShare your ideas and expertise on this topic

Please add your comment:

  1. You are currently: a Guest |
  2.  

Basic HTML tags that work in comments are: bold (<b></b>), italic (<i></i>), underline (<u></u>), and hyperlink (<a href></a)

advertisement
Click Here
advertisement
  • Click Here
  • Click Here
  • Click Here
advertisement

Content provided in partnership with ProQuest