cortex-m icon indicating copy to clipboard operation
cortex-m copied to clipboard

Provide storage section for writable flash memory

Open Nemo157 opened this issue 7 years ago • 5 comments

This may be getting a bit too complex to call "minimal", but to support applications that require some permanent storage there needs to be a section defined for that. This probably requires adding the flash page size into memory.x, then having a section something like

.storage BLOCK(_page_size) (NOLOAD) :
{
    FILL(0xFF)
    *(.storage .storage.*)
    . = ALIGN(_page_size);
} > FLASH

If possible, aligning in between each .storage.* section would be wonderful to allow having separately erasable sections (although, I don't know any way to do so).

(Note, I have only used flash storage on the nrf51, I assume other cortex-m devices behave similarly, but this may not be general enough).

Nemo157 avatar Mar 20 '18 10:03 Nemo157

@Nemo157 you can try your idea without modifying the cortex-m-rt crate. You can write a standalone linker script, e.g. named storage.x, and then pass that as a -Tstorage.x argument to the linker (cf. cargo/config).

If possible, aligning in between each .storage.* section would be wonderful to allow having separately erasable sections (although, I don't know any way to do so).

I don't think you can do that using just linker scripts but if what will be placed in .storage are static variables you may be able to do something like this:

#[link_section = ".storage"]
static PAGE: Page = Page { bytes: [0xff; 512] };

#[repr(align = "1024")] // or w/e the page size is
struct Page {
    bytes: [u8; 512],
}

japaric avatar Mar 27 '18 08:03 japaric

You can write a standalone linker script

Yep, that's my current plan. Unfortunately you cannot have multiple SECTIONS defined in different linker scripts, so that requires copying the full link.x into the application.

It will be a little while till I get round to actually using something like this in my current project, once I do I'll see if I can come up with something that is usable in this crate (although, I think generally writing to flash will require accessing a vendor specific memory controller, so I don't know if there's some abstraction that could live here or not).

Nemo157 avatar Mar 27 '18 08:03 Nemo157

Unfortunately you cannot have multiple SECTIONS defined in different linker scripts, so that requires copying the full link.x into the application.

Is that right? It seems to work for me after a quick test. I got no linker error and the new linker section I created is there.

japaric avatar Mar 27 '18 09:03 japaric

Hmm, you may be right. I'm sure I tested this earlier and had it ignore the sections specified in link.x when I added some extras, but it looks like it's working when I test it now.

Nemo157 avatar Mar 27 '18 09:03 Nemo157

Triage: This seems too specific to add to cortex-m-rt.

Flash memory is generally only writeable after performing some chip-specific steps, and some flash controllers might not support writes to the flash addresses at all (instead funneling writes through a single MMIO register, or via RAM-to-controller DMA without CPU intervention), so the use of this seems limited to only some chips.

Also, I would like to see HALs experiment with possible solutions for this before we consider adding this to cortex-m-rt.

jonas-schievink avatar Jan 07 '21 23:01 jonas-schievink