On 12/19/06, Vivek Goyal <[EMAIL PROTECTED]> wrote: > 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,
Hi Vivek! > 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(). RIght. That's what I meant, but I should have said the bzImage itself instead. Thanks for explaining! > At OLS Eric mentioned, that generally it it not loader's job to relocate > an image. I think that doing the relocation in the bzImage is perfectly fine, but I wouldn't say that it's bad that the loader performs the relocation. You can implement this in a zillion ways - I don't think that there is _one_ solution that is perfect for all uses. > > 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. Makeshift or not, that's the solution that people have been using until now. I don't mind the relocatable kernel code - I think it's a great idea - but I don't see why we need to break the old working vmlinux loading solution. > 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. Not if you load bzImages. But kdump users like me that load vmlinux images need CONFIG_PHYSICAL_START. So why remove it? > Are there any other usage where we have to use only vmlinux only and not > bzImage and that too compiled for a different address. Not sure I understand but my only concern is we should avoid breaking things. I think we should let people continue to use whatever method they've used so far and have an option to move over to relocatable kernels. This without breaking the existing vmlinux loading soltution. Thanks, / magnus _______________________________________________ fastboot mailing list fastboot@lists.osdl.org https://lists.osdl.org/mailman/listinfo/fastboot
