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: Wed, 2 Apr 2008 11:58:03 +1100 [thread overview]
Message-ID: <18418.55835.338209.611273@cargo.ozlabs.ibm.com> (raw)
In-Reply-To: <5DBEA342-7674-414B-A666-B8FBEED34814@kernel.crashing.org>
Kumar Gala writes:
> Hmm, need to think about that. But my initial reaction is two fold.
> One I don't think this information would be around and two don't we
> already have this problem with a kdump kernel?
I'm just concerned that we have two things that have to match up - the
compiled-in physical address that the kernel assumes it is running at,
and the physical address where it is actually loaded. While those two
things were both always 0 for embedded processors, there wasn't a
problem, but now we can have a situation where a kernel binary has to
be loaded at some nonzero address to work correctly, but there is no
way to work out what that address is for an existing vmlinux binary.
Or have I missed something?
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.
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?
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.
Paul.
next prev parent reply other threads:[~2008-04-02 0:58 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 [this message]
2008-04-02 13:14 ` Kumar Gala
2008-04-02 17:03 ` Segher Boessenkool
2008-04-03 6:34 ` Paul Mackerras
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=18418.55835.338209.611273@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).