From: "Marek Behún" <kabel@kernel.org> To: Andrew Lunn <andrew@lunn.ch> Cc: Gregory CLEMENT <gregory.clement@bootlin.com>, linux-arm-kernel@lists.infradead.org, pali@kernel.org, stable@vger.kernel.org Subject: Re: [PATCH mvebu + mvebu/dt64 4/4] arm64: dts: marvell: armada-37xx: move firmware node to generic dtsi file Date: Fri, 12 Mar 2021 16:17:04 +0100 [thread overview] Message-ID: <20210312161704.5e575906@kernel.org> (raw) In-Reply-To: <YEt/Ll08M1cwgGR/@lunn.ch> On Fri, 12 Mar 2021 15:48:14 +0100 Andrew Lunn <andrew@lunn.ch> wrote: > On Fri, Mar 12, 2021 at 10:10:27AM +0100, Marek Behún wrote: > > On Fri, 12 Mar 2021 09:58:34 +0100 > > Gregory CLEMENT <gregory.clement@bootlin.com> wrote: > > > > > Hello Marek, > > > > > > > From: Pali Rohár <pali@kernel.org> > > > > > > > > Move the turris-mox-rwtm firmware node from Turris MOX' device tree into > > > > the generic armada-37xx.dtsi file. > > > > > > I disagree with this patch. This firmware is specific to Turris MOX so > > > it is not something that should be exposed to all the Armada 3700 based > > > boards. > > > > > > If you want you still can create an dtsi for this and include it when > > > needed. > > > > > > Gregory > > > > Gregory, we are planning to send pull-request for TF-A documentation, > > adding information that people can compile the firmware with CZ.NIC's > > firmware. > > > > Since this firmware exposes HW random number generator, it is > > possible that people will start using it for espressobin. > > > > In that case this won't be specific for Turris MOX anymore. > > Part of the problem is that it looks specific to the Turris MOX. > > But please help me understand the big picture first. How is the > firmware distributed? Is the binary part of linux-firmware? How does > it get loaded? Does the firmware contain anything which is specific to > the Turris MOX? Could the hardware number generator part be split out > into a more generic sounding name blob? > > Andrew Hello Andrew, The WTMI firmware is loaded before kernel. This firmware is loaded by BootROM, and it is this firmware that does DDR training before loading TF-A + U-Boot. For example for ESPRESSObin you have several repositories you need to create a final flash-image.bin containing this WTMI firmware + TF-A + U-Boot. These repositories are: trusted-firmware-a (contains documentation how to build all this) A3700-utils-marvell u-boot mv-ddr-marvell From these sources you are able to create a final flash-image.bin that you can flash onto the SPI-NOR (or eMMC or other devices which A3720 can boot from). The A3700-utils-marvell repository contains the code of the WTMI firmware. On Turris MOX this is a little bit different, because - we have implemented the WTMI firmware differently (more mailbox commands, HW crypto, ...) - it supports retrieving MOX board information (MAC addresses, serial number) stored in eFuses (this information is stored in a specific way that in only true for MOX) - the firmware binary must be signed by our private key in order to boot on MOX. This is because the secure firmware has access to an ECDSA engine with a private key storage in eFuses (each MOX has its own private key generated and stored into the eFuses when manufactured) In order to disallow hackers to somehow extract the private key, the firmware must be signed so that they cannot load arbitrary firmware into the secure processor. BUT - since this firmware is able to provide HWRNG, we wanted to make it available for other Armada 3720 boards - we updated the code so that users can build it for non-MOX devices - it does not have to be signed for other devices - it does not contain MOX specific stuff for non-MOX devices So currently when users build the flash-image.bin binary containing WTMI firmware, they are using code from A3700-utils-marvell. This code is split into 2 parts: - sys_init - does HW and DDR initialization and execution of an "app" - efuse - default "app" which is loaded by sys_init The way it is written is that user can select a different "app" when building, and we have updated Turris MOX firmware code to be loadable as this "app" for sys_init. (And we have renamed it from "Turris MOX secure firmware" to "CZ.NIC's Armada 3720 secure firmware"). > Could the hardware number generator part be split out into a more > generic sounding name blob? It basically is. As I have written above, when users build the flash-image.bin with CZ.NIC's firmware, the prompt does not say anything about Turris MOX. Instead it says something like CZ.NIC's Armada 3720 Secure Firmware version build date Running on ESPRESSObin and currently provides only the random number generator command. So theoretically the turris-mox-rwtm driver can be renamed into something else and we can add a different compatible in order not to sound so turris-mox specific. Marek
WARNING: multiple messages have this Message-ID (diff)
From: "Marek Behún" <kabel@kernel.org> To: Andrew Lunn <andrew@lunn.ch> Cc: Gregory CLEMENT <gregory.clement@bootlin.com>, linux-arm-kernel@lists.infradead.org, pali@kernel.org, stable@vger.kernel.org Subject: Re: [PATCH mvebu + mvebu/dt64 4/4] arm64: dts: marvell: armada-37xx: move firmware node to generic dtsi file Date: Fri, 12 Mar 2021 16:17:04 +0100 [thread overview] Message-ID: <20210312161704.5e575906@kernel.org> (raw) In-Reply-To: <YEt/Ll08M1cwgGR/@lunn.ch> On Fri, 12 Mar 2021 15:48:14 +0100 Andrew Lunn <andrew@lunn.ch> wrote: > On Fri, Mar 12, 2021 at 10:10:27AM +0100, Marek Behún wrote: > > On Fri, 12 Mar 2021 09:58:34 +0100 > > Gregory CLEMENT <gregory.clement@bootlin.com> wrote: > > > > > Hello Marek, > > > > > > > From: Pali Rohár <pali@kernel.org> > > > > > > > > Move the turris-mox-rwtm firmware node from Turris MOX' device tree into > > > > the generic armada-37xx.dtsi file. > > > > > > I disagree with this patch. This firmware is specific to Turris MOX so > > > it is not something that should be exposed to all the Armada 3700 based > > > boards. > > > > > > If you want you still can create an dtsi for this and include it when > > > needed. > > > > > > Gregory > > > > Gregory, we are planning to send pull-request for TF-A documentation, > > adding information that people can compile the firmware with CZ.NIC's > > firmware. > > > > Since this firmware exposes HW random number generator, it is > > possible that people will start using it for espressobin. > > > > In that case this won't be specific for Turris MOX anymore. > > Part of the problem is that it looks specific to the Turris MOX. > > But please help me understand the big picture first. How is the > firmware distributed? Is the binary part of linux-firmware? How does > it get loaded? Does the firmware contain anything which is specific to > the Turris MOX? Could the hardware number generator part be split out > into a more generic sounding name blob? > > Andrew Hello Andrew, The WTMI firmware is loaded before kernel. This firmware is loaded by BootROM, and it is this firmware that does DDR training before loading TF-A + U-Boot. For example for ESPRESSObin you have several repositories you need to create a final flash-image.bin containing this WTMI firmware + TF-A + U-Boot. These repositories are: trusted-firmware-a (contains documentation how to build all this) A3700-utils-marvell u-boot mv-ddr-marvell From these sources you are able to create a final flash-image.bin that you can flash onto the SPI-NOR (or eMMC or other devices which A3720 can boot from). The A3700-utils-marvell repository contains the code of the WTMI firmware. On Turris MOX this is a little bit different, because - we have implemented the WTMI firmware differently (more mailbox commands, HW crypto, ...) - it supports retrieving MOX board information (MAC addresses, serial number) stored in eFuses (this information is stored in a specific way that in only true for MOX) - the firmware binary must be signed by our private key in order to boot on MOX. This is because the secure firmware has access to an ECDSA engine with a private key storage in eFuses (each MOX has its own private key generated and stored into the eFuses when manufactured) In order to disallow hackers to somehow extract the private key, the firmware must be signed so that they cannot load arbitrary firmware into the secure processor. BUT - since this firmware is able to provide HWRNG, we wanted to make it available for other Armada 3720 boards - we updated the code so that users can build it for non-MOX devices - it does not have to be signed for other devices - it does not contain MOX specific stuff for non-MOX devices So currently when users build the flash-image.bin binary containing WTMI firmware, they are using code from A3700-utils-marvell. This code is split into 2 parts: - sys_init - does HW and DDR initialization and execution of an "app" - efuse - default "app" which is loaded by sys_init The way it is written is that user can select a different "app" when building, and we have updated Turris MOX firmware code to be loadable as this "app" for sys_init. (And we have renamed it from "Turris MOX secure firmware" to "CZ.NIC's Armada 3720 secure firmware"). > Could the hardware number generator part be split out into a more > generic sounding name blob? It basically is. As I have written above, when users build the flash-image.bin with CZ.NIC's firmware, the prompt does not say anything about Turris MOX. Instead it says something like CZ.NIC's Armada 3720 Secure Firmware version build date Running on ESPRESSObin and currently provides only the random number generator command. So theoretically the turris-mox-rwtm driver can be renamed into something else and we can add a different compatible in order not to sound so turris-mox specific. Marek _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-03-12 15:18 UTC|newest] Thread overview: 107+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-08 15:37 [PATCH mvebu + mvebu/dt64 1/4] firmware: turris-mox-rwtm: fix reply status decoding function Marek Behún 2021-03-08 15:37 ` [PATCH mvebu + mvebu/dt64 2/4] firmware: turris-mox-rwtm: report failures better Marek Behún 2021-03-08 15:37 ` [PATCH mvebu + mvebu/dt64 3/4] firmware: turris-mox-rwtm: fail probing when firmware does not support hwrng Marek Behún 2021-03-08 15:37 ` [PATCH mvebu + mvebu/dt64 4/4] arm64: dts: marvell: armada-37xx: move firmware node to generic dtsi file Marek Behún 2021-03-08 15:37 ` Marek Behún 2021-03-12 8:58 ` Gregory CLEMENT 2021-03-12 8:58 ` Gregory CLEMENT 2021-03-12 9:10 ` Marek Behún 2021-03-12 9:10 ` Marek Behún 2021-03-12 14:48 ` Andrew Lunn 2021-03-12 14:48 ` Andrew Lunn 2021-03-12 15:17 ` Marek Behún [this message] 2021-03-12 15:17 ` Marek Behún 2021-03-12 15:53 ` Andrew Lunn 2021-03-12 15:53 ` Andrew Lunn 2021-03-12 16:18 ` Pali Rohár 2021-03-12 16:18 ` Pali Rohár 2021-03-12 16:32 ` Marek Behún 2021-03-12 16:32 ` Marek Behún 2021-03-15 10:14 ` Pali Rohár 2021-03-15 10:14 ` Pali Rohár 2021-03-15 12:08 ` Andrew Lunn 2021-03-15 12:08 ` Andrew Lunn 2021-04-26 18:36 ` Pali Rohár 2021-04-26 18:36 ` Pali Rohár 2021-04-26 19:52 ` Andrew Lunn 2021-04-26 19:52 ` Andrew Lunn 2021-04-29 8:36 ` [PATCH v2 mvebu + mvebu/dt64 1/6] firmware: turris-mox-rwtm: fix reply status decoding function Pali Rohár 2021-04-29 8:36 ` Pali Rohár 2021-04-29 8:36 ` [PATCH v2 mvebu + mvebu/dt64 2/6] firmware: turris-mox-rwtm: report failures better Pali Rohár 2021-04-29 8:36 ` Pali Rohár 2021-04-29 8:36 ` [PATCH v2 mvebu + mvebu/dt64 3/6] firmware: turris-mox-rwtm: fail probing when firmware does not support hwrng Pali Rohár 2021-04-29 8:36 ` Pali Rohár 2021-04-29 8:36 ` [PATCH v2 mvebu + mvebu/dt64 4/6] firmware: turris-mox-rwtm: show message about HWRNG registration Pali Rohár 2021-04-29 8:36 ` Pali Rohár 2021-04-29 8:36 ` [PATCH v2 mvebu + mvebu/dt64 5/6] firmware: turris-mox-rwtm: add marvell,armada-3700-rwtm-firmware compatible string Pali Rohár 2021-04-29 8:36 ` [PATCH v2 mvebu + mvebu/dt64 5/6] firmware: turris-mox-rwtm: add marvell, armada-3700-rwtm-firmware " Pali Rohár 2021-04-29 8:36 ` [PATCH v2 mvebu + mvebu/dt64 6/6] arm64: dts: marvell: armada-37xx: move firmware node to generic dtsi file Pali Rohár 2021-04-29 8:36 ` Pali Rohár 2021-05-03 12:22 ` [PATCH v2 mvebu + mvebu/dt64 1/6] firmware: turris-mox-rwtm: fix reply status decoding function Andrew Lunn 2021-05-03 12:22 ` Andrew Lunn 2021-05-05 16:04 ` Marek Behún 2021-05-05 16:04 ` Marek Behún 2021-05-05 16:20 ` Andrew Lunn 2021-05-05 16:20 ` Andrew Lunn 2021-05-11 21:46 ` Pali Rohár 2021-05-11 21:46 ` Pali Rohár 2021-05-06 9:07 ` [PATCH v3 " Pali Rohár 2021-05-06 9:07 ` Pali Rohár 2021-05-06 9:07 ` [PATCH v3 mvebu + mvebu/dt64 2/6] firmware: turris-mox-rwtm: report failures better Pali Rohár 2021-05-06 9:07 ` Pali Rohár 2021-05-06 9:07 ` [PATCH v3 mvebu + mvebu/dt64 3/6] firmware: turris-mox-rwtm: fail probing when firmware does not support hwrng Pali Rohár 2021-05-06 9:07 ` Pali Rohár 2021-05-12 0:56 ` Andrew Lunn 2021-05-12 0:56 ` Andrew Lunn 2021-05-20 11:38 ` Pali Rohár 2021-05-20 11:38 ` Pali Rohár 2021-05-06 9:08 ` [PATCH v3 mvebu + mvebu/dt64 4/6] firmware: turris-mox-rwtm: show message about HWRNG registration Pali Rohár 2021-05-06 9:08 ` Pali Rohár 2021-05-06 9:08 ` [PATCH v3 mvebu + mvebu/dt64 5/6] firmware: turris-mox-rwtm: add marvell,armada-3700-rwtm-firmware compatible string Pali Rohár 2021-05-06 9:08 ` [PATCH v3 mvebu + mvebu/dt64 5/6] firmware: turris-mox-rwtm: add marvell, armada-3700-rwtm-firmware " Pali Rohár 2021-05-06 9:08 ` [PATCH v3 mvebu + mvebu/dt64 6/6] arm64: dts: marvell: armada-37xx: move firmware node to generic dtsi file Pali Rohár 2021-05-06 9:08 ` Pali Rohár 2021-05-12 0:59 ` Andrew Lunn 2021-05-12 0:59 ` Andrew Lunn 2021-05-20 11:40 ` Pali Rohár 2021-05-20 11:40 ` Pali Rohár 2021-05-12 0:49 ` [PATCH v3 mvebu + mvebu/dt64 1/6] firmware: turris-mox-rwtm: fix reply status decoding function Andrew Lunn 2021-05-12 0:49 ` Andrew Lunn 2021-05-20 11:35 ` [PATCH v4 mvebu 0/4] firmware: turris-mox-rwtm: fixups Pali Rohár 2021-05-20 11:35 ` Pali Rohár 2021-05-20 11:35 ` [PATCH v4 mvebu 1/4] firmware: turris-mox-rwtm: fix reply status decoding function Pali Rohár 2021-05-20 11:35 ` Pali Rohár 2021-05-20 11:35 ` [PATCH v4 mvebu 2/4] firmware: turris-mox-rwtm: report failures better Pali Rohár 2021-05-20 11:35 ` Pali Rohár 2021-05-21 1:38 ` Andrew Lunn 2021-05-21 1:38 ` Andrew Lunn 2021-05-20 11:35 ` [PATCH v4 mvebu 3/4] firmware: turris-mox-rwtm: fail probing when firmware does not support hwrng Pali Rohár 2021-05-20 11:35 ` Pali Rohár 2021-05-21 1:39 ` Andrew Lunn 2021-05-21 1:39 ` Andrew Lunn 2021-05-20 11:35 ` [PATCH v4 mvebu 4/4] firmware: turris-mox-rwtm: show message about HWRNG registration Pali Rohár 2021-05-20 11:35 ` Pali Rohár 2021-05-21 1:40 ` Andrew Lunn 2021-05-21 1:40 ` Andrew Lunn 2021-06-17 13:06 ` [PATCH v4 mvebu 0/4] firmware: turris-mox-rwtm: fixups Gregory CLEMENT 2021-06-17 13:06 ` Gregory CLEMENT 2021-07-07 18:14 ` Pali Rohár 2021-07-07 18:14 ` Pali Rohár 2021-07-23 12:45 ` Gregory CLEMENT 2021-07-23 12:45 ` Gregory CLEMENT 2021-07-23 12:47 ` Pali Rohár 2021-07-23 12:47 ` Pali Rohár 2021-05-20 11:38 ` [PATCH v4 mvebu + mvebu/dt64 0/2] firmware: turris-mox-rwtm: new compatible string Pali Rohár 2021-05-20 11:38 ` Pali Rohár 2021-05-20 11:38 ` [PATCH v4 mvebu + mvebu/dt64 1/2] firmware: turris-mox-rwtm: add marvell,armada-3700-rwtm-firmware " Pali Rohár 2021-05-20 11:38 ` [PATCH v4 mvebu + mvebu/dt64 1/2] firmware: turris-mox-rwtm: add marvell, armada-3700-rwtm-firmware " Pali Rohár 2021-05-21 1:41 ` [PATCH v4 mvebu + mvebu/dt64 1/2] firmware: turris-mox-rwtm: add marvell,armada-3700-rwtm-firmware " Andrew Lunn 2021-05-21 1:41 ` Andrew Lunn 2021-06-17 13:07 ` Gregory CLEMENT 2021-06-17 13:07 ` Gregory CLEMENT 2021-05-20 11:38 ` [PATCH v4 mvebu + mvebu/dt64 2/2] arm64: dts: marvell: armada-37xx: move firmware node to generic dtsi file Pali Rohár 2021-05-20 11:38 ` Pali Rohár 2021-05-21 1:42 ` Andrew Lunn 2021-05-21 1:42 ` Andrew Lunn 2021-06-17 13:08 ` Gregory CLEMENT 2021-06-17 13:08 ` Gregory CLEMENT
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210312161704.5e575906@kernel.org \ --to=kabel@kernel.org \ --cc=andrew@lunn.ch \ --cc=gregory.clement@bootlin.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=pali@kernel.org \ --cc=stable@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.