You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What is currently implemented in the FSBL is that first, the XFsbl_BoardInit() function is being called where users can write their own initialization code for their specific board. Then after this function is complete, the XFsbl_ResetValidation() is being called in order to validate the reset reason and trigger specific actions in case of error (i.e. WDT timeout). Then, the WDT is being enabled in the XFsbl_PrimaryBootDeviceInit() function. To me, the order of execution of those functions looks problematic. Let me explain.
First of all, I would expect the Initialization of WDT to take place ASAP. What if one of the external devices in the XFsbl_BoardInit() hangs the code? The WDT wouldn't be enabled yet and so this fallback wouldn't be implemented. Of course, I can accept an answer like "correct code should always understand errors and fallback" but in general, I think that the Initialization of a safety mechanism like the WDT should definitely take place before we start initializing devices, especially ones that are outside of the chip like the code for the Si570.
The ResetValidation() should be something that takes place definitely before the XFsbl_BoardInit() function. The XFsbl_BoardInit() function is a function that includes in the very well written and tested FSBL code, some extra functionality that usually has to do with external devices. If there was an error with an external device, why to try again to run XFsbl_BoardInit() (after the board has resetted) and not check initially the Reset Reason in XFsbl_ResetValidation() and then decide if the FSBL should continue or fallback?
So to sum up, my proposal is to move the WDT initialization code ASAP in the execution order of FSBL and definitely before the XFsbl_BoardInit() function and to move as well the XFsbl_ResetValidation() before the XFsbl_BoardInit(). With those changes, in case of any error or bad code in XFsbl_BoardInit() function, the user will always be safe and rebooted by the WDT.
Please let me know what you think.
Cheers,
Vasilis
The text was updated successfully, but these errors were encountered:
So, I would like to raise some comments on the FSBL code and especially the following parts:
What is currently implemented in the FSBL is that first, the XFsbl_BoardInit() function is being called where users can write their own initialization code for their specific board. Then after this function is complete, the XFsbl_ResetValidation() is being called in order to validate the reset reason and trigger specific actions in case of error (i.e. WDT timeout). Then, the WDT is being enabled in the XFsbl_PrimaryBootDeviceInit() function. To me, the order of execution of those functions looks problematic. Let me explain.
First of all, I would expect the Initialization of WDT to take place ASAP. What if one of the external devices in the XFsbl_BoardInit() hangs the code? The WDT wouldn't be enabled yet and so this fallback wouldn't be implemented. Of course, I can accept an answer like "correct code should always understand errors and fallback" but in general, I think that the Initialization of a safety mechanism like the WDT should definitely take place before we start initializing devices, especially ones that are outside of the chip like the code for the Si570.
The ResetValidation() should be something that takes place definitely before the XFsbl_BoardInit() function. The XFsbl_BoardInit() function is a function that includes in the very well written and tested FSBL code, some extra functionality that usually has to do with external devices. If there was an error with an external device, why to try again to run XFsbl_BoardInit() (after the board has resetted) and not check initially the Reset Reason in XFsbl_ResetValidation() and then decide if the FSBL should continue or fallback?
So to sum up, my proposal is to move the WDT initialization code ASAP in the execution order of FSBL and definitely before the XFsbl_BoardInit() function and to move as well the XFsbl_ResetValidation() before the XFsbl_BoardInit(). With those changes, in case of any error or bad code in XFsbl_BoardInit() function, the user will always be safe and rebooted by the WDT.
Please let me know what you think.
Cheers,
Vasilis
The text was updated successfully, but these errors were encountered: