The VS_MODULE_OPERATION message is now the only way of write flash memory. The legacy message types VS_RD_MOD, VS_WR_MOD, VS_MOD_NVM and VS_PTS_NVM are deprecated and will no longer be supported by runtime firmware. This means that some customers must re-write their applications to flash newer powerline devices.
The VS_MODULE_OPERATION message type has many formats and the structure differs with each format. Readers should consult the QCA Firmware Technical Reference Manual for a complete description.
A blank flash memory must first be programmed with a softloader module. The module consists of a manifest, the executable softloader program image and a flash memory map. The map is used to manage flash memory during initializations and upgrades. The softloader module must be written into flash memory as a separate module before parameter and firmware modules are written. After that, parameter and firmware modules may be written and re-written without re-writing the softloader module. Of course, the softloader module must be re-written if flash memory is erased.
Figure 4.9. Flashing the Softloader (AR7420)
AR7420 LOCAL-HOST
[02] |<- VS_MODULE_OPERATION.REQ (Start Session) ---| [01]
[03] |-- VS_MODULE_OPERATION.CNF (Start Session) -->| [04]
| |
[06] |<-- VS_MODULE_OPERATION.REQ (Write Module) ---| [05]
[07] |--- VS_MODULE_OPERATION.CNF (Write Module) -->| [08]
|<---------------------------------------------|
|--------------------------------------------->|
| |
[10] |<- VS_MODULE_OPERATION.REQ (Close Session) ---| [09]
[11] |-- VS_MODULE_OPERATION.CNF (Close Session) -->| [12]
The local host sends a VS_MODULE_OPERATION.REQ module write session request to register a session identifier and the module identifier, module length and module checksum of the softloader module. The softloader module identifier is 0x7003. The softloader module is the entire softloader chain including manifest, softloader image and flash memory layout.
The device receives the request, validates the module identifier and preserves the module length and checksum until the module write session is closed. The local host has 30 minutes to complete registered module write operations and close the module write session.
The device responds with VS_MODULE_OPERATION.CNF with MSTATUS set to 0, if things went well.
The local host receives the confirmation and prepares to download the softloader module.
The local host sends a VS_MODULE_OPERATION.REQ module write request containing the offset, length and content of the first portion of the module being downloaded.
The device receives the request and write to a scrath region of flash memory awaiting session close.
The device responds with VS_MODULE_OPERATION.CNF with MSTATUS set to 0 if things went well.
The local host receives the confirmation and continues downloading the softloader in fragments using VS_MODULE_OPERATION write requests, advancing the offset and adjusting the length with each write.
The local host send a VS_MODULE_OPERATION.REQ close module write session request having COMMIT_CODE bits 0 and 1 set. to indicate “Force Commit” and “Commit without reset”, respectively.
The device recevies the request, verifies the module length and checksum then transfers the module from scratch memory to it's final location in flash memory.
The device responds with VS_MODULE_OPERATION.CNF close module write session with MSTATUS set to 0 if things went well. If things did not go well then the local host must request a new write module session and start over.
Once the softloader module is written, the parameter and firmware modules may be written in much the same way except that they must be written as a pair. The parameter module must be downloaded first. The firmware module cannot be committed to without a compatible parameter module.
When parameters and firmware are written together the User PIB, Factory PIB and firmware are modified modified. The new User PIB is created by copying the old User PIB over the new one. Consequently the only change comes from extra fields found at the end of the new User PIB. The new Factory PIB becomes the new User PIB with certain fields from the old User PIB preserved, such as the MAC, DAK and so on.
Figure 4.10. Flash Parameters and Firmware (AR7420)
AR7420 LOCAL-HOST
[02] |<- VS_MODULE_OPERATION.REQ (start session) ---| [01]
[03] |-- VS_MODULE_OPERATION.CNF (start session) -->| [04]
| |
[06] |<-- VS_MODULE_OPERATION.REQ (write module) ---| [05]
[07] |--- VS_MODULE_OPERATION.CNF (write module) -->| [08]
|<---------------------------------------------|
|--------------------------------------------->|
| |
[10] |<-- VS_MODULE_OPERATION.REQ (write module) ---| [09]
[11] |--- VS_MODULE_OPERATION.CNF (write module) -->| [12]
|<---------------------------------------------|
|--------------------------------------------->|
| |
[14] |<- VS_MODULE_OPERATION.REQ (commit modules) --| [13]
[15] |-- VS_MODULE_OPERATION.CNF (commit modules) ->| [16]
The local host sends a VS_MODULE_OPERATION.REQ module write session request to register the session identifier, module identifiers, module lengths and module checksums. In this case, the two modules are the runtime parameters and runtime firmware. The module identifiers are 0x7002 and 0x7003, respectively. The application running on the local must must locate these modules and determine their size and checksum.
The device receives the request, validates the module identifier and preserves the module lengths and checksums until the module write session is closed. The local host has 30 minutes to complete registered module write operations and close the module write session.
The device responds with VS_MODULE_OPERATION.CNF with MSTATUS set to 0, if things went well.
The local host receives the confirmation and prepares to download the parameter module.
The local host sends a VS_MODULE_OPERATION.REQ module write request containing the offset, length and content of the first portion of the module being downloaded.
The device receives the request and write to a scratch region of flash memory awaiting write session close.
The device responds with VS_MODULE_OPERATION.CNF with MSTATUS set to 0 if things went well.
The local host receives the confirmation and continues downloading the parameter module in fragments using VS_MODULE_OPERATION write requests, advancing the offset and adjusting the length with each write.
The local host receives the confirmation and prepares to download the firmware module.
The local host sends a VS_MODULE_OPERATION.REQ module write request containing the offset, length and content of the first portion of the module being downloaded.
The device receives the request and write to a scratch region of flash memory awaiting write session close.
The device responds with VS_MODULE_OPERATION.CNF with MSTATUS set to 0 if things went well.
The local host receives the confirmation and continues downloading the firmware module in fragments using VS_MODULE_OPERATION write requests, advancing the offset and adjusting the length with each write.
The local host send a VS_MODULE_OPERATION.REQ close module write session request having COMMIT_CODE bits 0 and 1 set. to indicate “force commit” and “commit without reset”, respectively.
The device receives the request, verifies the module length and checksum then transfers the module from scratch memory to it's final location in flash memory.
The device responds with VS_MODULE_OPERATION.CNF close module write session with MSTATUS set to 0 if things went well. If things did not go well then the local host must request a new write module session and start over.
At this point, the device is ready to boot from flash memory if the power fails or the device resets.