Re: [OpenOCD-devel] Atmel SAMA5Dxx support?

[David M. <da...@eg...>]

Olivier,

Thanks for your response!  My results are a bit mixed: yes, your tree works
a lot better, but things still seem to be rather fragile.  Here is what has
worked best so far:

- Push reset button on SAMA5D2 Xplained board (target)
- start openocd:

openocd -f tcl/interface/cmsis-dap.cfg -f tcl/board/at91sama5d2X-ek.cfg

- start gdb:

arm-buildroot-linux-gnueabihf-gdb
binaries/sama5d2_xplained-dataflashboot-linux-zimage-dt-3.8-alpha7.elf

(gdb) target extended-remote localhost:3333

(gdb) mon halt

(gdb) load

(gdb) b main

(gdb) jump *0x200000

(gdb) step

(gdb) continue


​After the "continue" command, at91bootstrap seems to execute normally but
it fails to load the kernel from the SPI flash:

​AT91Bootstrap 3.8-alpha7-00015-g0957103-dirty (Thu Nov  5 23:14:45 MST
2015)

ACT8865: The REG2 output 1200mV
ACT8865: The REG4 output 2500mV
ACT8865: The REG5 output 3300mV
ACT8865: The REG6 output 2500mV
ACT8865: The REG7 output 1800mV
SF: Got Manufacturer and Device ID:*0xff 0xff 0xff 0xff 0xff*
Not supported spi flash Manufactorer ID: 0xff
SF: Fail to probe atmel spi flash
SF: Failed to load image


​I assume the failure to load from the SPI flash is because SAM-BA would
normally setup the hardware for access to the SPI flash before handing off
control to AT91Bootstrap, so that may be OK.  It's kind of a problem
though: how do I debug AT91Bootstrap properly when I first have to hand
control to SAM-BA to connect the ICE to the chip?  Shouldn't it be possible
to issue a "mon reset halt" command from gdb and have it reset the chip and
cause it to start the normal bootstrap procedure?  I understand this is
complicated by the fact that the secure boot mode will disable JTAG/SWD
while in secure mode, but since the Xplained board normally boots in
non-secure mode, it would be helpful if openocd could regain control as
soon as SAM-BA switches back into non-secure mode.  Do you have some
suggestions/thoughts on this?  The best I can think of is to insert a long
delay at the beginning of AT91Bootstrap that would give me enough time to
issue the "mon halt" command, but that seems rather cumbersome.

Note: sometimes the command "jump 0x200000" just seems to hang.  I can
press Ctrl-C and then re-issue the same command and then it works (it stops
at the "main" entry point).​


Thanks and best regards,

  --david

On Fri, Nov 6, 2015 at 11:51 PM, Olivier Schonken <
oli...@gm...> wrote:

> Hi David
>
> I did work on adding support to Openocd support for Sama5Dx processors.
> The short and the long of it was that I got it working(sortof), it relies
> on Oleksij Rempel's cache handling patches to be able to do single
> stepping.  For Cortex-A debugging, if an interrupt occurs while stepping,
> openocd only gives the address of the interrupt vector 0x18 for example,
> and does not step inside the handler.
>
> I pushed an openocd repo to github with oleksij's and my patches to make
> it easier for anyone wanting to work on the SAMA5 -
> <https://github.com/olivierschonken/openocd-sama5.git>https://github.com/
> olivierschonken/openocd-sama5.git
> (I might update it at a later stage with more up to date patches regarding
> the cache handling)
> Example session was run with CMSIS-DAP SWD - looks like that is the
> default for CMSIS-DAP
>
> Ok, just to be sure - for compiling the softpack application you need to
> use the compiler from
> https://launchpad.net/gcc-arm-embedded.
>
>  Before compiling openocd for cmsis-dap remember to install libhidapi-dev
> dependency
>
> For building openocd - ./configure --enable-maintainer-mode
> --enable-cmsis-dap --enable-hidapi-libusb --enable-ftdi --enable-jlink
>
> For running openocd
> openocd -f interface/cmsis-dap.cfg -f board/atmel_sama5d2_xplained.cfg
> (add sudo if permissions an issue)
>
> Issues with this build:
> Needs a double load of your app.  But only the first time the board is
> powered. (Might have something to do with the JTAG being enabled only after
> sending # through SAM-BA?)
> If I keep openocd open, and do a ctrl c, and reload the app, everything
> starts working
> every subsequent time.  I can restart GDB with different apps, and the
> load/debug sequence would be fine.
> It thus looks like something that is an issue on power-up/reset. The same
> scenario happens when doing 'mon reset' - you have to restart openocd, and
> then on the first load it doesn't work.  On the second load and everyone
> after that it works, as long as you don't reset or cycle power.
>
> Regards
> Olivier
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> OpenOCD-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openocd-devel
>
>


-- 
eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768