Re: [PATCH] hw/block/pflash_cfi01: Limit maximum flash size to 256 MiB

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

Hi Peter,

On 5/25/20 10:59 PM, Peter Maydell wrote:
> On Mon, 25 May 2020 at 16:58, Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
>>
>> As of this commit, the biggest CFI01 NOR flash documented is
>> the Micron PC28F00BP33EF. Its size is 2 GiB (256 MiB).

Oops, read as "2 Gbit (256 Mbyte)".

>>
>> Actually this "2Gb device employs a virtual chip enable feature,
>> which combines two 1Gb die with a common chip enable".
>>
>> Since we do not want to model unrealistic hardware, cap the
>> current model to this maximum. At least we have a datasheet
>> to refer.
>>
>> If a bigger flash is provided, the user get this warning:
>>
>>   qemu-system-aarch64: Initialization of device cfi.pflash01 failed: Maximum supported CFI flash size is 16 MiB.

Also here read "256 MiB" (I capped to 16MiB to test the patch).
>>
>> Note, the sbsa-ref ARM machine introduced in commit 64580903c2b
>> already uses a pair of 256 MiB flash devices.
> 
> What problem is this check solving? Is there some implementation
> imposed limitation or a limit within the flash header format
> that means larger sizes don't work? If so, what's the restriction?

I am not confident maintaining virtual device with no specifications.
If someone come with a datasheet for a pflash > 256MB then we can add
another commit to relax this restriction.
If someone is forced to use a >256MB and such hardware does not exist,
I'd rather have a document in docs/specs/pflash_cfi01.rst describing the
CFI fields.

IOW this is not a hardware limitation, but a maintenance protection.

I am worried with the recent EDK2 activity with the SBSA-ref, and I
don't want to give false hope to developers that they can create any
kind of pflash with the current device model.

If I reword this better in the commit description, is my argument
acceptable?

Thanks,

Phil.

> 
> thanks
> -- PMM
>