Kumar Gala writes: > > For a kdump kernel, at least for 64-bit, the physical address has to > > be 32MB. There is no other choice, so there is no possibility of > > confusion. > > But how do you know a vmlinux image is for kdump or not?
By looking at the ELF headers -- either the first PT_LOAD segment or the .text section -- and seeing whether the start address is 0xc000000002000000 or not. > > For 85xx, would it be possible to have the kernel figure out what > > physical address it has been loaded at, and use that as the base > > address, rather than having the base address set at compile time? > > Yes, that is what CONFIG_RELOCATABLE is all about. Is there any reason to have that as an option, rather than just always doing that? > > That would solve my objection since it would mean that there would no > > longer be two things that had to be kept in sync. You could pass any > > value to wrapper/mkimage (subject to constraints such as it has to be > > a multiple of 256M) and it would work. That value could even come > > from a config option in the case where wrapper is invoked as part of > > the kernel build, but that config option shouldn't affect anything at > > all in the vmlinux. > > Ok, but I still think the issues exists when we config PHYSICAL_START > to non-zero and CONFIG_RELOCATABLE=n. Ideally we get set the phys > address the PHDR, but I'm not sure how to get the linker to do that. If we can do that then the wrapper script can dig it out and pass it to mkimage, which would solve the problem. Paul. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
