Re: [ECOS] arm evaluator e7t hangs when executing example progs/tests

Re: [ECOS] arm evaluator e7t hangs when executing example progs/tests

[Matt Kober]

as soon as i import the ecm file that loads the flashdriver and the zlib package the build 
fails due to a invalid undefined reference to `_flash_info'

i unloaded the the zlib and flash package and the build succeeds. also downloading 
and running redboot is no problem, but when i want to debug the hello world example, gdb 
just displays 'continuing' even though i have assertions and tracing enabled. 
isn't it sufficient to use the template in conjunction the ecm file to build a valid image ? 
did i totally miss something ?  here are my build results.

arm-elf-gcc -mcpu=arm7tdmi -mno-short-load-words -Wl,--gc-sections -Wl,-static -g -nostdlib -L/ecos-d/workdir \
/redboot/redboot_e7t_install/lib -Ttarget.ld -o /ecos-d/workdir/redboot/redboot_e7t_install/bin/redboot.elf  \
/ecos-d/workdir/redboot/redboot_e7t_install/lib/version.o
make[1]: Leaving directory `/ecos-d/workdir/redboot/redboot_e7t_build/redboot/v2_0b1'
/ecos-d/workdir/redboot/redboot_e7t_install/lib/libtarget.a(redboot_main.o): In function `do_reset':
make: Leaving directory `/ecos-d/workdir/redboot/redboot_e7t_build'
/ecos-d/cygwin/opt/ecos/ecos-2.0b1/packages/redboot/v2_0b1/src/main.c:149: undefined reference to `_flash_info'
collect2: ld returned 1 exit status
make[1]: *** [/ecos-d/workdir/redboot/redboot_e7t_install/bin/redboot.elf] Error 1
make: *** [build] Error 2       

thanks,

Matt
______________________________________________________________________________
UNICEF bittet um Spenden fur die Kinder im Irak! Hier online an
UNICEF spenden: https://spenden.web.de/unicef/special/?mc=021101


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] arm evaluator e7t hangs when executing example progs/tests

[Chris Garry]

----- Original Message ----- 
From: "Matt Kober" <mattkober@web.de>
To: "JonathanLarmour" <jifl@eCosCentric.com>
Cc: <ecos-discuss@sources.redhat.com>
Sent: Monday, April 14, 2003 10:37 PM
Subject: Re: [ECOS] arm evaluator e7t hangs when executing example progs/tests


> as soon as i import the ecm file that loads the flashdriver and the zlib package the build 
> fails due to a invalid undefined reference to `_flash_info'

Are you loading the correct ecm file?  The flashdriver is not loaded with the ecm file I use.
( ecos-2.0b1/packages/hal/arm/e7t/v2_0b1/misc/redboot_ROM.ecm )

> 
> i unloaded the the zlib and flash package and the build succeeds. also downloading 
> and running redboot is no problem, but when i want to debug the hello world example, gdb 
> just displays 'continuing' even though i have assertions and tracing enabled. 
> isn't it sufficient to use the template in conjunction the ecm file to build a valid image ? 
> did i totally miss something ?  here are my build results.
> 

Selecting the E7T/Redboot template and importing the ecm file should be sufficient to build
a valid image.  It works on my system anyway!

> arm-elf-gcc -mcpu=arm7tdmi -mno-short-load-words -Wl,--gc-sections -Wl,-static -g -nostdlib -L/ecos-d/workdir \
> /redboot/redboot_e7t_install/lib -Ttarget.ld -o /ecos-d/workdir/redboot/redboot_e7t_install/bin/redboot.elf  \
> /ecos-d/workdir/redboot/redboot_e7t_install/lib/version.o
> make[1]: Leaving directory `/ecos-d/workdir/redboot/redboot_e7t_build/redboot/v2_0b1'
> /ecos-d/workdir/redboot/redboot_e7t_install/lib/libtarget.a(redboot_main.o): In function `do_reset':
> make: Leaving directory `/ecos-d/workdir/redboot/redboot_e7t_build'
> /ecos-d/cygwin/opt/ecos/ecos-2.0b1/packages/redboot/v2_0b1/src/main.c:149: undefined reference to `_flash_info'
> collect2: ld returned 1 exit status
> make[1]: *** [/ecos-d/workdir/redboot/redboot_e7t_install/bin/redboot.elf] Error 1
> make: *** [build] Error 2       
> 
> thanks,
> 
> Matt
> 

Chris

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

[ECOS] vectors.s

[Rupesh S]

Hi,

Can anybody tell me what does the macro "FUNC_START" represent in the
architecture specific assembly files.



-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] vectors.s

[Mark Salter]

>>>>> Rupesh S writes:

> Hi,
> Can anybody tell me what does the macro "FUNC_START" represent in the
> architecture specific assembly files.

It is a convenience macro used to declare the start of assembly language
functions.

--Mark

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] arm evaluator e7t hangs when executing example progs/tests

[Jonathan Larmour]

Matt Kober wrote:
> as soon as i import the ecm file that loads the flashdriver and the zlib package the build 
> fails due to a invalid undefined reference to `_flash_info'

My .ecm file doesn't load a flash driver.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] vectors.s

[Rupesh S]

Hi,

In the dissambled code for vectors.s, at the label, "_reset_platform", I
find an instruction, " bra 8000000e".
Unfortunately, I could not find any code attched at that address.It looked
important to me since the reset_platform is the place where the reset vector
code jumps to..,
Can anyone tell me where the branching happens ?
Rupesh

----- Original Message -----
From: "Mark Salter" <msalter@redhat.com>
To: <rupeshs@myw.ltindia.com>
Cc: <ecos-discuss@sources.redhat.com>
Sent: Tuesday, April 15, 2003 4:46 AM
Subject: Re: [ECOS] vectors.s


> >>>>> Rupesh S writes:
>
> > Hi,
> > Can anybody tell me what does the macro "FUNC_START" represent in the
> > architecture specific assembly files.
>
> It is a convenience macro used to declare the start of assembly language
> functions.
>
> --Mark
>
> --
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss
>


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] vectors.s

[Andrew Lunn]

On Wed, Apr 16, 2003 at 09:23:11AM -0700, Rupesh S wrote:
> Hi,
> 
> In the dissambled code for vectors.s, at the label, "_reset_platform", I
> find an instruction, " bra 8000000e".
> Unfortunately, I could not find any code attched at that address.It looked
> important to me since the reset_platform is the place where the reset vector
> code jumps to..,
> Can anyone tell me where the branching happens ?
> Rupesh

I don't know your hardware platform, but my guess is your flash is
mapped into memory twice. Once at 0x0, and a second time at
0x800000000. The mapping at 0x0 is used to boot time. It will then
jump into the high memory version and then unmap the low version.

     Andrew

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] vectors.s

[Rupesh S]

My architecture is sh3 processor ,7729.
As you said, Flash is mapped at 0x0 & 0x80000000.
But what I don't understand is that, when it jumps to the High memory,
(0x8000000e in my case), shouldn't there  be some or the other pice of code
attached there,
But I'm not seeing any instruction placed at that address.


----- Original Message -----
From: "Andrew Lunn" <andrew.lunn@ascom.ch>
To: "Rupesh S" <rupeshs@myw.ltindia.com>
Cc: <ecos-discuss@sources.redhat.com>
Sent: Tuesday, April 15, 2003 11:56 PM
Subject: Re: [ECOS] vectors.s


> On Wed, Apr 16, 2003 at 09:23:11AM -0700, Rupesh S wrote:
> > Hi,
> >
> > In the dissambled code for vectors.s, at the label, "_reset_platform", I
> > find an instruction, " bra 8000000e".
> > Unfortunately, I could not find any code attched at that address.It
looked
> > important to me since the reset_platform is the place where the reset
vector
> > code jumps to..,
> > Can anyone tell me where the branching happens ?
> > Rupesh
>
> I don't know your hardware platform, but my guess is your flash is
> mapped into memory twice. Once at 0x0, and a second time at
> 0x800000000. The mapping at 0x0 is used to boot time. It will then
> jump into the high memory version and then unmap the low version.
>
>      Andrew
>
> --
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss
>


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] vectors.s

[Andrew Lunn]

On Mon, Apr 16, 2001 at 01:35:26PM -0700, Rupesh S wrote:
> My architecture is sh3 processor ,7729.
> As you said, Flash is mapped at 0x0 & 0x80000000.
> But what I don't understand is that, when it jumps to the High memory,
> (0x8000000e in my case), shouldn't there  be some or the other pice of code
> attached there,
> But I'm not seeing any instruction placed at that address.

How are you looking?

    Andrew

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] vectors.s

[Rupesh S]

I looked in the dissambled code generated using sh-elf-objdump,

----- Original Message -----
From: "Andrew Lunn" <andrew.lunn@ascom.ch>
To: "Rupesh S" <rupeshs@myw.ltindia.com>
Cc: <ecos-discuss@sources.redhat.com>
Sent: Wednesday, April 16, 2003 1:00 AM
Subject: Re: [ECOS] vectors.s


> On Mon, Apr 16, 2001 at 01:35:26PM -0700, Rupesh S wrote:
> > My architecture is sh3 processor ,7729.
> > As you said, Flash is mapped at 0x0 & 0x80000000.
> > But what I don't understand is that, when it jumps to the High memory,
> > (0x8000000e in my case), shouldn't there  be some or the other pice of
code
> > attached there,
> > But I'm not seeing any instruction placed at that address.
>
> How are you looking?
>
>     Andrew


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] vectors.s

[Andrew Lunn]

On Mon, Apr 16, 2001 at 02:28:21PM -0700, Rupesh S wrote:
> I looked in the dissambled code generated using sh-elf-objdump,

The code will be position independent. It might looked to be linked to
run at 0x0, but since its position independent, it will run OK at the
flash high address 0x80000000.

      Andrew
 
> ----- Original Message -----
> From: "Andrew Lunn" <andrew.lunn@ascom.ch>
> To: "Rupesh S" <rupeshs@myw.ltindia.com>
> Cc: <ecos-discuss@sources.redhat.com>
> Sent: Wednesday, April 16, 2003 1:00 AM
> Subject: Re: [ECOS] vectors.s
> 
> 
> > On Mon, Apr 16, 2001 at 01:35:26PM -0700, Rupesh S wrote:
> > > My architecture is sh3 processor ,7729.
> > > As you said, Flash is mapped at 0x0 & 0x80000000.
> > > But what I don't understand is that, when it jumps to the High memory,
> > > (0x8000000e in my case), shouldn't there  be some or the other pice of
> code
> > > attached there,
> > > But I'm not seeing any instruction placed at that address.
> >
> > How are you looking?
> >
> >     Andrew
> 

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] vectors.s

[Rupesh S]

I din't feel that the code is linked for Position independency, 'coz the
jump and bra instructions in the dissambled code seems to have 4 byte full
address operands.

----- Original Message -----
From: "Andrew Lunn" <andrew.lunn@ascom.ch>
To: "Rupesh S" <rupeshs@myw.ltindia.com>
Cc: <ecos-discuss@sources.redhat.com>
Sent: Wednesday, April 16, 2003 1:56 AM
Subject: Re: [ECOS] vectors.s


> On Mon, Apr 16, 2001 at 02:28:21PM -0700, Rupesh S wrote:
> > I looked in the dissambled code generated using sh-elf-objdump,
>
> The code will be position independent. It might looked to be linked to
> run at 0x0, but since its position independent, it will run OK at the
> flash high address 0x80000000.
>
>       Andrew
>
> > ----- Original Message -----
> > From: "Andrew Lunn" <andrew.lunn@ascom.ch>
> > To: "Rupesh S" <rupeshs@myw.ltindia.com>
> > Cc: <ecos-discuss@sources.redhat.com>
> > Sent: Wednesday, April 16, 2003 1:00 AM
> > Subject: Re: [ECOS] vectors.s
> >
> >
> > > On Mon, Apr 16, 2001 at 01:35:26PM -0700, Rupesh S wrote:
> > > > My architecture is sh3 processor ,7729.
> > > > As you said, Flash is mapped at 0x0 & 0x80000000.
> > > > But what I don't understand is that, when it jumps to the High
memory,
> > > > (0x8000000e in my case), shouldn't there  be some or the other pice
of
> > code
> > > > attached there,
> > > > But I'm not seeing any instruction placed at that address.
> > >
> > > How are you looking?
> > >
> > >     Andrew
> >


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] vectors.s

[Gary D. Thomas]

On Mon, 2001-04-16 at 15:51, Rupesh S wrote:
> I din't feel that the code is linked for Position independency, 'coz the
> jump and bra instructions in the dissambled code seems to have 4 byte full
> address operands.
> 

IIRC on that hardware, the upper bits control cacheability of
the memory region.  0x0XXXXXXX can be cached, 0x8XXXXXXX cannot.

> ----- Original Message -----
> From: "Andrew Lunn" <andrew.lunn@ascom.ch>
> To: "Rupesh S" <rupeshs@myw.ltindia.com>
> Cc: <ecos-discuss@sources.redhat.com>
> Sent: Wednesday, April 16, 2003 1:56 AM
> Subject: Re: [ECOS] vectors.s
> 
> 
> > On Mon, Apr 16, 2001 at 02:28:21PM -0700, Rupesh S wrote:
> > > I looked in the dissambled code generated using sh-elf-objdump,
> >
> > The code will be position independent. It might looked to be linked to
> > run at 0x0, but since its position independent, it will run OK at the
> > flash high address 0x80000000.
> >
> >       Andrew
> >
> > > ----- Original Message -----
> > > From: "Andrew Lunn" <andrew.lunn@ascom.ch>
> > > To: "Rupesh S" <rupeshs@myw.ltindia.com>
> > > Cc: <ecos-discuss@sources.redhat.com>
> > > Sent: Wednesday, April 16, 2003 1:00 AM
> > > Subject: Re: [ECOS] vectors.s
> > >
> > >
> > > > On Mon, Apr 16, 2001 at 01:35:26PM -0700, Rupesh S wrote:
> > > > > My architecture is sh3 processor ,7729.
> > > > > As you said, Flash is mapped at 0x0 & 0x80000000.
> > > > > But what I don't understand is that, when it jumps to the High
> memory,
> > > > > (0x8000000e in my case), shouldn't there  be some or the other pice
> of
> > > code
> > > > > attached there,
> > > > > But I'm not seeing any instruction placed at that address.
> > > >
> > > > How are you looking?
> > > >
> > > >     Andrew
> > >
> 
> 
> -- 
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss

-- 
.--------------------------------------------------------.
|       Mind: Embedded Linux and eCos Development        |
|--------------------------------------------------------|
| Gary Thomas              email:  gary.thomas@mind.be   |
| Mind ( http://mind.be )  tel:    +1 (970) 229-1963     |
| gpg: http://www.chez-thomas.org/gary/gpg_key.asc       |
'--------------------------------------------------------'


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] vectors.s

[Jonathan Larmour]

Rupesh S wrote:
> I din't feel that the code is linked for Position independency, 'coz the
> jump and bra instructions in the dissambled code seems to have 4 byte full
> address operands.


Looking at the memory layout of the SE77x9 HAL, it should be linked to run 
at 0x80000000 anyway, not 0x0.

I suggest you look at and read the comments in 
hal/sh/arch/current/include/hal_var_bank.inc. From that file it seems that 
what is at _reset_platform is data, not code. Although presumably due to 
some fluke of opcodes, it looks like one. Instead it looks like it's 
jumping to the umapped shadow address of the function __reset_platform 
(note the underscores) which is defined in vectors.S.

HTH,

Jifl

> ----- Original Message -----
> From: "Andrew Lunn" <andrew.lunn@ascom.ch>
> To: "Rupesh S" <rupeshs@myw.ltindia.com>
> Cc: <ecos-discuss@sources.redhat.com>
> Sent: Wednesday, April 16, 2003 1:56 AM
> Subject: Re: [ECOS] vectors.s
> 
> 
> 
>>On Mon, Apr 16, 2001 at 02:28:21PM -0700, Rupesh S wrote:
>>
>>>I looked in the dissambled code generated using sh-elf-objdump,
>>
>>The code will be position independent. It might looked to be linked to
>>run at 0x0, but since its position independent, it will run OK at the
>>flash high address 0x80000000.
>>
>>      Andrew
>>
>>
>>>----- Original Message -----
>>>From: "Andrew Lunn" <andrew.lunn@ascom.ch>
>>>To: "Rupesh S" <rupeshs@myw.ltindia.com>
>>>Cc: <ecos-discuss@sources.redhat.com>
>>>Sent: Wednesday, April 16, 2003 1:00 AM
>>>Subject: Re: [ECOS] vectors.s
>>>
>>>
>>>
>>>>On Mon, Apr 16, 2001 at 01:35:26PM -0700, Rupesh S wrote:
>>>>
>>>>>My architecture is sh3 processor ,7729.
>>>>>As you said, Flash is mapped at 0x0 & 0x80000000.
>>>>>But what I don't understand is that, when it jumps to the High
> 
> memory,
> 
>>>>>(0x8000000e in my case), shouldn't there  be some or the other pice
> 
> of
> 
>>>code
>>>
>>>>>attached there,
>>>>>But I'm not seeing any instruction placed at that address.
>>>>
>>>>How are you looking?
>>>>
>>>>    Andrew
>>>
> 
> 


-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] vectors.s

[Rupesh S]

thanx for the info...
As u said, the content of _reset_platform is data (the address of
__reset_platform , which is in vectors.S , and does the hardware inits...).
May be the dissambler would have interpreted the address as a match of the
bra instruction. I was reading that fluke code.
Good leason not to rely on the disassembled code....!!!

I have yet another doubt regarding the same...
if the startup is ROM , then the data there is address of
__reset_platform+0x20000000, why is it done like that...??


----- Original Message -----
From: "Jonathan Larmour" <jifl@eCosCentric.com>
To: "Rupesh S" <rupeshs@myw.ltindia.com>
Cc: "Andrew Lunn" <andrew.lunn@ascom.ch>; <ecos-discuss@sources.redhat.com>
Sent: Wednesday, April 16, 2003 2:37 PM
Subject: Re: [ECOS] vectors.s


> Rupesh S wrote:
> > I din't feel that the code is linked for Position independency, 'coz the
> > jump and bra instructions in the dissambled code seems to have 4 byte
full
> > address operands.
>
>
> Looking at the memory layout of the SE77x9 HAL, it should be linked to run
> at 0x80000000 anyway, not 0x0.
>
> I suggest you look at and read the comments in
> hal/sh/arch/current/include/hal_var_bank.inc. From that file it seems that
> what is at _reset_platform is data, not code. Although presumably due to
> some fluke of opcodes, it looks like one. Instead it looks like it's
> jumping to the umapped shadow address of the function __reset_platform
> (note the underscores) which is defined in vectors.S.
>
> HTH,
>
> Jifl
>
> > ----- Original Message -----
> > From: "Andrew Lunn" <andrew.lunn@ascom.ch>
> > To: "Rupesh S" <rupeshs@myw.ltindia.com>
> > Cc: <ecos-discuss@sources.redhat.com>
> > Sent: Wednesday, April 16, 2003 1:56 AM
> > Subject: Re: [ECOS] vectors.s
> >
> >
> >
> >>On Mon, Apr 16, 2001 at 02:28:21PM -0700, Rupesh S wrote:
> >>
> >>>I looked in the dissambled code generated using sh-elf-objdump,
> >>
> >>The code will be position independent. It might looked to be linked to
> >>run at 0x0, but since its position independent, it will run OK at the
> >>flash high address 0x80000000.
> >>
> >>      Andrew
> >>
> >>
> >>>----- Original Message -----
> >>>From: "Andrew Lunn" <andrew.lunn@ascom.ch>
> >>>To: "Rupesh S" <rupeshs@myw.ltindia.com>
> >>>Cc: <ecos-discuss@sources.redhat.com>
> >>>Sent: Wednesday, April 16, 2003 1:00 AM
> >>>Subject: Re: [ECOS] vectors.s
> >>>
> >>>
> >>>
> >>>>On Mon, Apr 16, 2001 at 01:35:26PM -0700, Rupesh S wrote:
> >>>>
> >>>>>My architecture is sh3 processor ,7729.
> >>>>>As you said, Flash is mapped at 0x0 & 0x80000000.
> >>>>>But what I don't understand is that, when it jumps to the High
> >
> > memory,
> >
> >>>>>(0x8000000e in my case), shouldn't there  be some or the other pice
> >
> > of
> >
> >>>code
> >>>
> >>>>>attached there,
> >>>>>But I'm not seeing any instruction placed at that address.
> >>>>
> >>>>How are you looking?
> >>>>
> >>>>    Andrew
> >>>
> >
> >
>
>
> --
> eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
> --[ "You can complain because roses have thorns, or you ]--
> --[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine
>
>
> --
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss
>


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] vectors.s

[Rupesh S]

thanx for the info...
As u said, the content of _reset_platform is data (the address of
__reset_platform , which is in vectors.S , and does the hardware inits...).
May be the dissambler would have interpreted the address as a match of the
bra instruction. I was reading that fluke code.
Good leason not to rely on the disassembled code....!!!

I have yet another doubt regarding the same...
if the startup is ROM , then the data there is address of
__reset_platform+0x20000000, why is it done like that...??


----- Original Message -----
From: "Jonathan Larmour" <jifl@eCosCentric.com>
To: "Rupesh S" <rupeshs@myw.ltindia.com>
Cc: "Andrew Lunn" <andrew.lunn@ascom.ch>; <ecos-discuss@sources.redhat.com>
Sent: Wednesday, April 16, 2003 2:37 PM
Subject: Re: [ECOS] vectors.s


> Rupesh S wrote:
> > I din't feel that the code is linked for Position independency, 'coz the
> > jump and bra instructions in the dissambled code seems to have 4 byte
full
> > address operands.
>
>
> Looking at the memory layout of the SE77x9 HAL, it should be linked to run
> at 0x80000000 anyway, not 0x0.
>
> I suggest you look at and read the comments in
> hal/sh/arch/current/include/hal_var_bank.inc. From that file it seems that
> what is at _reset_platform is data, not code. Although presumably due to
> some fluke of opcodes, it looks like one. Instead it looks like it's
> jumping to the umapped shadow address of the function __reset_platform
> (note the underscores) which is defined in vectors.S.
>
> HTH,
>
> Jifl
>
> > ----- Original Message -----
> > From: "Andrew Lunn" <andrew.lunn@ascom.ch>
> > To: "Rupesh S" <rupeshs@myw.ltindia.com>
> > Cc: <ecos-discuss@sources.redhat.com>
> > Sent: Wednesday, April 16, 2003 1:56 AM
> > Subject: Re: [ECOS] vectors.s
> >
> >
> >
> >>On Mon, Apr 16, 2001 at 02:28:21PM -0700, Rupesh S wrote:
> >>
> >>>I looked in the dissambled code generated using sh-elf-objdump,
> >>
> >>The code will be position independent. It might looked to be linked to
> >>run at 0x0, but since its position independent, it will run OK at the
> >>flash high address 0x80000000.
> >>
> >>      Andrew
> >>
> >>
> >>>----- Original Message -----
> >>>From: "Andrew Lunn" <andrew.lunn@ascom.ch>
> >>>To: "Rupesh S" <rupeshs@myw.ltindia.com>
> >>>Cc: <ecos-discuss@sources.redhat.com>
> >>>Sent: Wednesday, April 16, 2003 1:00 AM
> >>>Subject: Re: [ECOS] vectors.s
> >>>
> >>>
> >>>
> >>>>On Mon, Apr 16, 2001 at 01:35:26PM -0700, Rupesh S wrote:
> >>>>
> >>>>>My architecture is sh3 processor ,7729.
> >>>>>As you said, Flash is mapped at 0x0 & 0x80000000.
> >>>>>But what I don't understand is that, when it jumps to the High
> >
> > memory,
> >
> >>>>>(0x8000000e in my case), shouldn't there  be some or the other pice
> >
> > of
> >
> >>>code
> >>>
> >>>>>attached there,
> >>>>>But I'm not seeing any instruction placed at that address.
> >>>>
> >>>>How are you looking?
> >>>>
> >>>>    Andrew
> >>>
> >
> >
>
>
> --
> eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
> --[ "You can complain because roses have thorns, or you ]--
> --[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine
>


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] vectors.s

[Jonathan Larmour]

Rupesh S wrote:
> thanx for the info...
> As u said, the content of _reset_platform is data (the address of
> __reset_platform , which is in vectors.S , and does the hardware inits...).
> May be the dissambler would have interpreted the address as a match of the
> bra instruction. I was reading that fluke code.
> Good leason not to rely on the disassembled code....!!!
> 
> I have yet another doubt regarding the same...
> if the startup is ROM , then the data there is address of
> __reset_platform+0x20000000, why is it done like that...??

 From the comments I guess 0x80000000 is the address the app is linked at 
to run, but in fact is a mapped (and maybe also cached region), but the 
mappings haven't been set up yet, whereas 0xa0000000 will work regardless. 
Maybe :-). I'm sure an SH3 CPU manual should help.... go to the SuperH site.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] vectors.s

[Rupesh S]

thanks for the clue...

the board flash is mapped for 0x8000000, and the mapping is done at an
initialization code for chip select registers which is apart from the RESET.
The reset vector for SH3 is hooked at 0xA0000000, and the code is linked at
0x80000000. So changing the PC with a value other than 0xA0xxxxxx, would not
provide the appropriate chip selects untill the chipselect registers are
initialized.....

I find that the MMU initializations are commented off.
Out of curiosity ,,,Is it not feasible to handle the MMU related stuff at
the bootloader level ??
Rupesh

----- Original Message -----
From: "Jonathan Larmour" <jifl@eCosCentric.com>
To: "Rupesh S" <rupeshs@myw.ltindia.com>
Cc: "Andrew Lunn" <andrew.lunn@ascom.ch>; <ecos-discuss@sources.redhat.com>
Sent: Thursday, April 17, 2003 6:53 AM
Subject: Re: [ECOS] vectors.s


> Rupesh S wrote:
> > thanx for the info...
> > As u said, the content of _reset_platform is data (the address of
> > __reset_platform , which is in vectors.S , and does the hardware
inits...).
> > May be the dissambler would have interpreted the address as a match of
the
> > bra instruction. I was reading that fluke code.
> > Good leason not to rely on the disassembled code....!!!
> >
> > I have yet another doubt regarding the same...
> > if the startup is ROM , then the data there is address of
> > __reset_platform+0x20000000, why is it done like that...??
>
>  From the comments I guess 0x80000000 is the address the app is linked at
> to run, but in fact is a mapped (and maybe also cached region), but the
> mappings haven't been set up yet, whereas 0xa0000000 will work regardless.
> Maybe :-). I'm sure an SH3 CPU manual should help.... go to the SuperH
site.
>
> Jifl
> --
> eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
> --[ "You can complain because roses have thorns, or you ]--
> --[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine
>
>
> --
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss
>


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] arm evaluator e7t hangs when executing example progs/tests

[Jonathan Larmour]

Chris Garry wrote:
> ----- Original Message -----
> From: "Matt Kober" <mattkober@web.de>
> To: "JonathanLarmour" <jifl@eCosCentric.com>
> Cc: <ecos-discuss@sources.redhat.com>
> Sent: Sunday, April 13, 2003 11:35 PM
> Subject: Re: [ECOS] arm evaluator e7t hangs when executing example progs/tests
> 
> 
> 
>>I just rebuilt redboot based on the 2.0b1 source code. i got no errors at built
>>time and after download the redboot module is available but when i try to start it,
>>it just returns to the e7t BSL boot prompt.
>>
>>previously, i used a prebuilt image that i downloaded at http://sources.redhat.com/ecos/boards/redbootbins/e7t/ ,which seemed to
> 
> work just fine for me.
> 
>>i really hope i just have a hardware problem, but i don't quite understand why the
>>prebuilt redboot works then. on the other hand, is it working properly ?
>>
>>just to rule out the posibillity of a hardware issue, i'll try a different board.
>>
>>Matt
>>
> 
> 
> Did you change the 'Startup Type' from RAM to ROM before building?

Although if this was it, then this would imply Matt also didn't do import 
the redboot_ROM.ecm file - he should do that too, which will set the 
Startup Type as well as other things.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] arm evaluator e7t hangs when executing example progs/tests

[Chris Garry]

----- Original Message -----
From: "Matt Kober" <mattkober@web.de>
To: "JonathanLarmour" <jifl@eCosCentric.com>
Cc: <ecos-discuss@sources.redhat.com>
Sent: Sunday, April 13, 2003 11:35 PM
Subject: Re: [ECOS] arm evaluator e7t hangs when executing example progs/tests


> I just rebuilt redboot based on the 2.0b1 source code. i got no errors at built
> time and after download the redboot module is available but when i try to start it,
> it just returns to the e7t BSL boot prompt.
>
> previously, i used a prebuilt image that i downloaded at http://sources.redhat.com/ecos/boards/redbootbins/e7t/ ,which seemed to
work just fine for me.
>
> i really hope i just have a hardware problem, but i don't quite understand why the
> prebuilt redboot works then. on the other hand, is it working properly ?
>
> just to rule out the posibillity of a hardware issue, i'll try a different board.
>
> Matt
>

Did you change the 'Startup Type' from RAM to ROM before building?

Chris


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] arm evaluator e7t hangs when executing example progs/tests

[Matt Kober]

I just rebuilt redboot based on the 2.0b1 source code. i got no errors at built
time and after download the redboot module is available but when i try to start it, 
it just returns to the e7t BSL boot prompt. 

previously, i used a prebuilt image that i downloaded at http://sources.redhat.com/ecos/boards/redbootbins/e7t/ ,which seemed to work just fine for me. 

i really hope i just have a hardware problem, but i don't quite understand why the 
prebuilt redboot works then. on the other hand, is it working properly ?

just to rule out the posibillity of a hardware issue, i'll try a different board.

Matt
 
______________________________________________________________________________
UNICEF bittet um Spenden fur die Kinder im Irak! Hier online an
UNICEF spenden: https://spenden.web.de/unicef/special/?mc=021101


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] arm evaluator e7t hangs when executing example progs/tests

[Jonathan Larmour]

Chris Garry wrote:
>>
>>Of course there's always the possibility of a hardware problem...
>>
>>You should probably say what version or date of RedBoot you are using.
>>
> 
> 
> I ran the mutex tests (mutex0, mutex1, mutex2 and mutex3) on my e7t
> using the first the 2.0b1 code and then the latest CVS code and they
> all passed fine.
> 
> The RedBoot I used was built using the 2.0b1 code.  One point to note
> is that my sources have been slightly modified to use 32M of SDRAM
> on a daughter board instead of the E7T's 512K of SRAM - but I don't
> think this should make any difference.

Agreed - I wouldn't have thought so given the symptoms.

> If nobody has alraedy done this, I will run the tests as described at
> http://sources.redhat.com/ecos/testing.html using unmodified 2.0b1
> code on my E7T. However I think the 'default' template will have to
> be used instead of the 'all' template in order to fit in the 512K of
> SRAM.

That might be good since your positive results make me think it may be 
Matt's hardware. Besides, testing for e7t for the beta is good anyway!

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] arm evaluator e7t hangs when executing example progs/tests

[Chris Garry]

> > I enabled assertions and tracing and also disabled compiler optimisation.
> > Just for the fun of it i even tried the bitmap scheduler but without any better results 
> > though.the bin_sem0 test seems to complete correctly and "pass" is displayed but 
> > then the board crashes anyway. the same thing with mutex0, the others don't even 
> > get to display a friendly "pass" before the crash.
> > to me it looks like the problem is occuring in the idle task.
> > i'm kind of desperate, could you please have a look at the attached gdb log file ?
> 
> I've had a look, and (unfortunately) I can't see anything wrong. The 
> threads start, delay and so on. What it seems to be is "simply" that the 
> clock interrupt doesn't happen - I don't think it's anything to do with 
> the idle thread itself as there's not meant to be anything in there. While 
> it might be conceivable the idle thread stack could get overrun, it seems 
> very unlikely given that there's only one interrupt to take.
> 
> The fact you can't ctrl-c it implies the serial interrupt doesn't work 
> either; i.e. *no* interrupts work.
> 
> To debug it I'd suggest setting a breakpoint somewhere like 
> cyg_idle_thread_main, and try and poke the processor state to find out 
> what the status of global interrupts and individual interrupt masks is, as 
> well as what eCos's interrupt structures point to for those interrupts.
> 
> Of course there's always the possibility of a hardware problem...
> 
> You should probably say what version or date of RedBoot you are using.
> 

I ran the mutex tests (mutex0, mutex1, mutex2 and mutex3) on my e7t
using the first the 2.0b1 code and then the latest CVS code and they
all passed fine.

The RedBoot I used was built using the 2.0b1 code.  One point to note
is that my sources have been slightly modified to use 32M of SDRAM
on a daughter board instead of the E7T's 512K of SRAM - but I don't
think this should make any difference.

If nobody has alraedy done this, I will run the tests as described at
http://sources.redhat.com/ecos/testing.html using unmodified 2.0b1
code on my E7T. However I think the 'default' template will have to
be used instead of the 'all' template in order to fit in the 512K of
SRAM.

--
Chris

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] arm evaluator e7t hangs when executing example progs/tests

[Jonathan Larmour]

Matt Kober wrote:
> I enabled assertions and tracing and also disabled compiler optimisation.
> Just for the fun of it i even tried the bitmap scheduler but without any better results 
> though.the bin_sem0 test seems to complete correctly and "pass" is displayed but 
> then the board crashes anyway. the same thing with mutex0, the others don't even 
> get to display a friendly "pass" before the crash.
> to me it looks like the problem is occuring in the idle task.
> i'm kind of desperate, could you please have a look at the attached gdb log file ?

I've had a look, and (unfortunately) I can't see anything wrong. The 
threads start, delay and so on. What it seems to be is "simply" that the 
clock interrupt doesn't happen - I don't think it's anything to do with 
the idle thread itself as there's not meant to be anything in there. While 
it might be conceivable the idle thread stack could get overrun, it seems 
very unlikely given that there's only one interrupt to take.

The fact you can't ctrl-c it implies the serial interrupt doesn't work 
either; i.e. *no* interrupts work.

To debug it I'd suggest setting a breakpoint somewhere like 
cyg_idle_thread_main, and try and poke the processor state to find out 
what the status of global interrupts and individual interrupt masks is, as 
well as what eCos's interrupt structures point to for those interrupts.

Of course there's always the possibility of a hardware problem...

You should probably say what version or date of RedBoot you are using.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss