FLC Auditing

[MelonShooter]

Auditing FLC Implementation for deviations in the SDK and user guide

References:
User guide - page 122
Our HAL's FLC driver
MSDK's FLC Common Source File
MSDK's FLC Revision-specific Source File
MSDK's FLC Platform-specific Source File

[suaviloquence]

• update flc tests to test with semihosting and with uart

[MelonShooter]

Deviations from the SDK:

• The SDK clears the FLC interrupt register before most operations. We don't do this and it's not specified in the user guide. It's likely for interrupt functionality which we don't support so we'll skip this for now
• For ICC Flush, the SDK invalidates the cache at the start of ICC Enable, with no other checks or early returns. The ICC flush function calls ICC Disable and then ICC Enable.
• We read 4 bytes from two pages to clear the line fill buffer, the MSDK nor the user guide do/mention this
• For set_clock_divisor, we dont do a busy wait loop, which makes set_clock_divisor unsafe as it must be done after the FLC is ready. This led to incorrect usage in our write implementations. We should create a safer function to use ONLY for writes similar to MSDK's prepare_flc following operation with some modifications - called flc_write_guard:
  • check address bounds
  • busy loop until flc ready
  • disable icc0
  • clear interrupts register
  • set clock divisor
  • unlock write operations
  • EXECUTE CLOSURE
  • lock write operation
  • flush icc
  • enable icc0
• this new flc_write_guard or whatever we want to call it will be used in write128, page_erase, and mass_erase if it's ever implemented
• all flc write subfunctions should be marked as unsafe with safety comments
• IMPORTANT: benchmark verifying a 4kb subscription AND writing it to flash
• If this operation takes too long, try verifying a hash of the subscription instead or move the icc operations out
• For check_address_bounds, we might want to be generic over the range type to make it more flexible.

Deviations from the user guide:

• Neither our HAL nor MSDK zeroize the ICC instance by setting GCR_MEMZ.icc0 to 1
• The user guide says "Writes to a flash address are only successful if the target address is already in its erased state". This is potentially ambiguous. Does it refer to the FLC_ADDR register needing to be be reset, to 0x0 or 0x1000000? Or does it refer to the page needing to be erased at the target address? Or does the memory in the bounds of what you're writing need to be erased? Neither our HAL nor MSDK page erases before doing an FLC write