Hi lili,

It is "-fomit-frame-pointer" added to the CFLAGS that you can use in debug mode to resolve this.

Thanks,
David Garske, wolfSSL

Hi ballen,

To accomplish a split partition between onboard and external QSPI you will need to implement your own custom image_sha256() function to have awareness of the partition geometry, since the SHA calculation is currently done on contiguous addresses.

We support the NXP Kinetis K82 hardware and the K81 is compatible. The FRDM-K82F board we use for testing has an external QSPI with XIP support, which I have used successfully. However, I have not tried setting up a split boot partition. If you would like some consulting help with this feature please email facts@wolfssl.com with some project details and we can quote this. If you would like to implement support and provide these changes upstream feel free to open a GitHub pull request.

Thanks,
David Garske, wolfSSL

Hi Reid,

Thanks for the pointer to the benchmarking code argument issue. I'll post a fix for shortly.
The benchmarking isn't testing the data inputs/outputs, so the use of the buffer is not critical.

If you are looking for AES CBC test cases see wolfcrypt/test/test.c -> `aes_cbc_test`.

Are you seeing the AES benchmarks you expected? Depending on your platform you might consider using `--enable-intelasm` or `--enable-armasm` to speed up symmetric AES/SHA.

Let me know if you have any further questions.

Thanks,
David Garske, wolfSSL

Hi François,

This is a great question! Currently our TIS layer uses polling to detect data ready, however some TPM's do have an interrupt pin available. I have the ST33 TPM and will look into adding this feature. Aside from the physical GPIO it will also depend on how the ST33 enables the IRQ pin use.

Until then another option is to implement a delay in the polling period using the `XTPM_WAIT` macro, which you can define like this

#define XTPM_WAIT() usleep(1000)

.

If you do end up making changes to wolfTPM for IRQ support and would like to contribute them back, you are welcome to open a PR and sign a contributor agreement.

Thanks,
David Garske, wolfSSL

Hi r-type,

Were you able to get wolfTPM working with the Asus E15028 (Nuvoton NPCT750) on a Pi? Make sure you have the SPI wait state build option enabled `WOLFTPM_CHECK_WAIT_STATE` or use the `./configure --enable-nuvoton` option. Note: I pushed a wolfTPM v2.3 release this week, which does have some Nuvoton Fixups.

Thanks,
David Garske, wolfSSL

Hi Mor71,

Thank you so much for this report! I was able to reproduce and locate the server side bug. I've put up a fix here:
https://github.com/wolfSSL/wolfssl/pull/4509

Let me know if you continue to see any issues.

Thanks,
David Garske, wolfSSL

Hi Elliot,

To be clear, wolfSSL does not require an RTOS. In the generated configuration if no RTOS is selected it will define SINGLE_THREADED. It is only our TLS in-memory example since it starts multiple threads, although even that could be written non-blocking and used in bare-metal with shared memory.

Let us know if you have any questions. It would be great to hear more about your project so we can best support you.

Thanks,
David Garske, wolfSSL

Hi r-type,

That is a great little module ASUS has for their motherboard. The steps you listed for wolfTPM with direct /dev/spi access looks great. Make sure you have the right SPI chip select. The PI has two and they are "/dev/spidev0.0" and "/dev/spidev0.1". The modules Nuvoton provides for the Pi use CS0 (Pin 24).

Also the reset line is active low, so if pulled low it will hold in reset, so make sure it is high. Also you should make sure you have a pull-up on the Chip Select pin to make sure it is only active when the Pi drives it. I would leave the IRQ line alone and not tie to anything. Use 3.3v for VCC.

Thanks,
David Garske, wolfSSL

Hi raghu,

I also had that issue at first. Make sure you've pulled that branch and reconfigured your cmake. You might even need to delete wolfssl/options.h.

git fetch origin pull/4368/head:cmake_cflags
git checkout cmake_cflags
rm wolfssl/options.h
rm -rf build
mkdir build
cd build
cmake -DCMAKE_C_FLAGS="-DWOLFSSL_AESGCM_STREAM" ..
make

Let us know if that does not help.

Thanks,
David Garske, wolfSSL

Hi ACV,

You can instead call `wolfCrypt_Init` and `wolfCrypt_Cleanup`. For most use-cases you are not required to call these, but I recommend it to future proof yourself.

Thanks,
David Garske, wolfSSL

Hi ACV,

Have you seen our RISC-V examples here? https://github.com/wolfSSL/wolfssl/tree … /IDE/RISCV

To build wolfCrypt only you can define `WOLFCRYPT_ONLY` and compile the source files in wolfcrypt/src/*.c that are applicable. If you are not cross-compiling with ./configure I would recommend defining CFLAG -DWOLFSSL_USER_SETTINGS and adding your own `user_settings.h` file. Your include path needs to be in the wolfssl root. Then in your application make sure you include wolfssl/wolfcrypt/settings.h prior to any other wolfSSL headers.

We have some user_settings.h examples here:
https://github.com/wolfSSL/wolfssl/tree … es/configs

This is also covered in the FAQ here:
https://www.wolfssl.com/docs/frequently … r_wolfSSL?

Let us know if you have any issues.

Thanks,
David Garske, wolfSSL