On Tue, Jan 14, 2014 at 10:09 AM, Olivier Martin olivier.martin@arm.com wrote:

...

-----Original Message----- From: Roy Franz [mailto:roy.franz@linaro.org] Sent: 14 January 2014 01:31 To: Olivier Martin Cc: ryan.harkin@linaro.org; edk2-devel@lists.sourceforge.net; linaro- uefi; Patch Tracking Subject: Re: [PATCH V2] Move RTSM VExpress variable storage to 256k flash blocks

...

I have to admit I prefer the solution 2) - but I am quite open to any

valid arguments. My argument is I would prefer to expose the correct implementation when possible. And if qEmu adds support for the missing VExpress IP block in the future then it will be easier to restore the correct approach (ie: the default RTSM approach) for qEmu. I don't think that the flash will every be fixed in QEMU, since accurate modeling of flash writing is not all that valuable of a feature.

I can add a compile option for the flash, as I have done for the networking. The networking required this due to conflicting ethernet devices. (And here QEMU matches real hardware, and it is RTSM that is 'wrong'.) I think that the value of a common binary for a common case is worth the cost of moving the variable storage to larger blocks, but if you remain unconvinced I'll resubmit the patch with a build option :) (and in that case I will also resubmit the networking patch so the same build option is used for both QEMU related changes.)

Nice try! but I remain unconvinced :-) From what you said, we will need a compiler flag for the Ethernet driver anyway. So let's go for it :-) And it will quite easy to 'grep' for SUPPORT_QEMU to highlight the difference between the different models than to go through the git history to find out the workaround which has been made to use UEFI on qEmu.

OK :) I'll redo both changes into 1 series, both keying off the SUPPORT_QEMU build define.

Thanks, Roy