mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Marco Felsch <m.felsch@pengutronix.de>
To: barebox@lists.infradead.org
Subject: [PATCH] scripts: imx-image: don't pad the final binary for i.MX8M devices
Date: Tue, 14 Nov 2023 14:33:58 +0100	[thread overview]
Message-ID: <20231114133358.3746051-1-m.felsch@pengutronix.de> (raw)

If the padding was required the follwing error may appear:

| found i.MX8MP USB device [1fc9:0146]
| No dcd table in this ivt
| dl_command err=-1, last_trans=-1
| 4 in err=-4, last_trans=0  00 00 00 00

The error is triggered since the target request only the required size
of bytes and move on as soon as all bytes are received while, on the other
hand, host tools like imx-usb-loader and uuu try to send the complete
file size.

The alignment was introduced long time ago by commit 7cb4778e7f49
("imx-image: pad generated image to 4k") and may be required for HAB
boot on older SoCs like i.MX6/7. On these SoCs the CSF data is placed
behind the whole barebox image including the optional padding. On newer
SoCs like the i.MX8M* this isn't the case anymore. On these SoCs the CSF
is placed behind the barebox-pbl (aligned to 0x1000). So the final padding
isn't required anymore on these SoCs.

Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
---
 scripts/imx/imx-image.c | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/scripts/imx/imx-image.c b/scripts/imx/imx-image.c
index 1f96b383901f..a5639d696931 100644
--- a/scripts/imx/imx-image.c
+++ b/scripts/imx/imx-image.c
@@ -1100,12 +1100,21 @@ int main(int argc, char *argv[])
 
 	xwrite(outfd, infile, insize);
 
-	/* pad until next 4k boundary */
-	now = 4096 - (insize % 4096);
-	if (data.csf && now) {
-		memset(buf, 0x5a, now);
+	/*
+	 * The alignment may be required on ARMv7 SoCs like i.MX6/7 for HAB
+	 * boot. On newer SoCs like i.MX8MP/N this cause libusb communication
+	 * errors while uploading images because these machines request the
+	 * exact amount of required bytes and move on afterwards while the host
+	 * tool still try to send the whole (padded) file size.
+	 */
+	if (!cpu_is_mx8m(&data)) {
+		/* pad until next 4k boundary */
+		now = 4096 - (insize % 4096);
+		if (data.csf && now) {
+			memset(buf, 0x5a, now);
 
-		xwrite(outfd, buf, now);
+			xwrite(outfd, buf, now);
+		}
 	}
 
 	ret = close(outfd);
-- 
2.39.2




             reply	other threads:[~2023-11-14 13:35 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-14 13:33 Marco Felsch [this message]
2023-12-05  8:12 ` Sascha Hauer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231114133358.3746051-1-m.felsch@pengutronix.de \
    --to=m.felsch@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox