* RedBoot built with gcc 3.4.4
@ 2007-02-07 11:52 Guennadi Liakhovetski
2007-02-07 12:11 ` Andrew Lunn
0 siblings, 1 reply; 16+ messages in thread
From: Guennadi Liakhovetski @ 2007-02-07 11:52 UTC (permalink / raw)
To: ecos-devel
Hi all
I've built redboot for an XSCALE PXA270 based board from eCos CVS snapshot
around December 2006. What built with gcc 3.3.2 binutils 2.14.90 redboot
works fine. When built with gcc 3.4.4 binutils 2.15.96 it comes to
Reset caused by: hardware reset pin
Core voltage will be set to 1.150 Volts.
Clock speed will be changed to 208 MHz
clock speed set to 208 MHz ...
+
and then comes a string
$T0a0f:58ab00a0;0d:34d500a0;#0b
and it keeps repeating on every ENTER. I was told that this string comes
from some debugging mode, which is invoked due to some unrecognised
exception. Here are the used flags
-O2 -ffunction-sections -fdata-sections -fno-rtti -fno-builtin \
-fno-exceptions -fvtable-gc -finit-priority -mapcs-frame
Originally there was also a "-g" there, which I now removed, and haven't
yet checked if the problem is still there, but I think it is not the
reason.
Is the problem known to anybody / how do we solve it?
Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RedBoot built with gcc 3.4.4
2007-02-07 11:52 RedBoot built with gcc 3.4.4 Guennadi Liakhovetski
@ 2007-02-07 12:11 ` Andrew Lunn
2007-02-07 12:43 ` Guennadi Liakhovetski
0 siblings, 1 reply; 16+ messages in thread
From: Andrew Lunn @ 2007-02-07 12:11 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: ecos-devel
On Wed, Feb 07, 2007 at 12:52:43PM +0100, Guennadi Liakhovetski wrote:
> Hi all
>
> I've built redboot for an XSCALE PXA270 based board from eCos CVS snapshot
> around December 2006. What built with gcc 3.3.2 binutils 2.14.90 redboot
> works fine. When built with gcc 3.4.4 binutils 2.15.96 it comes to
>
> Reset caused by: hardware reset pin
> Core voltage will be set to 1.150 Volts.
> Clock speed will be changed to 208 MHz
> clock speed set to 208 MHz ...
> +
>
> and then comes a string
>
> $T0a0f:58ab00a0;0d:34d500a0;#0b
>
> and it keeps repeating on every ENTER. I was told that this string comes
> from some debugging mode, which is invoked due to some unrecognised
> exception.
Correct. Use gdb and find out where it crashed. It can decode the
string to give you an address.
You might also want to try the old gcc with the new binutils, and the
new gcc with the old binutils etc to find out which is the problem.
Andrew
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RedBoot built with gcc 3.4.4
2007-02-07 12:11 ` Andrew Lunn
@ 2007-02-07 12:43 ` Guennadi Liakhovetski
2007-02-07 12:52 ` Andrew Lunn
2007-02-07 12:56 ` Edgar Grimberg
0 siblings, 2 replies; 16+ messages in thread
From: Guennadi Liakhovetski @ 2007-02-07 12:43 UTC (permalink / raw)
To: Andrew Lunn; +Cc: ecos-devel
On Wed, 7 Feb 2007, Andrew Lunn wrote:
>> $T0a0f:58ab00a0;0d:34d500a0;#0b
>>
>> and it keeps repeating on every ENTER. I was told that this string comes
>> from some debugging mode, which is invoked due to some unrecognised
>> exception.
>
> Correct. Use gdb and find out where it crashed. It can decode the
> string to give you an address.
Ok, a short look through eCos / RedBoot docs didn't reveal anything. Could
you, please, give some short instructions? I used gdb also remotely, but
with the bdi2000 stub... And never heard of such cryptic lines. How do I
debug it? I'll try to look further.
Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RedBoot built with gcc 3.4.4
2007-02-07 12:43 ` Guennadi Liakhovetski
@ 2007-02-07 12:52 ` Andrew Lunn
2007-02-07 13:00 ` Guennadi Liakhovetski
2007-02-07 12:56 ` Edgar Grimberg
1 sibling, 1 reply; 16+ messages in thread
From: Andrew Lunn @ 2007-02-07 12:52 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: Andrew Lunn, ecos-devel
On Wed, Feb 07, 2007 at 01:43:35PM +0100, Guennadi Liakhovetski wrote:
> On Wed, 7 Feb 2007, Andrew Lunn wrote:
>
> >>$T0a0f:58ab00a0;0d:34d500a0;#0b
> >>
> >>and it keeps repeating on every ENTER. I was told that this string comes
> >>from some debugging mode, which is invoked due to some unrecognised
> >>exception.
> >
> >Correct. Use gdb and find out where it crashed. It can decode the
> >string to give you an address.
>
> Ok, a short look through eCos / RedBoot docs didn't reveal anything. Could
> you, please, give some short instructions? I used gdb also remotely, but
> with the bdi2000 stub... And never heard of such cryptic lines. How do I
> debug it? I'll try to look further.
http://ecos.sourceware.org/docs-latest/user-guide/user-guide-installation-target.html
Connect the serial port of your PC to the serial port of your device.
start gdb with the elf or redboot.
gdb redboot.elf
target remote /dev/ttyS0
bt
Andrew
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RedBoot built with gcc 3.4.4
2007-02-07 12:43 ` Guennadi Liakhovetski
2007-02-07 12:52 ` Andrew Lunn
@ 2007-02-07 12:56 ` Edgar Grimberg
1 sibling, 0 replies; 16+ messages in thread
From: Edgar Grimberg @ 2007-02-07 12:56 UTC (permalink / raw)
To: Guennadi Liakhovetski, ecos-devel
>
> Ok, a short look through eCos / RedBoot docs didn't reveal anything.
> Could you, please, give some short instructions? I used gdb also
> remotely, but with the bdi2000 stub... And never heard of such cryptic
> lines. How do I debug it? I'll try to look further.
>
Replace the
target remote <IP>:2001
with
target remote <serial_channel>
Using gdb:
(gdb) help target remote
Use a remote computer via a serial line, using a gdb-specific protocol.
Specify the serial device it is connected to
(e.g. /dev/ttyS0, /dev/ttya, COM1, etc.).
Edgar
PS: if you have the BDI2000 connected to the target, you better use that
instead of serial debugging.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RedBoot built with gcc 3.4.4
2007-02-07 12:52 ` Andrew Lunn
@ 2007-02-07 13:00 ` Guennadi Liakhovetski
2007-02-07 13:03 ` Gary Thomas
0 siblings, 1 reply; 16+ messages in thread
From: Guennadi Liakhovetski @ 2007-02-07 13:00 UTC (permalink / raw)
To: Andrew Lunn; +Cc: ecos-devel
On Wed, 7 Feb 2007, Andrew Lunn wrote:
> gdb redboot.elf
> target remote /dev/ttyS0
> bt
Ok, thanks. Here:
(gdb) bt
#0 0xa0011bb4 in workspace_start ()
#1 0x18e59ff0 in ?? ()
#2 0xa000d79c in __startup_stack_base ()
Cannot access memory at address 0xe3e85dd9
Will look at that workspace_start, if I can identify anything...
Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RedBoot built with gcc 3.4.4
2007-02-07 13:00 ` Guennadi Liakhovetski
@ 2007-02-07 13:03 ` Gary Thomas
2007-02-07 13:24 ` Guennadi Liakhovetski
0 siblings, 1 reply; 16+ messages in thread
From: Gary Thomas @ 2007-02-07 13:03 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: Andrew Lunn, ecos-devel
Guennadi Liakhovetski wrote:
> On Wed, 7 Feb 2007, Andrew Lunn wrote:
>
>> gdb redboot.elf
>> target remote /dev/ttyS0
>> bt
>
> Ok, thanks. Here:
>
> (gdb) bt
> #0 0xa0011bb4 in workspace_start ()
> #1 0x18e59ff0 in ?? ()
> #2 0xa000d79c in __startup_stack_base ()
> Cannot access memory at address 0xe3e85dd9
>
> Will look at that workspace_start, if I can identify anything...
Those are all data addresses (that RedBoot uses), so it
looks like it has jumped into space...
You'll be better off restarting it using GDB and step
through to find out where it goes wrong.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RedBoot built with gcc 3.4.4
2007-02-07 13:03 ` Gary Thomas
@ 2007-02-07 13:24 ` Guennadi Liakhovetski
2007-02-07 13:42 ` Gary Thomas
0 siblings, 1 reply; 16+ messages in thread
From: Guennadi Liakhovetski @ 2007-02-07 13:24 UTC (permalink / raw)
To: Gary Thomas; +Cc: Andrew Lunn, ecos-devel
On Wed, 7 Feb 2007, Gary Thomas wrote:
> You'll be better off restarting it using GDB and step
> through to find out where it goes wrong.
hm, that requires gdb support from the redboot, which I am not sure if I
have. It crashes somewhere inside bootp. "+" is where it starts sending
bootp requests. So, I could set a breakpoint on __bootp_find_local_ip (is
this the right function for it?), but how do I reset the board from under
gdb? and will it directly contact the gdb stub on the board and set the
breakpoint?
Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RedBoot built with gcc 3.4.4
2007-02-07 13:24 ` Guennadi Liakhovetski
@ 2007-02-07 13:42 ` Gary Thomas
2007-02-07 13:59 ` Guennadi Liakhovetski
0 siblings, 1 reply; 16+ messages in thread
From: Gary Thomas @ 2007-02-07 13:42 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: ecos-devel
Guennadi Liakhovetski wrote:
> On Wed, 7 Feb 2007, Gary Thomas wrote:
>
>> You'll be better off restarting it using GDB and step
>> through to find out where it goes wrong.
>
> hm, that requires gdb support from the redboot, which I am not sure if I
> have. It crashes somewhere inside bootp. "+" is where it starts sending
> bootp requests. So, I could set a breakpoint on __bootp_find_local_ip
> (is this the right function for it?), but how do I reset the board from
> under gdb? and will it directly contact the gdb stub on the board and
> set the breakpoint?
To debug RedBoot, you'll need to use your BDI.
Simply connect GDB to the BDI instead of the serial port.
Something like this:
(gdb) tar rem bdi:2001
where 'bdi' is the DNS name or IP of your unit. It has commands
for resetting the device, setting hardware breakpoints, etc. Read
the BDI manual for the details.
Then you can step through the RedBoot code to find out where it's
going bad.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RedBoot built with gcc 3.4.4
2007-02-07 13:42 ` Gary Thomas
@ 2007-02-07 13:59 ` Guennadi Liakhovetski
2007-02-07 14:32 ` Gary Thomas
0 siblings, 1 reply; 16+ messages in thread
From: Guennadi Liakhovetski @ 2007-02-07 13:59 UTC (permalink / raw)
To: Gary Thomas; +Cc: ecos-devel
On Wed, 7 Feb 2007, Gary Thomas wrote:
> To debug RedBoot, you'll need to use your BDI.
>
> Simply connect GDB to the BDI instead of the serial port.
> Something like this:
> (gdb) tar rem bdi:2001
Aha, ok, this makes sense, but, unfortunately, bdi doesn't work with this
board. It worked somehow with pxa255 (not very reliably) and I haven't
been able to use it with pxa270. Yes, I do have the necessary register
description etc. files, just it wouldn't work. So, I guess, it's not an
option for me. I could disable bootp, but the point was not to somehow get
it to build and run, but to find the reason of the mis-compilation and
(preferrably) fix redboot. Besides, every non-booting redboot means about
20 minutes jtag flashing...
Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RedBoot built with gcc 3.4.4
2007-02-07 13:59 ` Guennadi Liakhovetski
@ 2007-02-07 14:32 ` Gary Thomas
2007-02-09 7:55 ` Guennadi Liakhovetski
0 siblings, 1 reply; 16+ messages in thread
From: Gary Thomas @ 2007-02-07 14:32 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: ecos-devel
Guennadi Liakhovetski wrote:
> On Wed, 7 Feb 2007, Gary Thomas wrote:
>
>> To debug RedBoot, you'll need to use your BDI.
>>
>> Simply connect GDB to the BDI instead of the serial port.
>> Something like this:
>> (gdb) tar rem bdi:2001
>
> Aha, ok, this makes sense, but, unfortunately, bdi doesn't work with
> this board. It worked somehow with pxa255 (not very reliably) and I
> haven't been able to use it with pxa270. Yes, I do have the necessary
> register description etc. files, just it wouldn't work. So, I guess,
> it's not an option for me. I could disable bootp, but the point was not
> to somehow get it to build and run, but to find the reason of the
> mis-compilation and (preferrably) fix redboot. Besides, every
> non-booting redboot means about 20 minutes jtag flashing...
In that case, what I would do is install a working RedBoot
(built with 3.3.2) and then experiment with a RAM version
built with the new tools. Put in some diag_printf() to
trace the code. You might even be able to debug this
using the serial connection and GDB (since that does
seem to be alive in your ROM/ROMRAM version)
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RedBoot built with gcc 3.4.4
2007-02-07 14:32 ` Gary Thomas
@ 2007-02-09 7:55 ` Guennadi Liakhovetski
2007-02-09 9:53 ` Guennadi Liakhovetski
0 siblings, 1 reply; 16+ messages in thread
From: Guennadi Liakhovetski @ 2007-02-09 7:55 UTC (permalink / raw)
To: Gary Thomas; +Cc: ecos-devel
On Wed, 7 Feb 2007, Gary Thomas wrote:
> In that case, what I would do is install a working RedBoot
> (built with 3.3.2) and then experiment with a RAM version
> built with the new tools. Put in some diag_printf() to
> trace the code. You might even be able to debug this
> using the serial connection and GDB (since that does
> seem to be alive in your ROM/ROMRAM version)
Well, yeah, looked shortly at this, but RAM build is not supported on this
plaform and a quick try wasn't successful.
OTOH, I realised, that I, probably, was wrong about where it crashes. The
last messages that I see are from CPU clock switching code. I looked in
those disassembled functions - they are VERY different. And I noticed that
RedBoot / eCos doesn't specify any ARM version specific options. This
toolchain builds kernels just fine, but the kernel does provide a few
CPU-specific options. It also compiles user-space applications fine
without any options - but that is user-space. So, there might be a problem
with some supervisor mode insn. I tried adding "-mapcs-frame
-march=armv5te -mtune=xscale -Wa,-mcpu=xscale" to c-flags, it didn't help.
Looking further
Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RedBoot built with gcc 3.4.4
2007-02-09 7:55 ` Guennadi Liakhovetski
@ 2007-02-09 9:53 ` Guennadi Liakhovetski
2007-02-09 10:18 ` Guennadi Liakhovetski
2007-02-12 18:36 ` Kurt Siedenburg
0 siblings, 2 replies; 16+ messages in thread
From: Guennadi Liakhovetski @ 2007-02-09 9:53 UTC (permalink / raw)
To: Gary Thomas; +Cc: ecos-devel
On Fri, 9 Feb 2007, Guennadi Liakhovetski wrote:
> Looking further
Auch... I came as far as to the loop
/*------------------------------------------------------------------------*/
/* C++ support - run initial constructors */
#ifdef CYGSEM_HAL_STOP_CONSTRUCTORS_ON_FLAG
cyg_bool cyg_hal_stop_constructors;
#endif
typedef void (*pfunc) (void);
extern pfunc __CTOR_LIST__[];
extern pfunc __CTOR_END__[];
void
cyg_hal_invoke_constructors (void)
{
#ifdef CYGSEM_HAL_STOP_CONSTRUCTORS_ON_FLAG
static pfunc *p = &__CTOR_END__[-1];
cyg_hal_stop_constructors = 0;
for (; p >= __CTOR_LIST__; p--) {
diag_printf("Invoking constructor @ 0x%08x\n", *p);
(*p) ();
if (cyg_hal_stop_constructors) {
p--;
break;
}
}
#else
pfunc *p;
for (p = &__CTOR_END__[-1]; p >= __CTOR_LIST__; p--) {
diag_printf("Invoking constructor @ 0x%08x\n", *p);
(*p) ();
}
#endif
And put the diag_printf() there... And it prints 1 address and that's
it... So, do I understand it right that here it is supposed to call C++
constructors?... Oh, no... and already in the first one it crashes... So,
some C++ internal calling conventions have changed. I am pretty helpless
in what concerns C++ ABI... Anyone?
Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RedBoot built with gcc 3.4.4
2007-02-09 9:53 ` Guennadi Liakhovetski
@ 2007-02-09 10:18 ` Guennadi Liakhovetski
2007-02-12 18:36 ` Kurt Siedenburg
1 sibling, 0 replies; 16+ messages in thread
From: Guennadi Liakhovetski @ 2007-02-09 10:18 UTC (permalink / raw)
To: Gary Thomas; +Cc: ecos-devel
Hm, can it be "-finit-priority". It errors in 3.4.4, so, I took it out,
which works fine with other "recent" compilers. And here:
http://sources.redhat.com/ml/ecos-devel/2003-10/msg00061.html
<quote>
Gary> That's really too bad - we can't take it out globally
Gary> because that could possibly break things for folks using
Gary> older compilers and we may have troubles using newer ones..
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
</quote>
It has been verified that it is not needed on even 2.95.x and taken away
from in-tree platforms. Can it be that we DO have a problem now?
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: RedBoot built with gcc 3.4.4
2007-02-09 9:53 ` Guennadi Liakhovetski
2007-02-09 10:18 ` Guennadi Liakhovetski
@ 2007-02-12 18:36 ` Kurt Siedenburg
2007-02-13 17:12 ` Guennadi Liakhovetski
1 sibling, 1 reply; 16+ messages in thread
From: Kurt Siedenburg @ 2007-02-12 18:36 UTC (permalink / raw)
To: Guennadi Liakhovetski, Gary Thomas; +Cc: ecos-devel
I'd be interested in the answer to this question also - although our
situation is different:
- We have seen the same crash you observed.
However
- It happens *very* rarely.
Over a period of 12 months I've seen it 3 times.
Thus in >99.9(9)% of bootups it works fine.
However - once it gets into this state - chances are it can be
repro'd.
- We have no idea how to reproduce the problem.
- We use a pretty old version of ecos (1.3 based).
- We use gcc 2.95.3
- Our CPU is Xscale
Looking at the differences (eg. reproducibility) I think that the root
cause of our problems is likely to be different. Nevertheless I'd be
interested in the solution to your problem. Maybe it applies to us
also.
Just looking at our symptoms I'd think there's some uninitialized
variable somewhere in early ecos startup. And most of the times it
contains a value not causing trouble. Only occasionally ... .
Regards,
Kurt Siedenburg
-----Original Message-----
From: ecos-devel-owner@ecos.sourceware.org
[mailto:ecos-devel-owner@ecos.sourceware.org] On Behalf Of Guennadi
Liakhovetski
Sent: Friday, February 09, 2007 1:53 AM
To: Gary Thomas
Cc: ecos-devel@ecos.sourceware.org
Subject: Re: RedBoot built with gcc 3.4.4
On Fri, 9 Feb 2007, Guennadi Liakhovetski wrote:
> Looking further
Auch... I came as far as to the loop
/*----------------------------------------------------------------------
--*/
/* C++ support - run initial constructors
*/
#ifdef CYGSEM_HAL_STOP_CONSTRUCTORS_ON_FLAG
cyg_bool cyg_hal_stop_constructors;
#endif
typedef void (*pfunc) (void);
extern pfunc __CTOR_LIST__[];
extern pfunc __CTOR_END__[];
void
cyg_hal_invoke_constructors (void)
{
#ifdef CYGSEM_HAL_STOP_CONSTRUCTORS_ON_FLAG
static pfunc *p = &__CTOR_END__[-1];
cyg_hal_stop_constructors = 0;
for (; p >= __CTOR_LIST__; p--) {
diag_printf("Invoking constructor @ 0x%08x\n", *p);
(*p) ();
if (cyg_hal_stop_constructors) {
p--;
break;
}
}
#else
pfunc *p;
for (p = &__CTOR_END__[-1]; p >= __CTOR_LIST__; p--) {
diag_printf("Invoking constructor @ 0x%08x\n", *p);
(*p) ();
}
#endif
And put the diag_printf() there... And it prints 1 address and that's
it... So, do I understand it right that here it is supposed to call C++
constructors?... Oh, no... and already in the first one it crashes...
So, some C++ internal calling conventions have changed. I am pretty
helpless in what concerns C++ ABI... Anyone?
Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: RedBoot built with gcc 3.4.4
2007-02-12 18:36 ` Kurt Siedenburg
@ 2007-02-13 17:12 ` Guennadi Liakhovetski
0 siblings, 0 replies; 16+ messages in thread
From: Guennadi Liakhovetski @ 2007-02-13 17:12 UTC (permalink / raw)
To: Kurt Siedenburg; +Cc: Gary Thomas, ecos-devel
On Mon, 12 Feb 2007, Kurt Siedenburg wrote:
> I'd be interested in the answer to this question also - although our
> situation is different:
Yes, looks like your situation is very different. You have a runtime
problem, whereas I have a compile / link-time one.
...and I am afraid I am not much nearer to the solution now than before. I
thought I identified the exact crash location with the help of debugging
printf's, but it looks like the crash / run behaviour differs also with
the amount and kind of debugging.
Now what I currently cannot understand is how one is supposed to handle
the .fixed_vectors section (ARM). This section contains some objects,
which are allocated in packages/hal/arm/arch/current/src/vectors.S
(although, I don't see any need for assembly, couldn't one just use an
appropriate __attribute__ and define those objects in a C file?) and then
should be described in the system linker script using the macro:
#define SECTION_fixed_vectors(_region_, _vma_, _lma_) \
.fixed_vectors _vma_ : _lma_ \
{ FORCE_OUTPUT; KEEP (*(.fixed_vectors)) } \
> _region_
in packages/hal/arm/arch/current/src/arm.ld. Now, those objects will be
written at run time, so, the section has to be in RAM. However, I do not
understand how this is achieved? As you dont have any loader, you have to
initialise it explicitely like the .bss or the .data, which I can
perfectly recognize in the above 2 files - as _start and _end addresses
are defined, and then the area between them is either cleared (for .bss)
or copied from the original image location (.data). But I don't understand
how this is supposed to work with .fixed_vectors.
Please, explain.
Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2007-02-13 17:12 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-07 11:52 RedBoot built with gcc 3.4.4 Guennadi Liakhovetski
2007-02-07 12:11 ` Andrew Lunn
2007-02-07 12:43 ` Guennadi Liakhovetski
2007-02-07 12:52 ` Andrew Lunn
2007-02-07 13:00 ` Guennadi Liakhovetski
2007-02-07 13:03 ` Gary Thomas
2007-02-07 13:24 ` Guennadi Liakhovetski
2007-02-07 13:42 ` Gary Thomas
2007-02-07 13:59 ` Guennadi Liakhovetski
2007-02-07 14:32 ` Gary Thomas
2007-02-09 7:55 ` Guennadi Liakhovetski
2007-02-09 9:53 ` Guennadi Liakhovetski
2007-02-09 10:18 ` Guennadi Liakhovetski
2007-02-12 18:36 ` Kurt Siedenburg
2007-02-13 17:12 ` Guennadi Liakhovetski
2007-02-07 12:56 ` Edgar Grimberg
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).