- Is it possible to use arm-elf-none-edbi-gdb on the ARM9 to debug code running on the ARM M4? So, no need to attach SWD/JTAG and take pins - How is the code loaded onto the M4? i.e remoteproc? - Is there some IPC between the two processors (Linux/RTOS)? i.e remotemsg?
Hi there, for the moment we are getting started with UDOO Neo, so it is better to wait before answering. Please, be patient Andrea
I have the same question please inform when possible. Payment tool is needed? as desing studio 5 arm. I would like programming and debug tools open source
Yeah, I am wondering how the M4 programming will work as well! In theory, it could be fast and seamless compared to a serial connection, but getting all the magic to work inside one chip is a lot of work.. The IMX6SoloX is quite a beast! I'd be happy if it was just a "virtual serial" connection (via whatever mechanism), if that was robust.
Dear all, for the moment we are still unable to answer these questions. By the way, you may investigate the topic on the reference manual of i.MX 6SoloX, which is available at this address: http://cache.freescale.com/files/32...ORMAT=pdf&WT_ASSET=Documentation&fileExt=.pdf
I'm going to push forward and create a gdbserver that runs on the A9 and accesses the debug unit, i.e DHCSR, DEMCR . Basicly do what openOCD and pyOCD do. I think the hard part is to work with the kernel module to alloc memory to load the code for the M4, power up/power down M4, and start it.
You need to be aware that the M4 in my opinion is bettered described as a 'slave' core which has a number of ramifications, such as 1. sharing of clocks between the 2 cores (stopping clocks for one may effect the other). 2. how/when the M4 can be started or reset. There are assumption in the current kernel that the M4 has to be alive before the kernel boots so that it can control power management and setup shared clocks. 3. memory map between the cores is different, the M4 vector table may not sit as the obvious location. In my opinion if your planning to debug, then JTAG may be the only practical option. Which itself may have restrictions, for example the M4 is only visible to JTAG once the M4 has been enabled from the A9.
>There are assumption in the current kernel that the M4 has to be alive before the kernel boots so that it can control power management and setup shared clocks. Where is this in the kernel? In mu.c? The current examples in the mqx (RTOS) Linux sends messages to the M4 for low power mode, i.e M4 lis a client. I would think the device tree would set all of this up depending if the M4 is running, there are several device trees, with the M4 running and not running. > memory map between the cores is different, the M4 vector table may not sit as the obvious location. There is a register to map this. FYI: There are several examples, with linux creating a TTY interface so M4 and Linux can exchange simple messages... So, that is good.
