# Boot from Host (AR7420)

The `VS_WRITE_AND_EXECUTE` message is now the only way to write runtime parameters and firmware into volatile memory. The legacy `VS_RD_MEM`, `VS_WR_MEM` and `VS_ST_MAC` are deprecated and will no longer be supported by the bootloader. This means that some customers must re-write their applications to boot newer powerline devices.

## Boot from Host (AR6410/AR7420)

              AR7420                             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 enters boot-from-host mode based on the hardware strapping or failure to load runtime firmware from flash memory. The device hardware address is `00:B0:52:00:00:01` in this state.

2. The bootloader broadcasts a `VS_HOST_ACTION.IND` message with `HOST_ACTION_REQ` set to `4` to indicate that it is waiting to be configured. The bootloader will continue to broadcast the `VS_HOST_ACTION.IND` message every `750`ms until it receives a `VS_HOST_ACTION.RSP` message from the local host. The BootROM does not know the local host hardware address at this stage so indications are broadcast, not addressed.

3. The local host receives a `VS_HOST_ACTION.IND` message and inspects `HOST_ACTION_REQ` field to determine the required action. The local host must be programmed to listen and act appropriately. The first indcation requests device configuration.

4. The local host sends a `VS_HOST_ACTION.RSP` message with `MSTATUS` set to `0` to indicate a willingness and ability to service the request.

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`, `ALLOWED_MEM_TYPES` to `1`, `CURR_PART_OFFSET` to the applet image header `IMAGEADDRESS` and `CURR_PART_LENGTH` to the applet image header `IMAGELENGTH` 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.

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 download the configuration applet in `1400` byte blocks until the last block is reached. The local host sets `START_ADDR` to the applet image header `ENTRYPOINT`, `CHECKSUM` to the applet image header `IMAGECHECKSUM` and the execute bit in `FLAGS` to `1`.

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`, `ALLOWED_MEM_TYPES` set to `1`, `CURR_PART_OFFSET` to the parameter image header `IMAGEADDRESS` and `CURR_PART_LENGTH` to the entire parameter image chain length 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.

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 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`, `CHECKSUM` to the parameter image header `IMAGECHECKSUM` and the execute bit in `FLAGS` to `1`.

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`, `ALLOWED_MEM_TYPES` to `1`, `CURR_PART_OFFSET` to the firmware image header `IMAGEADDRESS` and `CURR_PART_LENGTH` to the firmware image header `IMAGELENGTH` 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.

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 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`, `CHECKSUM` to the parameter image header `IMAGECHECKSUM` and the execute bit in `FLAGS` to `1`.

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.

At this point, runtime firmware is executing in volatile memory with runtime parameters. If the power is reset at this point then all would be lost. If the device has dedicated flash memory attached then we may want to write runtime parameters and firmware to flash memory so that the device can boot from flash in case of a power failure or reset.