Hi Peter, On 5/25/20 10:59 PM, Peter Maydell wrote: > On Mon, 25 May 2020 at 16:58, Philippe Mathieu-Daudé <phi...@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 >
