See Section 29 of the datasheet:
The Boot Loader Support provides a real Read-While-Write Self-Programming mechanism for downloading and uploading program code by the MCU itself. This feature allows flexible application software updates controlled by the MCU using a Flash-resident Boot Loader program. The Boot Loader program can use any available data interface and associated protocol to read code and write (program) that code into the Flash memory, or read the code from the program memory. The program code within the Boot Loader section has the capability to write into the
entire Flash, including the Boot Loader memory. The Boot Loader can thus even modify itself, and it can also erase itself from the code if the feature is not needed anymore. The size of the Boot Loader memory is configurable with fuses and the Boot Loader has two separate sets of Boot Lock bits which can be set independently. This gives the user a unique flexibility to select different levels of protection.
The Application section is the section of the Flash that is used for storing the application code. The Application section can never store any Boot Loader code since the SPM instruction is disabled when executed from the Application section.
While the Application section is used for storing the application code, the The Boot Loader software must be located in the BLS since the SPM instruction can initiate a programming when executing from the BLS only. The SPM instruction can access the entire Flash, including the BLS itself.
The program memory is updated in a page by page fashion. Before programming a page with the data stored in the temporary page buffer, the page must be erased. The temporary page buffer is filled one word at a time using SPM and the buffer can be filled either before the Page Erase command or between a Page Erase and a Page Write operation:
If only a part of the page needs to be changed, the rest of the page must be stored (for example in the temporary page buffer) before the erase, and then be rewritten.
Boot size choices: 1K bytes, 2K bytes, 4K bytes, or 8K bytes (K=1024)
Read-While-Write section (RWW), 992. 0x00000 - 0x1EFFF
No Read-While-Write section (NRWW), 32. 0x1F000 - 0x1FFFF
RWW – Read-While-Write Section
If a Boot Loader software update is programming a page inside the RWW section, it is possible to read code from the Flash, but only code that is located in the NRWW section. During an on-going programming, the software must ensure that the RWW section never is being read. If the user software is trying to read code that is located inside the RWW section (that is, by load program memory, call, or jump instructions or an interrupt) during programming, the software might end up in an unknown state. To avoid this, the interrupts should either be disabled or moved to the Boot Loader section. The Boot Loader section is always located in the NRWW section.
NRWW – No Read-While-Write Section
The code located in the NRWW section can be read when the Boot Loader software is updating a page in the RWW section. When the Boot Loader code updates the NRWW section, the CPU is halted during the entire Page Erase or Page Write operation.
So, what you seek in general is possible. Could lead to big performance hits as entire pages must be read, modified, and rewritten. I'm with AWOL, using an external device, I'd personally go with SPI interface for speed, would be way less complicated. SD card is only accessible via SPI interface. FRAM has speed of SRAM and non-volatility of EEPROM.