On 1 February 2012 01:10, Alexander Graf wrote:
> On 01.02.2012, at 01:11, Grant Likely wrote:
>> @@ -312,7 +397,6 @@ void arm_load_kernel(CPUState *env, struct arm_boot_info
>> *info)
>> if (info->nb_cpus > 1) {
>> info->write_secondary_boot(env, info);
>> }
>> -
On 01.02.2012, at 18:38, Grant Likely wrote:
> On Tue, Jan 31, 2012 at 6:44 PM, Alexander Graf wrote:
>>
>> On 01.02.2012, at 02:35, Paul Brook wrote:
>>
We could also just change machine->init() and pass the dtb in there. In a
QOM world these would become machine device properties a
On Tue, Jan 31, 2012 at 6:44 PM, Alexander Graf wrote:
>
> On 01.02.2012, at 02:35, Paul Brook wrote:
>
>>> We could also just change machine->init() and pass the dtb in there. In a
>>> QOM world these would become machine device properties anyways.
>>>
>>> machine->init(ram_size, boot_devices,
On 02/01/2012 07:55 AM, Alexander Graf wrote:
On 01.02.2012, at 14:52, Anthony Liguori wrote:
Fine, but to boot u-boot, the real hardware must set IP to something that's
most likely an offset into ROM flash.
Why can't we bootstrap semi-hosted mode by having a ROM somewhere that just
redirect
On 01.02.2012, at 14:52, Anthony Liguori wrote:
> On 02/01/2012 07:49 AM, Alexander Graf wrote:
>>
>> On 01.02.2012, at 14:44, Anthony Liguori wrote:
>>
>>> On 02/01/2012 07:32 AM, Alexander Graf wrote:
On 01.02.2012, at 14:25, Anthony Liguori wrote:
> On 02/01/2012 07:10 A
On 02/01/2012 07:49 AM, Alexander Graf wrote:
On 01.02.2012, at 14:44, Anthony Liguori wrote:
On 02/01/2012 07:32 AM, Alexander Graf wrote:
On 01.02.2012, at 14:25, Anthony Liguori wrote:
On 02/01/2012 07:10 AM, Peter Maydell wrote:
On 1 February 2012 13:04, Anthony Liguoriwrote:
How
On 01.02.2012, at 14:44, Anthony Liguori wrote:
> On 02/01/2012 07:32 AM, Alexander Graf wrote:
>>
>> On 01.02.2012, at 14:25, Anthony Liguori wrote:
>>
>>> On 02/01/2012 07:10 AM, Peter Maydell wrote:
On 1 February 2012 13:04, Anthony Liguori wrote:
> How does it race? Devices norm
On 02/01/2012 07:32 AM, Alexander Graf wrote:
On 01.02.2012, at 14:25, Anthony Liguori wrote:
On 02/01/2012 07:10 AM, Peter Maydell wrote:
On 1 February 2012 13:04, Anthony Liguori wrote:
How does it race? Devices normally never touch memory so a loader device
will be the only thing mucki
On 01.02.2012, at 14:25, Anthony Liguori wrote:
> On 02/01/2012 07:10 AM, Peter Maydell wrote:
>> On 1 February 2012 13:04, Anthony Liguori wrote:
>>> How does it race? Devices normally never touch memory so a loader device
>>> will be the only thing mucking with memory.
>>
>> The obvious one
On 02/01/2012 07:10 AM, Peter Maydell wrote:
On 1 February 2012 13:04, Anthony Liguori wrote:
How does it race? Devices normally never touch memory so a loader device
will be the only thing mucking with memory.
The obvious one is "loader reset function wants to set starting PC to
entry point
On 1 February 2012 13:04, Anthony Liguori wrote:
> How does it race? Devices normally never touch memory so a loader device
> will be the only thing mucking with memory.
The obvious one is "loader reset function wants to set starting PC to
entry point of kernel/etc" vs "CPU device reset wants to
On 01/31/2012 08:40 PM, John Williams wrote:
On Wed, Feb 1, 2012 at 12:37 PM, Anthony Liguori wrote:
Globals are even worse!
Can't you hear the kernel loader begging to be turned into a device? It's
pleading with us to stop abusing other parts of QEMU and make it a first
class citizen of QEM
On Wed, Feb 1, 2012 at 12:37 PM, Anthony Liguori wrote:
> On 01/31/2012 07:44 PM, Alexander Graf wrote:
>>
>>
>> On 01.02.2012, at 02:35, Paul Brook wrote:
>>
We could also just change machine->init() and pass the dtb in there. In
a
QOM world these would become machine device proper
On 01/31/2012 07:44 PM, Alexander Graf wrote:
On 01.02.2012, at 02:35, Paul Brook wrote:
We could also just change machine->init() and pass the dtb in there. In a
QOM world these would become machine device properties anyways.
machine->init(ram_size, boot_devices,
kernel
On 01/31/2012 07:35 PM, Paul Brook wrote:
We could also just change machine->init() and pass the dtb in there. In a
QOM world these would become machine device properties anyways.
machine->init(ram_size, boot_devices,
kernel_filename, kernel_cmdline, initrd_filename,
cpu_
On 01.02.2012, at 02:35, Paul Brook wrote:
>> We could also just change machine->init() and pass the dtb in there. In a
>> QOM world these would become machine device properties anyways.
>>
>>machine->init(ram_size, boot_devices,
>> kernel_filename, kernel_cmdline, initrd_fi
> We could also just change machine->init() and pass the dtb in there. In a
> QOM world these would become machine device properties anyways.
>
> machine->init(ram_size, boot_devices,
> kernel_filename, kernel_cmdline, initrd_filename,
> cpu_model);
>
> Essentially we should
On 01.02.2012, at 01:11, Grant Likely wrote:
> If compiled with CONFIG_FDT, allow user to specify a device tree file using
> the -dtb argument. If the machine supports it then the dtb will be loaded
> into memory and passed to the kernel on boot.
>
> v2: - Enable for all arm platforms by making
If compiled with CONFIG_FDT, allow user to specify a device tree file using
the -dtb argument. If the machine supports it then the dtb will be loaded
into memory and passed to the kernel on boot.
v2: - Enable for all arm platforms by making arm_boot use the filename directly
- Fix style issue
19 matches
Mail list logo
