Maybe Kevin or Christoph (cc'ed) can help.
Mathias Krause writes:
> On 24.09.2010 14:47, Markus Armbruster wrote:
>> Mathias Krause writes:
>>
>>> On 17.09.2010 15:27, Anthony Liguori wrote:
On 09/17/2010 01:50 AM, Mathias Krause wrote:
> Am 16.09.2010 19:20 schrieb Anthony Liguori:
>
On 24.09.2010 14:47, Markus Armbruster wrote:
> Mathias Krause writes:
>
>> On 17.09.2010 15:27, Anthony Liguori wrote:
>>> On 09/17/2010 01:50 AM, Mathias Krause wrote:
Am 16.09.2010 19:20 schrieb Anthony Liguori:
> Instead of using FILE, I'd suggest using a BlockDriver to read
Mathias Krause writes:
> On 17.09.2010 15:27, Anthony Liguori wrote:
>> On 09/17/2010 01:50 AM, Mathias Krause wrote:
>>> Am 16.09.2010 19:20 schrieb Anthony Liguori:
>>>
Instead of using FILE, I'd suggest using a BlockDriver to read and write
the data.
>>> I'll fix that a
Anthony Liguori writes:
> On 09/16/2010 08:58 AM, Mathias Krause wrote:
>> In contrast to the BIOS and Option ROMs the CMOS content cannot be
>> predefined by the user. Also the amount of useable CMOS ARM is pretty
>> limited, even though the amount of CMOS bytes emulated by qemu is
>> already tw
Mathias Krause writes:
> Hi Kevin,
>
> On 17.09.2010 12:44, Kevin Wolf wrote:
>> Hi Mathias,
>>
>> Am 17.09.2010 08:42, schrieb Mathias Krause:
Using QEMU's block devices instead of a simple file would be
more consistent with the rest of QEMU and allow reading the
CMOS data not on
On 17.09.2010 15:27, Anthony Liguori wrote:
> On 09/17/2010 01:50 AM, Mathias Krause wrote:
>> Am 16.09.2010 19:20 schrieb Anthony Liguori:
>>
>>> Instead of using FILE, I'd suggest using a BlockDriver to read and write
>>> the data.
>>>
>> I'll fix that as soon as I figured how to use thi
On 09/17/2010 01:50 AM, Mathias Krause wrote:
Am 16.09.2010 19:20 schrieb Anthony Liguori:
Instead of using FILE, I'd suggest using a BlockDriver to read and write
the data.
I'll fix that as soon as I figured how to use this interface.
I think it would be very nice to add write
Hi Kevin,
On 17.09.2010 12:44, Kevin Wolf wrote:
> Hi Mathias,
>
> Am 17.09.2010 08:42, schrieb Mathias Krause:
>>> Using QEMU's block devices instead of a simple file would be
>>> more consistent with the rest of QEMU and allow reading the
>>> CMOS data not only from a file but also from an URL
On 17.09.2010 12:58, Stefan Weil wrote:
> Am 17.09.2010 08:42, schrieb Mathias Krause:
>> Am 16.09.2010 18:49, Stefan Weil schrieb:
>>> Are there use cases where having a smaller CMOS size is better?
>>> For example, when I want to emulate a system with 128 byte CMOS?
>>> The size of CMOS could be
Am 17.09.2010 08:42, schrieb Mathias Krause:
Am 16.09.2010 18:49, Stefan Weil schrieb:
The intention of this patch is ok. Loading CMOS with initial data
is needed. I just want to add two questions / remarks how the
implementation might be improved.
Are there use cases where having a smaller CMO
Hi Mathias,
Am 17.09.2010 08:42, schrieb Mathias Krause:
>> Using QEMU's block devices instead of a simple file would be
>> more consistent with the rest of QEMU and allow reading the
>> CMOS data not only from a file but also from an URL or other
>> sources.
>
> Thanks for the hint. Since this i
Am 16.09.2010 19:20 schrieb Anthony Liguori:
> Instead of using FILE, I'd suggest using a BlockDriver to read and write
> the data.
I'll fix that as soon as I figured how to use this interface.
> I think it would be very nice to add write support too so that writes to
> CMOS were persisted across
Am 16.09.2010 18:49, Stefan Weil schrieb:
> The intention of this patch is ok. Loading CMOS with initial data
> is needed. I just want to add two questions / remarks how the
> implementation might be improved.
>
> Are there use cases where having a smaller CMOS size is better?
> For example, when
On 09/16/2010 08:58 AM, Mathias Krause wrote:
In contrast to the BIOS and Option ROMs the CMOS content cannot be
predefined by the user. Also the amount of useable CMOS ARM is pretty
limited, even though the amount of CMOS bytes emulated by qemu is
already twice as much as of the original MC14681
Am 16.09.2010 15:58, schrieb Mathias Krause:
In contrast to the BIOS and Option ROMs the CMOS content cannot be
predefined by the user. Also the amount of useable CMOS ARM is pretty
limited, even though the amount of CMOS bytes emulated by qemu is
already twice as much as of the original MC146818
In contrast to the BIOS and Option ROMs the CMOS content cannot be
predefined by the user. Also the amount of useable CMOS ARM is pretty
limited, even though the amount of CMOS bytes emulated by qemu is
already twice as much as of the original MC146818. Nevertheless those
limitations are pretty ann
16 matches
Mail list logo