Filter
Top Products
Intel
®
82575EB Gigabit Ethernet Controller — Software-Firmware Synchronization -
SW_FW_SYNC (05B5Ch; R/WS)
Intel
®
82575EB Gigabit Ethernet Controller 324632-003
Software Developer’s Manual and EEPROM Guide Revision: 2.1
414 January 2011
Software and firmware synchronize accesses to shared resources in the 82575 through a semaphore
mechanism and a shared configuration register. The SWESMBI bit in the Software Semaphore Register
(SWSM) and the EEP_FW_semaphore bit in the Firmware Semaphore Register (FWSM) serve as a
semaphore mechanism between software and firmware. Once software or firmware takes control over
the semaphore, it might access the Software-Firmware Synchronization Register (SW_FW_SYNC) and
claim ownership of a specific resource. The Software-Firmware Synchronization Register includes pairs
of bits (one owned by software and the other by firmware), where each pair of bits control a different
resource. A resource is owned by software or firmware when the respective bit is set. Note that
programmers cannot set both bits in a pair set at the same time.
When software or firmware gains control over the Software-Firmware Synchronization Register, it
checks if a certain resource is owned by the other (the bit is set). If not, it might set its bits for that
resource, taking ownership of the resource. The same process (claiming the semaphore and accessing
the Software-Firmware Synchronization Register) is done when a resource is freed up.
The following example shows how software can use this mechanism to own a resource (firmware
accesses are done in an analogous manner):
1. Software takes control over the software/firmware semaphore
a. Software writes a 1b to the SWESMBI bit in the Software Semaphore Register (SWSM)
b. Software then reads the SWESMBI. If set, software owns the semaphore. If cleared, this is an
indication that firmware currently owns the semaphore. Software should retry the previous step
after some delay.
2. Software reads the Software-Firmware Synchronization Register (SW_FW_SYNC) and checks the
firmware bit in the pair of bits that control the resource is requests to own.
a. If the bit is cleared (firmware does not own the resource), software sets the software bit in the
pair of bits that control the resource is requests to own.
b. If the bit is set (firmware owns the resource), go to step 4.
3. Software releases the software/firmware semaphore by clearing the SWESMBI bit in the Software
Semaphore Register (SWSM).
4. Software did not succeed in owning the resource (continued from step 2b) - software repeats the
process after some delay.
The following example shows how software can use this mechanism to release a resource (firmware
accesses are done in an analogous manner):
1. Software takes control over the software/firmware semaphore
a. Software writes a 1b to the SWESMBI bit in the Software Semaphore Register (SWSM).
b. Software then reads the SWESMBI bit. If set, software owns the semaphore. If cleared, this is
an indication that firmware currently owns the semaphore. software should retry the previous
step after some delay.
2. Software writes a 0b to the software bit in the pair of bits that control the resource is requests to
release.
3. Software releases the software/firmware semaphore by clearing the SWESMBI bit in the Software
Semaphore Register (SWSM).
4. Software waits some delay before attempting to control the semaphore again
Note: There are distinct bits for each PHY port.