On Tue, Dec 19, 2006 at 06:04:16PM +0900, Magnus Damm wrote:
> >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?
>
Hi Magnus,
I think you are the only user. Why can't you load bzImage for second kernel?
I think one of the reasons it was removed because it conflicted with the
relocatable kernel. For example, if somebody compiles the kernel for 4MB
physical location, and grub loads the kernel at 1MB. Then what do we do?
Run the kernel from 1MB location or decompress the kernel to 4MB and run
from there?
If we decompress to 4MB and run from there then the whole purpose of
relocatable kernel is lost. Because relocatable kernel means that it runs
from the location where it has been loaded at.
If we don't run from 4MB, then CONFIG_PHYSICAL_START has kind of lost
its significance and is meaningful only for vmlinux.
> >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.
>
I agree that we should not be breaking things. Let me look into it
deeper and let me see if I can write a clean patch without making the
logic too obscure. I think we can adopt following policy.
#ifndef CONFIG_RELOCATABLE
Decompress the kernel to CONFIG_PHYSICAL_START location and run
from there. Make sure CONFIG_PHYSICAL_START meets the alignment
restriction imposed by CONFIG_PHYSICAL_ALIGN.
#else
Run the bzImage from where it has been loaded and perform the
relocations. Align it according to CONFIG_PHYSICAL_ALIGN values.
#endif
Thanks
Vivek
_______________________________________________
fastboot mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/fastboot
