Hello Rouven. Thanks for your response. We will need another hardware update before production so we will try to get this added. Regards, Lars Pedersen On Mon, 12 Apr 2021 at 14:22, Rouven Czerwinski <r.czerwinski@xxxxxxxxxxxxxx> wrote: > > On Mon, 2021-04-12 at 13:24 +0200, Ahmad Fatoum wrote: > > Hello Lars, > > > > On 12.04.21 12:45, Lars Pedersen wrote: > > > > > +#define BOARD_RESTART_GPIO IMX_GPIO_NR(7, 12) > > > > > +#define TPM_RESET_GPIO IMX_GPIO_NR(3, 8) > > > > > + > > > > > +static void kamstrup_mx7_tpm_reset(void) > > > > > +{ > > > > > + imx7_setup_pad(MX7D_PAD_LCD_DATA03__GPIO3_IO8); > > > > > + > > > > > + gpio_request(TPM_RESET_GPIO, "tpm-reset"); > > > > > + gpio_direction_output(TPM_RESET_GPIO, 1); > > > > > + mdelay(100); > > > > > + gpio_set_value(TPM_RESET_GPIO, 0); > > > > > + mdelay(100); > > > > > + gpio_set_value(TPM_RESET_GPIO, 1); > > > > > + gpio_free(TPM_RESET_GPIO); > > > > > > > > We are trying to cut down on code that doesn't use the driver model. > > > > Couldn't this be represented as a gpio-hog in the device tree or > > > > a reset line for the SPI device? > > > > > > I can't find anything in the DT binding for the SPI/TPM driver to use > > > a reset line. > > > > Proper way would be for this to be added into Linux then, > > but that's out of scope for the patch here. > > > > > Can a DT gpio-hog toggle the pin? Don't you need a > > > driver for this? > > > > You can't pulse with a gpio-hog. I assumed the TPM is in reset by > > default. > > > > > I see the following options: > > > > > > 1) gpio-hog with a label and use new gpiolib in board.c. > > > 2) gpio-hog and control the pin in a boot script. > > > > If there's no straight-forward way to do it without board code, > > it's ok the way it is with one change though: I missed it the first > > time, but your board breaks multi-image support because you don't > > check whether the initcall is indeed running on your board (See for > > example imx_v7_defconfig, which builds over a hundred boards at once). > > > > Easiest way to get this right is to write a board driver. > > See arch/arm/boards/lxa-mc1/board.c for an example. > > TPMs usually don't have a reset line since it is a hardware misdesign > if the reset needs to be done within the bootloader. This opens up the > TPM to an attack where the system is properly booted, unlocking keys > which are only accessible if the correct PCR sequence is send to the > TPM. Than the attacker resets the hardware/CPU, but potentially loads > up a different bootloader or tricks the bootloader into skipping the > TPM reset. This will leave the TPM keys accessible even if the system > has not been booted with the correct measured boot values. Boards with > TPMs should be designed so that a CPU-Reset always results in a TPM > Reset as well. > > Regards, > Rouven > _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox