On 17/04/14 21:35, Jason Gunthorpe wrote:
The above is useful for loading the raw uncompressed Image without
carrying the full ELF baggage.
What exactly is the full ELF baggage? Aren't there existing mechanisms to
omit
debugging symbols, for example, if size is of concern?
FWIW, it is a
On 22/04/14 11:40, Russell King - ARM Linux wrote:
On Tue, Apr 22, 2014 at 11:26:53AM +0100, Daniel Thompson wrote:
On 18/04/14 05:34, Nicolas Pitre wrote:
I'm not suggesting to break anything or changing existing platforms,
but how do we improve the Image format in a compatible way. If
On 04/17/2014 10:35 PM, Jason Gunthorpe wrote:
On Thu, Apr 17, 2014 at 02:33:43PM -0400, Christopher Covington wrote:
On 04/16/2014 07:21 PM, Nicolas Pitre wrote:
On Wed, 16 Apr 2014, Christopher Covington wrote:
Thank you for the suggestion. This approach also came to mind, but it would
index 8756e4b..551e971 100644
+++ b/arch/arm/include/asm/memory.h
@@ -350,7 +350,7 @@ static inline __deprecated void *bus_to_virt(unsigned
long x)
#define virt_addr_valid(kaddr) (((unsigned long)(kaddr) = PAGE_OFFSET
(unsigned long)(kaddr) (unsigned long)high_memory) \
On Tue, Apr 22, 2014 at 10:44:14AM +0100, Daniel Thompson wrote:
On 17/04/14 21:35, Jason Gunthorpe wrote:
The above is useful for loading the raw uncompressed Image without
carrying the full ELF baggage.
What exactly is the full ELF baggage? Aren't there existing mechanisms to
omit
On Tue, Apr 22, 2014 at 04:50:12PM +0200, Michal Simek wrote:
On 04/17/2014 10:35 PM, Jason Gunthorpe wrote:
+/* If we have a known, fixed physical load address then set LOAD_OFFSET
+ and generate an ELF that has the physical load address in the program
+ headers. */
+#ifndef
On Tue, Apr 22, 2014 at 06:11:42PM +0100, Russell King - ARM Linux wrote:
Put another way, if your platform is part of the multi-platform kernel
then you are *excluded* from being able to use this... unless you hack
the Kconfig, and then also provide a constant value for PHYS_OFFSET,
thereby
On Tue, 22 Apr 2014, Jason Gunthorpe wrote:
On Tue, Apr 22, 2014 at 10:44:14AM +0100, Daniel Thompson wrote:
On 17/04/14 21:35, Jason Gunthorpe wrote:
The above is useful for loading the raw uncompressed Image without
carrying the full ELF baggage.
What exactly is the full ELF
On Tue, Apr 22, 2014 at 11:53:25AM -0600, Jason Gunthorpe wrote:
On Tue, Apr 22, 2014 at 06:11:42PM +0100, Russell King - ARM Linux wrote:
Put another way, if your platform is part of the multi-platform kernel
then you are *excluded* from being able to use this... unless you hack
the
On Tue, Apr 22, 2014 at 01:55:16PM -0400, Nicolas Pitre wrote:
We do not want people in general to have PLAT_PHYS_OFFSET defined and
CONFIG_ARM_PATCH_PHYS_VIRT disabled. In fact a huge effort has been
deployed to go the exact opposite way over the last few years.
There are special cases
On Tue, Apr 22, 2014 at 08:32:10PM +0200, Arnd Bergmann wrote:
@@ -1943,6 +1953,7 @@ config DEPRECATED_PARAM_STRUCT
# TEXT and BSS so we preserve their values in the config files.
config ZBOOT_ROM_TEXT
hex Compressed ROM boot loader base address
+ depends on BROKEN_MULTIPLATFORM
On Tuesday 22 April 2014 19:38:55 Russell King - ARM Linux wrote:
On Tue, Apr 22, 2014 at 08:32:10PM +0200, Arnd Bergmann wrote:
@@ -1943,6 +1953,7 @@ config DEPRECATED_PARAM_STRUCT
# TEXT and BSS so we preserve their values in the config files.
config ZBOOT_ROM_TEXT
hex
On Wed, Apr 16, 2014 at 2:14 PM, Nicolas Pitre nicolas.pi...@linaro.org wrote:
On Wed, 16 Apr 2014, Christopher Covington wrote:
On 04/15/2014 06:44 AM, Daniel Thompson wrote:
Hi Folks
[snip]
Or could we patch up the linker script to set zero-based ELF load
memory addresses (LMAs) [4] so
On Thu, Apr 17, 2014 at 02:33:43PM -0400, Christopher Covington wrote:
On 04/16/2014 07:21 PM, Nicolas Pitre wrote:
On Wed, 16 Apr 2014, Christopher Covington wrote:
Thank you for the suggestion. This approach also came to mind, but it would
require new documentation and tooling in the
On Thu, Apr 17, 2014 at 4:35 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Thu, Apr 17, 2014 at 04:18:45PM -0500, Rob Herring wrote:
The problem here is more than just the TEXT_OFFSET changed. From what
I've heard, there are some QC chips which need much more reserved RAM
than
On Wed, 16 Apr 2014, Christopher Covington wrote:
On 04/15/2014 06:44 AM, Daniel Thompson wrote:
Hi Folks
I've just been rebasing some of my development branches against v3.15rc1
and observed some boot regressions due to TEXT_OFFSET changing from
0x8000 to 0x208000.
Now the boot
Hi Nicolas,
Thanks for your response.
On 04/16/2014 03:14 PM, Nicolas Pitre wrote:
On Wed, 16 Apr 2014, Christopher Covington wrote:
On 04/15/2014 06:44 AM, Daniel Thompson wrote:
Hi Folks
I've just been rebasing some of my development branches against v3.15rc1
and observed some boot
On Wed, Apr 16, 2014 at 05:08:35PM -0400, Christopher Covington wrote:
What I meant to ask about was variance from one kernel version and build to
the next, given a single platform. Platform-to-platform variation can probably
be abstracted where needed by the scripts controlling the external
On Wed, Apr 16, 2014 at 10:36:11PM +0100, Peter Maydell wrote:
On 16 April 2014 22:08, Christopher Covington c...@codeaurora.org wrote:
On 04/16/2014 03:14 PM, Nicolas Pitre wrote:
But both QEMU and the boot-wrapper should deal with zImage. That's the
only image format with documented load
19 matches
Mail list logo
