NRF54L15 ReRAM write-block-size in DTS

[Radoslaw Koppel]

Further into development of the ReRAM file system. I noticed that in generated DTS for nRF54L15 board for the ReRAM we have:

cpuapp_rram: rram@0 {
        compatible = "soc-nv-flash";
        erase-block-size = < 0x1000 >;
        write-block-size = < 0x10 >;
        reg = < 0x0 0x165000 >;
        partitions {
                compatible = "fixed-partitions";
                #address-cells = < 0x1 >;
                #size-cells = < 0x1 >;
                boot_partition: partition@0 {
                        label = "mcuboot";
                        reg = < 0x0 0x10000 >;
                };
                slot0_partition: partition@10000 {
                        label = "image-0";
                        reg = < 0x10000 0x51000 >;
                };
                slot0_ns_partition: partition@61000 {
                        label = "image-0-nonsecure";
                        reg = < 0x61000 0x51000 >;
                };
                slot1_partition: partition@b2000 {
                        label = "image-1";
                        reg = < 0xb2000 0x51000 >;
                };
                slot1_ns_partition: partition@103000 {
                        label = "image-1-nonsecure";
                        reg = < 0x103000 0x51000 >;
                };
                storage_partition: partition@15c000 {
                        label = "storage";
                        reg = < 0x15c000 0x9000 >;
                };
        };
};

What is the reason for providing erase-block-size to the 0x1000 value while the memory does not require erasing? I would expect it to be rather set to the same value like write-block-size. It provides now this value via page layout related functions.

[Turbo J]

Probably just copied from code used on other MCUs.

The value has to match what mcuboot was compiled with, and I don't think it can be as small as 16 bytes. Mcuboot checks page size from the image header and refuses the update when it reads a mismatched value.

[Radoslaw Koppel]

Ok. I can see that mcuboot creates a structure that holds information about all sectors, where sectors refers to minimum erase size. Setting it to 16 would require to hold almost 100 000 such entries. Every one holding offset and size. We do not have enough RAM for such configuration.

It seems that for optimal usage of ReRAM or MRAM properties we need to reimplement loader.c file. Maybe some updates to swap_move and swap_scratch. Seems like mcuboot is totally not prepared for NVM technologies that do not require memory erase before programming and RRAM together with MRAM drivers are providing kind of a gimmick to present as an ordinary FLASH driver. It does not seem as a very robust solution but I suppose there are no resources to redesign the whole bootloader. But maybe mcuboot is not the best choice for the future as the FLASH technology for with it was prepared does not scale down well?