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 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 case
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_MULTIPLAT
On Tuesday 22 April 2014 11:53:25 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 Kconf
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
> > t
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
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,
> there
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 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 mechanism
> > 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_m
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
>> > bootloaders want to support booting Image files or vmlinux directly,
>> > then we should support that including an
On 17/04/14 22:35, Russell King - ARM Linux 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 the 2MB discussed here. Changin
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?
>
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
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
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
> >> > bootloaders want to support booting Image
On Tue, Apr 22, 2014 at 10:53:07AM +0100, Daniel Thompson wrote:
> On 17/04/14 22:35, Russell King - ARM Linux 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
On Thu, Apr 17, 2014 at 09:53:23PM -0500, Rob Herring wrote:
> On Thu, Apr 17, 2014 at 4:35 PM, Russell King - ARM Linux
> wrote:
> > No. You simply can't eliminate any of the above - each one has been
> > negotiated through quite an amount of discussion with relevant parties
> > and/or due to te
On Thu, 17 Apr 2014, Rob Herring wrote:
> Here's a simple test of what I was trying to point out. I took a
> working kernel with TEXT_OFFSET of 0x8000 and booted it on QEMU using
> the "virt" machine which RAM normally starts at 0x4000. Then
> varying the RAM base, I get these results:
>
> 0x
On Thu, Apr 17, 2014 at 4:35 PM, Russell King - ARM Linux
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 the 2MB discusse
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 the 2MB discussed here. Changing the TEXT_OFFSET is a hack that
> doesn't scale.
You m
On Thu, Apr 17, 2014 at 3:16 PM, Russell King - ARM Linux
wrote:
> On Thu, Apr 17, 2014 at 04:06:16PM -0400, Nicolas Pitre wrote:
>> On Thu, 17 Apr 2014, Rob Herring wrote:
>> > Better yet, we should adopt the arm64 Image header which has this and
>> > other fields for arm Image files. We're going
On 17 April 2014 21:49, Christopher Covington wrote:
> In any case, when performing boot debugging I'm not as interested in
> traditional self-hosted bootloaders as I am external loaders, like those built
> into software models (QEMU, Fast Models, etc.) or available to JTAG scripts
> (OpenOCD, Tra
On 04/17/2014 03:48 PM, Nicolas Pitre wrote:
> On Thu, 17 Apr 2014, 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
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
On Thu, Apr 17, 2014 at 04:06:16PM -0400, Nicolas Pitre wrote:
> On Thu, 17 Apr 2014, Rob Herring wrote:
> > Better yet, we should adopt the arm64 Image header which has this and
> > other fields for arm Image files. We're going to have to deal with raw
> > Image (and Image.gz) in bootloaders for a
On Thu, 17 Apr 2014, Rob Herring wrote:
> On Wed, Apr 16, 2014 at 2: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
>
> [snip]
>
> >> Or could we patch up the linker script to set zero-b
On Thu, 17 Apr 2014, 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 JTAG scripts
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 JTAG scripts or simulator
>> equivalent. That's another aspect of the ELF-
On Wed, Apr 16, 2014 at 2: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
[snip]
>> Or could we patch up the linker script to set zero-based ELF load
>> memory addresses (LMAs) [4] so that the physi
On Wed, 16 Apr 2014, Christopher Covington wrote:
> On 04/16/2014 03:14 PM, Nicolas Pitre wrote:
> > On Wed, 16 Apr 2014, Christopher Covington wrote:
> >
> >> It seems to me that if external/uncompressed image loaders could query the
> >> text offset in a straightforward manner, variance between
On Wed, Apr 16, 2014 at 10:36:11PM +0100, Peter Maydell wrote:
> On 16 April 2014 22:08, Christopher Covington 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 offset is g
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 16 April 2014 22:08, Christopher Covington 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 offset is guaranteed not to
>> change i.e. it can be loaded at about any offset as
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 observe
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.
> >
> >
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 regression turned out to be fault in the JTAG boot to
37 matches
Mail list logo
