Re: Automated/remote flashing of R-Car3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux