[Oberon] Oberon Linker and the memory mapping

[John R. Strohm]

The usual reason for using such a bootloader is to facilitate online updating of the Flash image.  The bootloader copies itself to RAM and runs from there, allowing its former Flash space to be rewritten.

I spent a few years on ARM Cortex M3/M4 work.

--- chris at cfbsoftware.com wrote:

From: Chris Burrows <chris at cfbsoftware.com>
To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
Subject: Re: [Oberon] Oberon Linker and the memory mapping
Date: Thu, 27 Aug 2015 23:18:59 +0930

> -----Original Message-----
> From: skulski at pas.rochester.edu [mailto:skulski at pas.rochester.edu]
> Sent: Thursday, 27 August 2015 3:21 PM
> To: chris at cfbsoftware.com; ETH Oberon and related systems
> Subject: Oberon Linker and the memory mapping
> 
>   thank you for the pointers to the Astrobe forum. So you have a
> linker.

For the ARM Cortex-M3/M4 devices, yes, the main program is statically linked
with all the modules it uses and then uploaded to the target. For RISC5 I'm
using Project Oberon's dynamic module loader. Only the modules that have
been changed need to be uploaded to the target device. 

> The example MODULE ExtraRAM does not show the linker directives. I
> wonder what the linker commands look like.
> 

The parameters are stored in a configuration 'ini' file. There are two
RAM-related parameters:

Heap Start: 
The lowest address of the heap used when allocating memory to dynamic
pointer records using NEW (Default = 10000200H) 

Heap Limit: 
The highest address of the heap used when allocating memory to dynamic
pointer records using NEW. If the value is zero the heap is shared with the
stack and the highest address is the current value of the stack pointer
(Default = 0H)

If you are interested in more detail the linking / loading mechanism in
Astrobe for M3/M4 is described in the Astrobe documentation (in the Windows
Help and PDF files) which you can download from:

http://www.astrobe.com


> The example MODULE ExtraRAM does not show how the *code* can be
> placed in different kinds of memory. Code allocation is less critical
> with the MCU.

Astrobe ARM Cortex-M3/M4 code is always executed directly from Flash ROM.
RAM is used for data only. Some ARM embedded system designers use a
bootloader to transfer code from flash to RAM where it is then executed but
we have not yet had a need to do that.

Regards,
Chris

Chris Burrows
CFB Software
http://www.astrobe.com


--
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
https://lists.inf.ethz.ch/mailman/listinfo/oberon