On 12/21/06, Magnus Damm <[EMAIL PROTECTED]> wrote:
> On 12/22/06, Larry Brigman <[EMAIL PROTECTED]> wrote:
> > Trying to debug a problem and my understanding is dim.
> >
> > Is the entry that is presented to the kernel equal to
> > the entry that one would get from readelf -h on a vmlinux compiled with
> > a physical offset?
>
> On a vmlinux (2.6.19 to be more exact):
>
> So you have the startup_32 symbol in the kernel that you want to boot.
> It should be in arch/i386/kernel/head.S.
>
> Then you have the linker script in arch/i386/kernel.vmlinux.lds.S
> which sets ENTRY() to phys_startup_32 which is startup_32 -
> PAGE_OFFSET ie the physical address of startup_32.
>
> Linux-2.6.19 is known to work to boot into on i386. Use that as a
> secondary kernel to begin with and when you have that working you can
> try booting older kernels. I have a small working serial console
> config if you are interested.
>
> The kernel entry point is not everything though. You have purgatory
> which is a glue layer in between the kernels. It is contained in the
> kexec-tool and loaded and linked during runtime.
>
> So the entry point you will see in kexec (in your first kernel) will
> most likely be the entry point of purgatory. It took me a while to
> figure that out and now I have mixed feelings about purgatory... =)
>
But if the address kexec provides as the entry is not (within)
( entry < crashk_res.start ) || (entry > crashk_res.end)
then nothing gets loaded (kernel/kexec.c::kimage_crash_alloc() ).
Doesn't mater if
this code is in purgatory or not.
_______________________________________________
fastboot mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/fastboot
