MCUdude / MightyCore

Arduino hardware package for ATmega1284, ATmega644, ATmega324, ATmega324PB, ATmega164, ATmega32, ATmega16 and ATmega8535
Other
637 stars 181 forks source link

urboot copy_flash_pages #284

Closed eiten closed 1 month ago

eiten commented 8 months ago

Hello there

is it true that copy_flash_pages is not included in urboot? If so, how can I achieve that platformio burns the Optiboot loader instead of the urboot loader?

Thanks, Edi

MCUdude commented 8 months ago

AFAIK, Urboot doesn't provide a direct drop-in replacement for the copy_flash_pages that Optiboot provided for chips with 64kB flash size or larger. @stefanrueger may have a different answer here though. Are you planning to use it with ArduinoOTA?

Currently, Urboot is only available through Arduino IDE. I'll start working on the PlatformIO integration soon.

stefanrueger commented 8 months ago

I had to look up what copy_flash_pages does. No, urboot cannot upload a sketch from internal flash. Urboot provides a functionality to upload a sketch from external SPI flash memory (this is called dual boot and needs to be compiled in). To do so from internal flash sounds a bit counter-intuitive to me as it limits the sketch size to half the available flash.

eiten commented 8 months ago

AFAIK, Urboot doesn't provide a direct drop-in replacement for the copy_flash_pages that Optiboot provided for chips with 64kB flash size or larger. @stefanrueger may have a different answer here though. Are you planning to use it with ArduinoOTA?

Not exactly. I'm implementing FOTA from internal flash for MySensors. If Optiboot soon will be dropped from MightyCore, it's not worth the pain.

@stefanrueger I got some sensors that run on LoRaWAN or on MySensors. The MySensors firmware is much smaller so I could save the external flash for FOTA, as FOTA is not possible on TTN, at least not on the free plan.

stefanrueger commented 8 months ago

The MySensors firmware is much smaller so I could save the external flash for FOTA

Understood. BTW, copy_flash_pages() does not need to reside in the bootloader, neither with optiboot nor with urboot as both already have code that allows an application to write a page to flash.

copy_flash_pages() would need to be "out of the way" though, eg, the application could be linked to have three sections

For simplicity maxsize should be a multiple of a page size. For example, for an ATmega328P the page size is 128, a large urboot bootloader takes up three pages, and copy_flash_pages() will easily fit into one page that even leaves space for avrdude -c urclock's metadata. So maxsize is 32768/2 - 256. Note that urboot and optiboot's respective interfaces to write a flash page differ, but I believe that @MCUdude has written a unifying interface that hides the differences.

JAndrassy commented 8 months ago

https://github.com/MCUdude/optiboot_flash/blob/0d634cc1302ad3b1dcb137256edc5a7da5ab0725/optiboot_flash.c#L1187-L1217

JAndrassy commented 8 months ago

Located at the address 2*maxsize (and below the bootloader)

It would require modified linker script(s). Now AVR Arduino platforms uses stock linker scripts from the toolchain. The copy_flash_pages part would be required only in hex for serial upload. For the bin file for (OTA) update it would cause the bin to be as large as the flash (except of the few pages for the bootloader)

stefanrueger commented 8 months ago

@JAndrassy Yes, I realise it's swings and roundabouts.

It would require modified linker script(s).

Not necessarily: one could

Think of copy_flash_pages_below_bootloader.hex as a modular bootloader extension ;)

For the bin file for (OTA) update it would cause the bin to be as large as the flash

I don't understand this probably b/c I don't know how the envisaged OTA works). In my view the OTA upload could send a data stream of no more than maxsize bytes to the application that stores it in the flash space at [maxsize, 2maxsize-1], then calls copy_flash_pages() at the address 2maxsize, eg, through

  ((void (*)())((2*MAXSIZE)/2))();

Does not need parameters when maxsize is agreed beforehand as compile-time constant.

The only disadvantage of this is that the code in copy_flash_pages_below_bootloader.hex is not protected by avrdude nor by the bootloader. But then, optiboot does not protect itself from being overwritten either. In both cases you can use FUSE settings to protect the bootloader + extra module from being overwritten.

eiten commented 8 months ago

OK, thank you, that are some good hints. I'll report back with my progress.