Skip to content

Conversation

@ToSa27
Copy link

@ToSa27 ToSa27 commented May 29, 2016

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.

ToSa27 and others added 3 commits May 27, 2016 23:47
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
@ToSa27
Copy link
Author

ToSa27 commented May 31, 2016

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...
I'd propose to close this without merging - I'll share an improved PR later (refactoring my entire codebase, hence it might take a couple of days).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant