On 2004-04-16, Ken Lee <postmaster@noname.com> wrote:
> As you've already surmised you need to create a startup code
> section which takes the ROM-based .data section and copies it
> into the .bss section.
Nooo!
The .bss section should be initialized to all zeros.
The .data section should have two addresses:
VMA (virtial memory address): the run-time address where the
compiled code expects the variables to be. This will be
in RAM.
LMA (load memory address): the addresses to which the
initialization data are stored by the linker. This will
be in ROM.
Startup code should copy from .data's LMA to .data's VMA.
> The linker, LD, configuartion file is so organised to refer to
> an image of the .data section but offset into the .bss or RAM
> area.
It sounds like you're doing a round-about, home-made
implimenation of the VMA/LMA capabilities built into the
linker?
>[...]
> Of course there is the simple solution and that is to
> eliminate all use of initialised variables.
That's rarely simple.
It takes 4-5 lines of code to copy all of the initializer
values from .data LMA to the .data VMA. It takes at least one
line of code per vairable to itialize them piecemeal in
application code. Your "simpler" solution can take thousands
of times more code.
--
Grant Edwards grante Yow! I'm young... I'm
at HEALTHY... I can HIKE
visi.com THRU CAPT GROGAN'S LUMBAR
REGIONS!
Reply by Michael N. Moran●April 16, 20042004-04-16
Ken Lee wrote:
> As you've already surmised you need to create a startup code
> section which takes the ROM-based .data section and copies it into the
> .bss section.
A small nit here. The initialized data is copied to RAM, but
not the bss. The bss is for global/static variables that are
initialized by default to zero.
> The linker, LD, configuartion file is so organised to
> refer to an image of the .data section but offset into the .bss or RAM
> area. The GNU manual on LD provides you with information on how to
> setup the linker file. From that you can write the companion startup
> code. The startup code is initiated from the Power-on-reset. The start
> and end boundaries of the .data section can be defined in the linker
> configuration file -- this is required to mark out the start & range
> of the ROM code to copy.
>
> Of course there is the simple solution and that is to
> eliminate all use of initialised variables.
While this eliminates the need to copy initialized data
into RAM, it does not do the other important setup of
the C runtime, which is to zero the bss section. I assume
that if your startup code is missing the data initialization
it may also be missing the bss initialization.
--
Michael N. Moran (h) 770 516 7918
5009 Old Field Ct. (c) 678 521 5460
Kennesaw, GA, USA 30144 http://mnmoran.org
"... abstractions save us time working, but they don't
save us time learning."
Joel Spolsky, The Law of Leaky Abstractions
The Beatles were wrong: 1 & 1 & 1 is 1
Reply by Ken Lee●April 16, 20042004-04-16
On 14 Apr 2004 23:11:47 -0700, robert.bielik@gyros.com (Robert Bielik)
wrote:
>Hi all,
>
>I have "inherited" a project with a H8S/2633F MPU (using the GNU gcc
>toolchain). I need static variables. Problem is that there is no init
>code for static variables in the bootloader code. I.e. the initial
>static data is correctly placed in the FLASH ROM, but the data is
>never transferred at startup to the RAM. I have searched everywhere
>for a simple example showing how to do it but have come up empty so
>far.
>
>Does anyone have a (asm) code snippet for this ?? I guess any MPU in
>the 26xx series would do...
>
>If you do, please send a copy to my email address also.
>
>TIA
>/Rob
Hi Rob,
As you've already surmised you need to create a startup code
section which takes the ROM-based .data section and copies it into the
.bss section. The linker, LD, configuartion file is so organised to
refer to an image of the .data section but offset into the .bss or RAM
area. The GNU manual on LD provides you with information on how to
setup the linker file. From that you can write the companion startup
code. The startup code is initiated from the Power-on-reset. The start
and end boundaries of the .data section can be defined in the linker
configuration file -- this is required to mark out the start & range
of the ROM code to copy.
Of course there is the simple solution and that is to
eliminate all use of initialised variables.
Ken.
+====================================+
I hate junk email. Please direct any
genuine email to: kenlee at hotpop.com
Reply by Steve at fivetrees●April 15, 20042004-04-15
"Paul Carpenter" <paul$@pcserv.demon.co.uk> wrote in message
news:20040415.2307.298224snz@pcserv.demon.co.uk...
> I have never seen "Hitachi" compilers, just IAR from Hitachi/Renesas, with
> more recognition of GCC.
IIRC, it was around the time that HEW came out ('99?) that the sales reps
were offering us three toolchains (gcc, IAR, Hitachi), and the Hitachi one
was being heavily promoted (as you'd expect). I do distinctly remember my
rep telling me that the IAR compilers were being "de-emphasised" in favour
of Hitachi versions, but I also remember wondering later if it was purely a
badging exercise.
More recently I've been working on the H8 again, with up-to-date tools
provided by my customer's R&D dept. And the compilers again are overtly IAR.
I think I missed the middle of the story (roughly '01 through late '03).
Steve
http://www.sfdesign.co.ukhttp://www.fivetrees.com
Reply by Paul Carpenter●April 15, 20042004-04-15
On Thursday, in article
<407ef10e$0$95327$65c69314@mercury.nildram.net>
steve@NOSPAMTAfivetrees.com "Steve at fivetrees" wrote:
>"Paul Carpenter" <paul$@pcserv.demon.co.uk> wrote in message
>news:20040415.1956.298209snz@pcserv.demon.co.uk...
>> >I don't know about the gcc code, but Hitachi's H8 compilers traditionally
>> >make the variable initialisation startup phase optional.
>>
>> Hitachi as such a) does not exist the semiconductor division is Renesas,
>> b) They themselves don't write compilers.
>
><sigh> Re a) - yes, I know. I'm a dinosaur who's been using H8s (and before
>that, other Hitachi CPUs) for far too long. Re b) - interesting point, that.
I have been using H8/H8S for a few years and set up the GNUH8 mailing list
in 1998 !!!
Also have a H8 Tiny and SH2 here I must get round to 'playing' with.
>When they changed over from the IAR compiler chain to "their own", the
>Hitachi reps here in the UK would refer to the two available toolchains as
>"IAR" and "Hitachi". This was a few years back. Have the real compiler
>writers now stood up and taken a bow? I almost missed the Renesas merger -
>have I missed something re the compilers? Wouldn't be too surprised...
On Thursday, in article
<407efa1e.173522045@News.individual.net> iddw@hotmail.com
"Dave Hansen" wrote:
>On Thu, 15 Apr 2004 21:23:15 +0100, "Steve at fivetrees"
><steve@NOSPAMTAfivetrees.com> wrote:
>>"Grant Edwards" <grante@visi.com> wrote in message
>>news:407edbe4$0$17256$a1866201@newsreader.visi.com...
>>> You expect the compiler to write your startup code? How is it
>>> supposed to know how you want things done?
>>
>>Point taken - although initialising variables by copying from one known
>>segment to another known segment is perhaps something I'd expect to be
>>standard. (Although I can certainly imagine cases where this would indeed
>>need to be turned off.)
>>
>>> All you have to do is tell the linker the load address for the
>>> .data section (presumably somewhere in ROM). Then you write 4-5
>>> lines of code in your startup routine to copy bytes from the
>>> .data section's load address to its virtual address.
>>
>>... which is the bit I (clearly naively) expected to be standard. Thanks for
>>the info.
>
>FWIW, the compilers I have that target micros with integrated memory
>(e.g., PIC, AVR, HC908) _do_ variable initialization by default in
>their startup code. In an old 80186 project (external memory only),
>however, I had to write my own code to initialize the chip selects and
>memory controller hardware before RAM could even be accessed.
The same is true for most H8xxx processors the default data could be being
written to external RAM (considering a 16MB address space and only a
relatively few KB internally).
>Every compiler I have except the one targetting the PIC allow me to
>edit or replace the standard startup code.
On Thu, 15 Apr 2004 21:23:15 +0100, "Steve at fivetrees"
<steve@NOSPAMTAfivetrees.com> wrote:
>"Grant Edwards" <grante@visi.com> wrote in message
>news:407edbe4$0$17256$a1866201@newsreader.visi.com...
>> You expect the compiler to write your startup code? How is it
>> supposed to know how you want things done?
>
>Point taken - although initialising variables by copying from one known
>segment to another known segment is perhaps something I'd expect to be
>standard. (Although I can certainly imagine cases where this would indeed
>need to be turned off.)
>
>> All you have to do is tell the linker the load address for the
>> .data section (presumably somewhere in ROM). Then you write 4-5
>> lines of code in your startup routine to copy bytes from the
>> .data section's load address to its virtual address.
>
>... which is the bit I (clearly naively) expected to be standard. Thanks for
>the info.
FWIW, the compilers I have that target micros with integrated memory
(e.g., PIC, AVR, HC908) _do_ variable initialization by default in
their startup code. In an old 80186 project (external memory only),
however, I had to write my own code to initialize the chip selects and
memory controller hardware before RAM could even be accessed.
Every compiler I have except the one targetting the PIC allow me to
edit or replace the standard startup code.
Regards,
-=Dave
--
Change is inevitable, progress is not.
Reply by Steve at fivetrees●April 15, 20042004-04-15
"Paul Carpenter" <paul$@pcserv.demon.co.uk> wrote in message
news:20040415.1956.298209snz@pcserv.demon.co.uk...
> >I don't know about the gcc code, but Hitachi's H8 compilers traditionally
> >make the variable initialisation startup phase optional.
>
> Hitachi as such a) does not exist the semiconductor division is Renesas,
> b) They themselves don't write compilers.
<sigh> Re a) - yes, I know. I'm a dinosaur who's been using H8s (and before
that, other Hitachi CPUs) for far too long. Re b) - interesting point, that.
When they changed over from the IAR compiler chain to "their own", the
Hitachi reps here in the UK would refer to the two available toolchains as
"IAR" and "Hitachi". This was a few years back. Have the real compiler
writers now stood up and taken a bow? I almost missed the Renesas merger -
have I missed something re the compilers? Wouldn't be too surprised...
Steve
http://www.sfdesign.co.ukhttp://www.fivetrees.com
Reply by Steve at fivetrees●April 15, 20042004-04-15
"Grant Edwards" <grante@visi.com> wrote in message
news:407edbe4$0$17256$a1866201@newsreader.visi.com...
> You expect the compiler to write your startup code? How is it
> supposed to know how you want things done?
Point taken - although initialising variables by copying from one known
segment to another known segment is perhaps something I'd expect to be
standard. (Although I can certainly imagine cases where this would indeed
need to be turned off.)
> All you have to do is tell the linker the load address for the
> .data section (presumably somewhere in ROM). Then you write 4-5
> lines of code in your startup routine to copy bytes from the
> .data section's load address to its virtual address.
On Thursday, in article
<407eb3d2$0$95319$65c69314@mercury.nildram.net>
steve@NOSPAMTAfivetrees.com "Steve at fivetrees" wrote:
>"Robert Bielik" <robert.bielik@gyros.com> wrote in message
>news:33b863b3.0404142211.7efd984f@posting.google.com...
>> I have "inherited" a project with a H8S/2633F MPU (using the GNU gcc
>> toolchain). I need static variables. Problem is that there is no init
>> code for static variables in the bootloader code. I.e. the initial
>> static data is correctly placed in the FLASH ROM, but the data is
>> never transferred at startup to the RAM. I have searched everywhere
>> for a simple example showing how to do it but have come up empty so
>> far.
>
>I don't know about the gcc code, but Hitachi's H8 compilers traditionally
>make the variable initialisation startup phase optional.
Hitachi as such a) does not exist the semiconductor division is Renesas,
b) They themselves don't write compilers.
>I would be shocked if the gcc H8 compiler didn't init the variables, or at
>least provide a means for this code to be included - since, without it, the
>compiler could be considered to be broken.
Remember the GCC compiler is multi-target and multi-platform compiler and
unless there is a defined crt0.o, it does not know which embedded scenario
it is compiling for. There are plenty of examples of startup code from
simple to complicated around.