[boot rom] Changing bootstrap protocol

[tjaychen]

There's been some ongoing discussion about how might replace ROM's boot strap protocol today with something that has inband back-pressure, along with a more structured protocol.

One suggestion has been to replace it with something like the spi-flash protocol used to access flash chips. The benefits of doing so is that long term we may be able to use well known tools like dediprog / flashrom to boot strap open titan.

High level steps

@moidx looked into this a little and believes the ROM / hardware would need to support the following

• Bootstrap pin low + toggle reset: Enter bootstrap mode. ROM enables EEPROM mode.
• WREN + CE + RDSR: Perform full flash erase. This step is required before allowing any writes. We need to discuss what gets erased here.
• WREN + CP (address + 2bytes) + UntilDoneWriting: {RDSR + CP (next 2 bytes)} + WRDI + RDSR: Write the image to flash. In this case we are only allowing continuous program mode. Need to check if we can allow other modes. Requires FW to:
  • Only allow programmable bank start addresses.
  • Perform address range and other sanity checks (refuse payloads with invalid manifest start or address ranges).
• READ/FAST READ:
  • This is usually done, but can we support it?
  • Allow the host to readback the image for consistency checks.
  • Need to determine if an user can toggle bootstrap mode to readback the image. Alternatively, can we store a hash of the entire image and write it somewhere (e.g. custom opcode)?

Opcodes used for reference:

Opcode	Description
WREN (06)	Write enable
CE (60 or C7)	Chip erase
CP (AD)	Continuous program mode
RDSR (05)	Read status register
RDSCUR (2B)	Read security register (this may be used if needed).
WRDI (04)	Write disable
RSTEN (66)	Reset enable
RST (99)	Reset command

[tjaychen]

@lenary This was something we discussed some time ago.. since it would be really nice to have a flow controlled protocol while boot strapping.

However, before we switch to a mode like this, we should double check with Nuvoton to understand what kinds of limitations ATE machines. A lot of times ATE machines are not happy with flow controlled protocols and are not good at retrying when something isn't ready.

[lenary]

I am drastically underqualified to review this proposal. This is for the step(s) after the pin toggling, right?

Tagging @mcy as he is leading the implementation of the Mask ROM bootstrap functionality.

[tjaychen]

Actually I think it would be okay to table this to a bit later... at least until after some of the manufacturing / provisioning discussions with Nuvoton have finalized.

[cfrantz]

I've written a Proposal Document which captures the technical details at the start of this bug.