#avr Logs

Jun 23 2022

02:44 AM Cracki: sounds like he's trying to implement the "usual" multiple firmware versions with bootloader-level-switching
02:53 AM Cracki: esp32/esp-idf has that implemented. bootloader can attempt to boot a new firmware once, and if that manages to call back "OK", it'll get flagged as the new permanent
02:53 AM Cracki: if not, the old firmware gets booted again
02:53 AM Cracki: they implement a 3-partition scheme. two update partitions, and if you fuck those up, there's still the factory partition that updates aren't supposed to touch, so you can fall back on that. "factory" just means whatever coders make it mean, not "espressif factory"
02:58 AM exp: Cracki: yeah that's more or less it except where the default image is the factory one
02:59 AM exp: i can relocate trampolines and i can create a new memory region for lowtext stuff, from my looking through libc there's only a single tiny section that seems to require being in progmem.data or whatever it was
02:59 AM exp: it does seem feasible, but i'm running out of time
02:59 AM exp: i probably could just have it parse the raw code and reposition all its addressing to manually shift the rom about, but i don't mind compiling the same thign twice for different offsets, that's not too bad
02:59 AM Cracki: :D
03:00 AM exp: just wondering what else there is, what else i may have missed, i think for now i'm going to go to a single image bootloader and pick this up again in a month or so
06:57 AM exp: in experimenting with this, when the reset vector instruction is generated, it seems to be hardcoded to a jmp, which i think can't reach above 2^17 on these AVRs? (xmega192)
06:58 AM exp: oh wait i'm thinking of the function pointer issue aren't i
07:00 AM specing_ is now known as specing
07:01 PM specing_ is now known as specing
10:01 PM nonlinear is now known as zero-xray