linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Paul Mackerras <paulus@samba.org>
To: Kumar Gala <galak@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 01/11] [POWERPC] bootwrapper: Allow specifying of image physical offset
Date: Thu, 3 Apr 2008 17:34:07 +1100	[thread overview]
Message-ID: <18420.31327.633359.619200@cargo.ozlabs.ibm.com> (raw)
In-Reply-To: <0F53B076-0A94-4A2D-8D9A-ED507B53ABE6@kernel.crashing.org>

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.

  parent reply	other threads:[~2008-04-03  6:34 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-01  2:08 [PATCH 00/11] ppc32 mm init clean and 85xx kernel reloc Kumar Gala
2008-04-01  2:08 ` [PATCH 01/11] [POWERPC] bootwrapper: Allow specifying of image physical offset Kumar Gala
2008-04-01  2:08   ` [PATCH 02/11] [POWERPC] Remove Kconfig option BOOT_LOAD Kumar Gala
2008-04-01  2:08     ` [PATCH 03/11] [POWERPC] Provide access to arch/powerpc include path on ppc64 Kumar Gala
2008-04-01  2:08       ` [PATCH 04/11 v2] [POWERPC] Remove and replace uses of PPC_MEMSTART with memstart_addr Kumar Gala
2008-04-01  2:08         ` [PATCH 05/11] [POWERPC] Introduce lowmem_end_addr to distiguish from total_lowmem Kumar Gala
2008-04-01  2:08           ` [PATCH 06/11] [POWERPC] 85xx: Cleanup TLB initialization Kumar Gala
2008-04-01  2:08             ` [PATCH 07/11] [POWERPC] Use lowmem_end_addr to limit lmb allocations on ppc32 Kumar Gala
2008-04-01  2:08               ` [PATCH 08/11 v2] [POWERPC] Rename __initial_memory_limit to __initial_memory_limit_addr Kumar Gala
2008-04-01  2:08                 ` [PATCH 09/11] [POWERPC] Clean up some linker and symbol usage Kumar Gala
2008-04-01  2:08                   ` [PATCH 10/11] [POWERPC] Move phys_addr_t definition into asm/types.h Kumar Gala
2008-04-01  2:08                     ` [PATCH 11/11] [POWERPC] 85xx: Add support for relocatble kernel (and booting at non-zero) Kumar Gala
2008-04-01 10:50         ` [PATCH 04/11 v2] [POWERPC] Remove and replace uses of PPC_MEMSTART with memstart_addr Paul Mackerras
2008-04-01 21:49           ` Kumar Gala
2008-04-01 10:08   ` [PATCH 01/11] [POWERPC] bootwrapper: Allow specifying of image physical offset Paul Mackerras
2008-04-01 21:52     ` Kumar Gala
2008-04-02  0:58       ` Paul Mackerras
2008-04-02 13:14         ` Kumar Gala
2008-04-02 17:03           ` Segher Boessenkool
2008-04-03  6:34           ` Paul Mackerras [this message]
2008-04-03  6:47             ` Kumar Gala
2008-04-10  2:25               ` Paul Mackerras
2008-04-10 10:53                 ` Kumar Gala

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=18420.31327.633359.619200@cargo.ozlabs.ibm.com \
    --to=paulus@samba.org \
    --cc=galak@kernel.crashing.org \
    --cc=linuxppc-dev@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).