# Boot from Host (AR7400)

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.

## 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] |                                    |

1. 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.

2. 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.

3. 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.

4. The local host sends a `VS_HOST_ACTION.RSP` message with `MSTATUS` set to `0` to indicate the start of sequence.

5. 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.

6. 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.

7. 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.

8. The bootloader acknowledges each `VS_WRITE_AND_EXECUTE.REQ` message with a `VS_WRITE_AND_EXECUTE.CNF` message having `MSTATUS` set to `0`.

9. 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.

10. 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`.

11. The local host exists the boot from host sequence and returns to listening mode.

12. The bootloader executes the configuration applet. The device hardware address is `00:B0:52:00:00:01` in this state.

13. 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.

14. 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.

15. 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.

16. 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.

17. 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.

18. The bootloader acknowledges each `VS_WRITE_AND_EXECUTE.REQ` message with a `VS_WRITE_AND_EXECUTE.CNF` message having `MSTATUS` set to `0`.

19. 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.

20. 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`.

21. 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.

22. 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`.

23. 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.

24. 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`.

25. The bootloader executes the runtime firmware and the device begins operation. The device hardware address will become that programmed into the parameter inforamtion block.