The Boot from Host configuration offers design flexibility but also increases the possibilities. Remember that the processes described here are based on simple rules that ultimately dictate why each process step is needed. Readers may find it helpful to review these rules.
The softloader and bootloader programs have limited vocabulary.
The INT6000™ softloader recognizes only the VS_SW_VER, VS_ST_MAC, VS_RS_DEV, VS_WR_MOD requests. It does not recognize VS_WR_MEM.
The INT6300™ bootloader recognizes only the VS_SW_VER, VS_WR_MEM, VS_ST_MAC, VS_RS_DEV and VS_SET_SDRAM requests. It does not recognize VS_WR_MOD.
The INT6400™ bootloader recognizes only the VS_SW_VER, VS_WR_MEM, VS_ST_MAC, VS_RS_DEV requests. It recognizes VS_SET_SDRAM and responds to it but ignores it. It does not recognize VS_WR_MOD.
The AR7400™ bootloader recognizes only VS_SW_VER, VS_WR_MEM, VS_ST_MAC, VS_RS_DEV requests. It recognizes VS_SET_SDRAM and responds to it but ignores it. It does not recognize VS_WR_MOD.
The AR7420™ bootloader recognizes only VS_SW_VER, VS_RS_DEV, VS_WRITE_AND_EXECUTE and VS_RAND_MAC_ADDRESS requests. Early versions recognize VS_WRITE_MEM and VS_ST_MAC requests but they must not be used.
Table 4.1. Softloader/Bootloader MMEs
| MME | NAME | INT6000 Softloader | INT6300 Bootloader | INT6400 Bootloader | AR7400 Bootloader | AR7420 Bootloader |
|---|---|---|---|---|---|---|
| 0xA000 | VS_SW_VER | Yes | Yes | Yes | Yes | Yes |
| 0xA008 | VS_WR_MEM | No | Yes | Yes | Yes | Deprecated |
| 0xA00C | VS_ST_MAC | Yes | Yes | Yes | Yes | Deprecated |
| 0xA01C | VS_RS_DEV | Yes | Yes | Yes | Yes | Yes |
| 0xA020 | VS_WR_MOD | Yes | No | No | No | No |
| 0xA05C | VS_SDRAM | No | Yes | Ignored | Ignored | No |
| 0xA060 | VS_HOST_ACTION | No | Yes | Yes | Yes | Yes |
| 0xA098 | VS_WRITE_AND_EXECUTE | No | No | No | Yes | Yes |
| 0xA0D4 | VS_RAND_MAC_ADDRESS | No | No | No | Yes | Yes |
The Softloader, Bootloader and runtime firmware may treat the same MME differently because each is a different program. A notorious obvious example is the VS_SW_VER message type. This means that one may need to be aware of the device state when anticipating device behaviour or interpreting device response.
The local host is surrogate flash memory. When dedicated flash memory is not available to a device, the device will request firmware and parameter storage services from the local host using VS_HST_ACTION messages. The local host must be programmed to detect and respond to these messages or the firmware will appear to hang. See program int6khost, int64host, amphost or plchost to demonstrate and experiment with this interaction.
Only runtime firmware can write flash memory. Runtime firmware must be executing in order to write flash memory or upload to the local host. The Softloader and Bootloader cannot perform either operation.
All PIB changes must be written in flash memory. There are several things that can cause PIB changes. When a PIB change is needed, the Working PIB is copied to a scratch area and modified there. The Scratch PIB must then be written to flash memory or sent to the local host for storage. The device then resets causing the stored PIB to replace the Working PIB. If a freshly downloaded PIB changes for any reason then the cycle will repeat, automatically.
Runtime firmware updates the PIB after joining and before leaving an AVLN. This will cause a device reset in each case. If the device is using the local host for persistent storage, runtime firmware will send the associated VS_HST_ACTION messages to the host and the host will send the associated VS_RD_MOD and VS_RS_DEV messages as per Update Local Host.