The INT6400™ boot-from-host operation downloads and executes a memory configuration applet then downloads runtime parameters and firmware from a local host and starts firmware execution. This method is initiated by the INT6400™ bootloader after reset on a device having no flash memory, blank flash memory or corrupted flash memory. The method requires bootloader aware software running on the local host in order to complete.
The INT6400™ boot-from-host method is similar to the INT6300™ boot-from-host method but it downloads and executes an SDRAM configuration applet instead of downloading SDRAM parameters. The applet is downloaded and executed using the same mechanism as runtime firmware. The applet executes and returns to the bootloader when done. The bootloader then continues to drive the boot process using VS_HOST_ACTION messages.
The INT6400™ boot-from-host method will work for AR7400™ and QCA7420™ chipsets but will not work on successive chipsets. Customers should adopt or implement the AR7400™ boot-from-host method, instead of this one, to avoid building obsolete products.
The INT6400™ does not have a unique hardware address until the firmware starts and assigns one from the parameter information block. Until that time, the bootloader will only acknowledge 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.6. Boot from Host (INT6400)
INT6400 LOCAL-HOST
[01] | |
[02] |-------- VS_HOST_ACTION.IND ------->| [03]
[05] |<------- VS_HOST_ACTION.RSP --------| [04]
| |
[06] |<------- VS_WR_MEM.REQ -------------| [06]
[06] |-------- VS_WR_MEM.CNF ------------>| [06]
[06] |<-----------------------------------| [06]
[06] |----------------------------------->| [06]
| |
[08] |<------- VS_ST_MAC.REQ -------------| [07]
[09] |-------- VS_ST_MAC.CNF ------------>| [10]
[11] | |
[12] |-------- VS_HOST_ACTION.IND ------->| [13]
[15] |<------- VS_HOST_ACTION.RSP --------| [14]
| |
| | [16]
| |
[17] |<------- VS_WR_MEM.REQ -------------| [17]
[17] |-------- VS_WR_MEM.CNF ------------>| [17]
[17] |<-----------------------------------| [17]
[17] |----------------------------------->| [17]
| |
[18] |<------- VS_WR_MEM.REQ -------------| [18]
[18] |-------- VS_WR_MEM.CNF ------------>| [18]
[18] |<-----------------------------------| [18]
[18] |----------------------------------->| [18]
| |
[20] |<------- VS_ST_MAC.REQ -------------| [19]
[21] |-------- VS_ST_MAC.CNF ------------>| [22]
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 futher action is required. If it fails, for any reason, then the bootloader initiates the boot-from-host sequence.
The bootloader broadcasts VS_HOST_ACTION.IND with HOST_ACTION_REQ set to 0x04 to request configuration. The destination address is FF:FF:FF:FF:FF:FF and source address is 00:B0:52:00:00:01 as explained above. This message is sent every 500 milliseconds which differs from that of other chips.
The local host receives the VS_HOST_ACTION.IND message and inspects the HOST_ACTION_REQ field to determine the appropriate action. On a single-host system, the lone host must service the request or the device will not start. On a multi-host system, one host must elect to service the request of the device will not start.
The local host sends VS_HOST_ACTION.RSP to silence the bootloader or indicate the ability and willingness to service the request. The destination address must be 00:B0:52:00:00:01 and the source address is that of the host interface. 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 messages and waits indefinitely for the local host to download a configuation applet and start execution.
The host downloads the memory control applet 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 one. Each message contains an image segment and the segment memory offset, length and checksum. These values are used to monitor and manage download progress. If a transaction fails, the host can detect it and should repeat it.
The host starts execution of the memory control applet by sending a VS_ST_MAC.REQ message to the device. The message contains the applet load address, length, checksum and start address. These values are often obtained from an NVM file image header.
The bootloader receives the VS_ST_MAC.REQ from the host and validates the contents.
The bootloader sends a VS_ST_MAC.CNF message to the host indicating the ability and willingness to start applet execution. The MSTATUS field is set to 0x00 for affirmative and 0x01 for negative.
The host receives the VS_ST_MAC.CNF message from the device and evaluates the MSTATUS field. On affirmative, the host waits for further requests from the device. On negative, the host may attempt another start or another download followed by a start or attempt to alert a human.
The bootloader starts applet execution. The applet configures memory, runs to completion and returns to the Bootloader.
The bootloader broadcasts a VS_HOST_ACTION.IND message every 500 milliseconds to request runtime firmware and parameter download. The message destination address is FF:FF:FF:FF:FF:FF and source address is 00:B0:52:00:00:01 as explained above. The HOST_ACTION_REQ field is set to 0x00.
The host receives the VS_HOST_ACTION.IND message and inspects the HOST_ACTION_REQ field to determine the requested action. On a single-host system, the lone host must service the request or the device will not start. On a multi-host system, one host 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 the 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 messages and waits indefinitely for the host to download the runtime firmware and parameters and start execution.
The host determines which firmware and parameter image to download. In some cases there may be no choice. In other cases, there may be a choice between default and custom images or between current and upgraded images. This is a principle design issue to consider.
The 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 message from the device after each one. Each message contains an image segment and the segment memory offset, length and checksum. These values are used to monitor and manage download progress. If a transaction fails, the local host can detect it and should repeat it.
The host downloads the 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 one. Each message contains an image segment and the segment memory offset, length and checksum. These values are used to monitor and manage download progress. If a transaction fails, the local host can detect it and should repeat it.
The host starts runtime firmware execution by sending a VS_ST_MAC.REQ message to the device. The message contains the firmware load address, length, checksum and start address. These values are often obtained from an NVM file image header.
The bootloader receives the VS_ST_MAC.REQ from the host and validates the content.
The bootloader sends a VS_ST_MAC.CNF message to indicate the ability or willingness to start firmware execution.
The host receives the VS_ST_MAC.CNF message from the device, inspects the MSTATUS field and acts accordingly.
The bootloader starts runtime firmware execution. The firmware reads and validates the parameter block then assumes full control of the device. It can take several seconds for firmware start to be evident. Once the firmware starts, any future VS_HOST_ACTION messages will contain the unique hardware address for the device.