Communication Device and Firmware Update Method Thereof

1. A communication device, comprising: a non-volatile memory comprising a first flag indicating boot firmware for the communication device, a second flag indicating whether a bootability check is to be executed, and a first data area storing original firmware of the communication device; an updating module configured for receiving and storing new firmware in a second data area of the non-volatile memory, utilizing the first flag to assign the new firmware as the boot firmware, and utilizing the second flag to enable the bootability check after the storing of the new firmware is completed; and a loading module configured for utilizing the first flag to assign a firmware version other than the new firmware as the boot firmware before verification of the new firmware, and loading and executing the new firmware in response to a boot up procedure of the communication device; wherein if the new firmware is executable and causes the communication device to satisfy a predetermined boot up condition, the communication device determines that the new firmware passes the bootability check, and modifies the value of the first flag to assign the new firmware as the boot firmware; and if the new firmware does not pass the bootability check, the communication device keeps the value of the first flag unchanged.

2. The communication device as described in claim 1 , wherein the first and the second data areas are different partitions of the non-volatile memory.

3. The communication device as described in claim 1 , wherein determination of whether the communication device satisfies the predetermined boot up condition is based on whether the new firmware successfully initialize a number of expected software processes, wherein if the new firmware successfully initialize the expected software processes, determination is made that the communication device satisfies the predetermined boot up condition, or if the new firmware does not successfully initialize the expected software processes, determination is made that the communication device does not satisfy the predetermined boot up condition.

4. The communication device as described in claim 3 , wherein the expected software processes include one or more software processes each providing at least one function selected from the group consisting of a command line, hypertext transmission protocol, dynamic host configuration protocol, telnet, system log, network address translation, and universal plug and play protocol.

5. The communication device as described in claim 3 , wherein one of the expected software processes is configured for receiving a request from a remote server, and allowing the remote server to set configuration of the communication device.

6. The communication device as described in claim 1 , wherein if the new firmware passes the bootability check, the new firmware modified the second flag to disable subsequent bootability checks.

7. The communication device as described in claim 6 , wherein the communication device detects whether the communication device is triggered to reboot or shutdown, and further determines whether the bootability check is enabled if the communication device is triggered to reboot or shutdown, the communication device modifies the value of the first flag to assign the new firmware as the boot firmware before the communication device reboots or shuts down if the bootability check is enabled, or keeps the value of the first flag unchanged before the communication device reboots or shuts down if the bootability check is disabled.

8. The communication device as described in claim 7 , further comprising a backup power supply providing electrical power to the communication device for operation after the triggering of the reboot or shutdown is detected.

9. The communication device as described in claim 1 , wherein the non-volatile memory is a flash memory.

10. A method for updating firmware executed in a communication device comprising a non-volatile memory, the non-volatile memory comprising a first flag indicating boot firmware for the communication device, a second flag indicating whether a bootability check is to be executed, and a first data area storing original firmware for the communication device, comprising: receiving and storing new firmware in a second data area of the non-volatile memory; utilizing the first flag to assign the new firmware as the boot firmware, and utilizing the second flag to enable the bootability check after the storing of the new firmware is completed; and utilizing the first flag to assign a firmware version other than the new firmware as the boot firmware before determining whether the new firmware passing the bootability check; and loading and executing the new firmware in response to a boot procedure of the communication device; wherein in response to the new firmware being executable and causing the communication device to satisfy a predetermined boot up condition, the communication device determines that the new firmware passes the bootability check, and modifies the value of the first flag to assign the new firmware as the boot firmware; or if the new firmware does not pass the bootability check, the communication device keeps the value of the first flag unchanged.

11. The method as described in claim 10 , wherein the determination of whether the communication device satisfies said predetermined boot up condition comprises: determining whether the new firmware successfully initialize a number of expected software processes; determining that the communication device satisfies the predetermined boot up condition if the new firmware successfully initialize the expected software processes; or determining that the communication device does not satisfy the predetermined boot up condition if the new firmware does not successfully initialize the expected software processes.

12. The method as described in claim 11 , wherein the expected software processes include one or more software processes each providing at least one function selected from the group consisting of a command line, hypertext transmission protocol, dynamic host configuration protocol, telnet, system log, network address translation, and universal plug and play protocol.

13. The method as described in claim 11 , wherein one of the expected software processes is configured for receiving a request from a remote server, and allowing the remote server to set configuration of the communication device.

14. The method as described in claim 10 , further comprising: modifying the second flag to disable subsequent bootability check if the new firmware passes the bootability check.

15. The method as described in claim 14 , further comprising: detecting whether the communication device is triggered to reboot or shutdown; determining whether the bootability check is enabled if the communication device is triggered to reboot or shutdown; modifying the value of the first flag to assign the new firmware as the boot firmware before the communication device reboots or shuts down if the bootability check is enabled; or keeping the value of the first flag unchanged before the communication device reboots or shuts down if the bootability check is disabled.

16. The method as described in claim 15 , further comprising: utilizing a backup power supply of the communication device to provide electrical power to the communication device for operation after the triggering of the reboot or shutdown is detected.

17. A method for updating firmware, executed in a communication device equipped with a non-volatile memory storing original firmware of the communication device in a first data area of the non-volatile memory, comprising: utilizing a first flag to indicate boot firmware for the communication device and a second flag indicating whether a bootability check is to be executed; receiving and storing new firmware in a second data area of the non-volatile memory; utilizing the second flag to enable the bootability check after the storing of the new firmware is completed; the bootability check further comprises: utilizing the first flag to assign a firmware version other than the new firmware as the boot firmware for the communication device before determining whether the new firmware passes the bootability check; loading and executing the new firmware in response to a boot procedure of the communication device; determining that the new firmware passes the bootability check and modifying the value of the first flag to assign the new firmware as the boot firmware if the new firmware is executable and causes the communication device to satisfy a predetermined boot up condition; or keeping the value of the first flag unchanged if the new firmware does not pass the bootability check.

18. The method as described in claim 17 , further comprising: if the new firmware passes the bootability check, modifying the second flag by the new firmware to disable subsequent bootability checks.

19. The method as described in claim 17 , wherein determination of whether the communication device satisfies the predetermined boot up condition is based on whether the new firmware successfully initialize a number of expected software processes, wherein if the new firmware successfully initialize the expected software processes, determination is made that the communication device satisfies the predetermined boot up condition, or if the new firmware does not successfully initialize the expected software processes, determination is made that the communication device does not satisfy the predetermined boot up condition.

20. The method as described in claim 19 , wherein the expected software processes include one or more software processes each providing at least one function selected from the group consisting of a command line, hypertext transmission protocol, dynamic host configuration protocol, telnet, system log, network address translation, and universal plug and play protocol.