From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 73D98C2B9F4 for ; Mon, 14 Jun 2021 15:12:08 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6273D6124B for ; Mon, 14 Jun 2021 15:12:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6273D6124B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=nic.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 0A2F982076; Mon, 14 Jun 2021 17:12:05 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=nic.cz Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; secure) header.d=nic.cz header.i=@nic.cz header.b="o9MOC/Dm"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 26798827E5; Mon, 14 Jun 2021 17:12:02 +0200 (CEST) Received: from mail.nic.cz (lists.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id B03EB82877 for ; Mon, 14 Jun 2021 17:11:57 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=nic.cz Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=marek.behun@nic.cz Received: from thinkpad (unknown [172.20.6.87]) by mail.nic.cz (Postfix) with ESMTPSA id 13D6A140A27; Mon, 14 Jun 2021 17:11:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1623683517; bh=6htsxri+K5BWpgyi4k35qQO9p63ZwfuPOySj+rG37Aw=; h=Date:From:To; b=o9MOC/DmsRpl5ySRkEEgAE5juZHrQ8Ec5E3EjOaWNhmkBsPY6zFQdA12JpBqkPtXh d13CrREYzqNAISsol7apXiWAr2VgYFo0eskwvu7Y2F5fxq8Nhj6LSGETBFN3ZQoqB2 yUrcvdbS5M+IOLHY2EqRC87gVcNjOzN/J/x/s5+0= Date: Mon, 14 Jun 2021 17:11:56 +0200 From: Marek Behun To: u-boot@lists.denx.de Cc: Pali =?UTF-8?B?Um9ow6Fy?= , Vladimir Vid , Luka Perkov , Tomasz Maciej Nowak , Hauke Mehrtens , Davor Popovic , Gregory CLEMENT , Miquel Raynal , Andre Heider , Konstantin Porotchkin , =?UTF-8?B?R8OpcmFsZA==?= Kerma , Scott Roberts , Grzegorz Jaszczyk , Marcin Wojtas , Stefan Roese , Luis Torres , Paul Arola , Scott Roberts , Jordan Greenling , Luis Torres , Steve Arnold , heaterC , Xogium , Remi Pommarel , Anders Trier Olesen , Philip Soares , =?UTF-8?B?UsO2dHRp?= Subject: Announcing a tool for Armada 3720 firmware Message-ID: <20210614171156.741af026@thinkpad> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean Hello, this is announcement of mox-imager [1], a firmware uploader / manipulator for Marvell's Armada 3720 SOC. For most of you who use the SOC on boards other than Turris MOX, the most useful feature probably is that it can upload a firmware via UART at higher baudrates than Marvell's original WtpDownloader, which is useful when debugging or during board manufacture. Features that should be interesting for you: - ability to upload firmware over UART at baudrates up to 6 MBaud. This was tested on ESPRESSObin, but should also work on other boards (uDPU, ESPRESSObin Ultra) Uploading at 3 MBaud: $ ./mox-imager -b 3000000 -D /dev/ttyUSB0 flash-image.bin - ability to upload flash-image.bin firmware over UART When TF-A builds for A3720, it creates image for SPI/eMMC called flash-image.bin, and a directory uart-images containing 3 binaries that you have to use instead of flash-image.bin if you want to boot via UART. mox-imager can work with both methods. When given flash-image.bin, it updates BootFlashSign in the TIM header so that the BootROM will accept the image when given over UART. So both of these work: $ ./mox-imager -D /dev/ttyUSB0 flash-image.bin $ ./mox-imager -D /dev/ttyUSB0 TIM_ATF.bin wtmi_h.bin boot-image_h.bin (This of course does not work if the image needs to be signed cryptographically and the singing key is not present. But AFAIK only Turris MOX uses this feature of the SOC.) - mox-imager has an implementation of a mini-terminal (code from U-Boot's kwboot), which can be used instead of minicom/kermit, once the firmware is uploaded. Although this mini-terminal does not support uploading images over Y-MODEM or other protocols to U-Boot, it can still be useful. If not for anything else, then at least for the ability to not lose any output which the SOC might have sent over UART. (When using minicom/kermit, there is a small window when the /dev/ttyX device is closed and some output is lost.) Use the -t flag to invoke this mini-terminal. Other features that we use on Turris MOX and may be useful to you, but need implementation for your boards: - we use one firmware image for all versions of our board: DDR3 512 MiB, DDR3 1024 MiB, DDR4 This simplifies development of updates significantly. We achieve this by burning board version info into the SOC's OTP. The GPP code contained in the TIM header can read OTP and decide how to initialize clock and DDR registers depending on the values there. The GPP code also works when OTP is empty. In that case it first tries to initialize the registers for DDR3, tests if DDR works, and if not, switches to DDR4. Then it determines RAM size. Note that we do not use this method in production, this was only tested on a few boards that we use for development. (We do not know for example, whether it is safe for the DDR4 chip if we first try to communicate with it in DDR3 mode, since the protocols are different.) You can look at the GPP code at https://gitlab.nic.cz/turris/mox-imager/-/blob/master/gpp/ddr.gpp - mox-imager can create trusted firmware image signed with ECDSA signature and can write the SOC's OTP so that only images signed with a specific ECDSA key will boot. We use this on Turris MOX. Related software: - we have significantly modified Marvell's original WTMI firmware that runs on the Cortex-M3 secure coprocessor. You can look at this modified firmware at our mox-boot-builder repository [2] in directory wtmi. Perhaps the most interesting feature for you is that this firmware exposes the SOC's internal HW RNG via the mailbox to Linux, and that upstream Linux has a driver (turris-mox-rwtm) that registers this random number generator via Linux' crypto API. Another feature our firmware supports is that it can utilize the crypto engine in the secure processor for creating ECDSA signatures. Every Turris MOX has an ECDSA key generated and burned into OTP when manufactured. When done correctly, it is impossible to read this key. It is only possible to use it via the crypto engine for ECDSA signatures. (The firmware has to be in trusted mode for this. If the user has the ability to upload any firmware into their device, they can read the private key from OTP.) This firmware can be built as a standalone replacement of Marvell's WTMI firmware from A3700-utils-marvell repository, but also as an wtmi_app.bin payload application for Marvell's firmware (in this case DDR and clocks are initialized by Marvell's code and HW RNG is provided by wtmi_app.bin). There are instructions on how to use this firmware on ESPRESSObin in mox-boot-builder's README.md. - turris-mox-rwtm driver in Linux [3] communicates with our WTMI firmware (see the point above) and exposes to Linux: - the SOC's HWRNG - the SOC's ECDSA signing engine with singing key stored in OTP. This can be used for authorizing the device, for example via SSH - OTP rows containing Turris MOX' serial number, board version and MAC address I'm thinking about implementing code into this driver so that it will also work with Marvell's original firmware, which only exposes access to OTP memory. - mox-pkcs11 [4] is a plugin for ssh that can utilize the HW ECDSA signing mechanism mentioned above when connecting to an ssh server Let us know if you are interested in any of these or need help with something. Marek & Pali [1] https://gitlab.nic.cz/turris/mox-imager The name should probably be something like a3720-tool, but I called it mox-imager at the beginning because then it was meant to be used only for Turris MOX. [2] https://gitlab.nic.cz/turris/mox-boot-builder [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/turris-mox-rwtm.c [4] https://gitlab.nic.cz/turris/mox-pkcs11