"Magnus Damm" <[EMAIL PROTECTED]> writes: > On 8/2/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote: >> "Magnus Damm" <[EMAIL PROTECTED]> writes: >> > Eric, could you please list the advantages of your run-time relocation >> > code over my incomplete relocate-in-userspace prototype posted to >> > fastboot a few weeks ago? >> >> If you watch an architecture evolve one thing you will notice is that >> the kinds of relocations keep growing. An ever growing list of things >> to for the bootloader to do is a pain. Especially when bootloaders >> generally need to be as simple and as fixed as possible because bootloaders >> are not something you generally want to update. > > I agree that updating bootloaders is something you want to avoid. I'm > not however sure that I would call kexec-tools a bootloader...
On the truly insane possibilities. It is actually possible to load a relocated bzImage. run setup16.S below 1M and have it jump to the kernel at any address below 4G. >> Beyond that if you look at head.S the code to process the relocations >> (after I have finished post processing them at build time) is 9 instructions. >> Which is absolutely trivial, at least for now. > > Yeah, but the 33 patches are touching more than 9 instructions. =) True. I at of that is general clean ups to allow the kernel to be relocated though. Not to actually perform the relocation. > One binary to rule them all... If that is true, is there any simple > way then to extract vmlinux from the bzImage? Unfortunately the process is a little lossy :( So that still means you still need the vmlinux to get the debug symbols. Eric _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
