On 21 February 2012 09:15, Peter Crosthwaite
wrote:
> On Tue, Feb 21, 2012 at 5:56 AM, Peter Maydell
> wrote:
>> On 20 February 2012 19:51, Andreas Färber wrote:
>>> Am 20.02.2012 20:43, schrieb Peter Maydell:
I don't particularly care how we QOMify arm_boot (it's not exactly at
the t
On Tue, Feb 21, 2012 at 5:56 AM, Peter Maydell wrote:
> On 20 February 2012 19:51, Andreas Färber wrote:
>> Am 20.02.2012 20:43, schrieb Peter Maydell:
>>> I don't particularly care how we QOMify arm_boot (it's not exactly at
>>> the top of my priority list demanding attention), I do care that (a
On 20 February 2012 19:51, Andreas Färber wrote:
> Am 20.02.2012 20:43, schrieb Peter Maydell:
>> I don't particularly care how we QOMify arm_boot (it's not exactly at
>> the top of my priority list demanding attention), I do care that (a)
>> we have a sensible user-facing interface [ie command li
Am 20.02.2012 20:43, schrieb Peter Maydell:
> On 8 February 2012 13:47, Anthony Liguori wrote:
>> On 02/08/2012 06:41 AM, Alexander Graf wrote:
>>> Yeah, basically the variable flow goes:
>>>
>>> vl.c -> machine_opts -> machine_init() -> device properties ->
>>> device_init()
>>
>> And the r
On 8 February 2012 13:47, Anthony Liguori wrote:
> On 02/08/2012 06:41 AM, Alexander Graf wrote:
>> Yeah, basically the variable flow goes:
>>
>> vl.c -> machine_opts -> machine_init() -> device properties ->
>> device_init()
>
> And the rationale is that machine_init() will do nothing other
On Thu, Feb 9, 2012 at 11:22 PM, Andreas Färber wrote:
> Am 08.02.2012 08:55, schrieb Peter A. G. Crosthwaite:
> > From: "Peter A. G. Crosthwaite"
> >
> > Create a QOM device for bootstrapping linux on arm. Wraps the existing
> > arm_boot code and calls arm_load_kernel() at device init. Allows b
Am 08.02.2012 08:55, schrieb Peter A. G. Crosthwaite:
> From: "Peter A. G. Crosthwaite"
>
> Create a QOM device for bootstrapping linux on arm. Wraps the existing
> arm_boot code and calls arm_load_kernel() at device init. Allows booting
> of linux without -kernel -initrd -append arguments. The m
> /* multicore boards that use the default secondary core boot functions
> * can ignore these two function calls. If the default functions won't
> * work, then write_secondary_boot() should write a suitable blob of
> * code mimicing the secondary CPU startup process used by the b
Alrighty,
So it seems like the bootloader as a device idea has some support, just
need to work out a few implementaiton details. It seems the consensus is
that machine models will instantiate the device. The latest idea is the
machine model will pass some of core props to the bootloader while othe
On 02/08/2012 10:15 AM, Paul Brook wrote:
Ok, that sounds more workable :). So i would add my initrd_addr property to
the bootloader as a qdev prop as I suggested before, then something like:
qemu-system-arm -M verstailepb -property
/foo/bar/arm_linux_loader.0,initrd_addr=0x1000
Yes.
Ther
On 02/08/2012 10:03 AM, Peter Crosthwaite wrote:
2012/2/9 Paul Brook
So here are some of the problems im trying to solve with the bootloader:
Smp bootstrap secondary CPUs while loading an elf (currently elfs will be
assumed to be not kernels).
Change the kernel, initrd and dtb load address on
> Ok, that sounds more workable :). So i would add my initrd_addr property to
> the bootloader as a qdev prop as I suggested before, then something like:
>
> qemu-system-arm -M verstailepb -property
> /foo/bar/arm_linux_loader.0,initrd_addr=0x1000
Yes.
There are various implementation/syntax
2012/2/9 Paul Brook
> > So here are some of the problems im trying to solve with the bootloader:
> >
> > Smp bootstrap secondary CPUs while loading an elf (currently elfs will be
> > assumed to be not kernels).
> > Change the kernel, initrd and dtb load address on the command line.
> > Use my own
> So here are some of the problems im trying to solve with the bootloader:
>
> Smp bootstrap secondary CPUs while loading an elf (currently elfs will be
> assumed to be not kernels).
> Change the kernel, initrd and dtb load address on the command line.
> Use my own SMP secondary bootloop.
>
> My
So here are some of the problems im trying to solve with the bootloader:
Smp bootstrap secondary CPUs while loading an elf (currently elfs will be
assumed to be not kernels).
Change the kernel, initrd and dtb load address on the command line.
Use my own SMP secondary bootloop.
My intention with t
> Its the other problem I am more worried about, i.e. when I -device
> instantiate my bootloader with an existing machine how do I get my ram_size
> and board_ID? The no machine opts for devices policy makes this impossible
> such that I would have to pass in board_id and ram_size to
> the boot-loa
2012/2/9 Paul Brook
> > So if we consider this bootloader a device and its -dtb argument a
> property
> > of that device, then what you are implying is that every device property
> of
> > every device in a machine must be managed by the machine model? Isn't the
> > dynamic machine model work that
> So if we consider this bootloader a device and its -dtb argument a property
> of that device, then what you are implying is that every device property of
> every device in a machine must be managed by the machine model? Isn't the
> dynamic machine model work that is in progress is trying to get a
On 08.02.2012, at 15:05, Peter Crosthwaite wrote:
>
>
> On Wed, Feb 8, 2012 at 11:35 PM, Alexander Graf wrote:
>
> On 08.02.2012, at 14:30, Peter Crosthwaite wrote:
>
>>
>>
>> On Wed, Feb 8, 2012 at 11:10 PM, Alexander Graf wrote:
>>
>> On 08.02.2012, at 14:04, Peter Crosthwaite wrote:
>
On Wed, Feb 8, 2012 at 11:35 PM, Alexander Graf wrote:
>
> On 08.02.2012, at 14:30, Peter Crosthwaite wrote:
>
>
>
> On Wed, Feb 8, 2012 at 11:10 PM, Alexander Graf wrote:
>
>>
>> On 08.02.2012, at 14:04, Peter Crosthwaite wrote:
>>
>>
>>
>> On Wed, Feb 8, 2012 at 10:41 PM, Alexander Graf wrote
On 02/08/2012 06:41 AM, Alexander Graf wrote:
On 08.02.2012, at 13:27, Paul Brook wrote:
2012/2/8 Paul Brook
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
ins
On 02/08/2012 01:55 AM, Peter A. G. Crosthwaite wrote:
From: "Peter A. G. Crosthwaite"
Create a QOM device for bootstrapping linux on arm. Wraps the existing
arm_boot code and calls arm_load_kernel() at device init. Allows booting
of linux without -kernel -initrd -append arguments. The main draw
On 08.02.2012, at 14:30, Peter Crosthwaite wrote:
>
>
> On Wed, Feb 8, 2012 at 11:10 PM, Alexander Graf wrote:
>
> On 08.02.2012, at 14:04, Peter Crosthwaite wrote:
>
>>
>>
>> On Wed, Feb 8, 2012 at 10:41 PM, Alexander Graf wrote:
>>
>> On 08.02.2012, at 13:27, Paul Brook wrote:
>>
>> >
On Wed, Feb 8, 2012 at 11:10 PM, Alexander Graf wrote:
>
> On 08.02.2012, at 14:04, Peter Crosthwaite wrote:
>
>
>
> On Wed, Feb 8, 2012 at 10:41 PM, Alexander Graf wrote:
>
>>
>> On 08.02.2012, at 13:27, Paul Brook wrote:
>>
>> >> 2012/2/8 Paul Brook
>> >>
>> > I suspect we want to replace
On 08.02.2012, at 14:04, Peter Crosthwaite wrote:
>
>
> On Wed, Feb 8, 2012 at 10:41 PM, Alexander Graf wrote:
>
> On 08.02.2012, at 13:27, Paul Brook wrote:
>
> >> 2012/2/8 Paul Brook
> >>
> > I suspect we want to replace the arm_load_kernel call with an
> > arm_linux_loader device
On Wed, Feb 8, 2012 at 10:41 PM, Alexander Graf wrote:
>
> On 08.02.2012, at 13:27, Paul Brook wrote:
>
> >> 2012/2/8 Paul Brook
> >>
> > I suspect we want to replace the arm_load_kernel call with an
> > arm_linux_loader device with appropriate properties.
>
> Ok, so does this
On 08.02.2012, at 13:27, Paul Brook wrote:
>> 2012/2/8 Paul Brook
>>
> 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 boot
> 2012/2/8 Paul Brook
>
> > > > 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?
> >
> > Yes. Bootloader
2012/2/8 Paul Brook
> > > 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?
>
> Yes. Bootloaders inherently have
> > 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?
Yes. Bootloaders inherently have machine specific knowledge. They n
2012/2/8 Paul Brook
> > > > + 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 t
> > > + 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
2012/2/8 Paul Brook
> > 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
> 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_
From: "Peter A. G. Crosthwaite"
Create a QOM device for bootstrapping linux on arm. Wraps the existing
arm_boot code and calls arm_load_kernel() at device init. Allows booting
of linux without -kernel -initrd -append arguments. The main drawback is
the boardid now has to be specified as there is
35 matches
Mail list logo
