Reboot File Handling #154
No reviewers
Labels
No Label
OPS TODO
api change
breaking api change
bug
documentation
duplicate
feature
help wanted
invalid
question
wontfix
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: eive/eive-obsw#154
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "mueller/reboot-file-handling"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Some more information can be found here:
https://egit.irs.uni-stuttgart.de/redmine/projects/eive-flight-manual/wiki/OBC_Reboot_Handler
This PR requires a cross-compile rootfs update or a manual update of
libxiphos.h
.It also might require setting up the build folder again because of a new linker flag.
Need to update CI cross-compile rootfs because of bugs in
libxiphos.h
.There is a deciated unittest which was coded and run in VS code to verify the correctness of the reboot alorithms without the need for hardware specific libraries.
Reboot File Handlingto WIP: Reboot File HandlingWIP: Reboot File Handlingto Reboot File HandlingReboot File Handlingto WIP: Reboot File Handling@ -1104,0 +1280,4 @@
}
void CoreController::determineAndExecuteReboot(RebootFile &rf, bool &needsReboot,
xsc::Chip &tgtChip, xsc::Copy &tgtCopy) {
There might be the unlikely but nevertheless possible case that one of the firmware images is corrupted and all reboot counters except for the counter of the partition containing the corrupted firmware reached the maximum reboot count. I think this could lead in the current configuration to a scenario where the OBSW tries to boot from the partition with the corrupted firmware (because the reboot counter for this image is the only one not set to max reboot counts) but always ends in another image because the Xiphos bootloader prevents booting the corrupted image (according to datasheet performs integrity check by means of a CRC and md5sum).
Just my thoughts on this. Maybe you already considered this scenario.
WIP: Reboot File Handlingto Reboot File HandlingThere is now an additional safety mechanism in place to prevent reboot loops onto images which fail before the OBSW is reached