Allow for special fallback rom slot#16
Open
ToSa27 wants to merge 5 commits intoraburton:masterfrom
ToSa27:master
Open
Allow for special fallback rom slot#16ToSa27 wants to merge 5 commits intoraburton:masterfrom ToSa27:master
ToSa27 wants to merge 5 commits intoraburton:masterfrom
ToSa27:master
Conversation
Ability to compile custom default rom map (or full config) directly into the code instead of providing separate struct to flash at the config location. Especially if for some reason the config gets corrupted during operation, with this approach a compatible default map is written whereas with the currently supported method only the hardcoded default would be written...
To enable, define BOOT_CONFIG_DEFAULTS in the rboot-integration.h and add a function that sets the default values. Simplistic rboot-integration.h for just this purpose could look like this:
#ifndef __RBOOT_INTEGRATION_H__
#define __RBOOT_INTEGRATION_H__
#include "..\rboot\rboot-private.h"
#define BOOT_CONFIG_DEFAULTS
void set_defaults(rboot_config *romconf) {
romconf->count = 4;
romconf->roms[0] = 0x010000;
romconf->roms[1] = 0x100000;
romconf->roms[2] = 0x200000;
romconf->roms[3] = 0x300000;
}
#endif
Custom default rom map
…MODE_FALLBACK in mode byte.
Author
|
Actually an even better approach would be to define the ROM number for the fallback ROM dynamically similar to the GPIO ROM number. The two unused bytes in the config struct would be a good place to do so. This would allow for OTA updates of the fallback itself as well leveraging another unused slot and then switching the fallback ROM number if successfully updated... |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I've moved OTA capabilities and a lot of other one time or rare case functionality (like AP with mini webserver for first time configuration of SSID/PW) into one dedicated ROM instead of duplicating that functionality in all ROMs wasting space. To properly select the last good ROM, the bootloader needs to be aware of this setup and pick the next ROM to check accordingly. I've added a new flag similar to the ERASE_SDKCONFIG flag to facilitate this - could be done via defines as well as I don't expect this behavior to change after design time. If another ROM wants to switch to this functionality, it can set the temp ROM in RTC-mem and force a soft-reboot e.g. forcing a watchdog timeout in an endless loop.