I noticed nv_update_engine always resets boot retry_count to 7 despite the configuration which was entered in smd_info.cfg.
Is it somehow configurable to change “good” value for this counter?
We have been verified it should be worked.
Did you follow the l4t document the chapter “TX2 Bootloader Update and Redundancy”
what I mean is that I choose a different value than 7. E.g. I write to the smd_info.cfg value of 2, flash it and then make update using nv_update_engine.
I expect my configuration to be preserved as 2. But it’s reset to 7.
Is there a workaround?
Just check it’s hard code as 7 didn’t apply from the cfg file.
are there any chances you could make it configurable or release the tool’s source code on some liberal license?
Does that an critical request for you. What’s you case need to modify it.
well, it’s not critical, it’s more nice to have. This reduces slightly the downtime in case when the rollback is needed. Now the system needs to reset 7 times after software update before the slot is considered ‘bad’, but one time would be enough.
If you ask about critical issues though the recommendation to disable watchdog timer in recent (stable) release notes is more critical. I written my concerns here:
Do you think this is fixed in next release? If yes when it will leave the beta phase?
7 times to revert to a different slot seems too long.
If it’s hard coded, is there a way that a developer can change it to a smaller number?
Could you help to try on latest BSP?
@ShaneCCC Where can I find it?
For the following URLs you will probably have to go there, log in, and then go there again (redirect does not work).
Actual flash and install puts “Linux for Tegra” (“L4T”) on. JetPack and SDK Manager are a GUI front end for this. Some related URLs showing various versions:
JetPack/SDK Manager https://developer.nvidia.com/embedded/jetpack-archive
The most recent SDKM would install the most recent L4T.
I’ve download L4T version 32.3.1, which sub .tbz2 will contain the latest changes for ‘retry_count’ modification? Thanks.
I’m unsure of the question, but if you are talking about network attempts to retry downloads, then this is through SDK Manager. Actual file downloads and locations are listed in the manifest.json, but I have no idea where retries or other related settings are. I probably cannot answer (maybe you are just asking about boot redundancy, but this too is something I couldn’t answer), but a more detailed description of what you are actually trying to do would probably be required.
Do you know where I can get hold of ‘nvbootctrl’ and ‘nv_update_engine’ source code which are not included in the package. Only the executables are included.
I do not know, but some of the early boot binary files are not available in source code format. Someone else would need to verify, but I believe that source is unreleased.
Is it possible for a company to ask NVidia to release the source code for accessing nvbootctrl, nv_update_engine and boot code?
For the nv_update_engine there’s no source release just binary release only.