Automated/remote flashing of R-Car3

Automated/remote flashing of R-Car3

[Eugeniu Rosca]

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.

Re: Automated/remote flashing of R-Car3

[Marek Vasut]

On 5/7/19 12:41 PM, Eugeniu Rosca wrote:
> Dear Marek, dear Kieran,

Hi,

[...]

> 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?

Any FT2232H (the H is important, due to MPSSE) works.
I like Flyswatter2 from TinCanTools.

> ? Not tested. Any patches needed on top of vanilla OpenOCD?

http://openocd.zylin.com/5149 and related ones, it adds RPC HF support.
However, there are two problems with this:
1) Even with buffered write, the programming is slow
   - This could be improved by running code on one of the Gen3 CPUs
     instead of whacking registers via JTAG adapter. I believe that's
     what lauterbach and everyone else does too. The data upload to
     SRAM/DRAM is fast via JTAG, register IO is not great.
2) LifeC locks the RPC HF access
   - This is a problem, since the JTAG probe cannot access it once
     it's locked. There might be a way around it, but it's rather
     nasty -- use boundary scan test mode to either flip MD pins or
     access the HF bus directly and bitbang at least erase command
     to wipe the first few sectors, then reset the CPU and have it
     drop to SCIF loader mode, then stop the CPU and reprogram the
     HF (since the SCIF loader runs in EL3 and does not touch the
     lifec settings.

Neither of 1) and 2) is implemented, but can be implemented if there is
interest.

> 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

Where can I obtain this and are there sources / documentation available?

-- 
Best regards,
Marek Vasut

Re: Automated/remote flashing of R-Car3

[Eugeniu Rosca]

Hi Marek,

Thanks for the swift reply and for the useful references/links.

On Tue, May 07, 2019 at 03:23:12PM +0200, Marek Vasut wrote:
> On 5/7/19 12:41 PM, Eugeniu Rosca wrote:
> > Dear Marek, dear Kieran,
> 
> Hi,
> 
> [...]
> 
> > 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?
> 
> Any FT2232H (the H is important, due to MPSSE) works.
> I like Flyswatter2 from TinCanTools.
> 
> > ? Not tested. Any patches needed on top of vanilla OpenOCD?
> 
> http://openocd.zylin.com/5149 and related ones, it adds RPC HF support.
> However, there are two problems with this:
> 1) Even with buffered write, the programming is slow
>    - This could be improved by running code on one of the Gen3 CPUs
>      instead of whacking registers via JTAG adapter. I believe that's
>      what lauterbach and everyone else does too. The data upload to
>      SRAM/DRAM is fast via JTAG, register IO is not great.
> 2) LifeC locks the RPC HF access
>    - This is a problem, since the JTAG probe cannot access it once
>      it's locked. There might be a way around it, but it's rather
>      nasty -- use boundary scan test mode to either flip MD pins or
>      access the HF bus directly and bitbang at least erase command
>      to wipe the first few sectors, then reset the CPU and have it
>      drop to SCIF loader mode, then stop the CPU and reprogram the
>      HF (since the SCIF loader runs in EL3 and does not touch the
>      lifec settings.
> 
> Neither of 1) and 2) is implemented, but can be implemented if there is
> interest.

1) looks like a performance issue to me (suboptimal flashing time).
To be honest, I don't think this is a deal-breaker, assuming that
erasing/re-writing the whole 64MiB HF doesn't exceed ~10-15min.
It is also my understanding this is subject of future optimization.

2) looks like a functional issue (insufficient permission to
write-access HF). To make things clear, could you please stress if
http://openocd.zylin.com/5149 already allows updating ATF/U-Boot/OPTEE
on HF of R-Car Gen3 or is it still awaiting some fixes?

> 
> > 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
> 
> Where can I obtain this and are there sources / documentation available?

I am able to find below related package freely available:
https://elinux.org/File:H3_StarterKit_CPLD_Update_20190408.zip

Unfortunately, it doesn't include H3_M3_StarterKit_Configurator.exe.
The user who uploaded the file is https://elinux.org/User:RenesasJa.
Are you aware of any messaging/commenting feature on elinux.org?
If not, I hope Michael (CC-ed) can answer your question. Hopefully
he sees this message. If not, I can forward your question to him via
mantis.

Thank you!

> 
> -- 
> Best regards,
> Marek Vasut

-- 
Best Regards,
Eugeniu.

Re: Automated/remote flashing of R-Car3

[Marek Vasut]

On 5/7/19 5:53 PM, Eugeniu Rosca wrote:
> Hi Marek,

Hi,

> Thanks for the swift reply and for the useful references/links.
> 
> On Tue, May 07, 2019 at 03:23:12PM +0200, Marek Vasut wrote:
>> On 5/7/19 12:41 PM, Eugeniu Rosca wrote:
>>> Dear Marek, dear Kieran,
>>
>> Hi,
>>
>> [...]
>>
>>> 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?
>>
>> Any FT2232H (the H is important, due to MPSSE) works.
>> I like Flyswatter2 from TinCanTools.
>>
>>> ? Not tested. Any patches needed on top of vanilla OpenOCD?
>>
>> http://openocd.zylin.com/5149 and related ones, it adds RPC HF support.
>> However, there are two problems with this:
>> 1) Even with buffered write, the programming is slow
>>    - This could be improved by running code on one of the Gen3 CPUs
>>      instead of whacking registers via JTAG adapter. I believe that's
>>      what lauterbach and everyone else does too. The data upload to
>>      SRAM/DRAM is fast via JTAG, register IO is not great.
>> 2) LifeC locks the RPC HF access
>>    - This is a problem, since the JTAG probe cannot access it once
>>      it's locked. There might be a way around it, but it's rather
>>      nasty -- use boundary scan test mode to either flip MD pins or
>>      access the HF bus directly and bitbang at least erase command
>>      to wipe the first few sectors, then reset the CPU and have it
>>      drop to SCIF loader mode, then stop the CPU and reprogram the
>>      HF (since the SCIF loader runs in EL3 and does not touch the
>>      lifec settings.
>>
>> Neither of 1) and 2) is implemented, but can be implemented if there is
>> interest.
> 
> 1) looks like a performance issue to me (suboptimal flashing time).
> To be honest, I don't think this is a deal-breaker, assuming that
> erasing/re-writing the whole 64MiB HF doesn't exceed ~10-15min.
> It is also my understanding this is subject of future optimization.

It will have to be optimized further.

> 2) looks like a functional issue (insufficient permission to
> write-access HF). To make things clear, could you please stress if
> http://openocd.zylin.com/5149 already allows updating ATF/U-Boot/OPTEE
> on HF of R-Car Gen3 or is it still awaiting some fixes?

You can read/write/erase the HF with it. Just keep in mind the HF has to
be unlocked.

Maybe there is some magic/sectret way to unlock the LifeC RPC access
restriction via JTAG, but we don't know about it.

>>> 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
>>
>> Where can I obtain this and are there sources / documentation available?
> 
> I am able to find below related package freely available:
> https://elinux.org/File:H3_StarterKit_CPLD_Update_20190408.zip
> 
> Unfortunately, it doesn't include H3_M3_StarterKit_Configurator.exe.
> The user who uploaded the file is https://elinux.org/User:RenesasJa.
> Are you aware of any messaging/commenting feature on elinux.org?
> If not, I hope Michael (CC-ed) can answer your question. Hopefully
> he sees this message. If not, I can forward your question to him via
> mantis.

It would be also interesting to obtain the CPLD sources and be able to
synthesise custom CPLD bitstreams for automated testing.

-- 
Best regards,
Marek Vasut

Re: Automated/remote flashing of R-Car3

[Eugeniu Rosca]

On Tue, May 07, 2019 at 06:09:10PM +0200, Marek Vasut wrote:
[..]
> >>> 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
> >>
> >> Where can I obtain this and are there sources / documentation available?
> > 
> > I am able to find below related package freely available:
> > https://elinux.org/File:H3_StarterKit_CPLD_Update_20190408.zip
> > 
> > Unfortunately, it doesn't include H3_M3_StarterKit_Configurator.exe.
> > The user who uploaded the file is https://elinux.org/User:RenesasJa.
> > Are you aware of any messaging/commenting feature on elinux.org?
> > If not, I hope Michael (CC-ed) can answer your question. Hopefully
> > he sees this message. If not, I can forward your question to him via
> > mantis.
> 
> It would be also interesting to obtain the CPLD sources and be able to
> synthesise custom CPLD bitstreams for automated testing.

Is my understanding correct that these "CPLD bitstreams" (once known)
could be implemented in U-Boot's board/renesas/ulcb/cpld.c?

-- 
Best Regards,
Eugeniu.

Re: Automated/remote flashing of R-Car3

[Marek Vasut]

On 5/8/19 11:32 AM, Eugeniu Rosca wrote:
> On Tue, May 07, 2019 at 06:09:10PM +0200, Marek Vasut wrote:
> [..]
>>>>> 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
>>>>
>>>> Where can I obtain this and are there sources / documentation available?
>>>
>>> I am able to find below related package freely available:
>>> https://elinux.org/File:H3_StarterKit_CPLD_Update_20190408.zip
>>>
>>> Unfortunately, it doesn't include H3_M3_StarterKit_Configurator.exe.
>>> The user who uploaded the file is https://elinux.org/User:RenesasJa.
>>> Are you aware of any messaging/commenting feature on elinux.org?
>>> If not, I hope Michael (CC-ed) can answer your question. Hopefully
>>> he sees this message. If not, I can forward your question to him via
>>> mantis.
>>
>> It would be also interesting to obtain the CPLD sources and be able to
>> synthesise custom CPLD bitstreams for automated testing.
> 
> Is my understanding correct that these "CPLD bitstreams" (once known)
> could be implemented in U-Boot's board/renesas/ulcb/cpld.c?

No, the CPLD is a programmable logic device. You synthesise the
bitstream with Quartus, program it and it stays programmed (in case of
that maxV on the ULCB at least)

-- 
Best regards,
Marek Vasut

RE: Automated/remote flashing of R-Car3

[Michael Dege]

Hello Marek and Eugeniu,

Regarding the H3_M3_StarterKit_Configurator.exe

I am not aware if we have an NDA with Marek. I know you do a lot of work for our products, but I don't know under which conditions. I need to be sure, that the legal prerequisites are met before I can give you the tool.

Regarding the sources of the Bitstream: The sources have not been shared with any of our customers to my knowledge. We have made some special versions (MD pin configurations) on request.

Best regards,

Michael



-----Original Message-----
From: Marek Vasut <marek.vasut@gmail.com>
Sent: Dienstag, 7. Mai 2019 18:09
To: REE erosca@DE.ADIT-JV.COM <erosca@DE.ADIT-JV.COM>
Cc: Marek Vasut <marek.vasut+renesas@gmail.com>; Kieran Bingham <kieran.bingham@ideasonboard.com>; Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>; 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>; REE pahmann@de.adit-jv.com <pahmann@de.adit-jv.com>; Simon Maleyka <smaleyka@de.adit-jv.com>; Eugeniu Rosca <roscaeugeniu@gmail.com>
Subject: Re: Automated/remote flashing of R-Car3

On 5/7/19 5:53 PM, Eugeniu Rosca wrote:
> Hi Marek,

Hi,

> Thanks for the swift reply and for the useful references/links.
>
> On Tue, May 07, 2019 at 03:23:12PM +0200, Marek Vasut wrote:
>> On 5/7/19 12:41 PM, Eugeniu Rosca wrote:
>>> Dear Marek, dear Kieran,
>>
>> Hi,
>>
>> [...]
>>
>>> 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?
>>
>> Any FT2232H (the H is important, due to MPSSE) works.
>> I like Flyswatter2 from TinCanTools.
>>
>>> ? Not tested. Any patches needed on top of vanilla OpenOCD?
>>
>> http://openocd.zylin.com/5149 and related ones, it adds RPC HF support.
>> However, there are two problems with this:
>> 1) Even with buffered write, the programming is slow
>>    - This could be improved by running code on one of the Gen3 CPUs
>>      instead of whacking registers via JTAG adapter. I believe that's
>>      what lauterbach and everyone else does too. The data upload to
>>      SRAM/DRAM is fast via JTAG, register IO is not great.
>> 2) LifeC locks the RPC HF access
>>    - This is a problem, since the JTAG probe cannot access it once
>>      it's locked. There might be a way around it, but it's rather
>>      nasty -- use boundary scan test mode to either flip MD pins or
>>      access the HF bus directly and bitbang at least erase command
>>      to wipe the first few sectors, then reset the CPU and have it
>>      drop to SCIF loader mode, then stop the CPU and reprogram the
>>      HF (since the SCIF loader runs in EL3 and does not touch the
>>      lifec settings.
>>
>> Neither of 1) and 2) is implemented, but can be implemented if there
>> is interest.
>
> 1) looks like a performance issue to me (suboptimal flashing time).
> To be honest, I don't think this is a deal-breaker, assuming that
> erasing/re-writing the whole 64MiB HF doesn't exceed ~10-15min.
> It is also my understanding this is subject of future optimization.

It will have to be optimized further.

> 2) looks like a functional issue (insufficient permission to
> write-access HF). To make things clear, could you please stress if
> http://openocd.zylin.com/5149 already allows updating ATF/U-Boot/OPTEE
> on HF of R-Car Gen3 or is it still awaiting some fixes?

You can read/write/erase the HF with it. Just keep in mind the HF has to be unlocked.

Maybe there is some magic/sectret way to unlock the LifeC RPC access restriction via JTAG, but we don't know about it.

>>> 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
>>
>> Where can I obtain this and are there sources / documentation available?
>
> I am able to find below related package freely available:
> https://elinux.org/File:H3_StarterKit_CPLD_Update_20190408.zip
>
> Unfortunately, it doesn't include H3_M3_StarterKit_Configurator.exe.
> The user who uploaded the file is https://elinux.org/User:RenesasJa.
> Are you aware of any messaging/commenting feature on elinux.org?
> If not, I hope Michael (CC-ed) can answer your question. Hopefully he
> sees this message. If not, I can forward your question to him via
> mantis.

It would be also interesting to obtain the CPLD sources and be able to synthesise custom CPLD bitstreams for automated testing.

--
Best regards,
Marek Vasut


Renesas Electronics Europe GmbH,Geschaeftsfuehrer/President : Olav Schulte, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany,Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647

Re: Automated/remote flashing of R-Car3

[Eugeniu Rosca]

Hi Marek,

On Tue, May 07, 2019 at 06:09:10PM +0200, Marek Vasut wrote:
[..]
> >>> 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?
> >>
> >> Any FT2232H (the H is important, due to MPSSE) works.
> >> I like Flyswatter2 from TinCanTools.
> >>
> >>> ? Not tested. Any patches needed on top of vanilla OpenOCD?
> >>
> >> http://openocd.zylin.com/5149 and related ones, it adds RPC HF support.
> >> However, there are two problems with this:
> >> 1) Even with buffered write, the programming is slow
> >>    - This could be improved by running code on one of the Gen3 CPUs
> >>      instead of whacking registers via JTAG adapter. I believe that's
> >>      what lauterbach and everyone else does too. The data upload to
> >>      SRAM/DRAM is fast via JTAG, register IO is not great.
> >> 2) LifeC locks the RPC HF access
> >>    - This is a problem, since the JTAG probe cannot access it once
> >>      it's locked. There might be a way around it, but it's rather
> >>      nasty -- use boundary scan test mode to either flip MD pins or
> >>      access the HF bus directly and bitbang at least erase command
> >>      to wipe the first few sectors, then reset the CPU and have it
> >>      drop to SCIF loader mode, then stop the CPU and reprogram the
> >>      HF (since the SCIF loader runs in EL3 and does not touch the
> >>      lifec settings.
> >>
> >> Neither of 1) and 2) is implemented, but can be implemented if there is
> >> interest.
> > 
> > 1) looks like a performance issue to me (suboptimal flashing time).
> > To be honest, I don't think this is a deal-breaker, assuming that
> > erasing/re-writing the whole 64MiB HF doesn't exceed ~10-15min.
> > It is also my understanding this is subject of future optimization.
> 
> It will have to be optimized further.
> 
> > 2) looks like a functional issue (insufficient permission to
> > write-access HF). To make things clear, could you please stress if
> > http://openocd.zylin.com/5149 already allows updating ATF/U-Boot/OPTEE
> > on HF of R-Car Gen3 or is it still awaiting some fixes?
> 
> You can read/write/erase the HF with it. Just keep in mind the HF has to
> be unlocked.
>
> Maybe there is some magic/sectret way to unlock the LifeC RPC access
> restriction via JTAG, but we don't know about it.

Well, "unlocking" HF via LifeC registers (set in BL2) is pretty much
equivalent to diverging from the Renesas-delivered BL2/IPL, by
accepting a solution like [0] referenced in my initial e-mail
(linked again below). Spawning multiple build variants of ATF (i.e.
tested vs released) is what we would like to avoid.

Thanks for pointing out this limitation.
Hopefully it can be addressed in a future iteration of
http://openocd.zylin.com/5149.

[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

-- 
Best Regards,
Eugeniu.

Re: Automated/remote flashing of R-Car3

[Marek Vasut]

On 5/8/19 3:51 PM, Eugeniu Rosca wrote:
> Hi Marek,
> 
> On Tue, May 07, 2019 at 06:09:10PM +0200, Marek Vasut wrote:
> [..]
>>>>> 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?
>>>>
>>>> Any FT2232H (the H is important, due to MPSSE) works.
>>>> I like Flyswatter2 from TinCanTools.
>>>>
>>>>> ? Not tested. Any patches needed on top of vanilla OpenOCD?
>>>>
>>>> http://openocd.zylin.com/5149 and related ones, it adds RPC HF support.
>>>> However, there are two problems with this:
>>>> 1) Even with buffered write, the programming is slow
>>>>    - This could be improved by running code on one of the Gen3 CPUs
>>>>      instead of whacking registers via JTAG adapter. I believe that's
>>>>      what lauterbach and everyone else does too. The data upload to
>>>>      SRAM/DRAM is fast via JTAG, register IO is not great.
>>>> 2) LifeC locks the RPC HF access
>>>>    - This is a problem, since the JTAG probe cannot access it once
>>>>      it's locked. There might be a way around it, but it's rather
>>>>      nasty -- use boundary scan test mode to either flip MD pins or
>>>>      access the HF bus directly and bitbang at least erase command
>>>>      to wipe the first few sectors, then reset the CPU and have it
>>>>      drop to SCIF loader mode, then stop the CPU and reprogram the
>>>>      HF (since the SCIF loader runs in EL3 and does not touch the
>>>>      lifec settings.
>>>>
>>>> Neither of 1) and 2) is implemented, but can be implemented if there is
>>>> interest.
>>>
>>> 1) looks like a performance issue to me (suboptimal flashing time).
>>> To be honest, I don't think this is a deal-breaker, assuming that
>>> erasing/re-writing the whole 64MiB HF doesn't exceed ~10-15min.
>>> It is also my understanding this is subject of future optimization.
>>
>> It will have to be optimized further.
>>
>>> 2) looks like a functional issue (insufficient permission to
>>> write-access HF). To make things clear, could you please stress if
>>> http://openocd.zylin.com/5149 already allows updating ATF/U-Boot/OPTEE
>>> on HF of R-Car Gen3 or is it still awaiting some fixes?
>>
>> You can read/write/erase the HF with it. Just keep in mind the HF has to
>> be unlocked.
>>
>> Maybe there is some magic/sectret way to unlock the LifeC RPC access
>> restriction via JTAG, but we don't know about it.
> 
> Well, "unlocking" HF via LifeC registers (set in BL2) is pretty much
> equivalent to diverging from the Renesas-delivered BL2/IPL, by
> accepting a solution like [0] referenced in my initial e-mail
> (linked again below). Spawning multiple build variants of ATF (i.e.
> tested vs released) is what we would like to avoid.

Maybe there's a way to do it over JTAG.

Or maybe there's a way to fiddle with the MD pins via boundary scan
testing, but I cannot find the BSDL files for either R-Car Gen2 or Gen3
on the internet. There are ones for RZ/A1 and some older SH stuff.

I wonder what magic Lauterbach does there to unlock the RPC :-)

> Thanks for pointing out this limitation.
> Hopefully it can be addressed in a future iteration of
> http://openocd.zylin.com/5149.
> 
> [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
> 


-- 
Best regards,
Marek Vasut