Skip to content

Embed Serial Number #4

Open
Open

Description

@JohnAZoidberg

Put somewhere it won't be overridden by the customer flashing their own firmware.

Two options:

  • Embed with linker script
  • Embed with UF2

For both we have to create a build script that builds a different variant of the firmware.
The script accepts the serial number and embeds it in the image.

The regular build script that customers would use builds an image that doesn't include this section with the serial number. And it also must avoid overriding the serial number when flashing.

Linker Script

The serial number could be embedded in the executable via a linker script. QMK let's you easily use your own linker script.
@kiram9 you suggested this. How would we avoid the customer overwriting the serial number when they flash their own binary?

WIP branch: https://github.com/FrameworkComputer/qmk_firmware/commits/lotus-ld

UF2

A UF2 file is just a series of independent 512B blocks that each say which address they should be flashed to and include the data.
I think if we put a block at the end it won't interfere with the firmware. But the script must check that there is enough empty space.
We can reserve one of these blocks for the serial number. The factory build script includes this block in the UF2 file, the regular script doesn't.

This way the serial number is preserved if the customer uses the default build script that we'll upstream to QMK.
They could modify it to overwrite the entire flash.

Activity

  1. JohnAZoidberg commented on Jan 13, 2023

    @JohnAZoidberg
    MemberAuthor

    UF2 should be able to be concatenated.
    So the factory file could be created by running a script on the regular binary:

    ./embed_serial --bin .build/lotus_ansi_default.uf2 --serial 123456789
    
  2. JohnAZoidberg commented on Jan 13, 2023

    @JohnAZoidberg
    MemberAuthor

    If we put the serial number at the end of the flash, users won't accidentally overwrite it if they create a bigger binary.
    Only if it fills the entire flash.

    The flash chip we use supports locking 4K sections. So we could even lock it to avoid it being overwritten.

  3. JohnAZoidberg commented on Jan 16, 2023

    @JohnAZoidberg
    MemberAuthor

    Current solution:

    • Use separate UF2 file that flashes at 0x100ff000. Which is 4KB below 1MB.

    UF2 generation and flashing is done like:

    echo -n 'FRALDLENA120110001' > serial.bin
    ./util/uf2conv.py serial.bin -o serial.uf2 -b 0x100ff000 -f rp2040 --convert
    sudo cp serial.uf2 /media/zoid/RPI-RP2/

    TODO:

    • Create diagram of full memory map including EEPROM emulated area
    • See if we can combine both UF2 files. I tried but the serial number isn't properly written.
    • Make sure the factory script has everything is needs. Serial number generation?
    • Cleaner hook into USB subsystem for iSerialNumber so that we can upstream it
      • And read from flash only once
      • Implement for tmk_core/protocol/vusb/vusb.c
    • Try to write-protect the region
    • Use dummy serial number FRALDLvvccxxxxxxxx if the flash was completely erased
  4. JohnAZoidberg commented on Feb 1, 2023

    @JohnAZoidberg
    MemberAuthor

    VIA puts configuration in emulated eeprom at the end of flash. Might conflict with the serial number.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    cleanupWorking but needs cleanupin progresswork in progresspvtShould be ready for PVTstale

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions