[U-Boot] 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