Laszlo Ersek writes:
> On 02/15/19 17:01, Markus Armbruster wrote:
>
>> The size of the flash chip is a property of the machine. It is *fixed*.
>
> I'll have to disagree on this one; in OVMF's case, you can build OVMF in
> 1MB, 2MB, and 4MB *cumulative* size (that is, the numbers I give here
>
On 02/16/19 12:21, Markus Armbruster wrote:
> Laszlo Ersek writes:
>> On 02/15/19 17:01, Markus Armbruster wrote:
>>> Using whatever size the image has is sloppy modelling.
>>
>> Maybe so, but it's also very convenient, and also quite important, right
>> now (given the multiple firmware image siz
Markus Armbruster writes:
> Markus Armbruster writes:
>
>> Laszlo Ersek writes:
>>
>>> On 02/15/19 13:28, Alex Bennée wrote:
It looks like there was going to be code to check we had some sort of
alignment so lets replace it with an actual check. This is a bit more
useful than the
Laszlo Ersek writes:
> On 02/15/19 17:01, Markus Armbruster wrote:
>
>> Let's take a step back and consider sane requirements.
>>
>> The size of the flash chip is a property of the machine. It is *fixed*.
>
> I'll have to disagree on this one; in OVMF's case, you can build OVMF in
> 1MB, 2MB, a
On 02/15/19 17:01, Markus Armbruster wrote:
> The size of the flash chip is a property of the machine. It is *fixed*.
I'll have to disagree on this one; in OVMF's case, you can build OVMF in
1MB, 2MB, and 4MB *cumulative* size (that is, the numbers I give here
each refer to the sum of both pflas
Markus Armbruster writes:
> Laszlo Ersek writes:
>
>> On 02/15/19 13:28, Alex Bennée wrote:
>>> It looks like there was going to be code to check we had some sort of
>>> alignment so lets replace it with an actual check. This is a bit more
>>> useful than the enigmatic "failed to read the initia
Laszlo Ersek writes:
> On 02/15/19 13:28, Alex Bennée wrote:
>> It looks like there was going to be code to check we had some sort of
>> alignment so lets replace it with an actual check. This is a bit more
>> useful than the enigmatic "failed to read the initial flash content"
>> when we attempt
On 02/15/19 13:28, Alex Bennée wrote:
> It looks like there was going to be code to check we had some sort of
> alignment so lets replace it with an actual check. This is a bit more
> useful than the enigmatic "failed to read the initial flash content"
> when we attempt to read the number of bytes
It looks like there was going to be code to check we had some sort of
alignment so lets replace it with an actual check. This is a bit more
useful than the enigmatic "failed to read the initial flash content"
when we attempt to read the number of bytes the device should have.
This is a potential c
