From: Tom Rini <trini@konsulko.com>
To: Varadarajan Narayanan <quic_varada@quicinc.com>
Cc: neil.armstrong@linaro.org, caleb.connolly@linaro.org,
sumit.garg@kernel.org, joe.hershberger@ni.com,
michal.simek@amd.com, marek.vasut+renesas@mailbox.org,
cniedermaier@dh-electronics.com, xypron.glpk@gmx.de,
sjg@chromium.org, u-boot-qcom@groups.io, u-boot@lists.denx.de
Subject: Re: [PATCH v1 0/3] Enable env in UFS
Date: Tue, 6 May 2025 07:32:36 -0600 [thread overview]
Message-ID: <20250506133236.GU5430@bill-the-cat> (raw)
In-Reply-To: <20250506072956.otki522irhggugxp@hu-varada-blr.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 2313 bytes --]
On Tue, May 06, 2025 at 12:59:56PM +0530, Varadarajan Narayanan wrote:
> On Tue, Apr 01, 2025 at 04:37:40PM +0200, neil.armstrong@linaro.org wrote:
> > On 01/04/2025 16:10, Tom Rini wrote:
> > > On Tue, Apr 01, 2025 at 01:30:12PM +0530, Varadarajan Narayanan wrote:
> > >
> > > > The qcs9100 based Ride platforms have UFS as their primary storage.
> > > > Hence add support to U-Boot env framework to be able to save and
> > > > retrieve the environment from UFS. The environment will be
> > > > saved/retrieved from the partition specified in the config option
> > > > CONFIG_SYS_UFS_ENV_PART.
> > > >
> > > > Also add an API to convert partition name string to block device
> > > > descriptor for UFS. This API will be used to get the block device
> > > > descriptor for the partition specified in CONFIG_SYS_UFS_ENV_PART.
> > >
> > > In general, I'm glad to see this, thanks! In specifics, Marek is trying
> > > to bring more consistency to some of the env symbol names and so I know
> > > CONFIG_SYS_UFS_ENV_PART is patterned on CONFIG_SYS_MMC_ENV_PART but lets
> > > use CONFIG_ENV_UFS_PART instead which I think follows where Marek is
> > > going.
> > >
> > > Also, this seems to be a generic ENV_IS_IN_SCSI implementation and it's
> > > just that UFS is accessed via "SCSI"? Perhaps we should name things a
> > > bit more generically, and it should already support various AHCI SATA
> > > devices out of the box?
> >
> > I agree we should use scsi to access ufs, we do not need a specific
> > ufs backend anywhere.
>
> Reviewers,
>
> Thanks for the feedback. Have posted v2 addressing the concerns.
> Please take a look.
>
> > > However all of that said, do we want to be encouraging environment to be
> > > stored directly in blocks like this rather than a filesystem on UFS?
>
> Enabling CONFIG_ENV_IS_IN_FAT and configuring CONFIG_ENV_FAT_xxx options
> appropriately works for these platforms. However, the current build
> system doesn't generate a FS image for default env settings. Hence,
> going with direct block storage instead of FS storage. Hope that is ok.
In the case of first boot where the env isn't found, it will use the
default built-in and create it upon "saveenv". This is the normal flow,
so I don't follow you here, sorry.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
prev parent reply other threads:[~2025-05-06 13:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-01 8:00 [PATCH v1 0/3] Enable env in UFS Varadarajan Narayanan
2025-04-01 8:00 ` [PATCH v1 1/3] scsi: Implement get_blk() function Varadarajan Narayanan
2025-04-01 16:29 ` Heinrich Schuchardt
2025-04-02 15:56 ` Varadarajan Narayanan
2025-04-01 8:00 ` [PATCH v1 2/3] env: Add support for storing env variables in UFS Varadarajan Narayanan
2025-04-01 8:00 ` [PATCH v1 3/3] configs: qcs9100: Enable env " Varadarajan Narayanan
2025-04-07 6:26 ` Michal Simek
2025-04-01 14:10 ` [PATCH v1 0/3] " Tom Rini
2025-04-01 14:37 ` neil.armstrong
2025-05-06 7:29 ` Varadarajan Narayanan
2025-05-06 13:32 ` Tom Rini [this message]
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=20250506133236.GU5430@bill-the-cat \
--to=trini@konsulko.com \
--cc=caleb.connolly@linaro.org \
--cc=cniedermaier@dh-electronics.com \
--cc=joe.hershberger@ni.com \
--cc=marek.vasut+renesas@mailbox.org \
--cc=michal.simek@amd.com \
--cc=neil.armstrong@linaro.org \
--cc=quic_varada@quicinc.com \
--cc=sjg@chromium.org \
--cc=sumit.garg@kernel.org \
--cc=u-boot-qcom@groups.io \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.