- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,278
- Punkte für Reaktionen
- 1,753
- Punkte
- 113
You need a version, which has the correct "branding" value - it's the entry named "firmware_version" in the environment of your device and the newly flashed image has to contain the appropriate subdirectories for a "normal" function.
The installation process works fairly simple ... the started image checks, whether it's running from RAM or from flash memory (this is detected by the existence of a special MTD entry, which is available only in the first version) and writes itself into NAND flash, if it's running from (random access) memory. While the software is written to flash chip, the INFO LED flashes fast.
Afterwards the device is restarted, now from flash memory and the next check reveals, that it's not running from RAM anymore, therefore the installation process is now skipped.
But now the "normal" operation gets important again ... and this mode needs the proper filesystem structure to run without problems.
If a firmware version gets installed using the normal GUI, a check is performed, whether the new firmware contains the correct structure for the "firmware_version" value, which is read from device. If that's not the case, the installation is abandoned.
If a new version is installed via boot-loader, this check doesn't take place (within the new firmware running from RAM), because it's assumed, that such validations were already made by the software, which was in charge of loading the new image.
A firmware version without the correct "branding" leads to a boot loop - as far as I understood, that's your problem now.
There are two possible solutions ... make sure, that the firmware matches the present "firmware_version" value or try to change this value (via SETENV command from FTP client). The latter isn't possible always ... newer boot-loader versions deny changes to this value.
But that's something completely different ... it has nothing in common with the question, how to update a device with a Freetz version. Therefore it's a theme for a different thread ... but there're enough threads present already, where this "branding theme" is handled - you don't need to open a new one. You'd better read one of the existing threads ...
If you've checked the "branding" already (I'd assume, that the two devices used for the tests had different brandings), there's no obvious reason, why the device enters a boot-loop with the new firmware.
In this case you'd have to take additional measures to get further info, why the boot process fails ... but that's a different theme and is - once again - better discussed in a new thread, too.
The installation process works fairly simple ... the started image checks, whether it's running from RAM or from flash memory (this is detected by the existence of a special MTD entry, which is available only in the first version) and writes itself into NAND flash, if it's running from (random access) memory. While the software is written to flash chip, the INFO LED flashes fast.
Afterwards the device is restarted, now from flash memory and the next check reveals, that it's not running from RAM anymore, therefore the installation process is now skipped.
But now the "normal" operation gets important again ... and this mode needs the proper filesystem structure to run without problems.
If a firmware version gets installed using the normal GUI, a check is performed, whether the new firmware contains the correct structure for the "firmware_version" value, which is read from device. If that's not the case, the installation is abandoned.
If a new version is installed via boot-loader, this check doesn't take place (within the new firmware running from RAM), because it's assumed, that such validations were already made by the software, which was in charge of loading the new image.
A firmware version without the correct "branding" leads to a boot loop - as far as I understood, that's your problem now.
There are two possible solutions ... make sure, that the firmware matches the present "firmware_version" value or try to change this value (via SETENV command from FTP client). The latter isn't possible always ... newer boot-loader versions deny changes to this value.
But that's something completely different ... it has nothing in common with the question, how to update a device with a Freetz version. Therefore it's a theme for a different thread ... but there're enough threads present already, where this "branding theme" is handled - you don't need to open a new one. You'd better read one of the existing threads ...
If you've checked the "branding" already (I'd assume, that the two devices used for the tests had different brandings), there's no obvious reason, why the device enters a boot-loop with the new firmware.
In this case you'd have to take additional measures to get further info, why the boot process fails ... but that's a different theme and is - once again - better discussed in a new thread, too.
Zuletzt bearbeitet: