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
