Understanding GNAT Bare Board Run-time for Cortex-M

Understanding GNAT Bare Board Run-time for Cortex-M

[Daniel Way]

I'm trying to port the bare-board GNAT run-time to a Coretex-M0+ (NXP KV11Z7) processor. I'm new to concurrency and have been reading through the run-times for the STM32 targets to understand how the tasks and protected objects are implemented, however, there seems to be a web of dependencies between the different packages and wrappers of wrappers of wrappers for types and subprograms.

* Is there any tool available to scan through the source code and generate a graphical call graph to help visualize the different dependencies?

* Has anyone on the forum successfully ported a bare-board run-time? What was your experience and do you have any tips?

* Is porting the run-time just a matter of updating the linker, a few packages, and a GPR script, or is there some fundamental implementation changes to consider?

Thank you,
Daniel

Re: Understanding GNAT Bare Board Run-time for Cortex-M

[Simon Wright]

Daniel Way <p.waydan@gmail.com> writes:

> I'm trying to port the bare-board GNAT run-time to a Coretex-M0+ (NXP
> KV11Z7) processor. I'm new to concurrency and have been reading
> through the run-times for the STM32 targets to understand how the
> tasks and protected objects are implemented, however, there seems to
> be a web of dependencies between the different packages and wrappers
> of wrappers of wrappers for types and subprograms.

Yes.

> * Is there any tool available to scan through the source code and
> generate a graphical call graph to help visualize the different
> dependencies?

Pass.

> * Has anyone on the forum successfully ported a bare-board run-time?
> What was your experience and do you have any tips?

AdaCore have published a guide for porting their runtime[0].

GNAT CE 2018 includes a ravenscar-sfp-microbit runtime.

My Cortex GNAT RTS[1] is based on FreeRTOS[2] and includes an RTS for
the nRF51 as found in the BBC micro:bit. That's a cortex-m0, but as far
as I can see[3] the differences from the m0+ are minimal.

The main issue I had was with the clock; the nRF51 doesn't have a system
tick, instead I had to use RTC1 (I think AdaCore used RTC0).

> * Is porting the run-time just a matter of updating the linker, a few
> packages, and a GPR script, or is there some fundamental
> implementation changes to consider?

That would be it (also the runtime.xml file) but the problem is
identifying _which_ packages to change! I wouldn't expect many from the
microbit RTS, it's likely to be clock setup and interrupt naming. It
would help if you had an SVD to generate the board peripheral
dependencies.

[0] https://github.com/AdaCore/bb-runtimes/tree/community-2018/doc/porting_runtime_for_cortex_m
[1] https://github.com/simonjwright/cortex-gnat-rts
[2] https://www.freertos.org
[3] https://community.cypress.com/docs/DOC-10652

Re: Understanding GNAT Bare Board Run-time for Cortex-M

[Daniel Way]

On Monday, April 8, 2019 at 4:37:03 PM UTC+9, Simon Wright wrote:

> My Cortex GNAT RTS[1] is based on FreeRTOS[2] and includes an RTS for
> the nRF51 as found in the BBC micro:bit. That's a cortex-m0, but as far
> as I can see[3] the differences from the m0+ are minimal.

Thank you, I'll check out your version of FreeRTOS as reference while I learn about the tasking model.

As an aside, why did you decide to create your own runtime rather than use the ones installed with GNAT CE?

> The main issue I had was with the clock; the nRF51 doesn't have a system
> tick, instead I had to use RTC1 (I think AdaCore used RTC0).

My controller uses the SysTick, so hopefully I can reuse the timing functions from the STM32F4 runtimes.

Thanks for the great advice!

Re: Understanding GNAT Bare Board Run-time for Cortex-M

[Simon Wright]

Daniel Way <p.waydan@gmail.com> writes:

> On Monday, April 8, 2019 at 4:37:03 PM UTC+9, Simon Wright wrote:
[...]
> As an aside, why did you decide to create your own runtime rather than
> use the ones installed with GNAT CE?

At the time, there was a lot of fuss about the fact that the AdaCore
public bare-board runtimes were GPL (they still are).

Also, lots of fun.

Re: Understanding GNAT Bare Board Run-time for Cortex-M

[Niklas Holsti]

On 19-04-08 05:13 , Daniel Way wrote:
> I'm trying to port the bare-board GNAT run-time to a Coretex-M0+ (NXP
> KV11Z7) processor. I'm new to concurrency and have been reading
> through the run-times for the STM32 targets to understand how the
> tasks and protected objects are implemented, however, there seems to
> be a web of dependencies between the different packages and wrappers
> of wrappers of wrappers for types and subprograms.

The wrappers of course try to isolate the target-specific code from the 
target-independent code.

> * Is there any tool available to scan through the source code and
> generate a graphical call graph to help visualize the different
> dependencies?

I know of no free tool that generates graphical call-graphs. I've used 
the non-graphical call tree information from GPS.

> * Has anyone on the forum successfully ported a bare-board run-time?
> What was your experience and do you have any tips?

In my last project, I ported the small-footprint Ravenscar run-time for 
the SPARC architecture from the generic off-the-shelf AdaCore version to 
a specific SPARC LEON2 processor embedded in an SoC for processing 
satellite navigation signals, the AGGA-4 SoC.

My advice is to first understand the differences between the original 
target processor and the new target processor, especially in these areas:

- Basic processor architecture, and especially if there is some 
difference in the instruction set or in the sets of registers that must 
be saved and restored in a task switch. In my case there was no 
difference, so I did not have to modify the task-switch code nor the 
Task Control Block structure. For porting across various models of the 
same processsor architecture, perhaps the most likely difference is in 
the presence or absence of a floating-point unit and dedicated 
floating-point registers.

- The HW timers. In my case the RTS used two HW timers, and there were 
some differences: the bit-width was different (32 instead of 24) and the 
HW addresses and interrupt numbers were different. The corresponding 
parts of the RTS had to be adapted, but in my case the changes were 
small, and the logic of the code did not change.

- Interrupts and traps. Differences may have to be implemented in the 
assembly-language code that initially handles interrupts and traps. In 
my case, the architecture was the same (the structure of the trap table 
and most of the HW error traps) but the set of external interrupt traps 
was different, because of the particular I/O devices available on the 
new target. This difference (if any) becomes visible to application 
programs through Ada.Interrupts.

- "Console" I/O, usually some form of UART accessible via GNAT.Text_IO. 
In my case, the UARTs in the new target were quite different from the 
standard LEON2 UARTs, so I had to reimplement the low-level I/O 
operations (Put character, Put string, etc.).

- Memory layout. Where in the address space is the ROM (or flash), where 
is the RAM, where are the I/O control registers? Any differences in the 
layout must be implemented in the linker command script, which in my 
case was a file called leon.ld. The Ada RTS code probably does not have 
to change for this reason, and did not change in my case.

Once all that is sorted out, you will probably have to modify the 
start-up assembly-language code, which in my case was in the file 
crt0.S. This deals with HW initialization (clearing registers, stopping 
any I/O that might be running, disabling interrupts, etc.) and SW 
initialization, which means to set up the stack for the environment task 
and then enter the body of that task.

> * Is porting the run-time just a matter of updating the linker, a few
> packages, and a GPR script, or is there some fundamental
> implementation changes to consider?

If you are porting from one implementation of the same architecture to 
another (in your case ARM Cortex M<n> with the Thumb-1/2 instruction 
sets, if I understand right), IMO it is unlikely that any fundamental 
changes are required. However, if there are differences in the 
instruction set (with M0+ omitting some instructions available larger 
members and perhaps used in the original RTS) be sure to use the correct 
target options for the compiler so as to avoid generating code that will 
not run on the M0+. If there is a major difference in instruction sets 
(say, porting from Thumb-2 to Thumb-1) you will have to review and 
perhaps modify all the assembly-language RTS parts, and all 
assembly-language code insertions in the Ada RTS code, and all the code 
in crt0.S.

HTH. I think others on this group have more experience with ARM Cortex 
run-time systems and can probably offer better advice.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Understanding GNAT Bare Board Run-time for Cortex-M

[J-P. Rosen]

Le 08/04/2019 à 09:46, Niklas Holsti a écrit :
>> * Is there any tool available to scan through the source code and
>> generate a graphical call graph to help visualize the different
>> dependencies?
> 
> I know of no free tool that generates graphical call-graphs. I've used 
> the non-graphical call tree information from GPS.
There is such a tool right from GPS (for static call graph). For a 
dynamic call graph, you can use Valgrind + kcachegrind

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Understanding GNAT Bare Board Run-time for Cortex-M

[Daniel Way]

> There is such a tool right from GPS (for static call graph). For a 
> dynamic call graph, you can use Valgrind + kcachegrind

Thank you J-P. I'm not experience with GPS, but I'll look into it.

Re: Understanding GNAT Bare Board Run-time for Cortex-M

[Daniel Way]

> HTH. I think others on this group have more experience with ARM Cortex 
> run-time systems and can probably offer better advice.

Thanks, your advice is very helpful. I guess there's quite a bit of legwork just to get something blinking.