After Uncompresseing Linux..., what's next

[Prakash kanthi]

I do have xilinx tools and i am working with their V2P
product. I completely understands what you are said.
But the problem is, right after the uncompression and
cpy to 0x00000000, i loose total control because i
don't have any clue what is getting executed.

And also, i have my boot monitor code at 0x00000000,
before uncompress process overwrites it. I see that
some of that code is getting executed after jump to
0x0. I reason i am overwriting 0x0 is because, i only
have 8MB RAM.

thanks,
Prakash


--- Gary Thomas <gary at chez-thomas.org> wrote:
> On Fri, 2002-12-20 at 09:14, Prakash kanthi wrote:
> >
> > Folks,
> >
> > I just wanted to provide more info on my env. I
> have
> > PPC405 based board with no network support forcing
> me
> > to use zImage.initrd.elf.
> >
> > Can you suggest more on my problem described
> below? I
> > saw the memory values at 0x00000000 onwards after
> > uncompressing linux and they have changed. But
> when
> > the control jumps to 0x0, my board hangs. I see
> that
> > ESR is showing a value of 0x80000000, meaning
> either
> > illegal instruction or Machine Check.
> >
> > Can you tell what's going on? What happens next
> after
> > uncompressing? I am thinking it executes
> start_kernel
> > function which calls lock_kernel. Let me know if i
> am
> > wrong.
> >
>
> A *lot* happens, even before the first "printk"!
>
> At the point where the kernel is being started, all
> that
> has happened is the basic image has been loaded to
> low
> memory.  The kernel then needs to set up the memory
> management
> (to map things the way it wants to), then perform
> quite a
> lot of initialization, then start up the generic
> kernel
> which will then do things like initialize devices,
> etc.
>
> Since you just say you have a board (and don't name
> it),
> I assume that you are porting Linux yourself.  In
> this case,
> you'll either need some tools (like the BDI already
> mentioned)
> or a lot of patience.  You'll need to look at how
> the kernel
> is trying to do its work, at least to the point
> where you can
> get to the first "printk" (which comes during the
> memory 'find'
> sequence on the PPC in arch/ppc/mm/ppc_mmu.c).  Once
> you get
> this far, and printk is working, you can then move
> on and find
> out what else needs to be done.
>
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/