public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Ye Li <ye.li@nxp.com>
To: "marex@denx.de" <marex@denx.de>,
	"u-boot@lists.denx.de" <u-boot@lists.denx.de>
Cc: Peng Fan <peng.fan@nxp.com>,
	"festevam@denx.de" <festevam@denx.de>,
	"sbabic@denx.de" <sbabic@denx.de>
Subject: Re: [EXT] [PATCH] ARM: imx: romapi: Repair FlexSPI NOR boot offset
Date: Tue, 29 Mar 2022 09:56:51 +0000	[thread overview]
Message-ID: <1648547811.123397.86.camel@nxp.com> (raw)
In-Reply-To: <57e91c30-aaac-60cc-b2e6-15bf4b3ca9ae@denx.de>

On Tue, 2022-03-29 at 11:01 +0200, Marek Vasut wrote:
> Caution: EXT Email
> 
> On 3/29/22 04:49, Ye Li wrote:
> 
> Hi,
> 
> > 
> > > 
> > > > 
> > > > If you change the ROM API driver, that will break our design.
> > > > You
> > > > can
> > > > try to overwrite spl_romapi_get_uboot_base for your board only.
> > > Since there are no users which boot from flexspi upstream, this
> > > design
> > > can still be fixed such that it does not require different
> > > flash.bin
> > > for
> > > different boot media, but rather one flash.bin works on all boot
> > > media.
> > > I think that is much better.
> > Your flash.bin can work on flexspi because you manually program the
> > flexspi configurations header.
> Sure, the header content is described in the MX8MP RM Rev. 1 06/2021
> "6.1.5.3.1 FlexSPI Configuration Block", this has nothing to do with
> this patch.
> 
> > 
> > But once you want to upgrade the
> > flash.bin, flexspi configurations will also be erased due to the
> > block
> > size. Then you have to reprogram the configurations with flash.bin.
> > So most of our customers add the flexspi configurations to
> > flash.bin
> > head. They don't use so called one image for both SD and flexspi.
> There are no upstream users of flexspi right now, see above.
> 
> > 
> > As the spl_romapi_get_uboot_base is defined to weak. It is better
> > to
> > overwrite this function for your particular usage.
> I would much rather prefer to have one flash.bin which works on both
> SD
> card and FlexSPI, on all iMX8M, that is far less confusing. And since
> there are no upstream users of flexspi boot so far, this is how it
> can
> still be implemented, consistently.

I can think out 3 drawbacks using this one flash.bin for flexspi:

1. The flexspi configuration header will be erased when you update the
flash.bin to flexspi device. In a common usage, this header will
combine with flash.bin to a final boot image which is not same with SD.
 
2. How can users update u-boot.itb only if using this one flash.bin?
With the same offset of SD, it causes the u-boot.itb locates at a
offset not block aligned.

3. Not all iMX8M can support this one flash.bin.  8MM and 8MQ have
different IVT. Their flexspi IVT can't work for SD/eMMC.

Best regards,
Ye Li
> 
> If downstream wants to have multiple flash.bin, one for each boot
> media,
> that's up to downstream.
> 
> [...]

  reply	other threads:[~2022-03-29  9:57 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-09 16:09 [PATCH] ARM: imx: romapi: Repair FlexSPI NOR boot offset Marek Vasut
2022-03-21  3:35 ` [EXT] " Ye Li
2022-03-21 14:59   ` Marek Vasut
2022-03-23  2:42     ` Ye Li
2022-03-23 21:16       ` Marek Vasut
2022-03-28  6:54         ` Ye Li
2022-03-28 14:54           ` Marek Vasut
2022-03-29  2:49             ` Ye Li
2022-03-29  9:01               ` Marek Vasut
2022-03-29  9:56                 ` Ye Li [this message]
2022-03-30 22:27                   ` Marek Vasut
2022-03-30 22:36                     ` Fabio Estevam
2022-03-31  4:45                     ` Ye Li
2022-03-31 15:09             ` Tim Harvey
2022-03-31 15:26               ` Marek Vasut
2022-03-31 16:03                 ` Tim Harvey
2022-03-31 16:41                   ` Marek Vasut
2022-03-31 18:02                     ` Tim Harvey
2022-03-31 18:04                       ` Marek Vasut
2022-04-12 21:40 ` sbabic

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=1648547811.123397.86.camel@nxp.com \
    --to=ye.li@nxp.com \
    --cc=festevam@denx.de \
    --cc=marex@denx.de \
    --cc=peng.fan@nxp.com \
    --cc=sbabic@denx.de \
    --cc=u-boot@lists.denx.de \
    /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