RE: [ECOS] an incompatibility between redboot/decompress.cv1.7,redboot/main.c v1.36, redboot/net/net_io.c v1.31 and ASSERT in a ROMbuild

["Stephen Goadhouse" <stephen dot goadhouse at adiengineering dot com>]

Okay, I reverted to an older compiler: gcc version 2.9-xscale-010413  (this
comes from RedHat via Intel).  I was using gcc version 2.96-xscale-010827
when the redboot build would not work.  I would like to use 2.95 as
recommended, but Intel never released a gcc version 2.95 for XScale.  I hope
v2.9 will suffice.  It appears to.  Thanks for all of your help in resolving
this.


> -----Original Message-----
> From: ecos-discuss-owner@sources.redhat.com
> [mailto:ecos-discuss-owner@sources.redhat.com]On Behalf Of Stephen
> Goadhouse
> Sent: Wednesday, September 25, 2002 4:29 PM
> To: Gary Thomas
> Cc: Mark Salter; eCos Discussion
> Subject: RE: [ECOS] an incompatibility between
> redboot/decompress.cv1.7,redboot/main.c v1.36, redboot/net/net_io.c
> v1.31 and ASSERT in a ROMbuild
>
>
>
> > On Wed, 2002-09-25 at 14:12, Stephen Goadhouse wrote:
> > >
> > >
> > > > >>>>> Stephen Goadhouse writes:
> > > >
> > > > > Sorry I did not include it.  Here it is:
> > > > > +$T0a0f:feffffff;0d:48d400c0;#1f+$T0a0f:feffffff;0d:48d400c0;#1f
> > > >
> > > > > The value 0x48d400c0 makes no sense to me.  This is an invalid
> > > > section of
> > > > > our memory map, so I don't expect it to be an address.
> > > >
> > > > How about 0xc000d448? ;-)
> > > > That's the SP address, BTW.
> > >
> > > Okay, that makes sense.  0xc000d448 is valid SDRAM.  RedBoot
> uses SDRAM
> > > starting at 0xc0000000.
> > >
> > > > The PC address of 0xfffffffe doesn't make any sense either.
> > Kinda points
> > > > to stack corruption.
> > >
> > > Yes, 0xfffffffe does not make any sense.
> > >
> > > > > If I retarget the build so that the ROM version starts at
> > Flash address
> > > > > 0x140000, I get the following GDB messages when I tried
> to bootup at
> > > > > 0x140000:
> > > >
> > > > > +$T0a0f:feffffff;0d:38d400c0;#1e+$T0a0f:feffffff;0d:38d400c0;#1e
> > > >
> > > > > Also, I discovered that decompress.c v1.6 is okay.  It's only
> > > > decompress.c
> > > > > v1.7 along with main.c v1.35 and net_io.c v1.31 that cause this
> > > > to happen.
> > > >
> > > > You'll also need an updated
> > services/compress/zlib/current/inflate.c v1.2
> > > > which has a related fix to go along with decompress.c.
> > >
> > > Yes, I have inflate.c v1.2 and it seems to compile into my
> > build just fine.
> > > The other updated files were redboot/current/src/load.c v1.28 and
> > > ecos/packages/hal/common/current/include/hal_if.h v1.17.
> >
> > What tools are you using?  I've built and run RedBoot from ROM with
> > these latest files using GCC 2.95.3 with no problems.
> >
> > --
> > ------------------------------------------------------------
> > Gary Thomas                  |
> > eCosCentric, Ltd.            |
> > +1 (970) 229-1963            |  eCos & RedBoot experts
> > gthomas@ecoscentric.com      |
> > http://www.ecoscentric.com/  |
> > ------------------------------------------------------------
>
> I'm using xscale-elf-gcc tools supplied by Intel.  This is
> version 010827 of
> their tools, which uses gcc v2.96. Running "xscale-elf-gcc --version",
> produces: 2.96-xscale-010827
>
> Are you building with CYGPKG_INFRA_DEBUG set to a 1?  That is what crashes
> for me.
>
> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> _/  Stephen Goadhouse                 Work: (434) 978-2888 x6 _/
> _/  Staff Engineer       stephen.goadhouse@adiengineering.com _/
> _/  ADI Engineering             http://www.adiengineering.com _/
> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>
>
>
>
>
> --
> 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