Specifications

AMD Geode™ GeodeROM Functional Specification 213
System Management Mode Software
32087C
15.2 GeodeROM Requirements
During POST, GeodeROM copies the VSA2 software image to a location below 640 KB, then executes a far call to the ini-
tialization code (Offset 20h). At the end of POST, GeodeROM notifies VSA2 software (via S/W SMI 5000h) so that any final
initialization can take place.
15.3 System Manager
When an SMI occurs, the processor micro-code saves minimal amount of processor state into an SMM header. The pro-
cessor is placed into real mode and execution is vectored to the physical address determined by the SMAR (SMM Address
Region) registers. VSA2 software initialization code sets these registers to the location of the System Manager entry point.
The code at the entry point:
1) Saves the CPU state not already saved by the Geode processor.
2) Initializes the processor to the SMM software environment.
3) Determines the source(s) of the SMI and enters the event(s) into message queue(s).
4) Dispatches to the VSMs that have pending messages.
5) Restores the interrupted task's state and resumes execution.
The System Manager provides the following services to VSMs:
• Manages inter-module message delivery.
• Allows chipset and/or processor dependency abstraction.
• Provides a mechanism for guarding critical sections of code.
• Handles memory allocation of stack and data segments.
• Ensures proper ordering of event handling.
15.4 Events
Events are SMIs. A VSM may register as a handler of one or more SMI event(s). This normally occurs at VSM initialization,
but dynamic registration is also allowed. Multiple VSMs may register for the same event. The order that VSMs are invoked
is determined by the priority specified at registration time. When the event occurs, the VSM registered with the highest pri-
ority for the event is invoked. If a VSM chooses to handle the event, nothing extra needs to be done. In the Geode GX1 pro-
cessor, if a VSM chooses not to handle the event, it must pass the event back to the System Manager via the
SYS_PASS_EVENT macro. The System Manager then sends a message to the next highest priority VSM, and so on until
the event is handled. In the Geode GX processor and later processors, each VSM gets the message no matter the priority,
so the SYS_PASS_EVENT macro is not needed.
15.5 Messaging
All event notification occurs via System Manager messages. The code at the entry point of each VSM is a message-
handling loop. A VSM is called only to respond to a message from the System Manager. The message queue for a VSM is
stored in the VSM header. The SYS_GET_NEXT_MSG macro is provided for accessing the message queue. When the
message queue is empty, the SYS_GET_NEXT_MSG macro automatically returns control to the System Manager. Control
is returned to the VSM when there is another message in its queue. The supported messages are enumerated in Section
15.11 “Messages” on page 225.