mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: "Hans Christian Lønstad" <hcl@datarespons.no>,
	"barebox@lists.infradead.org" <barebox@lists.infradead.org>
Subject: Re: Imx-usb-loader broken on IMX8MP/v2022.09.0
Date: Tue, 27 Sep 2022 18:42:47 +0100	[thread overview]
Message-ID: <e0778785-7de6-f91c-d4b1-3f828f6effe1@pengutronix.de> (raw)
In-Reply-To: <8CA6ADB4-FD4B-4CC8-9BD2-21DA02C08C85@datarespons.no>

Hello Hans,

On 17.09.22 13:04, Hans Christian Lønstad wrote:
> This is observed using straight out of the box v2022.09.0 on NXP IMX8MP Eval kit:
> 
> ---------
> 
> $ sudo ../drimx8/scripts/imx/imx-usb-loader ../drimx8/images/barebox-nxp-imx8mp-evk.img 
> [sudo] password for hcl: 
> found i.MX8MP USB device [1fc9:0146]
> 4 in err=-9, last_trans=0  00 00 00 00
> status failed

I just tested and have the same issue on i.MX8M Nano, which uses
the same new SDPS protocol. I've just sent out a potential fix.

> ————
> 
> Stripping off the header gap (32K) allows the binary to load using the standard NXP uuu (Ubuntu 22.04) utility,.
> 
> This further raises the question: Why have a header gap at all?
> 
> The makes sense for SD card loading, but not for eMMC boot partitions where ROM expects code to start at 0.

The realization that the eMMC boot partition usually lacks an on-disk partition
table came quite late to the NXP BootROM authors. On i.MX8M Mini, we still have
an offset for both SD-Card and eMMC boot partition.

> Maybe better just use a seek to put the code at the relevant position on the SD card?

imx-usb-loader does the correct thing and skips to the relevant position.
barebox_update should do the correct thing and skip over the header.

> For instance, I am using the Rauc boot loader slot update mechanism expecting no gap thus  requiring me to shave of 32k
> prior to shipping.

This is unfortunate, but I don't think this is something we should address at the
barebox side. barebox images for i.MX are always meant to be directly written
to an SD-Card at offset 0.

For RAUC integration, you may consider having your build system shave off the
bytes transparently. See for example:

https://github.com/rauc/meta-rauc/commit/8e049699f05483b694e6c5a3e260cd9e0fe58d2e

which does the inverse operation: pad U-Boot for older i.MX, so they are install-able
into an eMMC boot partition.

Cheers,
Ahmad

> 
> Comments??
> 
> Hans Christian
> 


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |



  reply	other threads:[~2022-09-27 17:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-17 12:04 Hans Christian Lønstad
2022-09-27 17:42 ` Ahmad Fatoum [this message]
2022-09-28 10:18   ` Info Skymem

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=e0778785-7de6-f91c-d4b1-3f828f6effe1@pengutronix.de \
    --to=a.fatoum@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=hcl@datarespons.no \
    /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