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.
First of all thanks for sharing this experince, it seems you did a great work there.
I'm wondering if I can connect any freescale board to the DS-5 and configure a debugger for it also to make OS awarence for mbed OS for example.
to be more specific I'm asking about the (FRDM-K64F) is it possible to debug it using the DS-5?
There are a couple of points to be aware of when debugging both cores simultaneously on this board.
Before you connect to the Cortex-M4 for the first time it will require releasing from reset - this can be achieved using the "Release Cortex-M4 from reset" tickbox in the DTSL options when creating the debug configuration.
When the Cortex-A9 boots Linux it will power down some of the M4's components if they are not in use, meaning it is then impossible to establish a debug connection to the M4 (the A9 will still be connectable though). The workaround to this is to establish a connection to the M4 before booting Linux on the A9 (i.e. during U-Boot).
Unfortunately I am not able to share the demo code I used, but I made very little changes to Freescale's components (I was using Linux 3.10.53_1.1.0_GA and MQX 4.1.0). In Linux kernel versions 3.10.53 and later you will need to disable the Freescale CAAM module in order to connect, although if you have successfully connected and booted Linux already it sounds like you may have done this, or do not have an affected kernel. More information on disabling the CAAM module can be found in "<ds5 install directory>/sw/debugger/configdb/Boards/Freescale/i.MX6 SoloX Sabre SDB/readme.txt". You will also need to add "mem=768m" to the Linux boot arguments to prevent it from using the area of RAM assigned to MQX. Otherwise everything should work out of the box.
Having followed the above steps you should be able to boot the board to U-Boot, connect with both the A9 and M4, and then continue to boot Linux on the A9 and MQX on the M4.
Hope this helps,
Thank you for sharing your experience. Would it be possible for you to share the demo code which you used? We have troubles with debugging Linux + MQX. Basically we either have (running M4 core) && (kernel panic on A9) or (succesfuly running Linux on A9) && (cannot attach to M4). It's clear that we are doing some wrong initialization or so and it would be helpful to have your demo because you know it is working.
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.
I would like to join my colleague and kindly request *.ds scripts if they are needed.