> On Feb 22, 2019, at 02:42, Markus Armbruster wrote:
>
> Awesome. The magic setup code in hw/i386/pc_sysfw.c will happily create
> any size that's a multiple of 4KiB. The current sizes are 128KiB
> writable (power of two, good) and 2MiB - 128KiB for read-only (very much
> not a power of two
> On Feb 22, 2019, at 02:55, Laszlo Ersek wrote:
>
> OVMF and the q35/i440fx boards use cfi01. The 4KB sector size is assumed
> by both QEMU board code and OVMF. The 4KB sector size is not assumed (to
> my knowledge) by cfi01.pflash device model code.
>
> Regarding the full size of each cfi01
On 02/22/19 08:42, Markus Armbruster wrote:
> Stephen Checkoway writes:
>
>>> On Feb 20, 2019, at 03:55, Laszlo Ersek wrote:
>>>
>>> I would strongly prefer if the guest-side view wouldn't change at all.
>>
>> It sounds like sector protection isn't something you want and it's not
>
> László is
On 02/21/19 20:57, Stephen Checkoway wrote:
>
>
>> On Feb 20, 2019, at 03:55, Laszlo Ersek wrote:
>>
>> I would strongly prefer if the guest-side view wouldn't change at
>> all.
>
> It sounds like sector protection isn't something you want and it's not
> something I currently need so unless tha
Stephen Checkoway writes:
>> On Feb 20, 2019, at 03:55, Laszlo Ersek wrote:
>>
>> I would strongly prefer if the guest-side view wouldn't change at all.
>
> It sounds like sector protection isn't something you want and it's not
László is content with the status quo, but I'm not.
> something I
> On Feb 20, 2019, at 03:55, Laszlo Ersek wrote:
>
> I would strongly prefer if the guest-side view wouldn't change at all.
It sounds like sector protection isn't something you want and it's not
something I currently need so unless that changes, I probably won't do anything
with it.
My goa
Laszlo Ersek writes:
> On 02/19/19 18:55, Markus Armbruster wrote:
>> Stephen Checkoway writes:
>>
On Feb 19, 2019, at 10:28, Markus Armbruster wrote:
My terminology might be confused...
Let me backtrack a bit an explain my use case. On physical PCs, the
single f
On 02/19/19 18:55, Markus Armbruster wrote:
> Stephen Checkoway writes:
>
>>> On Feb 19, 2019, at 10:28, Markus Armbruster wrote:
>>>
>>> My terminology might be confused...
>>>
>>> Let me backtrack a bit an explain my use case. On physical PCs, the
>>> single flash chip is commonly configured
Stephen Checkoway writes:
>> On Feb 19, 2019, at 10:28, Markus Armbruster wrote:
>>
>> My terminology might be confused...
>>
>> Let me backtrack a bit an explain my use case. On physical PCs, the
>> single flash chip is commonly configured to have a read-only part and a
>> read/write part.
> On Feb 19, 2019, at 10:28, Markus Armbruster wrote:
>
> My terminology might be confused...
>
> Let me backtrack a bit an explain my use case. On physical PCs, the
> single flash chip is commonly configured to have a read-only part and a
> read/write part. The read-only part holds UEFI co
Stephen Checkoway writes:
> On Feb 19, 2019, at 01:09, Markus Armbruster wrote:
>
>> Stephen Checkoway writes:
>>
>>> On Feb 18, 2019, at 13:08, Markus Armbruster wrote:
>>>
Any chance you could do multiple region support, too?
>>>
>>> Can you point me at the data sheet for a flash chi
On Feb 19, 2019, at 01:09, Markus Armbruster wrote:
> Stephen Checkoway writes:
>
>> On Feb 18, 2019, at 13:08, Markus Armbruster wrote:
>>
>>> Any chance you could do multiple region support, too?
>>
>> Can you point me at the data sheet for a flash chip with multiple region
>> support?
Stephen Checkoway writes:
> On Feb 18, 2019, at 13:08, Markus Armbruster wrote:
>
>> Stephen Checkoway writes:
>>
>>> On Feb 18, 2019, at 08:43, Thomas Huth wrote:
>>>
On 18/02/2019 07.07, Stephen Checkoway wrote:
> Hi all,
>
> I've been working on some improvements to the
On Feb 18, 2019, at 13:08, Markus Armbruster wrote:
> Stephen Checkoway writes:
>
>> On Feb 18, 2019, at 08:43, Thomas Huth wrote:
>>
>>> On 18/02/2019 07.07, Stephen Checkoway wrote:
Hi all,
I've been working on some improvements to the pflash_cfi02 block device
(int
Stephen Checkoway writes:
> On Feb 18, 2019, at 08:43, Thomas Huth wrote:
>
>>On 18/02/2019 07.07, Stephen Checkoway wrote:
>>> Hi all,
>>>
>>> I've been working on some improvements to the pflash_cfi02 block device
>>> (interleaved flash devices similar to pflash_cfi01, multi-sector erase,
>
On 18/02/2019 17.02, Stephen Checkoway wrote:
>
>
> On Feb 18, 2019, at 08:43, Thomas Huth wrote:
>
>> I think you could use one of the machines that has a cfi02 on board. For
>> example: Write some random data to a temporary file. Run qemu with:
>>
>> QTestState *qts;
>> qts = qtest_initf(" qe
On Feb 18, 2019, at 08:43, Thomas Huth wrote:
> I think you could use one of the machines that has a cfi02 on board. For
> example: Write some random data to a temporary file. Run qemu with:
>
> QTestState *qts;
> qts = qtest_initf(" qemu-system-arm -M musicpal,accel=qtest "
>
On 18/02/2019 07.07, Stephen Checkoway wrote:
> Hi all,
>
> I've been working on some improvements to the pflash_cfi02 block device
> (interleaved flash devices similar to pflash_cfi01, multi-sector erase,
> nonuniform sector sizes, and some bug fixes and I'm planning on implementing
> sector e
Hi all,
I've been working on some improvements to the pflash_cfi02 block device
(interleaved flash devices similar to pflash_cfi01, multi-sector erase,
nonuniform sector sizes, and some bug fixes and I'm planning on implementing
sector erase suspend/resume commands in the near future).
There a
19 matches
Mail list logo
