I hope were still saying the same thing, its going to be exactly like hal_bsp_hw_id.
However in the default upstream BSPs how big 64 as it is now? 128 as most uuids are. Is anyone using a serial generation platform of some kind that uses a specific size serial and would weigh in here? On Fri, Jun 22, 2018 at 10:30 AM marko kiiskila <ma...@runtime.io> wrote: > 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. > >>>> > >>>> > >> > >> > >
