On Fri, 2015-08-14 at 09:48AM +0100, Peter Maydell wrote:
> On 14 August 2015 at 07:16, Soren Brinkmann
> wrote:
> > The macro is defined twice in identical ways.
> >
> > Signed-off-by: Soren Brinkmann
> > ---
> > I have the feeling I'm missing a tiny one-letter difference or some
> > ifdef, but
On Sat, Jul 20, 2013 at 12:20:48AM +0100, Peter Maydell wrote:
> On 19 July 2013 18:53, Sören Brinkmann wrote:
> > On Fri, Jul 19, 2013 at 06:46:57PM +0100, Peter Maydell wrote:
> >> On 19 July 2013 18:39, Sören Brinkmann wrote:
> >> > On Fri, Jul 19, 2013 at 0
On Fri, Jul 19, 2013 at 01:04:20PM +0100, Peter Maydell wrote:
> On 8 July 2013 23:40, Soren Brinkmann wrote:
> > +
> > +if (ep) {
> > +*ep = hdr->ih_ep;
> > +}
>
> (Allowing ep to be NULL for IH_TYPE_KERNEL is new behaviour,
> but it makes sense for consistency with t
On Fri, Jul 19, 2013 at 06:46:57PM +0100, Peter Maydell wrote:
> On 19 July 2013 18:39, Sören Brinkmann wrote:
> > On Fri, Jul 19, 2013 at 01:04:20PM +0100, Peter Maydell wrote:
> >> On 8 July 2013 23:40, Soren Brinkmann wrote:
> >> > +
> >> > +
ping?
any comments?
Thanks,
Sören
On Mon, Jul 08, 2013 at 03:40:00PM -0700, Soren Brinkmann wrote:
> Sorry, for the delay, but I finally found some time for a follow up. I assume
> the asymmety between loading kernels and loading the ramdisk is the blocker
> for
> this series and
On Fri, Jun 14, 2013 at 06:36:06PM +0100, Peter Maydell wrote:
> On 14 June 2013 18:14, Sören Brinkmann wrote:
> > On Fri, Jun 14, 2013 at 05:56:31PM +0100, Peter Maydell wrote:
> >> If we're providing separate functions for kernel and
> >> ramdisk loading shou
Hi Peter,
On Fri, Jun 14, 2013 at 05:56:31PM +0100, Peter Maydell wrote:
> On 14 June 2013 17:36, Soren Brinkmann wrote:
> > Introduce 'load_ramdisk()' which can load "normal" ramdisks and ramdisks
> > with a u-boot header.
> > To enable this and leverage synergies 'load_uimage()' is refactored t
On Fri, Jun 07, 2013 at 02:02:43PM +1000, peter.crosthwa...@xilinx.com wrote:
> From: Peter Crosthwaite
>
> commit 1db8b5efe0c2b5000e50691eea61264a615f43de introduced an issue
> where QEMU would segfault if you have an unattached Cadence UART.
>
> Fix by guarding the flush-on-reset logic on ther
