From: Andre Przywara <andre.przywara@arm.com>
To: Sean Anderson <sean.anderson@seco.com>
Cc: Simon Glass <sjg@chromium.org>,
Jagan Teki <jagan@amarulasolutions.com>,
u-boot@lists.denx.de, linux-sunxi@lists.linux.dev,
Patrick Delaunay <patrick.delaunay@foss.st.com>,
Heiko Schocher <hs@denx.de>,
Kever Yang <kever.yang@rock-chips.com>,
Philipp Tomsich <philipp.tomsich@vrull.eu>
Subject: Re: [RFC PATCH 2/3] sunxi: Implement fastboot_get_mmc_device()
Date: Mon, 24 May 2021 15:57:27 +0100 [thread overview]
Message-ID: <20210524155727.444a71f0@slackpad.fritz.box> (raw)
In-Reply-To: <c4cd77a4-5e61-d2a4-15e3-164024e0051f@seco.com>
On Mon, 24 May 2021 10:33:58 -0400
Sean Anderson <sean.anderson@seco.com> wrote:
Hi Sean,
> On 5/23/21 8:36 PM, Andre Przywara wrote:
> > The default MMC device to use for the fastboot flash command is hard to
> > decide at runtime, since the numbering of the MMC devices depends on
> > devicetree nodes. On the hardware side, the eMMC is connected to device
> > 2, but this might be U-Boot's device 1 or 2, depending on whether the DT
> > contains a WiFi node for the hardware MMC1 device.
>
> Can you fix this with aliases? e.g.
>
> aliases {
> mmc0 = &mmc0;
> mmc1 = &mmc1;
> mmc2 = &mmc2;
> };
>
> That way the mmcs will always have the same number even if (e.g.) hardware mmc 1 is absent.
Well, that is partly what we do today: we have a "mmc1=&mmc2;"(!) in
sunxi-u-boot.dtsi, to fix the device name for the eMMC to 1 (the
eMMC hardware controller is always &mmc2).
But actually this is fragile, and might collide when for instance the
above aliases get introduced (Rockchip got those already in Linux, and
there are patches proposed for sunxi as well, but they don't see much
love).
So I would rather see we remove the dependency on certain U-Boot device
numbers, and this patch here being the first step.
As I see it this new solution expresses directly what we want: use the
eMMC is we have one. And do this without relying on certain U-Boot
implementation or hardware details.
Apart from the above aliases being much easier, do you see problems
with this patch here? Happy to hear about any issues. And as it
stands atm, this would only be used for sunxi.
Cheers,
Andre
> >
> > To avoid hardcoding this for each board, let's scan all MMC devices, and
> > try to find the eMMC device, given that this is enabled. If not, we use
> > the SD card.
> >
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> > board/sunxi/board.c | 37 +++++++++++++++++++++++++++++++++++++
> > 1 file changed, 37 insertions(+)
> >
> > diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> > index 21651a1bfca..5f64887e48b 100644
> > --- a/board/sunxi/board.c
> > +++ b/board/sunxi/board.c
> > @@ -625,6 +625,43 @@ int board_mmc_init(struct bd_info *bis)
> > }
> > #endif
> >
> > +#ifdef CONFIG_FASTBOOT_FLASH_MMC
> > +int fastboot_get_mmc_device(void)
> > +{
> > + struct udevice *dev;
> > + static int mmc_dev = -1;
> > + int sd_card = -1;
> > +
> > + if (mmc_dev != -1)
> > + return mmc_dev;
> > +
> > + for (uclass_first_device(UCLASS_MMC, &dev);
> > + dev;
> > + uclass_next_device(&dev)) {
> > + struct mmc *mmc = mmc_get_mmc_dev(dev);
> > +
> > + mmc_init(mmc);
> > + if (!mmc->has_init)
> > + continue;
> > +
> > + if (IS_SD(mmc)) {
> > + sd_card = dev->seq_;
> > + continue;
> > + } else {
> > + mmc_dev = dev->seq_;
> > + break;
> > + }
> > + }
> > +
> > + if (mmc_dev == -1)
> > + mmc_dev = sd_card;
> > + if (mmc_dev == -1)
> > + mmc_dev = 0;
> > +
> > + return mmc_dev;
> > +}
> > +#endif
> > +
> > #ifdef CONFIG_SPL_BUILD
> >
> > static void sunxi_spl_store_dram_size(phys_addr_t dram_size)
> >
next prev parent reply other threads:[~2021-05-24 14:57 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-24 0:36 [RFC PATCH 0/3] fastboot: sunxi: Determine MMC device at runtime Andre Przywara
2021-05-24 0:36 ` [RFC PATCH 1/3] fastboot: Allow runtime determination of MMC device Andre Przywara
2021-05-27 13:44 ` Simon Glass
2021-05-24 0:36 ` [RFC PATCH 2/3] sunxi: Implement fastboot_get_mmc_device() Andre Przywara
2021-05-24 14:33 ` Sean Anderson
2021-05-24 14:57 ` Andre Przywara [this message]
2021-05-24 0:36 ` [RFC PATCH 3/3] sunxi: Drop sunxi FASTBOOT_FLASH_MMC_DEV defaults Andre Przywara
2021-05-24 14:37 ` [RFC PATCH 0/3] fastboot: sunxi: Determine MMC device at runtime Sean Anderson
2021-05-24 15:15 ` Andre Przywara
2021-05-24 15:33 ` Sean Anderson
2021-05-24 15:28 ` Maxime Ripard
2021-05-24 15:43 ` Sean Anderson
2021-06-07 15:14 ` Maxime Ripard
2021-06-07 15:21 ` Sean Anderson
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=20210524155727.444a71f0@slackpad.fritz.box \
--to=andre.przywara@arm.com \
--cc=hs@denx.de \
--cc=jagan@amarulasolutions.com \
--cc=kever.yang@rock-chips.com \
--cc=linux-sunxi@lists.linux.dev \
--cc=patrick.delaunay@foss.st.com \
--cc=philipp.tomsich@vrull.eu \
--cc=sean.anderson@seco.com \
--cc=sjg@chromium.org \
--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;
as well as URLs for NNTP newsgroup(s).