linux-renesas-soc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eugeniu Rosca <erosca@de.adit-jv.com>
To: Marek Vasut <marek.vasut@gmail.com>,
	Marek Vasut <marek.vasut+renesas@gmail.com>,
	Kieran Bingham <kieran.bingham@ideasonboard.com>,
	Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Cc: <u-boot@lists.denx.de>, <linux-renesas-soc@vger.kernel.org>,
	Michael Dege <michael.dege@renesas.com>,
	Gotthard Voellmeke <gotthard.voellmeke@renesas.com>,
	Adam Bass <adam.bass@renesas.com>,
	Bastian Farkas <bfarkas@de.adit-jv.com>,
	Tobias Franzen <tfranzen@de.adit-jv.com>,
	Philipp Ahmann <pahmann@de.adit-jv.com>,
	Simon Maleyka <smaleyka@de.adit-jv.com>,
	Eugeniu Rosca <erosca@de.adit-jv.com>,
	Eugeniu Rosca <roscaeugeniu@gmail.com>
Subject: Automated/remote flashing of R-Car3
Date: Tue, 7 May 2019 12:41:15 +0200	[thread overview]
Message-ID: <20190507104115.GA27355@vmlxhi-102.adit-jv.com> (raw)

Dear Marek, dear Kieran,

CC: Michael, Gotthard, Adam
CC: U-Boot, linux-renesas-soc
CC: ADIT

We in ADIT have recently set up some remote servers for CI
deployment/testing of R-Car3 targets (Salvator-X and ULCB-KF).

Since re-flashing of "firmware" (i.e. ATF, U-Boot and OPTEE-OS) on
Hyperflash involves manipulation of on-board DIP switches and direct
access to the targets is difficult/infeasible in our case, we've
started to look for a solution of flashing the boards remotely.
Anticipating that you might have potentially implemented this in your
private setups, would you please provide your valuable feedback on
below thoughts which we have collected together with Michael Dege?

1.a Use Lauterbach
+ No changes in Renesas boot concept/flow
+ No changes in release/production ATF build flags
+ No physical changes on the boards
+ Immune to corrupted/wrong binaries
+ Tested. Fast and reliable.
- Keeping one lauterbach/target for flashing purpose only _is_ expensive

1.b Replace relevant on-board DIP switches with remote-controlled relays
+ No changes in Renesas boot concept/flow
+ No changes in release/production ATF build flags
+ If set up properly, presumably immune to corrupted/wrong binaries
- Major/intrusive physical changes required on the board
- Lost warranty for the modified targets

1.c Use OpenOCD
+ Presumably same advantages as using a Lauterbach
+ Based on Kieran's https://github.com/kbingham/renesas-jtag
  and on Adam's https://github.com/ntfreak/openocd/commit/1afec4f561392
  the solution is currently in use.
? Any ideas on the model/price of the JTAG adapter?
? Not tested. Any patches needed on top of vanilla OpenOCD?

1.d. Use CPLD Configurator
+ H3_M3_StarterKit_Configurator.exe is a Windows tool shipped by
  Renesas, hence readily available, which allows to modify the MD
  pins, to conveniently switch between QSPI/Hyperflash/SCIF
  boot mode from a GUI
+ Most of the advantages pointed out above
- ULCB-only solution (i.e. does not apply to Salvator-X)
- Requires a Windows host

2.a Enable non-secure access to Hyperflash and write from U-Boot/Linux
+ Implemented/used by CogentEmbedded via [0-3]
+ No changes in Renesas boot concept/flow
+ No physical changes on the boards
+ No additional HW adapters
- Requires changes in ATF build flags, i.e. the tested build flavor
  of ATF diverges from what's used in production
- Not immune to corrupted/wrong binaries and failures/interruptions,
  i.e. flashing a wrong binary would result in unbootable target
  (afterwards, direct access to the target is needed for either
  MiniMonitor or Lauterbach-based flashing)

2.b Implement a TA to get write access to Hyperflash via OPTEE OS
+ Same pros as (2.a) plus no need to build a special ATF variant
- Same as (2.a), not immune to flashing failures
- Not yet developed/tested

3 Add flash writer [4] to the boot chain between BL1 and BL2
+ No physical changes on the boards
+ No additional HW adapters
+ Presumably no changes in release/production ATF build flags
+ Presumably immune to flashing failures, since it is assumed to be
  executed before BL2
- Changes/mangles the Renesas boot concept/flow
- Not yet developed/tested. As pointed out by Michael offline,
  the implementation might be not so trivial
- Expensive (initial development + new bugs due to diverging
  from Renesas)

4 Store/load (BL31, cert_header, U-Boot and OPTEE) to/from eMMC
+ This is a PoC/dirty solution received in the Renesas Android release,
  which relies on the fact that eMMC can be written to regardless of
  DIP switch settings. Writing to eMMC can be done via fastboot.
+ No physical changes on the boards
+ No additional HW adapters
- BL2 remains in Hyperflash, hence can't be updated with this approach
- Not immune to flashing failures
- Not supported in vanilla or in Renesas Yocto ATF

It's really amazing that with this great number of options, there
is no perfect solution. If you have any comments, especially in the
area of OpenOCD, those would be highly appreciated. TIA!

[0] https://github.com/CogentEmbedded/meta-rcar/blob/v3.15.0/meta-rcar-gen3-adas/recipes-bsp/arm-trusted-firmware/files/0001-plat-renesas-rcar-Make-RPC-secure-settings-optional.patch
[1] https://github.com/CogentEmbedded/meta-rcar/blob/v3.15.0/meta-rcar-gen3-adas/recipes-bsp/u-boot/u-boot/0040-arm-renesas-Enable-RPC-HF-MTD-support-for-all-Salvat.patch
[2] https://github.com/CogentEmbedded/meta-rcar/blob/v3.15.0/meta-rcar-gen3-adas/recipes-bsp/u-boot/u-boot/0041-arm-renesas-Enable-RPC-HF-MTD-support-for-all-ULCB-b.patch
[3] https://github.com/CogentEmbedded/meta-rcar/blob/v3.15.0/meta-rcar-gen3-adas/recipes-kernel/linux/linux-renesas/0012-mtd-Add-RPC-HyperFlash-driver.patch
[4] https://github.com/renesas-rcar/flash_writer

-- 
Best Regards,
Eugeniu.

             reply	other threads:[~2019-05-07 10:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-07 10:41 Eugeniu Rosca [this message]
2019-05-07 13:23 ` Automated/remote flashing of R-Car3 Marek Vasut
2019-05-07 15:53   ` Eugeniu Rosca
2019-05-07 16:09     ` Marek Vasut
2019-05-08  9:32       ` Eugeniu Rosca
2019-05-08 11:30         ` Marek Vasut
2019-05-08 12:07       ` Michael Dege
2019-05-08 13:51       ` Eugeniu Rosca
2019-05-08 15:11         ` Marek Vasut

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=20190507104115.GA27355@vmlxhi-102.adit-jv.com \
    --to=erosca@de.adit-jv.com \
    --cc=adam.bass@renesas.com \
    --cc=bfarkas@de.adit-jv.com \
    --cc=gotthard.voellmeke@renesas.com \
    --cc=kieran.bingham+renesas@ideasonboard.com \
    --cc=kieran.bingham@ideasonboard.com \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=marek.vasut+renesas@gmail.com \
    --cc=marek.vasut@gmail.com \
    --cc=michael.dege@renesas.com \
    --cc=pahmann@de.adit-jv.com \
    --cc=roscaeugeniu@gmail.com \
    --cc=smaleyka@de.adit-jv.com \
    --cc=tfranzen@de.adit-jv.com \
    --cc=u-boot@lists.denx.de \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).