[U-Boot] Automated/remote flashing of R-Car3
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... [1] https://github.com/CogentEmbedded/meta-rcar/blob/v3.15.0/meta-rcar-gen3-adas... [2] https://github.com/CogentEmbedded/meta-rcar/blob/v3.15.0/meta-rcar-gen3-adas... [3] https://github.com/CogentEmbedded/meta-rcar/blob/v3.15.0/meta-rcar-gen3-adas... [4] https://github.com/renesas-rcar/flash_writer
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?
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:
- 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.
- 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
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:
- 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.
- 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.
- 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.
- 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.
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?
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)
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:
- 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.
- 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.
- 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.
- 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
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:
- 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.
- 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.
- 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.
- 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...
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:
- 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.
- 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.
- 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.
- 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...
participants (3)
-
Eugeniu Rosca -
Marek Vasut -
Michael Dege