People who were there (and who's Github handle I know): @LawrenceEsswood, @lschuermann.

Note that I don't think it's necessary to get all the details in this document down now, but an opportunity to add or correct some stuff before we merge this initial draft.

@reynoldsbd

Note that I don't think it's necessary to get all the details in this document down now, but an opportunity to add or correct some stuff before we merge this initial draft.

To clarify: do we want to have this merged in the current form (i.e., skeleton + some context + motivation + concerns) or do we want to add actual technical details in this first iteration?

I would like to add more. I think once this PR is merged the TRD is unlikely to change.

I think what I'm learning from this discussion (and perhaps exactly why I think we need this document) is that "non-XIP" is too broad in practice to be meaningful. I don't think we can effectively design solutions for all non-XIP MCUs. This is no different than Tock not being designed for all "traditional" MCUs (eg 8 bit cores, multi cores, arm A, etc).

I think we need to start with narrowing down non-XIP to a subset for this document. My understanding, from the breakout, is that there is a need to support the small RAM, untrusted nonxip flash use case.

I took the liberty of updating the doc. Happy to bikeshed the name at some point.

This is blocked on feedback from relevant stakeholders either using or planning to use non-XIP platforms:

@LawrenceEsswood @reynoldsbd ?

@ZhekaS it sounds like this may also be relevant to your use case — we welcome any feedback you may have here as well!

@ZhekaS it sounds like this may also be relevant to your use case — we welcome any feedback you may have here as well!

It is very relevant indeed. Rather than providing concrete feedback, I'd rather describe the use-case.
We have an SOC with many different cores on it, while at least one of them is expected to operate under Tock OS. All the firmwares are stored on external SPI-FLASH, and are cryptographically signed. In the boot-time relevant firmware is loaded into the specific component's SRAM where it is being validated (assuming SRAM is secure, it prevents TOCTOU which would be possible if validated in the flash). Then the firmware is being executed from SRAM.
I do not see a big deal with this flow (but I am surely not an expert in TockOS :) ). As long as the TockOS is linked for the correct SRAM location, it should be working out of the box. The only thing, is that the startup code does not need to copy the .data section as it's load address should be the same as execution address in SRAM. Not sure how much MPU/PMP settings need to be adjusted.

This was discussed on the core team call today. While we would still like more feedback from downstream users, this is also version 1 of a draft document, and should not linger as a PR forever.

I'm going to attempt to resolve all of the open discussion threads now, and then ping folks for a merge.

Done — this should be good to go. Will let it sit for a few hours in case anyone sees anything in my edits here they don't like.

Merge this?

Huh, I thought that I removed the litex-sim-ci checks from being required.

Rebased to pick up CI config changes.