2012/2/8 Paul Brook <p...@codesourcery.com>

> > diff --git a/hw/versatilepb.c b/hw/versatilepb.c
> > index 6e28e78..e42d845 100644
> > --- a/hw/versatilepb.c
> > +++ b/hw/versatilepb.c
> > @@ -313,12 +313,14 @@ static void versatile_init(ram_addr_t ram_size,
> >      /*  0x101f3000 UART2.  */
> >      /* 0x101f4000 SSPI.  */
> >
> > -    versatile_binfo.ram_size = ram_size;
> > -    versatile_binfo.kernel_filename = kernel_filename;
> > -    versatile_binfo.kernel_cmdline = kernel_cmdline;
> > -    versatile_binfo.initrd_filename = initrd_filename;
> > -    versatile_binfo.board_id = board_id;
> > -    arm_load_kernel(env, &versatile_binfo);
> > +     if (kernel_filename) {
> > +             versatile_binfo.ram_size = ram_size;
> > +             versatile_binfo.kernel_filename = kernel_filename;
> > +             versatile_binfo.kernel_cmdline = kernel_cmdline;
> > +             versatile_binfo.initrd_filename = initrd_filename;
> > +             versatile_binfo.board_id = board_id;
> > +             arm_load_kernel(env, &versatile_binfo);
> > +     }
> >  }
>
> This should be using the new object you just added.
>

Yes I agree. There is another question tho that if this approach is to be
considered, should this call to arm_load_kernel be removed from the machine
model altogether? Only reason to keep it would be backwards compatibility
for the original command line format.

You also need to fix all the other uses of arm_load_kernel.
>
>
Ok. I wanted to put this idea forward for a single machine model
(versatilepb in this case) as a proof of concept, before applying a
significant change pattern to all the arm machines. If this approach is to
be considered then I can recreate this series with the change pattern
applied to all arm platforms.

Paul
>

Peter

Reply via email to