Store filename and time?

[tannewt]

Could we come up with a way to store the filename and datetime of the latest uf2 file? It'd be great to see PXT-v1.2.uf2, Arduino-1.8.uf2 or micropython-1.8.6.uf2 instead of Current.uf2 when in mass storage mode. Ideally it'd actually be in the flashed region so flashing other ways would also update it.

[mmoskal]

This is a really good idea!

In general I would like to have a region in flash that stores a descriptor for content, in particular some form of checksum for application defined regions of flash and also metadata like the name. Note that the name can be only up to 8 characters, unless we implement VFAT.

The checksums are useful for partial flashing of device over slow links (HID, or even more importantly Bluetooth LE). In PXT flash has at least two regions - one is pre-compiled runtime, which only changes if you add new C++ libraries to the project, and the other (usually much smaller) is the compiled user program.

[finneyj]

Right - we should totally do this. We're likely to be revisiting the BLE loader soon...

I think there'd be two obvious laces to store it:

• at the top of FLASH memory. There's always contention for the early FLASH pages, and anywhere in the middle would cause fragmentation that would be difficult to manage with heterogeneous environments.

• Alternatively, is there space at the top of the 8K bootloader section for a memory map and meta data?

[mmoskal]

Depending on configuration, there might be very little space left in the bootloader. Also, we don't really want the bootloader to write over itself as this can cause lockups, and additionally it might be write protected.

I think after the vector table would be a good place, maybe starting with a magic number so we can accomodate vector table growing in the future. It requires a modification to the linker script though.

[finneyj]

good point about using bootloader space. Agree we should avoid having the bootloader overwrite itself wherever possible. I was wondering about turning these regions into proper, memory protected segments too - storing them as BASE/LIMIT might be efficient.

After vector table sounds fine for SAMD, but would likely cause problems for nrf51/52 using SoftDevice stacks, so we couldn't reuse this location for micro:bit and friends. I'll check though...

I guess we could have different memory locations for different processors if needed (as we'd need different loader implementations anyway), but we can still be consistent about the structure of the metadata block...

[ladyada]

shoot sorry, i didnt mean to close!

[mmoskal]

For reference, the draft spec for partial flashing is here: https://makecode.com/partial-flashing (and also here https://github.com/Microsoft/pxt/blob/master/docs/partial-flashing.md )

[stevenj]

Suggestion to implement this. Use the "RESERVED" area of the vector table. But the application has to set a name there itself, it's not the bootloaders job. Just the bootloader can read that area and get a name.

Something like this:

use:

        .pvReservedM9           = (void*) (0UL), /* Reserved */
        .pvReservedM8           = (void*) (0UL), /* Reserved */
        .pvReservedM7           = (void*) (0UL), /* Reserved */
        .pvReservedM6           = (void*) (0UL), /* Reserved */

Redefine:

• M9 as a Magic Number, to use to tell if M8-M6 hold the file name and/or file CRC.
  M9 = '1abe1ed' + 4 bits of flags.
  • Bit 0 = Name Present.
  • Bit 1 = CRC Present.
  • Bit 2 = reserved (0).
  • Bit 3 = reserved (0).
• M8-M7 are the name 8 Characters MAX, null terminated for short names.
• M6 [High Word] = Number of Flash pages constituting the CRC Check.
• M6 [Low Word] = CCITT CRC16 of those flash pages.
• M3 is also available, and could be used to store an extra 4 bytes of information for the bootloader.

Most (ALL?) apps will use a standard vector table which means these reserved areas will be 0x00. However, if an App wants to give information to the bootloader, such as its name and it's CRC, it can populate them like this, and the bootloader can rely on it.

It would be possible and appropriate to automatically populate this area when generating the UF2 file. However I do not think the bootloader should modify the uploaded binary and insert them.

Also, even though these areas are "reserved" thats only as far as the ARM Cortex implementation is concerned, they are just flash words, and can contain any data. There is no rule that says these words MUST be 0x00. I chose these reserved words because they are common between SAMD21 and 51, so the logic to handle it would be common. nRF51 is also a Cortex M0 core, so these words also should be reserved on it, but i haven't checked it's data.