[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openocd-development
Subject:    Re: [OpenOCD-devel] DAP handling for Cortex-A
From:       Matthias Welwarsky <matthias () welwarsky ! de>
Date:       2015-11-22 17:01:09
Message-ID: 5673758.QkHRVi2BfW () linux-feyn ! site
[Download RAW message or body]

On Friday 20 November 2015 13:25:04 Andreas Fritiofson wrote:
> On Fri, Nov 20, 2015 at 11:20 AM, Matthias Welwarsky <matthias@welwarsky.de>
> > How would gdb utilize the ahb-ap for uploading binaries?
> 
> First of all, should it? As (I think) we have established, the main (only?)
> type of memory access associated with a Cortex-A target should be APB-AP
> access since that is the only type of access that is in sync with the CPU
> state and the only one universally available. AHB-AP access is not really
> associated with the specific CPU-target that GDB controls. Why shouldn't
> image loading use the same method as other memory accesses?

Because performance. The difference is quite striking. On an AM437x IDK with 
the embedded JTAG running at 16MHz clock I get the following throughput when
uploading a Linux zImage through OpenOCD "load_image":

using AHB AP: 
"downloaded 3615560 bytes in 10.744359s (328.621 KiB/s)"

using APB AP:
"downloaded 3615560 bytes in 25.042395s (140.994 KiB/s)"

Keep in mind that the AHB AP can directly use the MEM-AP interface to write to 
the system bus, while the APB AP must do the accesses using the ARM core, i.e. 
through the target abstraction.

> If we wanted to load images through AHB-AP (for performance reasons, or
> because the memory is RO to the CPU) we could of course associate multiple
> APs with the Cortex-A target, much like it is done today with separate
> debug_ap and memory_ap. Although then we would still need to select which
> AP would be used for which memory accesses and we would need to be able to
> map GDB's commands to types of memory accesses. Or have a big switch much
> like "dap apsel", only that the switch would be a (Cortex-A specific)
> target operation and not a DAP operation.

I'd suggest the latter. If we want to have the DAP out of the game, and I 
agree that selecting an access point on a DAP level is not at the right level 
of abstraction. GDB always uses "target_read/write_buffer" eventually, for all 
memory related commands. Therefore we cannot separate image loading from 
debugging at this level. A "mon cortex_a memaccess_ap <apnum>" on the other 
hand is always possible.

> It's getting more complex when you consider flash writing as well. Today a
> flash bank is associated with a target instance but in reality it could be
> independent of any CPU, or shared between multiple CPUs, like if the flash
> controller is memory mapped and accessible over an AHB-AP style port. Does
> it make sense to have to maintain a dummy target just to be able to write
> that kind of flash?

It is not always clear what is mapped on the AHB on a SoC, and at which 
addresses. They may be entirely different from the view of the ARM core. The 
information is not always public. We could use a dummy target, or a 
translation table to map ARM MPU to AHB address ranges.

> I think long term it might be useful to split out the concept of a memory
> bus and not have to have a target to be able to do memory accesses. For
> example a (MEM-)AP object would expose such a memory interface and would
> inherit all memory related commands.

In many cases it makes sense to have the target do memory accesses, because 
that's how it effectively is. But of course the target could then simply 
contain a memory bus interface.

BR,
Matthias


------------------------------------------------------------------------------
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
[prev in list] [next in list] [prev in thread] [next in thread]