Thank you Alan, that is even better.
Another option is to introduce a separate configuration option, e.g.
CONFIG_BOARDCTL_RP2040_HARDWAREID. If that is set, code would be compiled to
return a unique id based directly on hardware values, independent of the
relative sizes of the CONFIG_BOARDCTL_UNIQUEID_SIZE and RP2040_FLASH_ID_SIZE.
If it is not set, Adam's code would be compiled and kick in.
If the flash hardware id is copied and not hashed, one thing to consider is
where the bytes should go in the NuttX unique id. If a subset of the 8 bytes
will be used in a shorter unique id variable, I suggest the least significant
bytes of the hardware id are used (as returned by the Pico SDK). But if the 8
byte hardware id will be put in a unique id variable that is larger than 8
bytes, will they be in the least significant bytes or in the most significant?
Also here I would suggest the least significant ones.
In any case, after feedback on the list, I can draft a proposal and prepare a
merge request.
Cheers,
Anders
On Monday, 1 April 2024 at 23:18, Alan C. Assis <acas...@gmail.com> wrote:
> Should it be:
>
> #if CONFIG_BOARDCTL_UNIQUEID_SIZE <= RP2040_FLASH_ID_SIZE ?
>
> BR,
>
> Alan
>
> On Mon, Apr 1, 2024 at 5:45 PM Anders andyl...@proton.me.invalid wrote:
>
> > Hi,
> >
> > The unique id solution for the Raspberry Pi by Adam and his team works
> > very well. However, I suggest a slight modification of the code. In short,
> > if the number of bytes of the NuttX unique id is configured equal to the
> > actual number of bytes of the id in the Pico flash hardware system (8
> > bytes), the hardware id is just copied and not used as a PRNG seed. If the
> > configured size of the NuttX unique id is larger than the flash hardware,
> > the PRNG code is used to return a unique id with more (non-zero) bytes. The
> > advantage of having the function returning the actual hardware id, is that
> > this is easily compared to the id returned by the Pico SDK function.
> > Remember that the number of bytes (bits) in the flash hardware id sets a
> > limit on how many unique ids there are, even if those are embedded
> > (distributed) in a larger number of bytes (bits), as is the result of the
> > PRNG function.
> >
> > The suggested code (from the
> > boards/arm/rp2040/common/src/rp2040_uniqueid.c):
> >
> > void rp2040_uniqueid_initialize(void)
> > {
> > uint8_t txbuf[RP2040_FLASH_ID_BUFFER_SIZE];
> > uint8_t rxbuf[RP2040_FLASH_ID_BUFFER_SIZE];
> >
> > memset(g_uniqueid, 0xac, CONFIG_BOARDCTL_UNIQUEID_SIZE);
> > memset(txbuf, 0, RP2040_FLASH_ID_BUFFER_SIZE);
> > memset(rxbuf, 0, RP2040_FLASH_ID_BUFFER_SIZE);
> > txbuf[0] = RP2040_FLASH_RUID_CMD;
> >
> > rp2040_flash_cmd(txbuf, rxbuf, RP2040_FLASH_ID_BUFFER_SIZE);
> >
> > #if CONFIG_BOARDCTL_UNIQUEID_SIZE == RP2040_FLASH_ID_SIZE
> > for (int i = 0; i < CONFIG_BOARDCTL_UNIQUEID_SIZE; i++)
> > {
> > g_uniqueid[i] = rxbuf[i + RP2040_FLASH_ID_BUFFER_OFFSET];
> > }
> > #else
> > /* xorshift PRNG: */
> > uint64_t x;
> > x = *(uint64_t *)(rxbuf + RP2040_FLASH_ID_BUFFER_OFFSET);
> > for (int i = 0; i < CONFIG_BOARDCTL_UNIQUEID_SIZE; i++)
> > {
> > x ^= x >> 12;
> > x ^= x << 25;
> > x ^= x >> 27;
> > g_uniqueid[i] = (uint8_t)((x * 0x2545f4914f6cdd1dull) >> 32);
> > }
> > #endif
> > }
> >
> > Any comments?
> >
> > Anders
> >
> > On Monday, 18 March 2024 at 06:51, Anders andyl...@proton.me.INVALID
> > wrote:
> >
> > > Hello Adam
> > >
> > > Excellent! Precisely what I was looking for. I'll check it out.
> > >
> > > Thanks,
> > > Anders
> > >
> > > On Sunday, 17 March 2024 at 12:54, Adam Comley a...@novators.net wrote:
> > >
> > > > Hi Anders,
> > > >
> > > > I recently had a need for this feature as well, and put together a PR
> > > > based on the pico-sdk implementation. See:
> > > >
> > > > https://github.com/apache/nuttx/pull/11927
> > > >
> > > > Hope this helps.
> > > >
> > > > -- Adam
