On 17 April 2018 at 03:20, Guo Heyi <heyi....@linaro.org> wrote: > Hi Ard, > > I tested mm -io on D05, for root bridge 4 with CPU IO address starting from > 0x8_abff0000, and it worked; both mm -io 0x8abff0000 and mm 0x8abff0000 > provided > the same output. It seems there is no other limit for 64bit IO address after > you > fixed the issue in EFI shell mm command. >
OK, so I think this is fine after all, even if my uneasy feeling hasn't gone away :-) Could you please resend the latest rebased version of the patches? (and include the ATU fix as well) > On Mon, Apr 16, 2018 at 09:57:09PM +0800, Guo Heyi wrote: >> Thanks, I will test mm command and let you know the result. >> >> Regards, >> >> Heyi >> >> On Fri, Apr 13, 2018 at 09:19:53AM +0200, Ard Biesheuvel wrote: >> > On 13 April 2018 at 04:05, Guo Heyi <heyi....@linaro.org> wrote: >> > > Hi Ard, >> > > >> > > Any comments? >> > > >> > >> > Apologies for the delay. I have been travelling and am behind on email. >> > >> > > Anyway we can modify the code if you insist on using an intermediate CPU >> > > IO >> > > address space. >> > > >> > >> > I have not made up my mind yet, to be honest. I agree there is a >> > certain elegance to merging both translations, but I am concerned that >> > existing EDK2 code may deal poorly with I/O addresses that require >> > more than 32 bits to express. >> > >> > Did you try the mm command in the shell for instance? As you know, I >> > recently removed an artificial address range limit there, but I wonder >> > if it uses 64-bit variables for I/O ports. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
