On Fri, Nov 11, 2016 at 09:23:43PM +, David Woodhouse wrote:
> On Fri, 2016-11-11 at 21:05 +0000, Russell King - ARM Linux wrote:
> >
> > 18:59:38.782818 IP (tos 0x0, ttl 52, id 35619, offset 0, flags [DF], proto
> > TCP (6), length 60)
> > 84.xx.xxx.196.61236
On Fri, Nov 11, 2016 at 09:23:43PM +, David Woodhouse wrote:
> It's also *fairly* unlikely that the kernel in the guest has developed
> a bug and isn't setting gso_size sanely. I'm more inclined to suspect
> that qemu isn't properly emulating those bits. But at first glance at
> the code, it lo
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 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.
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 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'v
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 pa
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 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 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 Wed, Aug 14, 2013 at 01:44:44PM +0100, Peter Maydell wrote:
> On 14 August 2013 11:33, Russell King - ARM Linux
> wrote:
> > On Mon, Aug 12, 2013 at 04:04:08PM -0700, Guenter Roeck wrote:
> >> Hacked diff is below. Can I write that up as clean patch and submit it,
> &g
On Mon, Aug 12, 2013 at 04:04:08PM -0700, Guenter Roeck wrote:
> Hacked diff is below. Can I write that up as clean patch and submit it,
> or do we need a test on real hardware ?
Well, if we want to ensure that it is really correct, the sensible thing
to do is to try it on real hardware, otherwise
On Tue, Aug 13, 2013 at 03:37:31AM -0500, Rob Landley wrote:
> Because working with old and new qemu, like it used to before everybody
> fiddled with it to not actually match hardware nobody _has_, is
> definitely not an interesting goal.
It appears that people *do* have the hardware.
What is
On Mon, Aug 12, 2013 at 10:36:17PM +0100, Peter Maydell wrote:
> On this point, yes. Equivalent bit from the PB926 TRM:
> http://infocenter.arm.com/help/topic/com.arm.doc.dui0224i/Cacdijji.html
>
> (There are differences between the PCI controllers on
> the different boards. Differences I know of
On Mon, Aug 12, 2013 at 09:49:54PM +0100, Peter Maydell wrote:
> On 12 August 2013 21:06, Russell King - ARM Linux
> wrote:
> > On Mon, Aug 12, 2013 at 06:33:28PM +0100, Peter Maydell wrote:
> >> /* Slot to IRQ mapping for RealView EB and PB1176 backplane
> >>
On Mon, Aug 12, 2013 at 06:33:28PM +0100, Peter Maydell wrote:
> /* Slot to IRQ mapping for RealView EB and PB1176 backplane
> * nameslotIntAIntBIntCIntD
> * A 31 IRQ50 IRQ51 IRQ48 IRQ49
> * B 30 IRQ49 IRQ50 IRQ51
On Mon, Aug 12, 2013 at 05:24:50PM +0100, Peter Maydell wrote:
> On 12 August 2013 01:40, Guenter Roeck wrote:
> > On 08/11/2013 03:04 PM, Russell King - ARM Linux wrote:
> >> It could be that it's qemu's PCI routing is wrong - it's not the first
> >&
20 matches
Mail list logo
