Using Partition Manager created partitions for FatFS

I have an issue with using partitions created by PM in external flash. I can create a partition in my prj.conf file and use that and everything works. But I need to put some data into the external NOR memory. PM creates the partitions correctly as far as I can see. But I have not found a way to make the FatFS driver correctly find those partitions. Basically I have the exact same issue as in this ticket:  How to reference PM generated partitions from device tree? 

I need to create a disk like this for FatFS driver to find.

/ {
	msc_disk0 {
		compatible = "zephyr,flash-disk";
		partition = <&external_flash>;
		disk-name = "NAND";
		cache-size = <4096>;
	};
};

If I have the partition in internal memory I can at least make this compile (the partition is tiny so it won't work for my application)

&flash0 {
	partitions {
		compatible = "fixed-partitions";
		#address-cells = <1>;
		#size-cells = <1>;

		boot_partition: partition@0 {
			label = "mcuboot";
			reg = <0x0 0xc000>;
		};
		slot0_partition: partition@c000 {
			label = "image-0";
			reg = <0xc000 0x72000>;
		};
		slot1_partition: partition@7e000 {
			label = "image-1";
			reg = <0x7e000 0x72000>;
		};
		scratch_partition: partition@f0000 {
			label = "image-scratch";
			reg = <0xf0000 0xa000>;
		};
		storage_partition: partition@fa000 {
			label = "storage";
			reg = <0xfa000 0x5f00>;
		};
		external_flash: partition@fff00 {
			label = "external_flash";
			reg = <0xfff00 0x100>;
		};
	};
};

The external memory itself is fine and I can read/write it with flash_area_read() and flash_area_write() functions. 

Is there a way to reference the PM created partitions from within the devicetree file of my main application?

  • Hi Simon,

    Thank you for checking with the devs.

    What I'm currently doing is patching each new version of the SDK by just hardcoding the "area_id" value in /zephyr/drivers/disk/flashdisk.c to 6 (6 being specific to my partition manager created partition for the flashdisk). 

    The macro that defines all the flashdisks uses DT_FIXED_PARTITION_ID(PARTITION_PHANDLE(n)) and that seems to only work for partitions defined in the devicetree. I tried my best to figure out how to change this macro to read the Partition Manager output but due to time constraints I can't put more time into this. Since we only really need one flashdisk this hardcoded partition id works for us for now. We are not likely to change our memory layout either so it should be safe for now.

    What your devs would need to do is replace the macro with one that can actually read Partition Manager outputs when that is used instead of the dts file.

    Best regards,

    Tiit

  • Thanks for the update Tiit, and for your feedback/suggestions.

    Got an update just now: We do not have a fix yet I'm afraid. However, as long as you leave space on the device that can be used for storage, that space can be repurposed. The bootloader will only be interested in the areas defined for it (primary and secondary application slot for example). Once you build the bootloader it will only know of the defined areas and not try to access anything else. 

    So for example, 

    +---------------------+------------------------------------+------------------------------------------+---------------------------------------------+
    | Bootloader (size A) | App primary slot (offset A, size B)| App secondary slot (Offset A + B, size C | Unallocated space (offset A + B + C, size D |
    +---------------------+------------------------------------+------------------------------------------+---------------------------------------------+
    
    Total flash size A+B+C+D.
    In the above flash map only the applications will have ability to later allocate the "Unallocated" space, if they want to. The bootloader and app will be bound to slot sizes and the bootloader will only know of the position of the bootloader, and app slots. So it should be fine to add a patch for this later.
    Best regards,
    Simon
  • Hello

    I just wanted to let you know that a potential fix for this issue is currently in review. See this pull request for details: https://github.com/nrfconnect/sdk-nrf/pull/11802 

    Best regards,

    Simon

Related