ChibiOS OpenOCD support

[mabl]

This is the development thread for ChibiOS Support in OpenOCD

The first prototype is working and eclipse is showing all threads currently running on the target:

eclipse_rtos.gif (49.46 KiB) Viewed 6288 times

Note, that openocd rtos support does currently not support the hardware FPU. You can disable it in your makefile.

For information on how to install and try this awesome feature yourself, have a look at the (incomplete) guide in the wiki.

Current status:
The patch has been included in upstream openocd master branch.

Original Post
Hello all,

since Giovanni gently pointed me to openocd for true thread support I tried to implement it last night.

What's already working is the detection of all treads. So if I go into gdb and issue a "info threads" I get a list with all threads and their names:

Code: Select all

(gdb) info threads
[New Thread 536890704]
[New Thread 536877264]
[New Thread 536903072]
[New Thread 536925496]
[New Thread 536908016]
[New Thread 536906752]
[New Thread 536905824]
[New Thread 536913056]
[New Thread 536918680]
[New Thread 536917752]
[New Thread 536911808]
[New Thread 536910880]
[New Thread 536919904]
[New Thread 536901832]
[New Remote target]
  16 Remote target  0x08011094 in _idle_thread (p=<value optimized out>)
    at /home/mabl/ASE/Entwicklung/axleSensorSTM32_git/src/external/chibios_git/os/kernel/src/chsys.c:55
  15 Thread 536901832 (blinker)  0x200078c8 in ?? ()
  14 Thread 536919904 (adcWorker)  broadcast (arg=<value optimized out>)
    at /home/mabl/ASE/Entwicklung/axleSensorSTM32_git/src/modules/com_ethernet/comEtherInterface_imp.hpp:29
  13 Thread 536910880 (ComEtherInterface)  0x08003ca6 in sys_arch_sem_wait (sem=0x20009c20,
    timeout=<value optimized out>)
    at /home/mabl/ASE/Entwicklung/axleSensorSTM32_git/src/modules/ethernet_lwip_adapter/sys_arch.c:107
  12 Thread 536911808 (ChannelWalker)  0x20009fc0 in ?? ()
  11 Thread 536917752 (ComEtherInterface)  0x08003ca6 in sys_arch_sem_wait (sem=0x2000b6f8,
    timeout=<value optimized out>)
    at /home/mabl/ASE/Entwicklung/axleSensorSTM32_git/src/modules/ethernet_lwip_adapter/sys_arch.c:107
  10 Thread 536918680 (ChannelWalker)  0x2000ba98 in ?? ()
  9 Thread 536913056 (axleBroadcastThread)  0x2000a4a0 in ?? ()
  8 Thread 536905824 (ComEtherInterface)  0x08003ca6 in sys_arch_sem_wait (sem=0x20008860,
    timeout=<value optimized out>)
    at /home/mabl/ASE/Entwicklung/axleSensorSTM32_git/src/modules/ethernet_lwip_adapter/sys_arch.c:107
  7 Thread 536906752 (ChannelWalker)  0x20008c00 in ?? ()
  6 Thread 536908016 (ConfigWorker)  0x08027490 in ?? ()
  5 Thread 536925496 (tcpip_thread)  0x2000d538 in ?? ()
  4 Thread 536903072 (lwip_thread_adapter)  ethernetif_init (netif=0x8012749)
    at /home/mabl/ASE/Entwicklung/axleSensorSTM32_git/src/modules/ethernet_lwip_adapter/lwipthread.cpp:211
  3 Thread 536877264 (MMCWorker)  0x200018d0 in ?? ()
  2 Thread 536890704 (idle)  0x08010fb0 in _port_thread_start ()
    at /home/mabl/ASE/Entwicklung/axleSensorSTM32_git/src/external/chibios_git/os/ports/GCC/ARMCMx/chcore_v7m.c:255
* 1 Thread 536890624 (main)  0x20004d00 in ?? ()


But somehow this looks a wrong... I think this is cause by me reading doing some fault reading the stack frame back. But I do not exactly get how the thread frame is saved.... Probably I'm just too stupid for it.

At the moment I'm working with an M3 F107 and use this default configuration. Somehow I cannot map this to the Stack layout in os/ports/GCC/ARMCMx/chcore_v7m.h.

Anything obviously wrong?

[Giovanni]

HI Mabl,

Great result in so little time

could you make a list of the info OpenOCD requires for each thread? I could be able to suggest the correct way to retrieve them.

Giovanni

[mabl]

Hi Giovanni,

thx for your help, I really appreciate it. First some remarks:

• gdb can request thread information from openocd.
• OpenOCD responds by querying the target memory, but since symbols can be located anywhere
• OpenOCD can ask gdb about the memory location of a symbol. No fancy stuff such as expressions.
  
• Since symbols contain only the start of the object. The OpenOCD rtos layer must know the offset and length of struct fields beforehand and it's hence hardwired.
• Since the location might vary for different platforms, the rtos support layer can have several tables which contain the memory layout.

For ChibiOS support, this is very problematic sice:

• ChibiOS might swap the position of the data fields i.e. in the rlist variable.
• ChibiOS is very customizable and there is no way yet to query if i.e. the thread registry has been enabled. Depending on other options also the location of the fields vary.

What needs to be checked for proper support is, if we can define symbols which can be read by OOCD but which take up no space. This would make OOCD support much easier. Alternatively, it might be possible to rearrange the Thread struct members so that their offset is not changed by the CH configuration.

I've uploaded my current work in progress to Github under the rtos_chibios branch.

What is currently probably malfunctioning is the thread register reading in ChibiOS_get_thread_reg_list. These registers are sent to gdb for each thread. The implementation is quite generic, one can basically define the register and its offset directly.

Unfortunately I'm not so sure what to put in the stack_register_offset since I've never looked so deep into the inner plumping of ChibiOS (It just workedâ„¢). Any help in this direction would be appreciated. The rest will be easy to finish.

[Giovanni]

The problem with the Thread structure is obvious, the Eclipse plugin can use expressions so it is not impacted. OpenOCD operates at a lower level and I imagine that also an RTOS extension for IAR or others would be impacted.

I was already considering adding to the kernel a "Run Time Info" record. A small static structure in flash describing the current organisation.

It would include (offsets):
0: "CHRT"
4: size of this structure (16)
5: reserved, zero.
6: ChibiOS version Mmpp
8: architecture identifier (ARM, MIPS, AVR etc).
9: enabled options (one bit for each option impacting the Thread structure)
10, 11: reserved, zero.
12: ptr to rlist
16: ptr to vtlist

Suggestions?

About the stack.
Stack base is the first byte after the Thread structure.
The pointer to the stack is the pointer to the intctx structure except for the current thread, in this case it is the SP register.
Stack end is pointed by an (optional) field in the Thread structure.

Giovanni

[Giovanni]

I added this record to chregistry.c, please feel free to propose changes.

Edit: I changed the format of the structure to include explicit offsets of all fields you may need, this way it should be easier to use compared to what I proposed before. I am a bit concerned about the method I used to calculate offsets, it is OK will GCC but I don't know about other compilers.
Can anybody test compile some project using IAR, Keil, Cosmic and Raisonance? I have no access to my workstation until Monday.

Giovanni

[mabl]

Hi Giovanni,

this looks great at first look. I'll incorporate it into the OpenOCD RTOS support - since it will likely only be merged with OpenOCD 0.7 (if ever) there is still plenty of time to get everything right and working. We should make sure that future ChibiOS versions also work with 0.7 for a long time.

I also like your change to explicitly state the offsets and not just the ChibiOS options. It takes more flash space but if somebody wants to save space the registry won't be enabled anyway. What might still be needed is some kind of options field where we can save stuff such as "FPU enabled" (changes Frame save behavior, right?) or "little/big-endian" (but openocd should have that info already.

Best,
MaBl

[mabl]

Hi Giovanni,

is it ok to copy your chroot_t struct definition without contaminating anything with copyright/licence issues? Is it enough to state that the are from os/kernel/include/chregistry.h? Just to make sure in case this code is accepted in upstream openocd.

PS: Any reason one field is named ch_reserved5, or is it a typo?

[Giovanni]

Hi,

No problems with the structure, just copy it where you need. The "5" is the offset in the structure, it is a trick I use when a structure has multiple reserved fields.

Giovanni

[mabl]

Great.

Further question: I'm a bit stupid in that regard but shouldn't the structure be declared as packed? Since otherwise there could be padding right? Or am I supposed to calculate the right padding based on the target?

[Giovanni]

There are only uint8_t there and a single uint16_t that is at word boundary.

Giovanni