2012/2/8 Paul Brook <p...@codesourcery.com> > > > > + 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 >
