The AR7400™ boot-from-host method downloads and executes a device configuration applet then downloads runtime parameters and firmware from a local host and starts firmware execution. This method is initiated by the 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 AR7400™ boot-from-host method is similar to the INT6400™ boot-from-host method but it uses the VS_WRITE_AND_EXECUTE message instead of the VS_WR_MEM message write into SDRAM and start firmware execution. This eliminates the need for the VS_ST_MAC message. The VS_WR_MEM and VS_ST_MAC message types will no longer be recognized by bootloaders after the QCA7420™ chipset.
The AR7400™ boot-from-host method works on AR6400™ and will continue to work on QCA7420™ and planned successors. Customers should implement this boot-from-host method now to avoid building obsolete products.
The AR7400™ does not have a unique hardware address until the firmware starts and assigns one read from the PIB. 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 all VS_HOST_ACTION messages to FF:FF:FF:FF:FF:FF; however, these messages are not transmitted over the powerline.
Figure 4.7. Boot from Host (AR7400)
AR7400 LOCAL-HOST
[01] | |
[02] |-------- VS_HOST_ACTION.IND ------->| [03]
[05] |<------- VS_HOST_ACTION.RSP --------| [04]
| | [06]
|<---- VS_WRITE_AND_EXECUTE.REQ -----| [07]
[08] |----- VS_WRITE_AND_EXECUTE.CNF ---->|
|<-----------------------------------| [09]
[10] |----------------------------------->| [11]
[12] | |
[13] |-------- VS_HOST_ACTION.IND ------->| [14]
[16] |<------- VS_HOST_ACTION.RSP --------| [15]
| | [16]
|<-VS_WRITE_AND_EXECUTE_APPLET.REQ --| [17]
[18] |--VS_WRITE_AND_EXECUTE_APPLET.CNF ->|
|<-----------------------------------| [19]
[20] |----------------------------------->|
|<-VS_WRITE_AND_EXECUTE_APPLET.REQ --| [21]
[22] |--VS_WRITE_AND_EXECUTE_APPLET.CNF ->|
|<-----------------------------------| [23]
[24] |----------------------------------->|
[25] | |
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 initiates the boot-from-host sequence.
The bootloader broadcasts VS_HOST_ACTION.IND with HOST_ACTION_REQ set to 0x04 to indicate that it is waiting to be configured. The bootloader continues to broadcast this message message every 750 milliseconds which differs from that of other chips.
The local host receives the VS_HOST_ACTION.IND and inspects HOST_ACTION_REQ field to determine the required action. The local host must be programmed to listen and act appropriately.
The local host sends a VS_HOST_ACTION.RSP message with MSTATUS set to 0 to indicate the start of sequence.
The bootloader receives the VS_HOST_ACTION.RSP message, stops broadcasting VS_HOST_ACTION.IND messages and waits indefinitely for the local host to act.
The local host retrieves the firmware chain and extracts the configuration applet image from the chain. The firmware chain may be stored on disk or in memory depending on how the local host is programmed.
The local host sends a VS_WRITE_AND_EXECUTE.REQ message with FLAGS set to 2 and ALLOWED_MEM_TYPES to 1 to download the applet in absolute address mode. Alternately, setting FLAGS to 0 and CURR_PART_OFFSET to 0 will download the applet in relative address mode. The TOTAL_LENGTH will be the applet image header IMAGELENGTH but CURR_PART_LENGTH cannot exceed 1400 bytes.
The bootloader acknowledges each VS_WRITE_AND_EXECUTE.REQ message with a VS_WRITE_AND_EXECUTE.CNF message having MSTATUS set to 0.
The local host continues to increment CURR_PART_OFFSET and download the configuration applet in 1400 byte blocks until the last block is reached. The local host then sets START_ADDR to the applet image header ENTRYPOINT, the CHECKSUM to the applet image header IMAGECHECKSUM and the execute bit in FLAGS to 1 in the last message frame.
The bootloader receives the last VS_WRITE_AND_EXECUTE.REQ message, confirms the configuration applet checksum then acknowledges with a VS_WRITE_AND_EXECUTE.CNF message having MSTATUS set to 0.
The local host exists the boot from host sequence and returns to listening mode.
The bootloader executes the configuration applet. The device hardware address is 00:B0:52:00:00:01 in this state.
The bootloader broadcasts a VS_HOST_ACTION.IND message with HOST_ACTION_REQ set to 0 to indicate that it is waiting for runtime parameters and firmware.
The local host receives a VS_HOST_ACTION.IND message and inspects the HOST_ACTION_REQ field to determine the required action. The local host must be programmed to listen and act appropriately.
The bootloader receives the VS_HOST_ACTION.RSP message, stops broadcasting VS_HOST_ACTION.IND messages and waits indefinitely for the local host to act.
The local host locates the parameter chain and firmware chain. The chains may be stored on disk or in memory depending on how the local host is programmed.
The local host sends a VS_WRITE_AND_EXECUTE.REQ message with FLAGS set to 2 and ALLOWED_MEM_TYPES set to 1 to download parameters in absolute address mode. Alternately, setting FLAGS to 0 and CURR_PART_OFFSET to 0 will download parameters in relative address mode. The TOTAL_LENGTH will be the entire parameter file length but the CURR_PART_LENGTH cannot exceed 1400 bytes.
The bootloader acknowledges each VS_WRITE_AND_EXECUTE.REQ message with a VS_WRITE_AND_EXECUTE.CNF message having MSTATUS set to 0.
The local host continues to CURR_PART_OFFSET and download the parameter chain in 1400 byte blocks until the last block is reached. The local host then sets the START_ADDR field to the parameter image header ENTRYPOINT, the CHECKSUM to the parameter image header IMAGECHECKSUM and the execute bit in FLAGS to 1 in the last message frame.
The bootloader receives the last VS_WRITE_AND_EXECUTE.REQ message, confirms the parameter chain checksum and acknowledges with a VS_WRITE_AND_EXECUTE.CNF message having MSTATUS set to 0.
The local host sends a VS_WRITE_AND_EXECUTE.REQ message with FLAGS set to 2 and ALLOWED_MEM_TYPES to 1 to download firmware in absolute address mode. Alternately, setting FLAGS to 0 and CURR_PART_OFFSET to 0 will download firmware in relative address mode. The TOTAL_LENGTH will be the firmware image header IMAGELENGTH but the CURR_PART_LENGTH cannot exceed 1400 bytes.
The bootloader acknowledges each VS_WRITE_AND_EXECUTE.REQ message with a VS_WRITE_AND_EXECUTE.CNF message having the MSTATUS field set to 0.
The local host continues to increment CURR_PART_OFFSET and download the parameter chain in 1400 byte blocks until the last block is reached. The local host then sets START_ADDR to the parameter image header ENTRYPOINT, the CHECKSUM to the parameter image header IMAGECHECKSUM and the execute bit in FLAGS to 1 in the last message frame.
The bootloader receives the last VS_WRITE_AND_EXECUTE.REQ message, confirms the firmware chain checksum and acknowledges with a VS_WRITE_AND_EXECUTE.CNF message having the MSTATUS field set to 0.
The bootloader executes the runtime firmware and the device begins operation. The device hardware address will become that programmed into the parameter inforamtion block.