using malloc in boot code

does it make sense to allocate memory dynamically in bootcode? i need to
uncompress the image before the os is started, and the zlib routine will
call malloc. my programming is failing in malloc and i believe that i'm not
initializing the heap. i'm using diab 4.2 compiler/ass/linker on ppc 860. i
should be linking the memory map correct w/ stack, heap, etc...any help?
thanks in advance

"Joe Bruin" <clarencechung@earthlink.net> wrote in message
news:Fo7fc.9590$A_4.6889@newsread1.news.pas.earthlink.net...
> does it make sense to allocate memory dynamically in bootcode? i need to
> uncompress the image before the os is started, and the zlib routine will
> call malloc. my programming is failing in malloc and i believe that i'm
not
> initializing the heap. i'm using diab 4.2 compiler/ass/linker on ppc 860.
i
> should be linking the memory map correct w/ stack, heap, etc...any help?
> thanks in advance
>

I'm guessing that the C library hasn't yet been initialized, so the malloc
routine hasn't really got any idea where to put your malloc'd block of
memory.

Since you're probably going to go through all the OS/application level
initialization after uncompressing the image, why not just grab a block of
memory that you know to be in the heap area for use as your buffer? The
final system need never know that this memory was used before the OS
started.

Remember... use defined constants for base and size, no magic numbers hidden
in the code that will bite you when the system layout changes ;)

Peter.

Joe Bruin wrote:
> 
> does it make sense to allocate memory dynamically in bootcode? i
> need to uncompress the image before the os is started, and the
> zlib routine will call malloc. my programming is failing in
> malloc and i believe that i'm not initializing the heap. i'm
> using diab 4.2 compiler/ass/linker on ppc 860. i should be
> linking the memory map correct w/ stack, heap, etc...any help?

That depends entirely on how malloc functions.  It obviously needs
memory to manage, and that cannot be created out of thin air.  For
most systems I would expect such usage to fail.  If you can
allocate the space on the stack, you would have a chance.

BTW it is conventional, in English, to capitalize the word "I" and
the initial letters of sentences.  This also greatly improves
readability.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

Joe Bruin <clarencechung@earthlink.net> wrote:
> does it make sense to allocate memory dynamically in bootcode? 

Generally, no, it doesn't.  Not if it's actually *boot* code.  A fancy
graphical "Wow -- that's cute!" targetting boot manager for PCs might
see a need to, but that's not generally what most of us here would
call "boot" code.

> i need to uncompress the image before the os is started, and the
> zlib routine will call malloc. 

I'm pretty sure that it doesn't really have to do that.  You'll have
to dig a bit deeper into the implementation of the deflate algorithm,
i.e. you won't get to blindly just use zlib as-is.  But that doesn't
mean it can't be done.  Linux has been doing it for years, so you can
probably learn a bit from that.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

"CodeSprite" <pmaloy@codesprite.com> wrote in message news:<407d26e0$0$79528$812600b3@news.nntpaccess.com>...
> "Joe Bruin" <clarencechung@earthlink.net> wrote in message
> news:Fo7fc.9590$A_4.6889@newsread1.news.pas.earthlink.net...
> > does it make sense to allocate memory dynamically in bootcode? i need to
> > uncompress the image before the os is started, and the zlib routine will
> > call malloc. my programming is failing in malloc and i believe that i'm
>  not
> > initializing the heap. i'm using diab 4.2 compiler/ass/linker on ppc 860.
>  i
> > should be linking the memory map correct w/ stack, heap, etc...any help?
> > thanks in advance
> >
> 
> I'm guessing that the C library hasn't yet been initialized, so the malloc
> routine hasn't really got any idea where to put your malloc'd block of
> memory.
> 

that's what i'm guessing too, but not sure how to initialize the C
library, any idea? pointers for me to look at?


> Since you're probably going to go through all the OS/application level
> initialization after uncompressing the image, why not just grab a block of
> memory that you know to be in the heap area for use as your buffer? The
> final system need never know that this memory was used before the OS
> started.
> 

that would work, except i'm the routines i'm using involved quite a
few call of memory allocation, and plus if there loops, etc, can't
really sure how many it'll require.

> Remember... use defined constants for base and size, no magic numbers hidden
> in the code that will bite you when the system layout changes ;)
> 
> Peter.

"CodeSprite" <pmaloy@codesprite.com> writes:

> Since you're probably going to go through all the OS/application level
> initialization after uncompressing the image, why not just grab a block of
> memory that you know to be in the heap area for use as your buffer?

We had a trivial boot time "alloc" function that merely incremented a
pointer.  Once the heap was initialized, based upon the current
pointer position, this alloc function wasn't used anymore.

We probably could have dispensed with the standard heap altogether,
except for a large base of existing code and not enough willpower to
rewrite it all.

-- 
Darin Johnson
    "Particle Man, Particle Man, doing the things a particle can"

chung_clarence@yahoo.com (googler) writes:

> that's what i'm guessing too, but not sure how to initialize the C
> library, any idea? pointers for me to look at?

Every C library is different.  You'd have to say the name and version
of yours.  But you should never need to use malloc() in bootup code,
unless something is very very weird.

> that would work, except i'm the routines i'm using involved quite a
> few call of memory allocation, and plus if there loops, etc, can't
> really sure how many it'll require.

Then change those calls to something else.  You said "zlib" earlier,
so just look at "zlib.h" and search for "alloc" in the comments.  Zlib
is already set up to use custom memory allocation routines.

-- 
Darin Johnson
    "Look here.  There's a crop circle in my ficus!"  -- The Tick