> On Jun 16, 2018, at 9:34 AM, Jacob Rosenthal <jakerosent...@gmail.com> wrote:
>
> I think you're saying create a CONFIG_NVMC much like we have CONFIG_FCB and
> CONFIG_NFFS
>
> Looking more into the config system
> "Configuration items are stored as key-value pairs, where both the key and
> the value are expected to be strings"
>
> Im not sure strings and config are a good fit as at least on the nrf
> devices Im familiar with we have a total of 32 32bit registers.
You would not store the key as in it’s full there, just a short key (which
then would be expanded), followed by value.
However, that’s probably too custom of a thing to make a good fit here.
> So I think its more likely well have to have custom functions at the
> bsp/mcu layer much like exsiting nrf52_hw_id.c and then something that
> registers those into strings dynamically into the id package (again like
> hw_id) rather than waste all the memory to duplicate the data as a string…
Yeah, I think that would be better. We could allow that data to be filled in
from BSP code (or wherever). And we should add that model & mfg
pointers as well. This would be an improvement.
> Maybe the bsp/mcu itself can just register a config like "bsp/serial",
> "bsp/custom1" instead of us trying to infinitely extend the id package for
> custom nvmic functions
That, while possible, I would not use. I want to find the identifying pieces
of info from the same place, regardless of BSP/MCU combo.
>
>
> On Tue, Jun 12, 2018 at 3:47 AM marko kiiskila <ma...@runtime.io> wrote:
>
>>
>>
>>> On Jun 12, 2018, at 8:24 AM, Jacob Rosenthal <jakerosent...@gmail.com>
>> wrote:
>>>
>>> I dig the config id package for what it has available, but several things
>>> puzzle me.
>>>
>>> Obviously I can fork this and make all these changes for my project, but
>>> just feeling out how people are using this.
>>>
>>> I tend to think of the id package kind of replacing or being the source
>> of
>>> truth for Device Information service.
>>>
>>> As such I feel like were missing a model/style and manufacturer name
>> value
>>> in here.
>>
>> I think that’s true, those are often used. It started with hwid, and as
>> people
>> don’t want to use that as device id for their stuff, then the serial
>> number.
>>
>>>
>>> Also the serial puzzles me, Is anyone using this? It seems odd to me that
>>> youd have user settable serial number.. Isnt it more likley wed burn a
>>> serial into user registers on the micro? And on top of that its holding
>>> 64byte array by default empty.
>>
>> People are using it. Whether it takes space in RAM or not could be made
>> configurable though.
>>
>> What is missing is a more fine-grained access control,
>> which would allow people access to specific operations, e.g. allow
>> config read but prevent config writes. I would have needed this already,
>> but haven’t had time to think what it should look like :)
>>
>> Updating serial number makes no sense, but you need to be able to set
>> it at the factory.
>>
>>>
>>> What if we expose id/serial to the bsp definition like we do in say
>>> nrf52_hw_id.c and let the user populate it however they like, most likely
>>> from (in this nordic case) UICR->CUSTOMER
>>
>> I would recommend writing a new backend to config, which reads data
>> from UICR. As you might’ve noticed, you can specify multiple sources
>> as a source of config. I have not verified that all the right APIs are
>> exposed
>> by the sys/config to allow config backend to live in a different package,
>> but the intent was that you’d be able to make part of config anywhere.
>> EEPROM has most often been brought up.
>>
>>
