On 18 August 2015 at 15:50, Leif Lindholm <leif.lindh...@linaro.org> wrote: > On Tue, Aug 18, 2015 at 02:14:53PM +0200, Ard Biesheuvel wrote: >> On 18 August 2015 at 14:12, Leif Lindholm <leif.lindh...@linaro.org> wrote: >> > On Tue, Aug 18, 2015 at 01:15:54PM +0200, Ard Biesheuvel wrote: >> >> On 12 August 2015 at 08:45, Ard Biesheuvel <ard.biesheu...@linaro.org> >> >> wrote: >> >> > Instead of omitting some drivers that are known to break the Foundation >> >> > model when ARM_FOUNDATION_FVP is defined, fix those drivers so that they >> >> > simply fail to load without interfering with the boot. >> >> > >> >> > This way, we can use the same boot image for both models. >> >> > >> >> >> >> Ping? >> > >> > Basicallt looks good to me, but I thought I'd wait for Ryan to comment >> > (and he's on holiday through this week). >> > >> > Just to confirm - the Mmio probes just return zeroes in the Foundation >> > model, rather than aborting? >> > >> >> Foundation model output: >> >> WARNING: Attempted to access VE CS3 space: Read 1 bytes from 0x1c050fe0. >> WARNING: Attempted to access VE CS3 space: Read 1 bytes from 0x1c1f0fe0. >> >> Note sure what these reads return, but in each case, the first byte >> already differs from the expected value so the init aborts. >> >> I know that this would still be sufficient to blow up on a real >> system, but thankfully the model does not model /that/ :-) > > No, my main concern would be if future versions of the model delete > this trapping and instead signal an abort (or do something else > entirely), to better mimic hardware behaviour. > > Do we have output console available at this point? > If so, maybe put in a printout - at least in DEBUG build - that this > is about to happen, to reduce debug time if the model behaviour > changes? >
I suppose that makes sense. These are DXEs being launched, so it is definitely feasible to print some diagnostic on a DEBUG build. > Regardless, unless Ryan objects on Monday: > Reviewed-by: Leif Lindholm <leif.lindh...@linaro.org> > Thanks, Ard. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
