From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c0b::235; helo=mail-it0-x235.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id B41A821CF58BB for ; Mon, 9 Oct 2017 05:20:10 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id j140so8140263itj.1 for ; Mon, 09 Oct 2017 05:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3ttla4+JSL62bSEbuoXF5X+QiChaOWi+UJeOX/vSz6c=; b=Ij1KTUoh8B45x9dESy17a+GGles8NtccLdxl0crGfiupSEeSn88ENVQgAI9CKxH4S9 pqOckLZJ7kJNZTevyGiHF9MEiQn9qhdsyGJVAysa/Hrm7QS+QNUjsT1XZamfbqBlNGbJ /2jn6S7jXQ+P4bC+RCIRjiz89mx4eFxST4yMQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3ttla4+JSL62bSEbuoXF5X+QiChaOWi+UJeOX/vSz6c=; b=jIeI+xJTslKxYKE6ACRGb25Fr3COOULDD7I0avXA6lxHwm+UTDGkSfT37rIzL82upM elb97kpjzaZKI/46xQVim3XCHta8Bpswgtbn9+rMZlMnuczY5GdohXh4Nj1BhcnTrHoA qkq1GV/dMKV+yXkDlAsZQvBQ4wrVWslqSReT0/vhWpUNgQ3nywYg273eZywap9Muf+Fq N4tSYVdUZkniP/YNcXoVbO8afyfo6sTnl1L86qA+Xebm7Fv5olXxIUjMj16ujeENe3eM 416IXZX468IlOQ6ub2s69QARfL2Spa9v+1kYrNwYfRC0GPmcGf7T+KQoqGzOCcsGExKE /8iQ== X-Gm-Message-State: AMCzsaVy6Xat93l/rEwrj8GBXrRowZc/eKF0IN85ZEn1pPT7AqZYfCDD D3/aiTU/HTNjpNFryCvan0YICbbw95jFZ7ggY61L1A== X-Google-Smtp-Source: AOwi7QCRo7opaXfDs4sya0nHIrxxe85aZpYW5ak3rfyN63Bz/nDeO71g/W5breHpeylcyFvey9e14170yoqekQ3Bi7g= X-Received: by 10.36.4.212 with SMTP id 203mr13913659itb.10.1507551816944; Mon, 09 Oct 2017 05:23:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.131.167 with HTTP; Mon, 9 Oct 2017 05:23:36 -0700 (PDT) In-Reply-To: References: <20171009011539.45115-1-daniil.egranov@arm.com> <734D49CCEBEEF84792F5B80ED585239D5BA8A854@SHSMSX104.ccr.corp.intel.com> From: Ard Biesheuvel Date: Mon, 9 Oct 2017 13:23:36 +0100 Message-ID: To: "Ni, Ruiyu" Cc: Daniil Egranov , "edk2-devel@lists.01.org" , "leif.lindholm@linaro.org" , "Zeng, Star" Subject: Re: [PATCH] MdeModulePkg/PciHostBridgeDxe: Fixed PCI DMA Map/Umap bounce buffer X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 12:20:10 -0000 Content-Type: text/plain; charset="UTF-8" On 9 October 2017 at 11:40, Ard Biesheuvel wrote: > On 9 October 2017 at 08:42, Ni, Ruiyu wrote: >> The "read"/"write" is from the Bus Master's point of view. >> >> >> Thanks/Ray >> >>> -----Original Message----- >>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Daniil >>> Egranov >>> Sent: Monday, October 9, 2017 9:16 AM >>> To: edk2-devel@lists.01.org >>> Cc: leif.lindholm@linaro.org; Zeng, Star ; >>> ard.biesheuvel@linaro.org >>> Subject: [edk2] [PATCH] MdeModulePkg/PciHostBridgeDxe: Fixed PCI DMA >>> Map/Umap bounce buffer >>> >>> The patch corrects the logic of transferring data between a bounce buffer and a >>> real buffer above 4GB: >>> 1. In the case of mapping a bounce buffer for the write operation, data from a >>> real buffer should be copied into a bounce buffer. >>> 2.In the case of unmapping a bounce buffer for the read operation, data should >>> be copied from a bounce buffer into a real buffer. >>> >>> The patch resolves a Juno board issue with the the grub and SATA drives. >>> > > I am intrigued by this. > > So as I suggested, this has to do with 64-bit DMA, but not in the way > I suspected. UEFI itself never hits this code path, because it runs > entirely < 32 GB, but as soon as GRUB starts allocating loader data > and use it for DMA, the bounce buffering kicks in because apparently, > the SATA controller is not 64-bit DMA capable. > > Are you using the SataSiI3132Dxe driver on Juno? Does this help at all? > > diff --git a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c > b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c > index 2fb5fd68db01..a938563ebdd6 100644 > --- a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c > +++ b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c > @@ -104,7 +104,7 @@ SiI3132AtaPassThruCommand ( > } > > Status = PciIo->Map ( > - PciIo, EfiPciIoOperationBusMasterRead, > + PciIo, EfiPciIoOperationBusMasterWrite, > Packet->InDataBuffer, &InDataBufferLength, > &PhysInDataBuffer, &PciAllocMapping > ); > if (EFI_ERROR (Status)) { > @@ -139,7 +139,7 @@ SiI3132AtaPassThruCommand ( > OutDataBufferLength = Packet->OutTransferLength * SataDevice->BlockSize; > > Status = PciIo->Map ( > - PciIo, EfiPciIoOperationBusMasterWrite, > + PciIo, EfiPciIoOperationBusMasterRead, > Packet->OutDataBuffer, &OutDataBufferLength, > &PhysOutDataBuffer, &PciAllocMapping > ); > if (EFI_ERROR (Status)) { Also, it might make sense to find out if the hardware is really not 64-bit DMA capable, or whether the driver simply fails to set the EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute.