Help with manually launching second stage bootloader from application.

NotMyRealName
Posts: 40
Joined: Thu Feb 13, 2020 1:35 am

Help with manually launching second stage bootloader from application.

Postby NotMyRealName » Mon Nov 27, 2023 12:52 am

Hi Everyone,

I am struggling a bit with finding a way to manually launch the second stage bootloader from a running application partition. My code implements a custom serial bootloader using bootloader hooks and it would be nice to be able to force launch it.

I also use OTA, but the serial backup is great if for some reason (Bug/corruption) there are no more viable firmware images on the device. This also lets me update the partition table on the device even though the device is using secure boot/encryption etc.

Does anyone know how I could go about launching the second stage bootloader safely?

I'm also toying with the idea of just forcing the PC, but not sure how to go about this safely?

I've tried this:

Code: Select all

((void(*)(void))0x1000)();
but I get a warning back

Code: Select all

(.text.app_resetToBootloader+0x36): dangerous relocation: windowed longcall crosses 1GB boundary; return may fail: (*UND*+0x1000)
Sounds like there is an instruction set limitation here. Is there a way to get around that with inline asm?

I had planned to use some of the RTC retain memory to signal to the bootloader that it has been manually entered and delay it restarting the main application, but the retain memory is re-initialised (by code) at bootloader entry as far as I can tell.

I was hoping to use this function to tell that it came from application space:

Code: Select all

intptr_t esp_cpu_get_call_addr(intptr_t return_address)
If its all too hard I'll have to give up, but thought I'd see if anyone has any ideas. I can always do it through a GPIO at boot, but it would be nice not to have to do that.

Thanks in advance!

ESP_Sprite
Posts: 9577
Joined: Thu Nov 26, 2015 4:08 am

Re: Help with manually launching second stage bootloader from application.

Postby ESP_Sprite » Mon Nov 27, 2023 2:20 am

ESP-IDF sets up a whole lot of things that need to be undone for the 2nd stage bootloader to work, and in some cases (no-execute/read-only RAM bits) there is no way to undo them aside from resetting the SOC. So I'd suggest you simply reset the ESP32 while keeping a bit in RTC RAM or one of the (unused) RTC scratch registers to indicate what you want to do.

NotMyRealName
Posts: 40
Joined: Thu Feb 13, 2020 1:35 am

Re: Help with manually launching second stage bootloader from application.

Postby NotMyRealName » Mon Nov 27, 2023 3:05 am

Thanks ESP_Sprite,

Sounds like jumping straight to second stage bootloader is a bad idea.

I'm assuming that a reset of any kind will also re-initialise system registers such as RTC scratch values in the first/second stage bootloader?

Reserving RAM is how I would normally tackle this, but I think the init code wipes all the ram (including RTC domain) apart from specific marked sections.

I was under the impression that it is difficult to manually locate a variable at a specific address and also set the 'no init' flags. I'd have to reserve the same address in the application and the bootloader obviously. I've found macros to reserve sections (SOC_RESERVE_MEMORY_REGION, https://github.com/espressif/esp-idf/bl ... yout.h#L66), and macros for RTC_NOINIT_ATTR etc, but not one that applies both so far.

ESP_Sprite
Posts: 9577
Joined: Thu Nov 26, 2015 4:08 am

Re: Help with manually launching second stage bootloader from application.

Postby ESP_Sprite » Mon Nov 27, 2023 9:03 am

NotMyRealName wrote:
Mon Nov 27, 2023 3:05 am
I'm assuming that a reset of any kind will also re-initialise system registers such as RTC scratch values in the first/second stage bootloader?

Reserving RAM is how I would normally tackle this, but I think the init code wipes all the ram (including RTC domain) apart from specific marked sections.
It depends on the register; I am decently sure the RTC scratch registers aren't reset. (Note that if you're testing this, an external reset using the EN pin actually is a power-down and power-up and will likely corrupt RAM and registers.)

Who is online

Users browsing this forum: dpmcgabriel and 56 guests