What is the use case for needing the ID to match pico-sdk's
implementation?
With the PRNG approach we get some useful properties:
1. Firmware updates can change CONFIG_BOARDCTL_UNIQUEID_SIZE without
affecting the most significant bytes of the board ID. If I'm using 6
bytes for a MAC address (for instance), and later need an 8 or 16 byte
ID for some reason, the first 6 bytes don't change.
2. A user / application can extract any number of bytes from any portion
of the board ID and have a reasonable expectation of uniqueness. The
application doesn't have to care about how the ID was generated or which
set of bytes it should use.
I'm not completely opposed to this idea, but I don't think I understand
the need. If there is a need for this, I would prefer the separate
configuration option.
-- Adam
On 2024-04-02 01:03, Anders wrote:
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
