[ECOS] eCos + goAhead probelm

[ECOS] eCos + goAhead probelm

[Hao]

I build a target system that use eCos + goAhead web server.
When I run goAhead , and try to open a page from browser.
My target is failed at malloc() reutrn NULL.
But the ping function still work.
I set CYGNUM_MEMALLOC_FALLBACK_MALLOC_POOL_SIZE from 16384 to 1638400.
But, it doesn't help.
Then I try to use 'Simple variable block implementation' instead of
'Doug Lea's malloc implementatioin'.
It still don't work.

My target system already pass all eCos tests include memalloc. And the
on board memory is
16MB. I think it's enough for eCos + goAhead.

It seems goAhead eat all of memory. why ?
Does anybody has same problem as I ?
I use goAhead 2.18 + eCos (2004/06/24 got from CVS).
(I already try goAhead 2.14 ~ 2.18. All that have same problem)

Regards
Hao

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

[ECOS] using fconfig

[David Lewin]

The facts :
I'm workin in flash with an ARM processor.

the fis init is working ok, I can see 
-Redboot 
- Redboot config 
- FIS directory 

directories that have been created.

My question is : 

what can make a fconfig -i crashing redboot[ROM] when I try 
to create a new config ?
while debugging in RAM (insight & gdb dislike Flash debugging)
is ok to create my config.

Regards.

David Lewin

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

Re: [ECOS] using fconfig

[Gary Thomas]

On Wed, 2004-08-04 at 03:28, David Lewin wrote:
> The facts :
> I'm workin in flash with an ARM processor.
> 
> the fis init is working ok, I can see 
> -Redboot 
> - Redboot config 
> - FIS directory 
> 
> directories that have been created.
> 
> My question is : 
> 
> what can make a fconfig -i crashing redboot[ROM] when I try 
> to create a new config ?
> while debugging in RAM (insight & gdb dislike Flash debugging)
> is ok to create my config.

Check that the FLASH drivers you use are ROM-friendly.  In other
words, while you are writing to the FLASH, you can't be executing
from it at the same time.

Note: probably the easiest way around this is to run RedBoot
in ROMRAM mode instead.

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


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

Re: [ECOS] using fconfig

[David Lewin]

thanks gary,

I tried it and this compiled Redboot to be in such a way that it didn't
start at all.

Therefore, for me, it enforce the idea that the Flash driver seems to be
executed in
RAM .

----- Original Message ----- 
From: "Gary Thomas" <gary@mlbassoc.com>
To: "David Lewin" <david.lewin@europe-technologies.com>
Cc: <ecos-discuss@sources.redhat.com>
Sent: Wednesday, August 04, 2004 12:28 PM
Subject: Re: [ECOS] using fconfig


> On Wed, 2004-08-04 at 03:28, David Lewin wrote:
> > The facts :
> > I'm workin in flash with an ARM processor.
> >
> > the fis init is working ok, I can see
> > -Redboot
> > - Redboot config
> > - FIS directory
> >
> > directories that have been created.
> >
> > My question is :
> >
> > what can make a fconfig -i crashing redboot[ROM] when I try
> > to create a new config ?
> > while debugging in RAM (insight & gdb dislike Flash debugging)
> > is ok to create my config.
>
> Check that the FLASH drivers you use are ROM-friendly.  In other
> words, while you are writing to the FLASH, you can't be executing
> from it at the same time.
>
> Note: probably the easiest way around this is to run RedBoot
> in ROMRAM mode instead.
>
> -- 
> Gary Thomas <gary@mlbassoc.com>
> MLB Associates
>
>
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


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

Re: [ECOS] using fconfig

[David Lewin]

Correction, I meant :"seems to be executed in Flash"


----- Original Message ----- 
From: "David Lewin" <david.lewin@europe-technologies.com>
To: "Gary Thomas" <gary@mlbassoc.com>
Cc: <ecos-discuss@sources.redhat.com>
Sent: Wednesday, August 04, 2004 2:01 PM
Subject: Re: [ECOS] using fconfig


> thanks gary,
>
> I tried it and this compiled Redboot to be in such a way that it didn't
> start at all.
>
> Therefore, for me, it enforce the idea that the Flash driver seems to be
> executed in
> RAM .
>
> ----- Original Message ----- 
> From: "Gary Thomas" <gary@mlbassoc.com>
> To: "David Lewin" <david.lewin@europe-technologies.com>
> Cc: <ecos-discuss@sources.redhat.com>
> Sent: Wednesday, August 04, 2004 12:28 PM
> Subject: Re: [ECOS] using fconfig
>
>
> > On Wed, 2004-08-04 at 03:28, David Lewin wrote:
> > > The facts :
> > > I'm workin in flash with an ARM processor.
> > >
> > > the fis init is working ok, I can see
> > > -Redboot
> > > - Redboot config
> > > - FIS directory
> > >
> > > directories that have been created.
> > >
> > > My question is :
> > >
> > > what can make a fconfig -i crashing redboot[ROM] when I try
> > > to create a new config ?
> > > while debugging in RAM (insight & gdb dislike Flash debugging)
> > > is ok to create my config.
> >
> > Check that the FLASH drivers you use are ROM-friendly.  In other
> > words, while you are writing to the FLASH, you can't be executing
> > from it at the same time.
> >
> > Note: probably the easiest way around this is to run RedBoot
> > in ROMRAM mode instead.
> >
> > -- 
> > Gary Thomas <gary@mlbassoc.com>
> > MLB Associates
> >
> >
> > -- 
> > Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
>
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


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

Re: [ECOS] using fconfig

[David Lewin]

Looks like strange :

is it normal that when doing a fconfig -i, the call of the flash_erase is
executed
at the same address that the FIS directory,
that is to say, if you take in account that :

Name                  FLASH addr    Mem addr           Length         Entry
point
RedBoot             0x01000000     0x01000000    0x00020000  0x00000000
RedBoot config   0x0107EC00   0x0107EC00    0x00001000  0x00000000
FIS directory      0x0107F800    0x0107F800     0x00000400  0x00000000

Boot script timeout (1000ms resolution): 0
Update RedBoot non-volatile configuration - continue (y/n)? y
 ... Erase from 0x0107ec00-0x0107fbff: ...
My Debug string : flash_erase with block: 107f800 / block_size :400
$T0a0f:00000801;0d:f8050

does someone knows ?
.
----- Original Message ----- 
From: "David Lewin" <david.lewin@europe-technologies.com>
To: "Gary Thomas" <gary@mlbassoc.com>
Cc: <ecos-discuss@sources.redhat.com>
Sent: Wednesday, August 04, 2004 2:01 PM
Subject: Re: [ECOS] using fconfig


> thanks gary,
>
> I tried it and this compiled Redboot to be in such a way that it didn't
> start at all.
>
> Therefore, for me, it enforce the idea that the Flash driver seems to be
> executed in
> RAM .
>
> ----- Original Message ----- 
> From: "Gary Thomas" <gary@mlbassoc.com>
> To: "David Lewin" <david.lewin@europe-technologies.com>
> Cc: <ecos-discuss@sources.redhat.com>
> Sent: Wednesday, August 04, 2004 12:28 PM
> Subject: Re: [ECOS] using fconfig
>
>
> > On Wed, 2004-08-04 at 03:28, David Lewin wrote:
> > > The facts :
> > > I'm workin in flash with an ARM processor.
> > >
> > > the fis init is working ok, I can see
> > > -Redboot
> > > - Redboot config
> > > - FIS directory
> > >
> > > directories that have been created.
> > >
> > > My question is :
> > >
> > > what can make a fconfig -i crashing redboot[ROM] when I try
> > > to create a new config ?
> > > while debugging in RAM (insight & gdb dislike Flash debugging)
> > > is ok to create my config.
> >
> > Check that the FLASH drivers you use are ROM-friendly.  In other
> > words, while you are writing to the FLASH, you can't be executing
> > from it at the same time.
> >
> > Note: probably the easiest way around this is to run RedBoot
> > in ROMRAM mode instead.
> >
> > -- 
> > Gary Thomas <gary@mlbassoc.com>
> > MLB Associates
> >
> >
> > -- 
> > Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
>
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


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

Re: [ECOS] using fconfig

[Gary Thomas]

On Wed, 2004-08-04 at 08:47, David Lewin wrote:
> Looks like strange :
> 
> is it normal that when doing a fconfig -i, the call of the flash_erase is
> executed
> at the same address that the FIS directory,
> that is to say, if you take in account that :
> 
> Name                  FLASH addr    Mem addr           Length         Entry
> point
> RedBoot             0x01000000     0x01000000    0x00020000  0x00000000
> RedBoot config   0x0107EC00   0x0107EC00    0x00001000  0x00000000
> FIS directory      0x0107F800    0x0107F800     0x00000400  0x00000000
> 
> Boot script timeout (1000ms resolution): 0
> Update RedBoot non-volatile configuration - continue (y/n)? y
>  ... Erase from 0x0107ec00-0x0107fbff: ...
> My Debug string : flash_erase with block: 107f800 / block_size :400
> $T0a0f:00000801;0d:f8050
> 
> does someone knows ?

Look at your configuration - the default is for the 'fconfig' data to
be stored in the same FLASH [erase] block as the FIS directory.

You really should work out how to get ROMRAM mode working.

> .
> ----- Original Message ----- 
> From: "David Lewin" <david.lewin@europe-technologies.com>
> To: "Gary Thomas" <gary@mlbassoc.com>
> Cc: <ecos-discuss@sources.redhat.com>
> Sent: Wednesday, August 04, 2004 2:01 PM
> Subject: Re: [ECOS] using fconfig
> 
> 
> > thanks gary,
> >
> > I tried it and this compiled Redboot to be in such a way that it didn't
> > start at all.
> >
> > Therefore, for me, it enforce the idea that the Flash driver seems to be
> > executed in
> > RAM .
> >
> > ----- Original Message ----- 
> > From: "Gary Thomas" <gary@mlbassoc.com>
> > To: "David Lewin" <david.lewin@europe-technologies.com>
> > Cc: <ecos-discuss@sources.redhat.com>
> > Sent: Wednesday, August 04, 2004 12:28 PM
> > Subject: Re: [ECOS] using fconfig
> >
> >
> > > On Wed, 2004-08-04 at 03:28, David Lewin wrote:
> > > > The facts :
> > > > I'm workin in flash with an ARM processor.
> > > >
> > > > the fis init is working ok, I can see
> > > > -Redboot
> > > > - Redboot config
> > > > - FIS directory
> > > >
> > > > directories that have been created.
> > > >
> > > > My question is :
> > > >
> > > > what can make a fconfig -i crashing redboot[ROM] when I try
> > > > to create a new config ?
> > > > while debugging in RAM (insight & gdb dislike Flash debugging)
> > > > is ok to create my config.
> > >
> > > Check that the FLASH drivers you use are ROM-friendly.  In other
> > > words, while you are writing to the FLASH, you can't be executing
> > > from it at the same time.
> > >
> > > Note: probably the easiest way around this is to run RedBoot
> > > in ROMRAM mode instead.
> > >
> > > -- 
> > > Gary Thomas <gary@mlbassoc.com>
> > > MLB Associates
> > >
> > >
> > > -- 
> > > Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> > > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> >
> >
> > -- 
> > Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


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

Re: [ECOS] using fconfig

[David Lewin]

Gary,

What do you mean by :

" the default is for the 'fconfig' data" ?

Thanx for your answers.

----- Original Message ----- 
From: "Gary Thomas" <gary@mlbassoc.com>
To: "David Lewin" <david.lewin@europe-technologies.com>
Cc: <ecos-discuss@sources.redhat.com>
Sent: Wednesday, August 04, 2004 4:47 PM
Subject: Re: [ECOS] using fconfig


> On Wed, 2004-08-04 at 08:47, David Lewin wrote:
> > Looks like strange :
> >
> > is it normal that when doing a fconfig -i, the call of the flash_erase
is
> > executed
> > at the same address that the FIS directory,
> > that is to say, if you take in account that :
> >
> > Name                  FLASH addr    Mem addr           Length
Entry
> > point
> > RedBoot             0x01000000     0x01000000    0x00020000  0x00000000
> > RedBoot config   0x0107EC00   0x0107EC00    0x00001000  0x00000000
> > FIS directory      0x0107F800    0x0107F800     0x00000400  0x00000000
> >
> > Boot script timeout (1000ms resolution): 0
> > Update RedBoot non-volatile configuration - continue (y/n)? y
> >  ... Erase from 0x0107ec00-0x0107fbff: ...
> > My Debug string : flash_erase with block: 107f800 / block_size :400
> > $T0a0f:00000801;0d:f8050
> >
> > does someone knows ?
>
> Look at your configuration - the default is for the 'fconfig' data to
> be stored in the same FLASH [erase] block as the FIS directory.
>
> You really should work out how to get ROMRAM mode working.
>
> > .
> > ----- Original Message ----- 
> > From: "David Lewin" <david.lewin@europe-technologies.com>
> > To: "Gary Thomas" <gary@mlbassoc.com>
> > Cc: <ecos-discuss@sources.redhat.com>
> > Sent: Wednesday, August 04, 2004 2:01 PM
> > Subject: Re: [ECOS] using fconfig
> >
> >
> > > thanks gary,
> > >
> > > I tried it and this compiled Redboot to be in such a way that it
didn't
> > > start at all.
> > >
> > > Therefore, for me, it enforce the idea that the Flash driver seems to
be
> > > executed in
> > > RAM .
> > >
> > > ----- Original Message ----- 
> > > From: "Gary Thomas" <gary@mlbassoc.com>
> > > To: "David Lewin" <david.lewin@europe-technologies.com>
> > > Cc: <ecos-discuss@sources.redhat.com>
> > > Sent: Wednesday, August 04, 2004 12:28 PM
> > > Subject: Re: [ECOS] using fconfig
> > >
> > >
> > > > On Wed, 2004-08-04 at 03:28, David Lewin wrote:
> > > > > The facts :
> > > > > I'm workin in flash with an ARM processor.
> > > > >
> > > > > the fis init is working ok, I can see
> > > > > -Redboot
> > > > > - Redboot config
> > > > > - FIS directory
> > > > >
> > > > > directories that have been created.
> > > > >
> > > > > My question is :
> > > > >
> > > > > what can make a fconfig -i crashing redboot[ROM] when I try
> > > > > to create a new config ?
> > > > > while debugging in RAM (insight & gdb dislike Flash debugging)
> > > > > is ok to create my config.
> > > >
> > > > Check that the FLASH drivers you use are ROM-friendly.  In other
> > > > words, while you are writing to the FLASH, you can't be executing
> > > > from it at the same time.
> > > >
> > > > Note: probably the easiest way around this is to run RedBoot
> > > > in ROMRAM mode instead.
> > > >
> > > > -- 
> > > > Gary Thomas <gary@mlbassoc.com>
> > > > MLB Associates
> > > >
> > > >
> > > > -- 
> > > > Before posting, please read the FAQ:
http://ecos.sourceware.org/fom/ecos
> > > > and search the list archive:
http://ecos.sourceware.org/ml/ecos-discuss
> > >
> > >
> > > -- 
> > > Before posting, please read the FAQ:
http://ecos.sourceware.org/fom/ecos
> > > and search the list archive:
http://ecos.sourceware.org/ml/ecos-discuss
> -- 
> Gary Thomas <gary@mlbassoc.com>
> MLB Associates
>
>
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


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

Re: [ECOS] using fconfig

[David Lewin]

If you meant that the option :

"Merged config data adn FIS directory " should be unchecked,
the Redboot configuration is therefore ok.

----- Original Message ----- 
From: "Gary Thomas" <gary@mlbassoc.com>
To: "David Lewin" <david.lewin@europe-technologies.com>
Cc: <ecos-discuss@sources.redhat.com>
Sent: Wednesday, August 04, 2004 4:47 PM
Subject: Re: [ECOS] using fconfig


> On Wed, 2004-08-04 at 08:47, David Lewin wrote:
> > Looks like strange :
> >
> > is it normal that when doing a fconfig -i, the call of the flash_erase
is
> > executed
> > at the same address that the FIS directory,
> > that is to say, if you take in account that :
> >
> > Name                  FLASH addr    Mem addr           Length
Entry
> > point
> > RedBoot             0x01000000     0x01000000    0x00020000  0x00000000
> > RedBoot config   0x0107EC00   0x0107EC00    0x00001000  0x00000000
> > FIS directory      0x0107F800    0x0107F800     0x00000400  0x00000000
> >
> > Boot script timeout (1000ms resolution): 0
> > Update RedBoot non-volatile configuration - continue (y/n)? y
> >  ... Erase from 0x0107ec00-0x0107fbff: ...
> > My Debug string : flash_erase with block: 107f800 / block_size :400
> > $T0a0f:00000801;0d:f8050
> >
> > does someone knows ?
>
> Look at your configuration - the default is for the 'fconfig' data to
> be stored in the same FLASH [erase] block as the FIS directory.
>
> You really should work out how to get ROMRAM mode working.
>
> > .
> > ----- Original Message ----- 
> > From: "David Lewin" <david.lewin@europe-technologies.com>
> > To: "Gary Thomas" <gary@mlbassoc.com>
> > Cc: <ecos-discuss@sources.redhat.com>
> > Sent: Wednesday, August 04, 2004 2:01 PM
> > Subject: Re: [ECOS] using fconfig
> >
> >
> > > thanks gary,
> > >
> > > I tried it and this compiled Redboot to be in such a way that it
didn't
> > > start at all.
> > >
> > > Therefore, for me, it enforce the idea that the Flash driver seems to
be
> > > executed in
> > > RAM .
> > >
> > > ----- Original Message ----- 
> > > From: "Gary Thomas" <gary@mlbassoc.com>
> > > To: "David Lewin" <david.lewin@europe-technologies.com>
> > > Cc: <ecos-discuss@sources.redhat.com>
> > > Sent: Wednesday, August 04, 2004 12:28 PM
> > > Subject: Re: [ECOS] using fconfig
> > >
> > >
> > > > On Wed, 2004-08-04 at 03:28, David Lewin wrote:
> > > > > The facts :
> > > > > I'm workin in flash with an ARM processor.
> > > > >
> > > > > the fis init is working ok, I can see
> > > > > -Redboot
> > > > > - Redboot config
> > > > > - FIS directory
> > > > >
> > > > > directories that have been created.
> > > > >
> > > > > My question is :
> > > > >
> > > > > what can make a fconfig -i crashing redboot[ROM] when I try
> > > > > to create a new config ?
> > > > > while debugging in RAM (insight & gdb dislike Flash debugging)
> > > > > is ok to create my config.
> > > >
> > > > Check that the FLASH drivers you use are ROM-friendly.  In other
> > > > words, while you are writing to the FLASH, you can't be executing
> > > > from it at the same time.
> > > >
> > > > Note: probably the easiest way around this is to run RedBoot
> > > > in ROMRAM mode instead.
> > > >
> > > > -- 
> > > > Gary Thomas <gary@mlbassoc.com>
> > > > MLB Associates
> > > >
> > > >
> > > > -- 
> > > > Before posting, please read the FAQ:
http://ecos.sourceware.org/fom/ecos
> > > > and search the list archive:
http://ecos.sourceware.org/ml/ecos-discuss
> > >
> > >
> > > -- 
> > > Before posting, please read the FAQ:
http://ecos.sourceware.org/fom/ecos
> > > and search the list archive:
http://ecos.sourceware.org/ml/ecos-discuss
> -- 
> Gary Thomas <gary@mlbassoc.com>
> MLB Associates
>
>
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


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

Re: [ECOS] using fconfig

[Gary Thomas]

On Wed, 2004-08-04 at 09:11, David Lewin wrote:
> If you meant that the option :
> 
> "Merged config data adn FIS directory " should be unchecked,
> the Redboot configuration is therefore ok.

No, I simply meant that the default configuration has these merged.
You asked why the FIS block was being erased - this is why.

> 
> ----- Original Message ----- 
> From: "Gary Thomas" <gary@mlbassoc.com>
> To: "David Lewin" <david.lewin@europe-technologies.com>
> Cc: <ecos-discuss@sources.redhat.com>
> Sent: Wednesday, August 04, 2004 4:47 PM
> Subject: Re: [ECOS] using fconfig
> 
> 
> > On Wed, 2004-08-04 at 08:47, David Lewin wrote:
> > > Looks like strange :
> > >
> > > is it normal that when doing a fconfig -i, the call of the flash_erase
> is
> > > executed
> > > at the same address that the FIS directory,
> > > that is to say, if you take in account that :
> > >
> > > Name                  FLASH addr    Mem addr           Length
> Entry
> > > point
> > > RedBoot             0x01000000     0x01000000    0x00020000  0x00000000
> > > RedBoot config   0x0107EC00   0x0107EC00    0x00001000  0x00000000
> > > FIS directory      0x0107F800    0x0107F800     0x00000400  0x00000000
> > >
> > > Boot script timeout (1000ms resolution): 0
> > > Update RedBoot non-volatile configuration - continue (y/n)? y
> > >  ... Erase from 0x0107ec00-0x0107fbff: ...
> > > My Debug string : flash_erase with block: 107f800 / block_size :400
> > > $T0a0f:00000801;0d:f8050
> > >
> > > does someone knows ?
> >
> > Look at your configuration - the default is for the 'fconfig' data to
> > be stored in the same FLASH [erase] block as the FIS directory.
> >
> > You really should work out how to get ROMRAM mode working.
> >
> > > .
> > > ----- Original Message ----- 
> > > From: "David Lewin" <david.lewin@europe-technologies.com>
> > > To: "Gary Thomas" <gary@mlbassoc.com>
> > > Cc: <ecos-discuss@sources.redhat.com>
> > > Sent: Wednesday, August 04, 2004 2:01 PM
> > > Subject: Re: [ECOS] using fconfig
> > >
> > >
> > > > thanks gary,
> > > >
> > > > I tried it and this compiled Redboot to be in such a way that it
> didn't
> > > > start at all.
> > > >
> > > > Therefore, for me, it enforce the idea that the Flash driver seems to
> be
> > > > executed in
> > > > RAM .
> > > >
> > > > ----- Original Message ----- 
> > > > From: "Gary Thomas" <gary@mlbassoc.com>
> > > > To: "David Lewin" <david.lewin@europe-technologies.com>
> > > > Cc: <ecos-discuss@sources.redhat.com>
> > > > Sent: Wednesday, August 04, 2004 12:28 PM
> > > > Subject: Re: [ECOS] using fconfig
> > > >
> > > >
> > > > > On Wed, 2004-08-04 at 03:28, David Lewin wrote:
> > > > > > The facts :
> > > > > > I'm workin in flash with an ARM processor.
> > > > > >
> > > > > > the fis init is working ok, I can see
> > > > > > -Redboot
> > > > > > - Redboot config
> > > > > > - FIS directory
> > > > > >
> > > > > > directories that have been created.
> > > > > >
> > > > > > My question is :
> > > > > >
> > > > > > what can make a fconfig -i crashing redboot[ROM] when I try
> > > > > > to create a new config ?
> > > > > > while debugging in RAM (insight & gdb dislike Flash debugging)
> > > > > > is ok to create my config.
> > > > >
> > > > > Check that the FLASH drivers you use are ROM-friendly.  In other
> > > > > words, while you are writing to the FLASH, you can't be executing
> > > > > from it at the same time.
> > > > >
> > > > > Note: probably the easiest way around this is to run RedBoot
> > > > > in ROMRAM mode instead.
> > > > >
> > > > > -- 
> > > > > Gary Thomas <gary@mlbassoc.com>
> > > > > MLB Associates
> > > > >
> > > > >
> > > > > -- 
> > > > > Before posting, please read the FAQ:
> http://ecos.sourceware.org/fom/ecos
> > > > > and search the list archive:
> http://ecos.sourceware.org/ml/ecos-discuss
> > > >
> > > >
> > > > -- 
> > > > Before posting, please read the FAQ:
> http://ecos.sourceware.org/fom/ecos
> > > > and search the list archive:
> http://ecos.sourceware.org/ml/ecos-discuss
> > -- 
> > Gary Thomas <gary@mlbassoc.com>
> > MLB Associates
> >
> >
> > -- 
> > Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> > and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


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

[ECOS] Endianness of the XScale

[Krishna Ganugapati]

Could someone confirm or deny the accuracy following statement.

"Endianness in the XScale only applies to data fetches. All instruction
opcode fetches are always little endian. This is the reason why when
downloading the big endian image of ecos redboot-rom binary images for the
IXDP425, we byte swap the big endian image"



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

Re: [ECOS] Endianness of the XScale

[Mark Salter]

>>>>> Krishna Ganugapati writes:

> Could someone confirm or deny the accuracy following statement.
> "Endianness in the XScale only applies to data fetches. All instruction
> opcode fetches are always little endian. This is the reason why when
> downloading the big endian image of ecos redboot-rom binary images for the
> IXDP425, we byte swap the big endian image"

That can't be the reason you have to byte swap the IXDP425 because
I can reprogram the reboot.bin image just as the toolchain generates
it without having to byte swap it.

There is an issue with downloading/programming a LE RedBoot when
running a BE RedBoot or vice-versa. That has to do with the way
the flash interface is wired to the core. But if you're using
on LE or only BE, then no byte swapping should be necessary.

--Mark




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

Re: [ECOS] Endianness of the XScale

[Krishna Ganugapati]

Hello Mark, Thanks for the quick response.

Could you clarify the first part?

Endianness in the XScale only applies to data fetches. All instruction
opcode fetches are always little endian irrespective of whether the machine
configured BE or LE

is the above accurate?

Thanks!

Krishna
-------------------------------------------------
----- Original Message ----- 
From: "Mark Salter" <msalter@redhat.com>
To: <krishnag@marakicorp.com>
Cc: <ecos-discuss@sources.redhat.com>
Sent: Wednesday, August 04, 2004 10:18 AM
Subject: Re: [ECOS] Endianness of the XScale


> >>>>> Krishna Ganugapati writes:
>
> > Could someone confirm or deny the accuracy following statement.
> > "Endianness in the XScale only applies to data fetches. All instruction
> > opcode fetches are always little endian. This is the reason why when
> > downloading the big endian image of ecos redboot-rom binary images for
the
> > IXDP425, we byte swap the big endian image"
>
> That can't be the reason you have to byte swap the IXDP425 because
> I can reprogram the reboot.bin image just as the toolchain generates
> it without having to byte swap it.
>
> There is an issue with downloading/programming a LE RedBoot when
> running a BE RedBoot or vice-versa. That has to do with the way
> the flash interface is wired to the core. But if you're using
> on LE or only BE, then no byte swapping should be necessary.
>
> --Mark
>
>
>
>
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>


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

Re: [ECOS] Endianness of the XScale

[Mark Salter]

>>>>> Krishna Ganugapati writes:

> Hello Mark, Thanks for the quick response.
> Could you clarify the first part?

> Endianness in the XScale only applies to data fetches. All instruction
> opcode fetches are always little endian irrespective of whether the machine
> configured BE or LE

> is the above accurate?

No, I don't think it is accurate. Endianess on a 32-bit ARM really only
comes into play when accessing 8-bit or 16-bit data. Instructions are
always fetched as 32-bit objects. I think that opcodes and data are
stored in memory in the same endianess. For instance, RedBoot may copy
flash driver routines from flash to RAM and run them from RAM. This
copy is done as data loads and stores. No byte swapping necessary
regardless of endianess. Also, the compiler will embed some data
along with the opcodes. That data and the opcodes around it all appear
to be stored in the same endianess.

As I said. I can load/flash a new redboot.bin on IXDP425 without doing
any byte swapping as long as the running RedBoot and the new RedBoot
are the same endianess. 

--Mark


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

Re: [ECOS] Endianness of the XScale

[Krishna Ganugapati]

See below...
-------------------------------------------------
----- Original Message ----- 
From: "Mark Salter" <msalter@redhat.com>
To: <krishnag@marakicorp.com>
Cc: <ecos-discuss@sources.redhat.com>
Sent: Wednesday, August 04, 2004 11:25 AM
Subject: Re: [ECOS] Endianness of the XScale


> >>>>> Krishna Ganugapati writes:
>
> > Hello Mark, Thanks for the quick response.
> > Could you clarify the first part?
>
> > Endianness in the XScale only applies to data fetches. All instruction
> > opcode fetches are always little endian irrespective of whether the
machine
> > configured BE or LE
>
> > is the above accurate?
>
> No, I don't think it is accurate. Endianess on a 32-bit ARM really only
> comes into play when accessing 8-bit or 16-bit data. Instructions are
> always fetched as 32-bit objects. I think that opcodes and data are

Agreed thay are always retrieved as 32 bit objects but if there is an
instruction AABBCCDD (software representation where left is always MSB), do
we store the 32 bit object as follows


Byte 0 - AA
Byte 1 - BB
Byte 2 - CC
Byte 3 - DD

or

Byte 0 - DD
Byte 1 - CC
Byte 2 - BB
Byte 3 - AA

> stored in memory in the same endianess. For instance, RedBoot may copy

Further in my investigation, I find the following. At reset, the XScale is
in little endian mode.
Instructions are stored on  4 byte boundaries. Consider an instruction
AABBCCDD. This is its software representation where the msb is AA and its
lsb is DD.

When you follow Intel's instructions for building redboot_rom for the XScale
using a big endian compiler, the image on the host has instruction AABBCCDD
stored as

byte 0 - AA
byte 1 - BB
byte 2 - CC
byte 3 - DD

For the Macraigor Flash Programmers, Intel requires byte swapping before you
create an s19 file which you then download. Once I perform the following and
then  dump the first instruction (assume it was AABBCCDD), the instruction
is stored as follows. I verified this by dumping individual bytes in the
Macraigor debugger.

byte 0 - DD
byte 1 - CC
byte 2 - BB
byte 3 - AA

which is a little endian representation.  Single step execution works fine.
About 10 instructions down the line, the redboot image switches endianness
of the  processor by switching the appropriate coprocessor bit.  Execution
continues on.... Though the processor has switched its endianess, its image
continues in the little endian mode (Remember every instruction has now been
represented as LE)  and it continues to execute instructions in the little
endian mode, which led me to the conclusion that instructions are always
stored LE.

Also if we were to assume that the instruction storage format had to map the
endianness of the processor, then once I had executed the instructions that
switched the endianness bit  to BE in the control register ( coprocessor 15
register 0??), then wouldn't it stand to reason that my instructions post
the endianness switch would also have to be BE which would imply that all my
instructions would be interpreted  the other way around. MSB in byte 0 which
would result in something very different for what I intended to execute. My
single step execution continues appropriately even after switching the
endianness.


Further I found the following snippet on web:


And AFAIK The opcode fetches are always little-endian (not that this
helps :(
Little/Big endian refers to the data-view.

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=85f19b17.0404280319.69ad72ac%40posting.google.com&rnum=1&prev=/groups%3Fq%3DAre%2Binstruction%2Binterpreted%2Bin%2Blittle%2Bendian%2Bor%2Bbig%2Bendian%2Bfor%2Bthe%2BARM%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3D85f19b17.0404280319.69ad72ac%2540posting.google.com%26rnum%3D1


Note: I'm certainly not claiming this is definitive or conclusive... I'm
just a thoroughly confused novice...



> flash driver routines from flash to RAM and run them from RAM. This
> copy is done as data loads and stores. No byte swapping necessary
> regardless of endianess. Also, the compiler will embed some data
> along with the opcodes. That data and the opcodes around it all appear
> to be stored in the same endianess.

Intel says that most Flash programmers do appropriate instruction layout
internally. Macraigor is the only one in their notes where they explicit
require the byte swapping.


>
> As I said. I can load/flash a new redboot.bin on IXDP425 without doing
> any byte swapping as long as the running RedBoot and the new RedBoot
> are the same endianess.
>

I'm sure you're right... I can't explain this mostly because I've not gotten
that far..



> --Mark
>


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

RE: [ECOS] eCos + goAhead probelm

[Amir Yiron]

Thanks Sebastien!

It works also at mine webs.
Anyway, also now (with the 50ms) it's still much slower than the
original socketSelect implementation (with a huge memory pool of 1.25M ..)

This "Winodw's implementation" of socketSelect is slow regardless the bufsize I work with (bopen).
Any idea why?

Thanks a lot,
-- Amir

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-owner@ecos.sourceware.org]On Behalf Of sebastien Couret
Sent: Tuesday, August 17, 2004 3:53 PM
To: Hao; ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] eCos + goAhead probelm


Well , in files Sockgen.c and main.c , you will find a call to socketSelect 
(on my 2.1.7 version, it's line 563 for Sockgen.c and line 77 for main.c) , 
the second argument is 1000 or 2000 (it's the timeout in milli-seconds). I 
suggested you to decrease this value to 50 in both files. 

I really thing that the second implementation of socketSelect is broken and 
doesn't even take this timeout in account which makes it faster than the 
first one. 

On the other hand, I would like to inform U that I have done a epk package of 
a light modified version of GoAhead Version 2.1.7 (It works as a thread and 
has some debugging asp pages for memory leaks ). 
I can send it to you if it helps and I will be pleased of your feedback.

For increasing performance, you can also act on your library build with the 
configtool by removing debugging flags, gdb stubs , asserts , tracing , 
thread list and stack checking. I had obtain a ratio of 6 by doing this for 
networking benchmarks.



On Tuesday 17 August 2004 15:25, Hao wrote:
> Hi, sebastien,
>
> Thanks for your information.
> I try your suggestion on my target. The problem of out of memory
> disappleared!!!
> The goAhead isn't crashed, but very very slowly when open a simple page.
> Do you have any experience about this ?
>
> Hao
>
> >Hello All,
> >In the past , (With GoAhead Webserver v 2.1.7) , I ran into the same kind
> > of problem with eCos.
> >After investigation this was caused by function "int socketSelect(int sid,
> >int timeout)" in file Sockgen.c (the one /* not WIN || CE || NW */ ) which
> >makes calls to balloc.
> >Using the another "socketSelect" (the one #if (defined (WIN) || defined
> > (CE) ) solved the memory leak/overflow. May be you should try this before
> > modifying balloc.c .
> >
> >Note : Now, I use a 64K balloc buffer without any problems.
> >
> >Hope this helps. Have a nice day.
> >
> >On Tuesday 17 August 2004 06:41, Hao wrote:
> >>Recently,  I modify balloc() in balloc.c of goAhead.
> >>I try to increase 64bytes at the line of  malloc() .  And the problem of
> >>out of memory disappeared.
> >>So , I think it's not the probelm caused by eCos.
> >>I think it's caused by goAhead somewhere that call balloc() and use
> >>wrong size.
> >>
> >>Now, in my target, goAhead still unstable just like you say. Then I use
> >>very simple web page instead of default web page(home.asp).
> >>It still unstable, but not crashed.
> >>But it can work very fine when I use 'lynx' instead of other browser(IE,
> >>mozilla..).
> >>I don't know what's the difference of behavior between lynx and other
> >>browser (IE,mozilla).
> >>
> >>Hope this information can help you something.
> >>
> >>Hao
> >>
> >>>Hello Hao!

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


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

Re: [ECOS] eCos + goAhead probelm

[sebastien Couret]

Well , in files Sockgen.c and main.c , you will find a call to socketSelect 
(on my 2.1.7 version, it's line 563 for Sockgen.c and line 77 for main.c) , 
the second argument is 1000 or 2000 (it's the timeout in milli-seconds). I 
suggested you to decrease this value to 50 in both files. 

I really thing that the second implementation of socketSelect is broken and 
doesn't even take this timeout in account which makes it faster than the 
first one. 

On the other hand, I would like to inform U that I have done a epk package of 
a light modified version of GoAhead Version 2.1.7 (It works as a thread and 
has some debugging asp pages for memory leaks ). 
I can send it to you if it helps and I will be pleased of your feedback.

For increasing performance, you can also act on your library build with the 
configtool by removing debugging flags, gdb stubs , asserts , tracing , 
thread list and stack checking. I had obtain a ratio of 6 by doing this for 
networking benchmarks.



On Tuesday 17 August 2004 15:25, Hao wrote:
> Hi, sebastien,
>
> Thanks for your information.
> I try your suggestion on my target. The problem of out of memory
> disappleared!!!
> The goAhead isn't crashed, but very very slowly when open a simple page.
> Do you have any experience about this ?
>
> Hao
>
> >Hello All,
> >In the past , (With GoAhead Webserver v 2.1.7) , I ran into the same kind
> > of problem with eCos.
> >After investigation this was caused by function "int socketSelect(int sid,
> >int timeout)" in file Sockgen.c (the one /* not WIN || CE || NW */ ) which
> >makes calls to balloc.
> >Using the another "socketSelect" (the one #if (defined (WIN) || defined
> > (CE) ) solved the memory leak/overflow. May be you should try this before
> > modifying balloc.c .
> >
> >Note : Now, I use a 64K balloc buffer without any problems.
> >
> >Hope this helps. Have a nice day.
> >
> >On Tuesday 17 August 2004 06:41, Hao wrote:
> >>Recently,  I modify balloc() in balloc.c of goAhead.
> >>I try to increase 64bytes at the line of  malloc() .  And the problem of
> >>out of memory disappeared.
> >>So , I think it's not the probelm caused by eCos.
> >>I think it's caused by goAhead somewhere that call balloc() and use
> >>wrong size.
> >>
> >>Now, in my target, goAhead still unstable just like you say. Then I use
> >>very simple web page instead of default web page(home.asp).
> >>It still unstable, but not crashed.
> >>But it can work very fine when I use 'lynx' instead of other browser(IE,
> >>mozilla..).
> >>I don't know what's the difference of behavior between lynx and other
> >>browser (IE,mozilla).
> >>
> >>Hope this information can help you something.
> >>
> >>Hao
> >>
> >>>Hello Hao!

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

Re: [ECOS] eCos + goAhead probelm

[Hao]

Hi, sebastien,

Thanks for your information.
I try your suggestion on my target. The problem of out of memory 
disappleared!!!
The goAhead isn't crashed, but very very slowly when open a simple page.
Do you have any experience about this ?

Hao


>Hello All,
>In the past , (With GoAhead Webserver v 2.1.7) , I ran into the same kind of 
>problem with eCos.
>After investigation this was caused by function "int socketSelect(int sid, 
>int timeout)" in file Sockgen.c (the one /* not WIN || CE || NW */ ) which 
>makes calls to balloc.
>Using the another "socketSelect" (the one #if (defined (WIN) || defined (CE) 
>) solved the memory leak/overflow. May be you should try this before 
>modifying balloc.c .
>
>Note : Now, I use a 64K balloc buffer without any problems.
>
>Hope this helps. Have a nice day.  
>
>On Tuesday 17 August 2004 06:41, Hao wrote:
>  
>
>>Recently,  I modify balloc() in balloc.c of goAhead.
>>I try to increase 64bytes at the line of  malloc() .  And the problem of
>>out of memory disappeared.
>>So , I think it's not the probelm caused by eCos.
>>I think it's caused by goAhead somewhere that call balloc() and use
>>wrong size.
>>
>>Now, in my target, goAhead still unstable just like you say. Then I use
>>very simple web page instead of default web page(home.asp).
>>It still unstable, but not crashed.
>>But it can work very fine when I use 'lynx' instead of other browser(IE,
>>mozilla..).
>>I don't know what's the difference of behavior between lynx and other
>>browser (IE,mozilla).
>>
>>Hope this information can help you something.
>>
>>Hao
>>
>>    
>>
>>>Hello Hao!
>>>
>>>      
>>>


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

Re: [ECOS] eCos + goAhead probelm

[sebastien Couret]

Hello All,
In the past , (With GoAhead Webserver v 2.1.7) , I ran into the same kind of
problem with eCos.
After investigation this was caused by function "int socketSelect(int sid,
int timeout)" in file Sockgen.c (the one /* not WIN || CE || NW */ ) which
makes calls to balloc.
Using the another "socketSelect" (the one #if (defined (WIN) || defined (CE)
) solved the memory leak/overflow. May be you should try this before
modifying balloc.c .

Note : Now, I use a 64K balloc buffer without any problems.

Hope this helps. Have a nice day.

On Tuesday 17 August 2004 06:41, Hao wrote:
> Recently,  I modify balloc() in balloc.c of goAhead.
> I try to increase 64bytes at the line of  malloc() .  And the problem of
> out of memory disappeared.
> So , I think it's not the probelm caused by eCos.
> I think it's caused by goAhead somewhere that call balloc() and use
> wrong size.
>
> Now, in my target, goAhead still unstable just like you say. Then I use
> very simple web page instead of default web page(home.asp).
> It still unstable, but not crashed.
> But it can work very fine when I use 'lynx' instead of other browser(IE,
> mozilla..).
> I don't know what's the difference of behavior between lynx and other
> browser (IE,mozilla).
>
> Hope this information can help you something.
>
> Hao
>
> >Hello Hao!
> >
> >I've got the same problem!
> >The target has eCos 2.0, and I use GoAhead 2.1.8 as well.
> >
> >I'm using an improved kernel, with:
> >CYGPKG_NET_MEM_USAGE set to 512K (instead of 256K)
> >where NET_MEMPOOL_SIZE is 5/8 of CYGPKG_NET_MEM_USAGE (instead of 1/4)
> >CYGPKG_NET_MAX_SOCKETS set to 192 (instead of 16)
> >
> >I increased 'bufsize' for bopen() to 192K, 256K, and more (instead of
> > 60K). I also tried to create a separate thread with a stack size of 80K
> > (and later 120K) and put the original main code inside ...
> >
> >... But in all cases the web server was unstable, and crashed after some
> >play...
> >
> > Any suggestion?
> >
> >b.t.w. When I load the default GoAhead web site (home.asp),
> >it doesn't handle with the left side menu applet (classes/treeapp.jar) -
> >it just leaves it black (no error message!)
> >The same applet works fine on Linux.
> >
> >Why does it behave like that?
> >Have you got this problem as well?
> >
> >Thanks in advance,
> >-- Amir
> >
> >---------------------------------------------------------------
> >Hao wrote:
> >
> >I build a target system that use eCos + goAhead web server.
> >When I run goAhead , and try to open a page from browser.
> >My target is failed at malloc() reutrn NULL.
> >But the ping function still work.
> >I set CYGNUM_MEMALLOC_FALLBACK_MALLOC_POOL_SIZE from 16384 to 1638400.
> >But, it doesn't help.
> >Then I try to use 'Simple variable block implementation' instead of
> >'Doug Lea's malloc implementatioin'.
> >It still don't work.
> >
> >My target system already pass all eCos tests include memalloc. And the
> >on board memory is
> >16MB. I think it's enough for eCos + goAhead.
> >
> >It seems goAhead eat all of memory. why ?
> >Does anybody has same problem as I ?
> >I use goAhead 2.18 + eCos (2004/06/24 got from CVS).
> >(I already try goAhead 2.14 ~ 2.18. All that have same problem)
> >
> >Regards
> >Hao

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

Re: [ECOS] eCos + goAhead probelm

[sebastien Couret]

Hello All,
In the past , (With GoAhead Webserver v 2.1.7) , I ran into the same kind of 
problem with eCos.
After investigation this was caused by function "int socketSelect(int sid, 
int timeout)" in file Sockgen.c (the one /* not WIN || CE || NW */ ) which 
makes calls to balloc.
Using the another "socketSelect" (the one #if (defined (WIN) || defined (CE) 
) solved the memory leak/overflow. May be you should try this before 
modifying balloc.c .

Note : Now, I use a 64K balloc buffer without any problems.

Hope this helps. Have a nice day.  

On Tuesday 17 August 2004 06:41, Hao wrote:
> Recently,  I modify balloc() in balloc.c of goAhead.
> I try to increase 64bytes at the line of  malloc() .  And the problem of
> out of memory disappeared.
> So , I think it's not the probelm caused by eCos.
> I think it's caused by goAhead somewhere that call balloc() and use
> wrong size.
>
> Now, in my target, goAhead still unstable just like you say. Then I use
> very simple web page instead of default web page(home.asp).
> It still unstable, but not crashed.
> But it can work very fine when I use 'lynx' instead of other browser(IE,
> mozilla..).
> I don't know what's the difference of behavior between lynx and other
> browser (IE,mozilla).
>
> Hope this information can help you something.
>
> Hao
>
> >Hello Hao!
> >
> >I've got the same problem!
> >The target has eCos 2.0, and I use GoAhead 2.1.8 as well.
> >
> >I'm using an improved kernel, with:
> >CYGPKG_NET_MEM_USAGE set to 512K (instead of 256K)
> >where NET_MEMPOOL_SIZE is 5/8 of CYGPKG_NET_MEM_USAGE (instead of 1/4)
> >CYGPKG_NET_MAX_SOCKETS set to 192 (instead of 16)
> >
> >I increased 'bufsize' for bopen() to 192K, 256K, and more (instead of
> > 60K). I also tried to create a separate thread with a stack size of 80K
> > (and later 120K) and put the original main code inside ...
> >
> >... But in all cases the web server was unstable, and crashed after some
> >play...
> >
> > Any suggestion?
> >
> >b.t.w. When I load the default GoAhead web site (home.asp),
> >it doesn't handle with the left side menu applet (classes/treeapp.jar) -
> >it just leaves it black (no error message!)
> >The same applet works fine on Linux.
> >
> >Why does it behave like that?
> >Have you got this problem as well?
> >
> >Thanks in advance,
> >-- Amir
> >
> >---------------------------------------------------------------
> >Hao wrote:
> >
> >I build a target system that use eCos + goAhead web server.
> >When I run goAhead , and try to open a page from browser.
> >My target is failed at malloc() reutrn NULL.
> >But the ping function still work.
> >I set CYGNUM_MEMALLOC_FALLBACK_MALLOC_POOL_SIZE from 16384 to 1638400.
> >But, it doesn't help.
> >Then I try to use 'Simple variable block implementation' instead of
> >'Doug Lea's malloc implementatioin'.
> >It still don't work.
> >
> >My target system already pass all eCos tests include memalloc. And the
> >on board memory is
> >16MB. I think it's enough for eCos + goAhead.
> >
> >It seems goAhead eat all of memory. why ?
> >Does anybody has same problem as I ?
> >I use goAhead 2.18 + eCos (2004/06/24 got from CVS).
> >(I already try goAhead 2.14 ~ 2.18. All that have same problem)
> >
> >Regards
> >Hao

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

Re: [ECOS] eCos + goAhead probelm

[Hou Qing]

Hi,

How about trying to grasp the TCP packets from lynx and IE transaction, and
find their difference?


-- 
HouQing

----- Original Message ----- 
From: "Hao" <hao@hao.dns2go.com>
To: <ecos-discuss@sources.redhat.com>
Sent: Tuesday, August 17, 2004 12:41 PM
Subject: Re: [ECOS] eCos + goAhead probelm


>
> Recently,  I modify balloc() in balloc.c of goAhead.
> I try to increase 64bytes at the line of  malloc() .  And the problem of
> out of memory disappeared.
> So , I think it's not the probelm caused by eCos.
> I think it's caused by goAhead somewhere that call balloc() and use
> wrong size.
>
> Now, in my target, goAhead still unstable just like you say. Then I use
> very simple web page instead of default web page(home.asp).
> It still unstable, but not crashed.
> But it can work very fine when I use 'lynx' instead of other browser(IE,
> mozilla..).
> I don't know what's the difference of behavior between lynx and other
> browser (IE,mozilla).
>
> Hope this information can help you something.
>
> Hao
>
>
> >Hello Hao!
> >
> >I've got the same problem!
> >The target has eCos 2.0, and I use GoAhead 2.1.8 as well.
> >
> >I'm using an improved kernel, with:
> >CYGPKG_NET_MEM_USAGE set to 512K (instead of 256K)
> >where NET_MEMPOOL_SIZE is 5/8 of CYGPKG_NET_MEM_USAGE (instead of 1/4)
> >CYGPKG_NET_MAX_SOCKETS set to 192 (instead of 16)
> >
> >I increased 'bufsize' for bopen() to 192K, 256K, and more (instead of
60K).
> >I also tried to create a separate thread with a stack size of 80K (and
> >later 120K) and put the original main code inside ...
> >
> >... But in all cases the web server was unstable, and crashed after some
> >play...
> >
> > Any suggestion?
> >
> >b.t.w. When I load the default GoAhead web site (home.asp),
> >it doesn't handle with the left side menu applet (classes/treeapp.jar) -
> >it just leaves it black (no error message!)
> >The same applet works fine on Linux.
> >
> >Why does it behave like that?
> >Have you got this problem as well?
> >
> >Thanks in advance,
> >-- Amir
> >
> >---------------------------------------------------------------
> >Hao wrote:
> >
> >I build a target system that use eCos + goAhead web server.
> >When I run goAhead , and try to open a page from browser.
> >My target is failed at malloc() reutrn NULL.
> >But the ping function still work.
> >I set CYGNUM_MEMALLOC_FALLBACK_MALLOC_POOL_SIZE from 16384 to 1638400.
> >But, it doesn't help.
> >Then I try to use 'Simple variable block implementation' instead of
> >'Doug Lea's malloc implementatioin'.
> >It still don't work.
> >
> >My target system already pass all eCos tests include memalloc. And the
> >on board memory is
> >16MB. I think it's enough for eCos + goAhead.
> >
> >It seems goAhead eat all of memory. why ?
> >Does anybody has same problem as I ?
> >I use goAhead 2.18 + eCos (2004/06/24 got from CVS).
> >(I already try goAhead 2.14 ~ 2.18. All that have same problem)
> >
> >Regards
> >Hao
> >
> >
> >
>
>
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
>


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

Re: [ECOS] eCos + goAhead probelm

[Hao]

I only change one line in the function balloc() in balloc.c

goAhead version: 218
orignal file (line 259 ~ 263)==>
            bp = (bType*) malloc(memSize);
            if (bp == NULL) {
                traceRaw(T("B: malloc failed\n"));
                return NULL;
            }

modified ==>
            bp = (bType*) malloc(memSize + 64);
            if (bp == NULL) {
                traceRaw(T("B: malloc failed\n"));
                return NULL;
            }

goAhead pre-allocate a lot of memory(about 60KB) at bopen() to build 
it's own memory pool.
When it need some memory, it will get it from it's own memory pool 
first, if the memory pool is empty,
then it call malloc() to get memory from eCos.
So, the balloc()  will check it's own memory pool first. if empty, then 
call malloc().
Because you increase the pool size of goAhead. So the balloc() never 
call malloc() to get new memory.

I try to put lots of debug message to trace the bug. Then I found eCos 
's memory pool information is overwirtten by goAhead.
So, I think the problem is goAhead use balloc() to get some memory, and 
the pre-allocate memory pool is already empty.
Then it call malloc() to get new memory from eCos.
After this, goAhead put too much data(more than the size it allocated) 
to this buffer, cause eCos 's memory pool information crashed.

Now, I don't have time to found real murderer in goAhead.
But hope it can give you a direction to solve your problem.

Hao


>After some more tests, I've got a stable web server when I call bopen()
>with a bufsize of 1.25M !
>(1M is still not enough - I could bring it to crash after a massive set
>of requests... )
>Does it make sense?
>
>What is the malloc size you're using for balloc's malloc() to solve the
>out of memory problem?
>
>Thanks,
>-- Amir
>
>-----Original Message-----
>From: ecos-discuss-owner@ecos.sourceware.org
>[mailto:ecos-discuss-owner@ecos.sourceware.org]On Behalf Of Hao
>Sent: Tuesday, August 17, 2004 6:41 AM
>To: ecos-discuss@sources.redhat.com
>Subject: Re: [ECOS] eCos + goAhead probelm
>
>
>
>Recently,  I modify balloc() in balloc.c of goAhead.
>I try to increase 64bytes at the line of  malloc() .  And the problem of 
>out of memory disappeared.
>So , I think it's not the probelm caused by eCos.
>I think it's caused by goAhead somewhere that call balloc() and use 
>wrong size.
>
>Now, in my target, goAhead still unstable just like you say. Then I use 
>very simple web page instead of default web page(home.asp).
>It still unstable, but not crashed.
>But it can work very fine when I use 'lynx' instead of other browser(IE, 
>mozilla..).
>I don't know what's the difference of behavior between lynx and other 
>browser (IE,mozilla).
>
>Hope this information can help you something.
>
>Hao
>
>
>  
>


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

Re: [ECOS] eCos + goAhead probelm

[Amir Yiron]

After some more tests, I've got a stable web server when I call bopen()
with a bufsize of 1.25M !
(1M is still not enough - I could bring it to crash after a massive set
of requests... )
Does it make sense?

What is the malloc size you're using for balloc's malloc() to solve the
out of memory problem?

Thanks,
-- Amir

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org]On Behalf Of Hao
Sent: Tuesday, August 17, 2004 6:41 AM
To: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] eCos + goAhead probelm



Recently,  I modify balloc() in balloc.c of goAhead.
I try to increase 64bytes at the line of  malloc() .  And the problem of 
out of memory disappeared.
So , I think it's not the probelm caused by eCos.
I think it's caused by goAhead somewhere that call balloc() and use 
wrong size.

Now, in my target, goAhead still unstable just like you say. Then I use 
very simple web page instead of default web page(home.asp).
It still unstable, but not crashed.
But it can work very fine when I use 'lynx' instead of other browser(IE, 
mozilla..).
I don't know what's the difference of behavior between lynx and other 
browser (IE,mozilla).

Hope this information can help you something.

Hao


>Hello Hao!
>
>I've got the same problem!
>The target has eCos 2.0, and I use GoAhead 2.1.8 as well.
>
>I'm using an improved kernel, with:
>CYGPKG_NET_MEM_USAGE set to 512K (instead of 256K)
>where NET_MEMPOOL_SIZE is 5/8 of CYGPKG_NET_MEM_USAGE (instead of 1/4)
>CYGPKG_NET_MAX_SOCKETS set to 192 (instead of 16)
>
>I increased 'bufsize' for bopen() to 192K, 256K, and more (instead of 60K).
>I also tried to create a separate thread with a stack size of 80K (and
>later 120K) and put the original main code inside ...
>
>... But in all cases the web server was unstable, and crashed after some
>play...
>
> Any suggestion?
>
>b.t.w. When I load the default GoAhead web site (home.asp),
>it doesn't handle with the left side menu applet (classes/treeapp.jar) -
>it just leaves it black (no error message!)
>The same applet works fine on Linux.
>
>Why does it behave like that?
>Have you got this problem as well?
>
>Thanks in advance,
>-- Amir
>
>---------------------------------------------------------------
>Hao wrote:
>
>I build a target system that use eCos + goAhead web server.
>When I run goAhead , and try to open a page from browser.
>My target is failed at malloc() reutrn NULL.
>But the ping function still work.
>I set CYGNUM_MEMALLOC_FALLBACK_MALLOC_POOL_SIZE from 16384 to 1638400.
>But, it doesn't help.
>Then I try to use 'Simple variable block implementation' instead of
>'Doug Lea's malloc implementatioin'.
>It still don't work.
>
>My target system already pass all eCos tests include memalloc. And the
>on board memory is
>16MB. I think it's enough for eCos + goAhead.
>
>It seems goAhead eat all of memory. why ?
>Does anybody has same problem as I ?
>I use goAhead 2.18 + eCos (2004/06/24 got from CVS).
>(I already try goAhead 2.14 ~ 2.18. All that have same problem)
>
>Regards
>Hao
>
>  
>


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


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

RE: [ECOS] eCos + goAhead probelm

[Amir Yiron]

After some more tests, I've got a stable web server when I call bopen()
with a bufsize of 1.25M !
(1M is still not enough - I could bring it to crash after a massive set
of requests... )
Does it make sense?

What is the malloc size you're

-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org]On Behalf Of Hao
Sent: Tuesday, August 17, 2004 6:41 AM
To: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] eCos + goAhead probelm



Recently,  I modify balloc() in balloc.c of goAhead.
I try to increase 64bytes at the line of  malloc() .  And the problem of 
out of memory disappeared.
So , I think it's not the probelm caused by eCos.
I think it's caused by goAhead somewhere that call balloc() and use 
wrong size.

Now, in my target, goAhead still unstable just like you say. Then I use 
very simple web page instead of default web page(home.asp).
It still unstable, but not crashed.
But it can work very fine when I use 'lynx' instead of other browser(IE, 
mozilla..).
I don't know what's the difference of behavior between lynx and other 
browser (IE,mozilla).

Hope this information can help you something.

Hao


>Hello Hao!
>
>I've got the same problem!
>The target has eCos 2.0, and I use GoAhead 2.1.8 as well.
>
>I'm using an improved kernel, with:
>CYGPKG_NET_MEM_USAGE set to 512K (instead of 256K)
>where NET_MEMPOOL_SIZE is 5/8 of CYGPKG_NET_MEM_USAGE (instead of 1/4)
>CYGPKG_NET_MAX_SOCKETS set to 192 (instead of 16)
>
>I increased 'bufsize' for bopen() to 192K, 256K, and more (instead of 60K).
>I also tried to create a separate thread with a stack size of 80K (and
>later 120K) and put the original main code inside ...
>
>... But in all cases the web server was unstable, and crashed after some
>play...
>
> Any suggestion?
>
>b.t.w. When I load the default GoAhead web site (home.asp),
>it doesn't handle with the left side menu applet (classes/treeapp.jar) -
>it just leaves it black (no error message!)
>The same applet works fine on Linux.
>
>Why does it behave like that?
>Have you got this problem as well?
>
>Thanks in advance,
>-- Amir
>
>---------------------------------------------------------------
>Hao wrote:
>
>I build a target system that use eCos + goAhead web server.
>When I run goAhead , and try to open a page from browser.
>My target is failed at malloc() reutrn NULL.
>But the ping function still work.
>I set CYGNUM_MEMALLOC_FALLBACK_MALLOC_POOL_SIZE from 16384 to 1638400.
>But, it doesn't help.
>Then I try to use 'Simple variable block implementation' instead of
>'Doug Lea's malloc implementatioin'.
>It still don't work.
>
>My target system already pass all eCos tests include memalloc. And the
>on board memory is
>16MB. I think it's enough for eCos + goAhead.
>
>It seems goAhead eat all of memory. why ?
>Does anybody has same problem as I ?
>I use goAhead 2.18 + eCos (2004/06/24 got from CVS).
>(I already try goAhead 2.14 ~ 2.18. All that have same problem)
>
>Regards
>Hao
>
>  
>


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


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

Re: [ECOS] eCos + goAhead probelm

[Hao]

Recently,  I modify balloc() in balloc.c of goAhead.
I try to increase 64bytes at the line of  malloc() .  And the problem of 
out of memory disappeared.
So , I think it's not the probelm caused by eCos.
I think it's caused by goAhead somewhere that call balloc() and use 
wrong size.

Now, in my target, goAhead still unstable just like you say. Then I use 
very simple web page instead of default web page(home.asp).
It still unstable, but not crashed.
But it can work very fine when I use 'lynx' instead of other browser(IE, 
mozilla..).
I don't know what's the difference of behavior between lynx and other 
browser (IE,mozilla).

Hope this information can help you something.

Hao


>Hello Hao!
>
>I've got the same problem!
>The target has eCos 2.0, and I use GoAhead 2.1.8 as well.
>
>I'm using an improved kernel, with:
>CYGPKG_NET_MEM_USAGE set to 512K (instead of 256K)
>where NET_MEMPOOL_SIZE is 5/8 of CYGPKG_NET_MEM_USAGE (instead of 1/4)
>CYGPKG_NET_MAX_SOCKETS set to 192 (instead of 16)
>
>I increased 'bufsize' for bopen() to 192K, 256K, and more (instead of 60K).
>I also tried to create a separate thread with a stack size of 80K (and
>later 120K) and put the original main code inside ...
>
>... But in all cases the web server was unstable, and crashed after some
>play...
>
> Any suggestion?
>
>b.t.w. When I load the default GoAhead web site (home.asp),
>it doesn't handle with the left side menu applet (classes/treeapp.jar) -
>it just leaves it black (no error message!)
>The same applet works fine on Linux.
>
>Why does it behave like that?
>Have you got this problem as well?
>
>Thanks in advance,
>-- Amir
>
>---------------------------------------------------------------
>Hao wrote:
>
>I build a target system that use eCos + goAhead web server.
>When I run goAhead , and try to open a page from browser.
>My target is failed at malloc() reutrn NULL.
>But the ping function still work.
>I set CYGNUM_MEMALLOC_FALLBACK_MALLOC_POOL_SIZE from 16384 to 1638400.
>But, it doesn't help.
>Then I try to use 'Simple variable block implementation' instead of
>'Doug Lea's malloc implementatioin'.
>It still don't work.
>
>My target system already pass all eCos tests include memalloc. And the
>on board memory is
>16MB. I think it's enough for eCos + goAhead.
>
>It seems goAhead eat all of memory. why ?
>Does anybody has same problem as I ?
>I use goAhead 2.18 + eCos (2004/06/24 got from CVS).
>(I already try goAhead 2.14 ~ 2.18. All that have same problem)
>
>Regards
>Hao
>
>  
>


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