On Tue, Apr 01, 2025 at 04:37:40PM +0200, neil.armstr...@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. Thanks again. -Varada