On Mon, Dec 18, 2006 at 10:23:55AM +0900, Magnus Damm wrote: > Hi guys, > > [CC Vivek] > > On 12/18/06, Horms <[EMAIL PROTECTED]> wrote: > >On Fri, Dec 15, 2006 at 11:16:39AM -0500, Don Zickus wrote: > >> > Kexec Kexec Kexec Kexec Kdump* > >Kdump** > >> > bzImage bzImage vmlinux vmlinux bzImage > >bzImage > >> > -> -> -> -> -> > >-> > >> > Kernel Arch bzImage vmlinux vmlinux bzImage vmlinux > >bzImage > >> > > >> > 2.6.18 i386 PASS PASS PASS PASS PASS > >> > 2.6.18 i386-pae PASS PASS PASS PASS PASS > >> > 2.6.18 x86_64 PASS PASS PASS PASS PASS > >> > > >> > 2.6.19 i386 PASS PASS PASS PASS PASS > >> > 2.6.19 i386-pae PASS PASS PASS PASS PASS > >> > 2.6.19 x86_64 PASS PASS PASS PASS PASS > >> > > >> > 2.6.20-rc1 i386 PASS PASS PASS PASS FAIL*** > >PASS > >> > 2.6.20-rc1 i386-pae PASS PASS PASS PASS FAIL*** > >PASS > >> > 2.6.20-rc1 x86_64 PASS PASS PASS PASS PASS > >> > > >> > xen-3.0.4-rc1 i386 PASS PASS PASS PASS PASS > >> > xen-3.0.4-rc1 i386-pae PASS PASS PASS PASS PASS > >> > xen-3.0.4-rc1 x86_64 PASS PASS PASS PASS PASS > >> > > >> > * Crash kernel compiled with CONFIG_PHYSICAL_START=0x2000000 > >> > ** Crash kernel compiled with CONFIG_RELOCATABLE=y > >> > *** Kernel issue: CONFIG_PHYSICAL_START option removed from 2.6.20-rc1 > >> > >> Vivek was able to get the i386 relocatable code into 2.6.20 which > >involved > >> removing the CONFIG_PHYSICAL_START and replacing it with > >> CONFIG_PHYSICAL_ALIGN. So now if you guys include the following options > >> into the base kernel > > > >It also involved a regression, as the results above show :( > > Right, kdumping into a vmlinux does not work in 2.6.20-rc1 but using > a relocatable bzImage works fine. I'm not sure exactly how the > relocatable code that got merged works, but I seem to remember that > the relocation is done in the bzImage loader. Any comments Vivek? >
Hi Magnus, No. relocations are not done by the bzImage loader. It bzImage itself performs its relocation. It first decompresses itself and then performs all the relocations (arch/i386/boot/compressed/head.S) and then it jumps to the startup_32(). At OLS Eric mentioned, that generally it it not loader's job to relocate an image. > I guess the easiest solution is to re-add the CONFIG_PHYS_START option > so people can continue to use the same scripts and booting strategies > as before. Another option is to fix up kexec-tools to do the linking > as my relocatable kernel prototype did, but I'm not sure how well that > would co-exist with the existing relocatable kernel support. > I am just thinking that why do we need a relocatable vmlinux. Using vmlinux compiled for a different address was an makeshift arrangement for kdump purposes as bzImage was not relocatable and same bzImage could not be used for capturing the dump. Now with relocatable bzImage, need for having a separate vmlinux compiled for a differnt address is gone. So we don't need CONFIG_PHYSICAL_START option at least for the kdump purposes. Are there any other usage where we have to use only vmlinux only and not bzImage and that too compiled for a different address. Thanks Vivek _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
