addition of uart and uartns550 to swtpm

[JacobBarthelmeh]

No description provided.

[dgarske]

For there UART transport it seems odd to still use the swtpm feature. Is there a reason you didn't set it up as its own transport like SPI/I2C as I did in this PR #286 ?

[JacobBarthelmeh]

Not sure I fully understand, is this pulling the uartns550 additions out of swtpm and placing it in its own location. Possibly something under hal/tpm_io_uartns550 or the like? Which re-looking at it may be a better fit for it. No reason for it to be in the swtpm code other than familiarity with that section of code when doing the work, happy to move it to a better spot.

[dgarske]

Not sure I fully understand, is this pulling the uartns550 additions out of swtpm and placing it in its own location. Possibly something under hal/tpm_io_uartns550 or the like? Which re-looking at it may be a better fit for it. No reason for it to be in the swtpm code other than familiarity with that section of code when doing the work, happy to move it to a better spot.

I see... you are still using the SWPTM packet framing (locality, TX size, packet, RX size, etc..) but you are adding UART transport instead of socket.
For some reason I was environing this solution looking more like a physical TPM, not SWTPM.
Keep this as-is for now.

[dgarske]

Looks great and tested it out. Just one minor suggestion.

[dgarske]

Would prefer a different build option to make this a non-static non-thread local. Maybe WOLFTPM2_PUBLIC_CTX?

[gojimmypi]

Hi @dgarske and @JacobBarthelmeh - just wondering what's the status of this PR?

I see there's a useful DEBUG_PRINTF proposed. I almost when down a similar path, but ended up changing my mind.

I have a similar change in the works, but using the ERROR_OUT(rc, exit) pattern found in the wolfCrypt test.

This is all in relation to my #351 adding Espressif TPM support, and in particular the ability to use the colorization of messages, such as the red ESP_LOGE() messages.

Any preference here?

[JacobBarthelmeh]

@gojimmypi it's been blocked on me. I went back and rebased it but after the rebase it was not working like I expected. Have not resolved that yet.

Yeah the abstraction of printf's saved a large amount of data when trying to debug in a resource constrained device that had a light version of printf.

My preference is not having ERROR_OUT and goto's.....that a preference though.

[gojimmypi]

@JacobBarthelmeh I hear ya on the goto's. I too, have mixed feeling about using them. It can be acceptable if used properly.

@dgarske has quite a few instances of the goto exit pattern, which of course lend themselves to easily adapting to ERROR_OUT.

In any case, I'll hold off on that for now.