Re: unique ID for flash devices

Puzdrowski, Andrzej

Hi Marti


Of course the providing of substitute of flash_area primitives is intermedium step for adding other modules. I will adapt mynewt FCB (Flash Circular Buffer) to zephyr, I will take mynewt Config module (or something very similar ) as well. What I also potentially want to do providing something like mynewt’s Manufacturer meta region is – this would be useful for inform both bootloader and application about how memory map looks like. I think that zephyr flash_map will simplify support for multi-memories and multi-images mcuboot support as well or event we can support dynamic image slots allocation basing on that (so will be possible to change flash areas boundaries during FWU – we see the case for that).


What I already do is that I took some part of your job from mcuboot as well. I thing after this It will be possible (even necessary) to use zephyr flash_map instead of mcuboot one.


> “Hard Link” – sory for this ambiguity. I mean that I need to define a proper way to describe Flash entity of certain flash_area and assign proper driver to it. It must be a multi applications solution – so basing a few application programed into one SoC will can discovered unambiguously memory layout of the system. I can imagine it would be for example the bootloader, the main application, the falbac application.



From: Marti Bolivar [mailto:marti@...]
Sent: Friday, December 08, 2017 9:29 PM
To: Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devel] unique ID for flash devices


Hi Andrzej,


On Thu, Dec 7, 2017 at 7:50 AM, Puzdrowski, Andrzej <Andrzej.Puzdrowski@...> wrote:

I’m planning to implement abstraction over flash devices driver similar to this what Mynewt has in flash_mam module.

This is using description of different flash areas. Some of this flash areas could be the embedded flash, some else could be an external.


I'm a bit confused about what you will implement based on this description. Zephyr already has equivalents to several functions in this API.



One of features is to provide identification of flash devices for each flash_area. It is important to have “a hard link” in manner which would support

correctlly Identification for a few application existing in one SoC (like case of having common flash memories description for Bootloader and Application)



In particular I don't understand which feature you're referring to here. What do you mean by "hard link"? I assume you're not referring to a hard link in the sense of a file system.


So fare in zphyr API each device is identified by its (configrable) name.

One idea is to introduce fixed Id numbers for each driver and a LUT for making possible to find the link between this ID and the device NAME.

This ID will be used by flash_area descriptions.



It seems like what you want to add is something like the "fa_device_id" field in struct flash_area. That is, an ID number for the flash device that contains a given area. Can you say a bit more about why you need an ID number, and can't just use a pointer to the struct device corresponding to the flash?


Are you trying to support this API for something outside of mcuboot? The mcuboot Zephyr port already has a shim which maps the defines from DT into fields in struct flash_areas in boot/zephyr/flash_map.c.


Maybe someone has got better idea or even my idea is totally wrong – please comment then.



What's this for? Maybe that will help understand.





Andrzej Puzdrowski


Zephyr-devel mailing list


Join to automatically receive all group messages.