From nobody Mon May 12 06:10:46 2025
Delivered-To: importer@patchew.org
Authentication-Results: mx.zohomail.com;
spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as
permitted sender)
smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org;
dmarc=pass(p=none dis=none) header.from=nongnu.org
ARC-Seal: i=1; a=rsa-sha256; t=1733910755; cv=none;
d=zohomail.com; s=zohoarc;
b=YMJw2PldK3VbzCbzAdHlkHQlCHq0BhYft4QO7wnisuyQy2V64OyWnknDn7njZAqjp+iTSMlhYz4NN2WH+RhM47+88W224UyQYVt48DOBvWOzJHLbzG53t922Yo2IHfy6kIN2Q+doVx6mZsCw7GdaHHSyFHhVvEg73lYoGx+kjx4=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com;
s=zohoarc;
t=1733910755;
h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Reply-To:Reply-To:References:Sender:Subject:Subject:To:To:Message-Id;
bh=g8t9o+2woOlPJJk/fmFvHHw1V0ybH+1TMUKc0arIes8=;
b=cINidRZM+iHMfj3CivwtgQytaKzIgJTyzLECTMKjdPh34Swy4Dqy9+Fy8gzepNxHWRWN8xwyRKWEJ3c6y2iBmAV/WPIvkE91TkPpVKDESPUGPCTmZ/g8BvBU8lmjscjzh0Gvq+zBkLkN5bfIwjcpEIRIV563Seu1kEooT6VdJLI=
ARC-Authentication-Results: i=1; mx.zohomail.com;
spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as
permitted sender)
smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org;
dmarc=pass header.from=<qemu-devel@nongnu.org> (p=none dis=none)
Return-Path: <qemu-devel-bounces+importer=patchew.org@nongnu.org>
Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by
mx.zohomail.com
with SMTPS id 1733910755607690.2903622593985;
Wed, 11 Dec 2024 01:52:35 -0800 (PST)
Received: from localhost ([::1] helo=lists1p.gnu.org)
by lists.gnu.org with esmtp (Exim 4.90_1)
(envelope-from <qemu-devel-bounces@nongnu.org>)
id 1tLJNP-0006A9-G5; Wed, 11 Dec 2024 04:51:27 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10])
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <jamin_lin@aspeedtech.com>)
id 1tLJNN-00069a-9L; Wed, 11 Dec 2024 04:51:25 -0500
Received: from mail.aspeedtech.com ([211.20.114.72] helo=TWMBX01.aspeed.com)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <jamin_lin@aspeedtech.com>)
id 1tLJNL-00057d-Oi; Wed, 11 Dec 2024 04:51:25 -0500
Received: from TWMBX01.aspeed.com (192.168.0.62) by TWMBX01.aspeed.com
(192.168.0.62) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.12; Wed, 11 Dec
2024 17:51:11 +0800
Received: from localhost.localdomain (192.168.10.10) by TWMBX01.aspeed.com
(192.168.0.62) with Microsoft SMTP Server id 15.2.1258.12 via Frontend
Transport; Wed, 11 Dec 2024 17:51:11 +0800
To: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>, Bin Meng
<bmeng.cn@gmail.com>, "open list:SD (Secure Card)" <qemu-block@nongnu.org>,
"open list:All patches CC here" <qemu-devel@nongnu.org>
CC: <jamin_lin@aspeedtech.com>, <troy_lee@aspeedtech.com>,
<yunlin.tang@aspeedtech.com>
Subject: [RFC.PATCH v1 1/2] sd:sdhci: Fix boundary_count overflow in
sdhci_sdma_transfer_multi_blocks
Date: Wed, 11 Dec 2024 17:51:09 +0800
Message-ID: <20241211095111.1421928-2-jamin_lin@aspeedtech.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20241211095111.1421928-1-jamin_lin@aspeedtech.com>
References: <20241211095111.1421928-1-jamin_lin@aspeedtech.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17
as permitted sender) client-ip=209.51.188.17;
envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org;
helo=lists.gnu.org;
Received-SPF: pass client-ip=211.20.114.72;
envelope-from=jamin_lin@aspeedtech.com; helo=TWMBX01.aspeed.com
X-Spam_score_int: -18
X-Spam_score: -1.9
X-Spam_bar: -
X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9,
RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001,
SPF_HELO_FAIL=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-BeenThere: qemu-devel@nongnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <https://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
Reply-to: Jamin Lin <jamin_lin@aspeedtech.com>
From: Jamin Lin via <qemu-devel@nongnu.org>
Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org
Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org
X-ZM-MESSAGEID: 1733910757463116600
Content-Type: text/plain; charset="utf-8"
How to reproduce it:
1. The value of "s->blksie" was 0x7200. The bits[14:12] was "111", so the b=
uffer
boundary was 0x80000.(512Kbytes). This SDMA buffer boundary the same as
u-boot default value.
The bit[11:0] is "001000000000", so the block size is 0x200.(512bytes)
2. The SDMA address was 0x83123456 which was not page aligned and
"s->sdmasysad % boundary_chk" was 0x23456. The value of boundary_count w=
as
0x5cbaa.("boundary_chk - (s->sdmasysad % boundary_chk)" -->
"(0x80000 - 0x23456)")
However, boundary_count did not aligned the block size 512 bytes and the SD=
MA
address is not page aligned(0x80000), so the following if-statement never b=
e true,
```
if (((boundary_count + begin) < block_size) && page_aligned)
````
Finally, it caused boundary_count overflow because its data type was uint32=
_t.
Ex: the last boundary_count was 0x1aa and "0x1aa - 0x200" became "0xffffffa=
a".
It is the wrong behavior.
To fix it, it seems we can directly check the "boundary_count < blocksize"
instead of "boundary_count < blocksize && page_aligned"
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
---
hw/sd/sdhci.c | 18 ++++--------------
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
index 37875c02c3..47d96b935b 100644
--- a/hw/sd/sdhci.c
+++ b/hw/sd/sdhci.c
@@ -590,7 +590,6 @@ static void sdhci_write_dataport(SDHCIState *s, uint32_=
t value, unsigned size)
/* Multi block SDMA transfer */
static void sdhci_sdma_transfer_multi_blocks(SDHCIState *s)
{
- bool page_aligned =3D false;
unsigned int begin;
const uint16_t block_size =3D s->blksize & BLOCK_SIZE_MASK;
uint32_t boundary_chk =3D 1 << (((s->blksize & ~BLOCK_SIZE_MASK) >> 12=
) + 12);
@@ -601,15 +600,6 @@ static void sdhci_sdma_transfer_multi_blocks(SDHCIStat=
e *s)
return;
}
=20
- /*
- * XXX: Some sd/mmc drivers (for example, u-boot-slp) do not account f=
or
- * possible stop at page boundary if initial address is not page align=
ed,
- * allow them to work properly
- */
- if ((s->sdmasysad % boundary_chk) =3D=3D 0) {
- page_aligned =3D true;
- }
-
s->prnsts |=3D SDHC_DATA_INHIBIT | SDHC_DAT_LINE_ACTIVE;
if (s->trnmod & SDHC_TRNS_READ) {
s->prnsts |=3D SDHC_DOING_READ;
@@ -618,7 +608,7 @@ static void sdhci_sdma_transfer_multi_blocks(SDHCIState=
*s)
sdbus_read_data(&s->sdbus, s->fifo_buffer, block_size);
}
begin =3D s->data_count;
- if (((boundary_count + begin) < block_size) && page_aligned) {
+ if (((boundary_count + begin) < block_size)) {
s->data_count =3D boundary_count + begin;
boundary_count =3D 0;
} else {
@@ -634,7 +624,7 @@ static void sdhci_sdma_transfer_multi_blocks(SDHCIState=
*s)
if (s->data_count =3D=3D block_size) {
s->data_count =3D 0;
}
- if (page_aligned && boundary_count =3D=3D 0) {
+ if (boundary_count =3D=3D 0) {
break;
}
}
@@ -642,7 +632,7 @@ static void sdhci_sdma_transfer_multi_blocks(SDHCIState=
*s)
s->prnsts |=3D SDHC_DOING_WRITE;
while (s->blkcnt) {
begin =3D s->data_count;
- if (((boundary_count + begin) < block_size) && page_aligned) {
+ if (((boundary_count + begin) < block_size)) {
s->data_count =3D boundary_count + begin;
boundary_count =3D 0;
} else {
@@ -659,7 +649,7 @@ static void sdhci_sdma_transfer_multi_blocks(SDHCIState=
*s)
s->blkcnt--;
}
}
- if (page_aligned && boundary_count =3D=3D 0) {
+ if (boundary_count =3D=3D 0) {
break;
}
}
--=20
2.34.1
From nobody Mon May 12 06:10:46 2025
Delivered-To: importer@patchew.org
Authentication-Results: mx.zohomail.com;
spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as
permitted sender)
smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org;
dmarc=pass(p=none dis=none) header.from=nongnu.org
ARC-Seal: i=1; a=rsa-sha256; t=1733910747; cv=none;
d=zohomail.com; s=zohoarc;
b=mxASdKftfObWEylloiDqNx6klZ+GnGNX95Jk4tRDs/2fgZjeJaxRK8C7jCvTEeRfgftSGJQlkpU1zu0Am48h2I44rjHqKG2VAO5OjaePr+BzCYKymmOWjjep2cMkqSodbSCBbQ4LY652VRRKnHPfAIKClIz4K5EISWuOrIXQXSM=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com;
s=zohoarc;
t=1733910747;
h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Reply-To:Reply-To:References:Sender:Subject:Subject:To:To:Message-Id;
bh=wxpPr9V67fL40bI34Caoa7TiQivU+7RZ/X+L29N4LNM=;
b=Mpqw2Kam4CvPSioRbDdrSBtn/ORmoC9nmHrUMYskdq9ge30aP4QRwCCSGqbdYmaAHqDmGDuEHD0P+0xGaB9Rd7B9P+01GoJ4q/i8l/Gzj1LUssvO2ztHNtMuqDE565hchNOHGKK42G5Lja53meBxGXYBIXKCZ7Mb9BiYzY5k8aY=
ARC-Authentication-Results: i=1; mx.zohomail.com;
spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as
permitted sender)
smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org;
dmarc=pass header.from=<qemu-devel@nongnu.org> (p=none dis=none)
Return-Path: <qemu-devel-bounces+importer=patchew.org@nongnu.org>
Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by
mx.zohomail.com
with SMTPS id 1733910746962287.16390802677984;
Wed, 11 Dec 2024 01:52:26 -0800 (PST)
Received: from localhost ([::1] helo=lists1p.gnu.org)
by lists.gnu.org with esmtp (Exim 4.90_1)
(envelope-from <qemu-devel-bounces@nongnu.org>)
id 1tLJNS-0006BY-Lu; Wed, 11 Dec 2024 04:51:30 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10])
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <jamin_lin@aspeedtech.com>)
id 1tLJNQ-0006AZ-23; Wed, 11 Dec 2024 04:51:28 -0500
Received: from mail.aspeedtech.com ([211.20.114.72] helo=TWMBX01.aspeed.com)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <jamin_lin@aspeedtech.com>)
id 1tLJNO-00057d-KX; Wed, 11 Dec 2024 04:51:27 -0500
Received: from TWMBX01.aspeed.com (192.168.0.62) by TWMBX01.aspeed.com
(192.168.0.62) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.12; Wed, 11 Dec
2024 17:51:11 +0800
Received: from localhost.localdomain (192.168.10.10) by TWMBX01.aspeed.com
(192.168.0.62) with Microsoft SMTP Server id 15.2.1258.12 via Frontend
Transport; Wed, 11 Dec 2024 17:51:11 +0800
To: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= <philmd@linaro.org>, Bin Meng
<bmeng.cn@gmail.com>, "open list:SD (Secure Card)" <qemu-block@nongnu.org>,
"open list:All patches CC here" <qemu-devel@nongnu.org>
CC: <jamin_lin@aspeedtech.com>, <troy_lee@aspeedtech.com>,
<yunlin.tang@aspeedtech.com>
Subject: [RFC.PATCH v1 2/2] sd:sdhci: Fix data transfer did not complete if
data size is bigger then SDMA Buffer Boundary
Date: Wed, 11 Dec 2024 17:51:10 +0800
Message-ID: <20241211095111.1421928-3-jamin_lin@aspeedtech.com>
X-Mailer: git-send-email 2.25.1
In-Reply-To: <20241211095111.1421928-1-jamin_lin@aspeedtech.com>
References: <20241211095111.1421928-1-jamin_lin@aspeedtech.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17
as permitted sender) client-ip=209.51.188.17;
envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org;
helo=lists.gnu.org;
Received-SPF: pass client-ip=211.20.114.72;
envelope-from=jamin_lin@aspeedtech.com; helo=TWMBX01.aspeed.com
X-Spam_score_int: -18
X-Spam_score: -1.9
X-Spam_bar: -
X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9,
RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001,
SPF_HELO_FAIL=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-BeenThere: qemu-devel@nongnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <https://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
Reply-to: Jamin Lin <jamin_lin@aspeedtech.com>
From: Jamin Lin via <qemu-devel@nongnu.org>
Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org
Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org
X-ZM-MESSAGEID: 1733910747544116600
Content-Type: text/plain; charset="utf-8"
According to the design of sdhci_sdma_transfer_multi_blocks, if the
"s->blkcnt * 512" was bigger than the SDMA Buffer boundary, it breaked the
while loop of data transfer and set SDHC_NISEN_DMA in the normal interreupt
status to notify the firmware that this SDMA boundary buffer Transfer Compl=
ete
and firmware should set the system address of the next SDMA boundary buffer
for the remaining data transfer.
However, after firmware set the system address of the next SDMA boundary bu=
ffer
in the SDMA System Address Register(0x00), SDHCI modle did not start the da=
ta
transfer, again. Finally, firmware breaked the data transfer because firmwa=
re
did not receive the DMA Interrupt and Tansfer Complete Interrupt from SDHCI
model.
Error log from u-boot
```
sdhci_transfer_data: Transfer data timeout
** fs_devread read error - block
```
According to the following mention from SDMA System Address Refister of SDH=
CI
spec,
'''
This register contains the system memory address for an SDMA transfer in
32-bit addressing mode. When the Host Controller stops an SDMA transfer,
this register shall point to the system address of the next contiguous data
position.
It can be accessed only if no transaction is executing (i.e., after a trans=
action
has stopped). Reading this register during SDMA transfers may return an
invalid value.
The Host Driver shall initialize this register before starting an SDMA
transaction.
After SDMA has stopped, the next system address of the next contiguous
data position can be read from this register.
The SDMA transfer waits at the every boundary specified by the SDMA
Buffer Boundary in the Block Size register. The Host Controller generates
DMA Interrupt to request the Host Driver to update this register. The Host
Driver sets the next system address of the next data position to this regis=
ter.
When the most upper byte of this register (003h) is written, the Host Contr=
oller
restarts the SDMA transfer.
''',
restrat the data transfer if firmware set the SDMA System Address, s->blkcnt
is bigger than 0 and SDHCI is in the data transfer state.
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
---
hw/sd/sdhci.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
index 47d96b935b..53c23c5437 100644
--- a/hw/sd/sdhci.c
+++ b/hw/sd/sdhci.c
@@ -1170,6 +1170,15 @@ sdhci_write(void *opaque, hwaddr offset, uint64_t va=
l, unsigned size)
sdhci_sdma_transfer_single_block(s);
}
}
+ } else if (TRANSFERRING_DATA(s->prnsts)) {
+ /* restarts the SDMA transfer if blkcnt is not zero */
+ if (s->blkcnt && SDHC_DMA_TYPE(s->hostctl1) =3D=3D SDHC_CTRL_S=
DMA) {
+ if (s->trnmod & SDHC_TRNS_MULTI) {
+ sdhci_sdma_transfer_multi_blocks(s);
+ } else {
+ sdhci_sdma_transfer_single_block(s);
+ }
+ }
}
break;
case SDHC_BLKSIZE:
--=20
2.34.1