Recently I have been preparing one of the demos for ARM's booth at Embedded World 2015 (which occurred last week 24th - 26th February) to showcase ARM Development Studio 5’s (DS-5) debug and trace functionality. This demo makes use of Freescale's SABRE board based on their newly announced i.MX 6SoloX Applications Processor, containing an ARM Cortex-A9 and ARM Cortex-M4. The image below shows the board with an attached LCD screen and connected to an ARM DSTREAM - ARM’s high-performance debug and trace unit.
The i.MX 6SoloX is a multimedia-focused processor aimed at a wide variety of applications - achieved by combining the high performance of a Cortex-A9 and low power of a Cortex-M4 to maximise power efficiency.
Thanks to the co-operation between ARM and Freescale I was able to bring up the board very quickly, allowing me to get Linux and Android both booting on the board within a day. This is especially impressive given the board was pre-production at that point.
Once I had Linux successfully booting I then went about getting the DS-5 Debugger connected to it using the DSTEAM via the board's JTAG-20 connector. DS-5 Debugger support for the board was also added (via the configuration database) during the board's pre-production stages allowing full DS-5 support from release. This makes connecting the debugger as simple as selecting the platform in the Debug Configuration editor, choosing the appropriate connection to use and configuring it. This also enables a smooth, rapid transition from receiving the board to debugging or profiling a target application from the product's launch.
As the board has both a Cortex-A9 and Cortex-M4 on, it was a good candidate to demonstrate DS-5’s multicore debugging. These cores use Asymmetric Multiprocessing (AMP), as opposed to Symmetric Multiprocessing (SMP), meaning they are running completely independently (rather than under a single Operating System). I used DS-5 to connect and debug Linux on the Cortex-A9 as well as simultaneously using a separate connection to load a small Freescale MQX RTOS based example onto the Cortex-M4.
When debugging, we have access to DS-5's full suite of tools including, among others:
DS-5 allows multicore debug of targets (in both SMP and AMP configurations) using hardware and software breakpoints, with tools to provide a wide range of additional functionality from MMU page table views to custom peripheral register maps.
Collecting trace from the target using the DSTREAM allows non-intrusive instruction-level trace which can be used to help with: debug, especially when when halting the core is undesirable; post-crash analysis; and profiling the target.
DS-5 offers additional information views (e.g. memory use, running tasks etc.) for a number of the most popular RTOS (pictured below is one of the views for MQX).
Specialised connections are available to Linux targets to allow debug and trace of the Linux Kernel and Kernel Modules as well as visualisations of the threads, processes and resources.
Applications may be debugged by downloading the target application and compatible gdbserver to the target for debugging using the DS-5 interface (concurrently with Bare Metal or OS-level debug and/or trace as desired).
Streamline allows visualisation of the target’s performance for profiling and optimizing target code. Requiring no additional hardware or debug connections, Streamline operates only via TCPIP (or optionally an ADB connection in the case of Android) and can profile many aspects of a CPU/GPU/interconnect in high detail at varying resolutions, including power analysis (via external or on-chip energy probes). The image below shows a Streamline trace from Linux on the i.MX 6SoloX under heavy load.
Thanks to a stable pre-production platform and Freescale's assistance adding the new board to the debug configuration database the whole bring up experience was seamless. For information on creating debug configurations for new platforms, see the "New Platform Bring-Up with DS-5" post. ARM encourages platform owners to submit any debug configurations for their platforms back to the DS-5 team so we can include them by default in subsequent releases - thus allowing the same, fluid out-of-box experience for end users.
Hello Luis, Rene,
Sorry I didn't get back to you sooner - I completely forgot!
You do not need a *.ds script to debug the device, the entry in the configuration database is sufficient to connect to the device and debug or collect trace. The configuration database entry is present in DS-5 version 5.21 (and later).
I did not debug U-Boot for the demo I gave but it is possible to do so with DS-5. I tried it out a few days ago and have written up some notes that may help you below:
Firstly, it is important to note that the i.MX SoCs use a slightly different U-Boot format to usual. The U-Boot image which is flashed to the device (u-boot.imx) contains an IVT header in front of the normal U-Boot binary (u-boot.bin). This header is used by the SoC's boot ROM to help load the image. More information can be found about this on the Freescale community: u-boot.bin and u-boot.imx | Freescale Community. As a result of this difference, debugging U-Boot requires slightly more steps than it would usually take.
I first downloaded and built Freescale's latest U-Boot sources, information on doing this can be found here: i.MX51 EVK U-boot | Freescale Community. You will need to use the make target "mx6sxsabresd_config" for this board. This will build the necessary components - "u-boot.imx", which is the image to flash to the SD card as described, and "u-boot", which is the unstripped image without Freescale's headers which can be loaded in the debugger.
Ordinarily debugging U-Boot is simply a case of first performing any initial board configuration (normally, if you already have a functional platform, the easiest way of doing this is to let the device boot to U-Boot itself before connecting), then connecting to it from the debugger and loading an unstripped U-Boot image to RAM. However this does not appear to work with the i.MX 6SoloX. Following the guide at ARM DS-5 Quick Start (i.MX6) - BlueWiki shows loading an unstripped U-Boot image and running an initialization .ds script. Looking through the script it is simply configuring a number of the board's registers. I do not have such an initialization script for the i.MX 6SoloX although you might be able to modify the script for the i.MX 6Solo to work. The best place to ask about doing this would be the Freescale community as it relies on knowledge of the SoC's memory map.
So in short, you don't need a .ds script to debug the device, nor do you ordinarily need one to debug U-Boot, but in this particular case, due to the way Freescale's U-Boot works, it looks like you may need a .ds script to configure the target to allow you to successfully load U-Boot from the debugger. I'm afraid I don't have access to such a script.
Hope this helps, sorry I couldn't provide a solid answer for you.
Best regards,
Jonathan