The boot-from-host operation downloads SDRAM configuration information, runtime parameters and runtime firmware from a local host and starts firmware execution. This method is initiated by the device bootloader after reset reset if the device has no flash memory, blank flash memory or corrupted flash memory. The method requires the bootloader aware software running on the local host to detect and service VS_HOST_ACTION messages from the device.
The INT6300™ boot-from-host method is similar to the INT6000™ method but it has an extra stage to download SDRAM configuration parameters and it uses VS_WR_MEM messages to download runtime parameters and firmware instead of VS_WR_MOD messages. The VS_WR_MEM messages write directly to SDRAM and an VS_ST_MAC message is needed to start firmware execution. Once the firmware is running, another method is used to write runtime parameters and firmware to flash memory.
The INT6300™ does not have a unique hardware address until runtime firmware starts and assigns one from the runtime parameter block. Until that time, the bootloader will accept messages addressed to 00:B0:52:00:00:01. In addition, the bootloader does not know the hardware address of the local host and so it addresses VS_HOST_ACTION messages to FF:FF:FF:FF:FF:FF; however, these messages are not transmitted over the powerline.
Figure 4.5. boot-from-host (INT6300)
INT6300 LOCAL-HOST
[01] | |
[02] |-------- VS_HOST_ACTION.IND ------->| [03]
[05] |<------- VS_HOST_ACTION.RSP --------| [04]
| |
[07] |<------- VS_SET_SDRAM.REQ ----------| [06]
[07] |-------- VS_SET_SDRAM.CNF --------->| [08]
| | [09]
[10] |<------- VS_WR_MEM.REQ -------------| [10]
[10] |-------- VS_WR_MEM.CNF ------------>| [10]
[10] |<-----------------------------------| [10]
[10] |----------------------------------->| [10]
| |
[11] |<------- VS_WR_MEM.REQ -------------| [11]
[11] |-------- VS_WR_MEM.CNF ------------>| [11]
[11] |<-----------------------------------| [11]
[11] |----------------------------------->| [11]
| |
[13] |<------- VS_ST_MAC.REQ -------------| [12]
[14] |-------- VS_ST_MAC.CNF ------------>| [15]
The bootloader automatically starts after device reset and attempts to read the runtime firmware image from flash memory, write it into SDRAM and start execution. If it succeeds then normal operation begins and no further action is required. If it fails, for any reason, then the bootloader starts the boot-from-host process.
The bootloader broadcasts VS_HOST_ACTION.IND with HOST_ACTION_REQ set to 0x04 to indicate that configuration is required. The destination address is FF:FF:FF:FF:FF:FF and the source address is 00:B0:52:00:00:01 as explained above. This message is sent every 10 seconds which differs from that of other chips.
The host receives the VS_HOST_ACTION.IND message and inspects the HOST_ACTION_REQ field to determine the action requested. On a single-host system, the local host must elect to service the request or the device will not start. On a multi-host system, one of the hosts must elect to service the request of the device will not start.
The host sends a VS_HOST_ACTION.RSP message to the device to indicate an ability and willingness to service the request. The MSTATUS field is set to 0x00 for affirmative and 0x01 for negative.
The bootloader receives the VS_HOST_ACTION.RSP from the host and inspects the MSTATUS field. On affirmative response, the bootloader stops broadcasting VS_HOST_ACTION.IND and waits indefinitely for SDRAM configuration information from the host.
The host sends a VS_SET_SDRAM.REQ message to the device containing an SDRAM configuration block and the block checksum.
The bootloader receives the VS_SET_SDRAM.REQ, validates the content, initializes SDRAM parameters and sends a VS_SET_SDRAM.CNF message to the servicing host to indicate either success or failure.
The local host receives the VS_SET_SDRAM.CNF and inspects the MSTATUS field for success or failure. Assuming success, the local host waits indefinitely for further requests from the device.
The local host determines which parameter block and firmware image to download. In some cases there may be no choice. In other cases, there may be a choice between default and custom software or between current and upgraded software. This is a principle design issue to consider.
The local host downloads the firmware image to the device by sending VS_WR_MEM.REQ messages to the device and waiting for a VS_WR_MEM.CNF messages from the device after each request. Each message contains an image segment, the memory offset, the segment length and the checksum used to monitor and manage download progress. It a single transaction fails, the local host should detect it and repeat it.
The local host downloads a parameter block to the device by sending VS_WR_MEM.REQ messages to the device and waiting for a VS_WR_MEM.CNF message from the device after each request. Each message contains an image segment, the memory offset, the segment length and the checksum used to monitor and manage download progress. If a single transaction fails, the local host should detect it and repeat it.
The local host starts firmware execution by sending a VS_ST_MAC.REQ message to the device. The message contains the firmware start address.
The bootloader receives the VS_ST_MAC.REQ from the local host, validates the content.
The device sends a VS_ST_MAC.CNF message to indicate an ability or willingness to start firmware execution. The device immediately starts firmware execution which relinquishes device control to the firmware. It can take 5 to 10 seconds for the firmware to start.
The host receives the VS_ST_MAC.CNF message from the device, inspects the MSTATUS field and acts accordingly. An afffirmative indication means that the firmware will start executing on the device in 5 to 10 seconds. Once the firmware starts, future messages will contain the unique hardware address for the device.