Unfortunately I don't know aarch64 target. The main point for the ring
buffer implementation is that there must be a possibility to read/write
the buffer head/tail pointers atomically and concurrently with the
running target
(and of course, to access the buffer itself, too).
On 2021-01-31 22:1
Thanks Andreas,
Do you know what the development state of target_run_flash_async_algorithm is
with an aarch64 target?
It looks like aarch64.c doesn't have a start_algorithm definition. Is that
going to be a big hurdle for this idea?
Thanks,
Taylor
On Thursday, January 21, 2021, 3:24:33 AM GM
On 2021-01-21 05:28, Taylor Stroobosscher via OpenOCD-devel wrote:
What would be the best approach to start here? Does a dedicated
'fslqspi' driver
seem like it would be a worthwhile effort? Would possibly working on
the
previous code be realistic?
If you decide to develop a driver, I'd sugg
The disadvantage of 4235 is programming speed: As the flash chips are
getting larger (16 MBytes is already only moderate size), handling every
single register read/write via the host and debug adapter becomes
unfeasible.
(Similar problem for a verify: Complete readout and comparison on the
host
Hi,
I'm looking for flash programming support for an NXP LS1012A.
I understand that adding support for Freescale's QSPI has been attempted
at least once before (change 4235), however it doesn't appear to have
gotten any traction after about a couple years ago.
What would be the best approach to
