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. > >> > >> > >
