I’m thinking maybe we’d just malloc() that thing, if it comes from sys/config. And allow it to be set by BSP, and add that model/mfg info. Following the same model with those ones.
> On Jun 22, 2018, at 10:04 AM, Jacob Rosenthal <jakerosent...@gmail.com> wrote: > > So now I think we just need to argue about the default serial size in the > upstream bsps. With something similar to chris's recent pr on hw_id_size > people can redefine size to whatever they want when they alter bsp, but > what should the default bsp size be? The existing id package is 64 > chars. UUID's nowadays are 128bit, ie 4 of the 32bit uicr registers on a > nordic which I guess is what Id naively argue for. How are others doing > serials these days? Is there an existing proprietary/open backend for > serial generation that we could keep in mind? I saw that bitmark thing > recently. > > > On Mon, Jun 18, 2018 at 11:31 AM marko kiiskila <ma...@runtime.io> wrote: > >> >> >>> 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. >>>> >>>> >> >>
