qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition
Date: Wed, 8 Feb 2012 21:10:37 +1000



2012/2/8 Paul Brook <address@hidden>
> > > +             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.

I think we want the -kernel commandline option, butI'mnot attached to a
particular implementation. 

Once we have an arm_linux_loader device then arm_load_kernel should go away,
or at least be a private implementation detail of arm_linux_loader.
 

Who creates the arm_linux_loader object (common code or board init function),
and how we arrange for it to have the right properties (filename from -kernel,
board ID from specific machine) is something I haven't entirely figured out.


Peter Maydell just emailed a series today that exported kernel_filename & friends as machine opts. Maybe if fundamental machine properties (such as num cpus, ram size and board ID) come from machine opts and the bootload specifics such as filepaths and command lines come from the bootloader device props? The existing -kernel arguments could come via the machine opts path and form defaults for the bootloader device if no -kernel arg is specified to the bootloader device?

I suspect we want to replace the arm_load_kernel call with an arm_linux_loader
device with appropriate properties.

 
Ok, so does this mean the machine model would still explicitly instantiate the bootloader device? Will there be a way of removing the bootloader from the machine model so if I need to create my own custom bootloader flow i can? We are doing some custom non-linux boots in our application where arm-boot.c is not working for us so being able to swap out arm_boot.c for another implemenation is one of our goals. The bootloader-as-a-device flow is ideal for this but only works if a user can choose their bootloader on the command line.
 
We should have some mechanism for the user to override/augment those
properties (e.g. overriding the FDT file).  I don't know if that functionality
actually exists, or if what we have is particularly well thought out.  Ideally
the -kernel commandline would just be shorthand for setting/overriding the
filename property on that device.  The machine->init arguments are removed. 
That's probably going to need wider coordination with other arches.

Paul


reply via email to

[Prev in Thread] Current Thread [Next in Thread]