RE: [ECOS] Modifying memory layout, possible?

RE: [ECOS] Modifying memory layout, possible?

[Andreas.Karlsson]

> Andreas> The warnings where gone when I modified target.ld but of

> Andreas> course there was a big error after downloading since I hadn't

> Andreas> defined, in BCR, which chip selects that should be used for

> Andreas> the added memory. So the program was downloaded outside the

> Andreas> addressable region.

> 

> You need to update the stub running on the board. The stub is the one

> settin up the memory.

> 

> Jesper



Yes, that sounds correct to me, that must be the place where it is specified
to gdb how to place the program.

I've thought of it before but the documentation made me busy with the .ldi
file. How do I update the stub to fullfill my needs, any hints? 

/Andreas

RE: [ECOS] Modifying memory layout, possible?

[Jesper Skov]

>>>>> "Andreas" == Andreas Karlsson <Andreas.Karlsson@combitechsystems.com> writes:

Andreas> Yes, that sounds correct to me, that must be the place where
Andreas> it is specified to gdb how to place the program.

Andreas> I've thought of it before but the documentation made me busy
Andreas> with the .ldi file. How do I update the stub to fullfill my
Andreas> needs, any hints?

Getting Started Guide for ARM should contain all the info you are
looking for.

Jesper

RE: [ECOS] Modifying memory layout, possible?

[Andreas.Karlsson]

First, I think that the first line in 

!/bin/sh

# these lines restart using the tcl shell \

  exec sh -c "if ( echo | tclsh ) 2>/dev/null ; then \

      exec tclsh \"${0}\" ${1+${*}} ; \

    elif ( echo | cygtclsh80 ) 2>/dev/null ; then \

      exec cygtclsh80 \"${0}\" ${1+${*}} ; \

    else \

      echo Could not find TCL interpreter ; \

      exit 1 ; \

    fi"



should be commented away.

Yes, my code should be clean. I downloaded those files I have been changing
from CVS to be sure. It is interesting to notice that if I by mistake choose
revB I will get in contact with the board even if it fails when downloading
.rodata.

/Andreas





> > 

> > But now the problem is that I don't have any contact with 

> my board. So I

> > thought that maybe I should try first to build a 

> non-modified stub, download

> > it and see if it works. I choose the template for AEB and 

> compiled and

> > downloaded but there is no contact with the board.

> 

> Is this with clean code? Have you tried it with clean code? 

> And you just

> did it with "ecosconfig new aeb stubs" (or config tool equivalent)?

> 

> Jifl

> -- 

> Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 

> (1223) 728762

> "Plan to be spontaneous tomorrow."  ||  These opinions are 

> all my own fault

> 

Re: [ECOS] Modifying memory layout, possible?

[Jonathan Larmour]

Andreas.Karlsson@combitechsystems.com wrote:
> 
> First, I think that the first line in
> 
> !/bin/sh
> 
[snip] 
> should be commented away.

Sorry, yes it should have a leading #. It was a simple cut and paste error.
I was just trying to tell you what is in CVS, which is an improvement. i.e.
http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/ecos/packages/hal/arm/aeb/current/src/flash_cksum.tcl?rev=1.5&cvsroot=ecos

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

RE: [ECOS] Modifying memory layout, possible?

[Andreas.Karlsson]

Hi,

Well, I thought that the space in my path /d/Program Files/Red Hat/....
fooled cygtclsh80 so I moved flash_cksum.tcl to the same directory as the
gdb_module_ncs.bin, which is input, and then hacked the makefile. This
worked. Then there is no uuencode with Cygwin but I have downloaded one for
windows before that I have used.

But now the problem is that I don't have any contact with my board. So I
thought that maybe I should try first to build a non-modified stub, download
it and see if it works. I choose the template for AEB and compiled and
downloaded but there is no contact with the board. 

Only the stub that comes with eCos works.

/Andreas





> e?


Andreas.Karlsson@combitechsystems.com wrote:

> > 

> > ok,

> > 

> > I had to modify the call to tclsh in flash_cksum.tcl from

> > 

> > exec tclsh "$0" ${1+"$@"} to

> > 

> > exec cygtclsh80 "$0" ${1+"$@"}

> > 

> > but now the compiler says that it can't find 

> flash_cksum.tcl. But in my

> > world it definitely is there.

> 

> Firstly, make sure you do have a /bin/sh.exe. If ls -l 

> /bin/sh.exe doesn't

> show something, then you'll probably need to use the cygwin 

> mount command

> to put the cygwin bin directory at /bin.

> 

> Secondly, just for consistency, replace the blurb at the top of

> flash_cksum.tcl with this:

> 

> !/bin/sh

> # these lines restart using the tcl shell \

>   exec sh -c "if ( echo | tclsh ) 2>/dev/null ; then \

>       exec tclsh \"${0}\" ${1+${*}} ; \

>     elif ( echo | cygtclsh80 ) 2>/dev/null ; then \

>       exec cygtclsh80 \"${0}\" ${1+${*}} ; \

>     else \

>       echo Could not find TCL interpreter ; \

>       exit 1 ; \

>     fi"

> 

> Yes, there is much magic here.

> 

> Jifl

> -- 

> Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 

> (1223) 728762

> "Plan to be spontaneous tomorrow."  ||  These opinions are 

> all my own fault

> 

Re: [ECOS] Modifying memory layout, possible?

[Jonathan Larmour]

Andreas.Karlsson@combitechsystems.com wrote:
> 
> But now the problem is that I don't have any contact with my board. So I
> thought that maybe I should try first to build a non-modified stub, download
> it and see if it works. I choose the template for AEB and compiled and
> downloaded but there is no contact with the board.

Is this with clean code? Have you tried it with clean code? And you just
did it with "ecosconfig new aeb stubs" (or config tool equivalent)?

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

RE: [ECOS] Modifying memory layout, possible?

[Andreas.Karlsson]

ok,

I had to modify the call to tclsh in flash_cksum.tcl from

exec tclsh "$0" ${1+"$@"} to

exec cygtclsh80 "$0" ${1+"$@"}



but now the compiler says that it can't find flash_cksum.tcl. But in my
world it definitely is there.

/Andreas

# Then build version with checksum from previously built image.

arm-elf-gcc -c
-DCHECKSUM=`//D/PROGRA~1/REDHAT~1/eCos/packages/hal/arm/aeb/v1_3_1/src/flash
_cksum.tcl src/gdb_module_ncs.bin`
-I//D/ecos-work/aeb/config2_expanded_install/include
-I//D/PROGRA~1/REDHAT~1/eCos/packages/hal/arm/aeb/v1_3_1
-I//D/PROGRA~1/REDHAT~1/eCos/packages/hal/arm/aeb/v1_3_1/src
-I//D/PROGRA~1/REDHAT~1/eCos/packages/hal/arm/aeb/v1_3_1/tests -I.
-I//D/PROGRA~1/REDHAT~1/eCos/packages/hal/arm/aeb/v1_3_1/src/ -mcpu=arm7di
-Wall -Wpointer-arith -Wstrict-prototypes -Winline -Wundef
-Woverloaded-virtual -g -O2 -ffunction-sections -fdata-sections -fno-rtti
-fno-exceptions -fvtable-gc -finit-priority -o src/gdb_module.o
//D/PROGRA~1/REDHAT~1/eCos/packages/hal/arm/aeb/v1_3_1/src/gdb_module.c

couldn't read file
"//D/PROGRA~1/REDHAT~1/eCos/packages/hal/arm/aeb/v1_3_1/src/flash_cksum.tcl"
: no such file or directory
//D/PROGRA~1/REDHAT~1/eCos/packages/hal/arm/aeb/v1_3_1/src/gdb_module.c:89:
parse error before `,'

make[1]: *** [//D/ecos-work/aeb/config2_expanded_install/bin/gdb_module.bin]
Error 1

make[1]: Leaving directory
`/d/ecos-work/aeb/config2_expanded_build/hal/arm/aeb/v1_3_1'

make: *** [build] Error 2

RE: [ECOS] Modifying memory layout, possible?

[Jesper Skov]

>>>>> "Andreas" == Andreas Karlsson <Andreas.Karlsson@combitechsystems.com> writes:

Andreas> but now the compiler says that it can't find
Andreas> flash_cksum.tcl. But in my world it definitely is there.

Sorry, can't help. I don't grok WinDOS peculiarities. Someone else on
the list may be able to help.

Jesper

Re: [ECOS] Modifying memory layout, possible?

[Jonathan Larmour]

Andreas.Karlsson@combitechsystems.com wrote:
> 
> ok,
> 
> I had to modify the call to tclsh in flash_cksum.tcl from
> 
> exec tclsh "$0" ${1+"$@"} to
> 
> exec cygtclsh80 "$0" ${1+"$@"}
> 
> but now the compiler says that it can't find flash_cksum.tcl. But in my
> world it definitely is there.

Firstly, make sure you do have a /bin/sh.exe. If ls -l /bin/sh.exe doesn't
show something, then you'll probably need to use the cygwin mount command
to put the cygwin bin directory at /bin.

Secondly, just for consistency, replace the blurb at the top of
flash_cksum.tcl with this:

!/bin/sh
# these lines restart using the tcl shell \
  exec sh -c "if ( echo | tclsh ) 2>/dev/null ; then \
      exec tclsh \"${0}\" ${1+${*}} ; \
    elif ( echo | cygtclsh80 ) 2>/dev/null ; then \
      exec cygtclsh80 \"${0}\" ${1+${*}} ; \
    else \
      echo Could not find TCL interpreter ; \
      exit 1 ; \
    fi"

Yes, there is much magic here.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

RE: [ECOS] Modifying memory layout, possible?

[Andreas.Karlsson]

hello,

While trying to build a new gdbstub the following error occurred.

# First build version with no checksum.

arm-elf-gcc -c  -I//D/ecos-work/aeb/config2_expanded_install/include
-I//D/PROGRA~1/REDHAT~1/eCos/packages/hal/arm/aeb/v1_3_1
-I//D/PROGRA~1/REDHAT~1/eCos/packages/hal/arm/aeb/v1_3_1/src
-I//D/PROGRA~1/REDHAT~1/eCos/packages/hal/arm/aeb/v1_3_1/tests -I.
-Wp,-MD,deps.tmp
-I//D/PROGRA~1/REDHAT~1/eCos/packages/hal/arm/aeb/v1_3_1/src/ -mcpu=arm7di
-Wall -Wpointer-arith -Wstrict-prototypes -Winline -Wundef
-Woverloaded-virtual -g -O2 -ffunction-sections -fdata-sections -fno-rtti
-fno-exceptions -fvtable-gc -finit-priority -o src/gdb_module_ncs.o
//D/PROGRA~1/REDHAT~1/eCos/packages/hal/arm/aeb/v1_3_1/src/gdb_module.c

arm-elf-gcc -mcpu=arm7di -Wl,--gc-sections -Wl,-static -g -nostdlib
-L//D/ecos-work/aeb/config2_expanded_install/lib -Ttarget.ld -o
src/gdb_module_ncs.tmp src/gdb_module_ncs.o

arm-elf-objcopy --strip-debug --change-addresses=0xFBFF4000
src/gdb_module_ncs.tmp src/gdb_module_ncs.img

arm-elf-objcopy -O binary src/gdb_module_ncs.img src/gdb_module_ncs.bin

# Prepare dependency file

# Then build version with checksum from previously built image.

arm-elf-gcc -c
-DCHECKSUM=`//D/PROGRA~1/REDHAT~1/eCos/packages/hal/arm/aeb/v1_3_1/src/flash
_cksum.tcl src/gdb_module_ncs.bin`
-I//D/ecos-work/aeb/config2_expanded_install/include
-I//D/PROGRA~1/REDHAT~1/eCos/packages/hal/arm/aeb/v1_3_1
-I//D/PROGRA~1/REDHAT~1/eCos/packages/hal/arm/aeb/v1_3_1/src
-I//D/PROGRA~1/REDHAT~1/eCos/packages/hal/arm/aeb/v1_3_1/tests -I.
-I//D/PROGRA~1/REDHAT~1/eCos/packages/hal/arm/aeb/v1_3_1/src/ -mcpu=arm7di
-Wall -Wpointer-arith -Wstrict-prototypes -Winline -Wundef
-Woverloaded-virtual -g -O2 -ffunction-sections -fdata-sections -fno-rtti
-fno-exceptions -fvtable-gc -finit-priority -o src/gdb_module.o
//D/PROGRA~1/REDHAT~1/eCos/packages/hal/arm/aeb/v1_3_1/src/gdb_module.c

exec: tclsh: not found

//D/PROGRA~1/REDHAT~1/eCos/packages/hal/arm/aeb/v1_3_1/src/gdb_module.c:89:
parse error before `,'

make[1]: *** [//D/ecos-work/aeb/config2_expanded_install/bin/gdb_module.bin]
Error 1

make[1]: Leaving directory
`/d/ecos-work/aeb/config2_expanded_build/hal/arm/aeb/v1_3_1'

make: *** [build] Error 2





The area in gdb_module.c looks like this, row 89 is the one with CHECKSUM.
What have I done wrong?



const static struct ModuleHeader __hdr = {

    0x4D484944,                     // MHID

    2,                              // flags = auto start

    1,                              // major

    0,                              // minor

    CHECKSUM,                       // checksum

    (cyg_uint32) &__exception_handlers,         // start of module
(read-only) image

    (cyg_uint32) &__rom_data_end,    // end of image

    0,                              // r/w base - unused

    0,                              // bss base - unused

    0,                              // bss limit - unused

    (cyg_uint32) &__hdr,            // self (for module identification)

    (cyg_uint32) &__exception_handlers,         // startup 

    0,                              // init - unused

    0,                              // final - unused

    0,                              // service - unused

    (cyg_uint32) &__title,          // title

    (cyg_uint32) &__help,           // help string

    0,                              // command table - unused

    0,                              // SWI table - unused

    0                               // SWI handler - unused

};

RE: [ECOS] Modifying memory layout, possible?

[Jesper Skov]

>>>>> "Andreas" == Andreas Karlsson <Andreas.Karlsson@combitechsystems.com> writes:

Andreas> exec: tclsh: not found

CHECKSUM is computed in one of the makefile runes using tclsh - but
that part evidently failed. You need to make sure tclsh is in the
PATH. 

Jesper

RE: [ECOS] Modifying memory layout, possible?

[Andreas.Karlsson]

Ok, I will try it out first thing tomorrow. Thanks.

/Andreas



>  "Andreas" == Andreas Karlsson 

> <Andreas.Karlsson@combitechsystems.com> writes:

> 

> Andreas> Yes, that sounds correct to me, that must be the place where

> Andreas> it is specified to gdb how to place the program.

> 

> Andreas> I've thought of it before but the documentation made me busy

> Andreas> with the .ldi file. How do I update the stub to fullfill my

> Andreas> needs, any hints?

> 

> Getting Started Guide for ARM should contain all the info you are

> looking for.

> 

> Jesper

> 

RE: [ECOS] Modifying memory layout, possible?

[Andreas.Karlsson]

> >>>>> "Andreas" == Andreas Karlsson 

> <Andreas.Karlsson@combitechsystems.com> writes:

> 

> Andreas> Hello, I'm wondering if it is possible to run eCos after

> Andreas> adding more memory, in any case it seems to be hard to edit

> Andreas> the memory layout, which is a bad feature for eCos.

> 

> There is a GUI for doing this, but it is only available on WinDOS.



Where do I find this GUI and how to use it?



> Changes in the memory layout has to be matched with appropriate

> changes to the startup code. Arguably, it should be automatic, but I

> suspect we didn't have the .h file when the AEB HAL was written.

> 

Where is the memory setup when using RAM-startup. For instance the
START,STOP,SDR and BCR registers have to be given values but I just can't
see where this is done for RAM-startup.



> Andreas> How can I tell eCos that there are more memory available so I

> Andreas> can get rid of those ".bss is not within region RAM"?

> 

> Maybe the linker map doesn't have the right dependencies. Did you try

> creating a new build directory after updating the .ldi and .h files?



No, I didn't. 

The warnings where gone when I modified target.ld but of course there was a
big error after downloading since I hadn't defined, in BCR, which chip
selects that should be used for the added memory. So the program was
downloaded outside the addressable region.

RE: [ECOS] Modifying memory layout, possible?

[Jesper Skov]

>>>>> "Andreas" == Andreas Karlsson <Andreas.Karlsson@combitechsystems.com> writes:

>> There is a GUI for doing this, but it is only available on WinDOS.

Andreas> Where do I find this GUI and how to use it?

sources.redhat.com, I'm sure.

>> Changes in the memory layout has to be matched with appropriate
>> changes to the startup code. Arguably, it should be automatic, but
>> I suspect we didn't have the .h file when the AEB HAL was written.

Andreas> Where is the memory setup when using RAM-startup. For
Andreas> instance the START,STOP,SDR and BCR registers have to be
Andreas> given values but I just can't see where this is done for
Andreas> RAM-startup.

As Gary pointed out, it cannot be done from RAM startup. Or at least
you have to rewrite the code to do so, using position independant code
to do so.

Andreas> The warnings where gone when I modified target.ld but of
Andreas> course there was a big error after downloading since I hadn't
Andreas> defined, in BCR, which chip selects that should be used for
Andreas> the added memory. So the program was downloaded outside the
Andreas> addressable region.

You need to update the stub running on the board. The stub is the one
settin up the memory.

Jesper

[ECOS] Modifying memory layout, possible?

[Andreas.Karlsson]

Hello,

I'm wondering if it is possible to run eCos after adding more memory, in any
case it seems to be hard to edit the memory layout, which is a bad feature
for eCos.

I've been reading 'Modifying the Memory Layout' in eCos documentation. It
says that the script /include/pkgconf/mlt_*.* in the install folder should
be modified. In my case when running on an AEB-1 revC I have modified
mlt_arm_aebC_ram.h and .ldi. 

Then I compile my testprogram and I expect to see some changes in the start
and stop registers but no.

How can I tell eCos that there are more memory available so I can get rid of
those ".bss is not within region RAM"?

Where is eCos setting up the memory layout?

I thought that it was in hal_platform_setup.h but this script
(PLATFORM_SETUP1)just runs when CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS is
defined and it is not in my configuration. I have tested by modifying this
script and enable CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS in the configuration
tool as well but again nothing happens, besides the size doubles, when I
look in the memory at the addresses of start and stop.



Any hints would be very appreciated.

brgds

Andreas

Re: [ECOS] Modifying memory layout, possible?

[Jesper Skov]

>>>>> "Andreas" == Andreas Karlsson <Andreas.Karlsson@combitechsystems.com> writes:

Andreas> Hello, I'm wondering if it is possible to run eCos after
Andreas> adding more memory, in any case it seems to be hard to edit
Andreas> the memory layout, which is a bad feature for eCos.

There is a GUI for doing this, but it is only available on WinDOS.

Editing the .ldi and .h files should be quite simple though. But I
guess I'm slightly biased.

Andreas> Then I compile my testprogram and I expect to see some
Andreas> changes in the start and stop registers but no.

Changes in the memory layout has to be matched with appropriate
changes to the startup code. Arguably, it should be automatic, but I
suspect we didn't have the .h file when the AEB HAL was written.

I'll put it on my TODO list, but of course I'd be happy to accept a
patch fixing that.

Andreas> How can I tell eCos that there are more memory available so I
Andreas> can get rid of those ".bss is not within region RAM"?

Maybe the linker map doesn't have the right dependencies. Did you try
creating a new build directory after updating the .ldi and .h files?

Andreas> I thought that it was in hal_platform_setup.h but this script
Andreas> (PLATFORM_SETUP1)just runs when
Andreas> CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS is defined and it is not

This is wrong. The startup code should allow the target to run with
ROM startup, doing all the necessary initializations - regardless of
the inclusion/exclusion of the GDB stubs.

The condition should probably be something like:

#if !defined(CYG_HAL_STARTUP_RAM) \
    defined(CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS)

That is, always init the MMU mapping for non-RAM startups, of if the
stubs are included.

Jesper

Re: [ECOS] Modifying memory layout, possible?

[Gary Thomas]

On 31-Oct-2000 Jesper Skov wrote:
>>>>>> "Andreas" == Andreas Karlsson <Andreas.Karlsson@combitechsystems.com> writes:
> 
> Andreas> Hello, I'm wondering if it is possible to run eCos after
> Andreas> adding more memory, in any case it seems to be hard to edit
> Andreas> the memory layout, which is a bad feature for eCos.
> 
> There is a GUI for doing this, but it is only available on WinDOS.
> 
> Editing the .ldi and .h files should be quite simple though. But I
> guess I'm slightly biased.
> 
> Andreas> Then I compile my testprogram and I expect to see some
> Andreas> changes in the start and stop registers but no.
> 
> Changes in the memory layout has to be matched with appropriate
> changes to the startup code. Arguably, it should be automatic, but I
> suspect we didn't have the .h file when the AEB HAL was written.
> 
> I'll put it on my TODO list, but of course I'd be happy to accept a
> patch fixing that.
> 
> Andreas> How can I tell eCos that there are more memory available so I
> Andreas> can get rid of those ".bss is not within region RAM"?
> 
> Maybe the linker map doesn't have the right dependencies. Did you try
> creating a new build directory after updating the .ldi and .h files?
> 
> Andreas> I thought that it was in hal_platform_setup.h but this script
> Andreas> (PLATFORM_SETUP1)just runs when
> Andreas> CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS is defined and it is not
> 
> This is wrong. The startup code should allow the target to run with
> ROM startup, doing all the necessary initializations - regardless of
> the inclusion/exclusion of the GDB stubs.
> 

Sorry, but on this and some other platforms, no can do :-(  The startup
code moves memory around, and in some cases at least, it would be very
difficult to allow this code to run after this remap had taken place.

> The condition should probably be something like:
> 
>#if !defined(CYG_HAL_STARTUP_RAM) \
>     defined(CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS)
> 
> That is, always init the MMU mapping for non-RAM startups, of if the
> stubs are included.
> 
> Jesper

Re: [ECOS] Modifying memory layout, possible?

[Jesper Skov]

>>>>> "Gary" == Gary Thomas <gthomas@redhat.com> writes:

Andreas> I thought that it was in hal_platform_setup.h but this script
Andreas> (PLATFORM_SETUP1)just runs when
Andreas> CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS is defined and it is not
>>  This is wrong. The startup code should allow the target to run
>> with ROM startup, doing all the necessary initializations -
>> regardless of the inclusion/exclusion of the GDB stubs.
>> 

Gary> Sorry, but on this and some other platforms, no can do :-( The
Gary> startup code moves memory around, and in some cases at least, it
Gary> would be very difficult to allow this code to run after this
Gary> remap had taken place.

Ah, good point. But still, the current code only executes when stubs
are included. That's wrong. In a production system you don't
(necessarily) want stubs to take up space.

So the condition should be:

 #if !defined(CYG_HAL_STARTUP_RAM)

Preventing the code from screwing up a RAM based system.

Right?!? Or am I missing something else?

Jesper