Re: Universal Flash Storage Driver Proposal

On Mon, Jan 20, 2025 at 5:26 PM Jaeyoon Choi <j_yoon.choi@samsung.com>
wrote:

> Hi Warner
>
> Thank you for your reply.
> I have learned a lot from your presentation and paper.
>
> Universal Flash Storage (UFS) only attaches one device to a single
> controller,
> meaning there is only one SCSI target.
> UFS supports a subset of SCSI commands, so the CAM periph driver may need
> to
> restrict requests for certain commands.
> (e.g. UFS does not support the MODE SENSE(6), READ(12)/WRITE(12) commands).
>
> So, I think I can just use the existing SCSI transport. Am I right?
> (I'm referring to sys/dev/usb/storage/umass.c and
> sys/dev/virtio/scsi/virtio_scsi.c).
>

Generally, yes. However, looking at umass, you'll see that different kinds
of USB
thumb drives have different subsets of SCSI that are supported. For
example, RBC
is a reduced subset of commands, and umass filters things so that we have
the right
length (only READ(10) and WRITE(10) are supported for RBC, for example).
I'd image
there'd be a similar list for UFS and you'd need to arrange for scsi_da to
only generate
those. It looks like some kind of quirk info is going on to force this, but
I've not puzzled
through all the layers to find it. umass also does some minor CDB rewriting
for things
like ATAPI that are close. UFI also has a different subset that's supported.

Right now that's all handled by the SIM setting cpi.hba_misc |=
PIM_NO_6_BYTE for
the CAM_PATH_INQ xpt request. You may need to create a PIM_NO_10_BYTE if
only the 12 byte variants are supported, or find some other way to signal
to scsi_da that
it must choose a different way to generate commands (if say a single bit
isn't enough,
or it turns into too much of a specialty quirk flag). Though having said
that, I kinda think
we can retire all the 6-byte command support: we don't need it on anything
modern and
it really is there for the pre-scsi-1 SASI drives that we don't support[*].
We may also want
to rework the number of special cases we have in scsi_da.c as well. There's
a number
of quirks that either go away with no-6-byte commands, or that can be
guessed w/o a loud
message to the user (which is why we avoid sending them with the quirk,
though some
of that avoidance is because some early drives hung).

So the SCSI protocol likely can still be used, but some adjustments might
be needed
to the SCSI transport (though the distinction between the two can get
rather confused at
times).  Eg, I think eventually you'll find you'll want a XPORT_UFS to sit
along side
XPORT_FC, XPORT_SPI, XPORT_SAS, etc. I think the protocol will be PROTO_SCSI
for everything. Each of the transports can and do report slightly different
things in handled
by XPT_GET_TRAN_SETTINGS and XPT_SET_TRAN_SETTINGS messages.

I would greatly appreciate your advice.
>

I hope my advice is useful. Also, although I've given talks on this topic,
you should double
check anything I said in those talks or that I say here. (a) It will help
you learn CAM better
and (b) some of these details I only think I know and understand, but I'm
missing something
subtle (if I knew which points, I'd say :).

Good luck with everything, and don't hesitate to ask if you have questions,
want some early
code review, design advice, etc.

Warner


> Thank you,
> Jaeyoon
>
> > Hi Jaeyoon
> >
> > This sounds really cool!
> >
> > What layering scheme did you have in mind to allow multiple storage
> devices
> > per
> > controller? Will it be a new kind of SIM in the CAM layer, or will it be
> > SCSI with
> > a different transport? Is this a full SCSI implementation, or will the
> CAM
> > periph
> > drivers need to restrict the requests they send down for this? We already
> > have a
> > number of subsets that we handle in an ad-hoc way, but maybe we need to
> be
> > a little
> > more organized about it.
> >
> > In the past, I've helped with the MMC and NVMe integration intro CAM, so
> I
> > have
> > an interest....
> >
> > Warner
> >
> > On Thu, Jan 16, 2025 at 9:54 PM Jaeyoon Choi <j_yoon.choi@samsung.com>
> > wrote:
> >
> > > Hello,
> > >
> > > As I mentioned in my previous email to the mailing list last year, I am
> > > planning
> > > to start developing a Universal Flash Storage Driver.
> > > -
> https://lists.freebsd.org/archives/freebsd-hackers/2024-July/003385.html
> > > Before I begin working on the driver, I would like to share my
> development
> > > plan
> > > with you.
> > >
> > > Universal Flash Storage (UFS) is a storage device for mobile devices
> which
> > > aims
> > > for high performance and low power consumption.
> > > UFS is currently used in most smartphones and tablets, and I believe
> there
> > > is a
> > > demand for UFS support in FreeBSD.
> > >
> > > The Universal Flash Storage Driver is named UFSHCI to avoid confusion
> with
> > > the
> > > UFS filesystem, and is located in the /sys/dev/ufshci folder.
> > >
> > > The driver will be developed based on the UFS 4.1 (JESD220G) and
> UFSHCI 4.1
> > > (JESD223F) specification documents, which are the latest versions
> > > available.
> > > The latest specifications can be found at the following link:
> > > -
> > >
> https://www.jedec.org/standards-documents/focus/flash/universal-flash-storage-ufs
> > >
> > > My plan is to first implement a PCIe-based driver and then make it
> > > compatible
> > > with various smartphone application processors.
> > > Since UFS uses SCSI commands, we need to use the SCSI I/O path of the
> CAM.
> > >
> > > Please note that there is currently a UFSHCI driver in development for
> > > OpenBSD,
> > > but due to its low spec version (UFSHCI 2.1) and lack of compatibility
> with
> > > FreeBSD, I have decided to start from scratch.
> > >
> > > The following platforms will be used for testing:
> > > - QEMU with Emulated UFS device
> > > - Samsung Galaxy Book S (Intel Lakefield + eUFS)
> > > - Lenovo Duet3 11ian8 (Intel N100 + eUFS)
> > >
> > > After developing the UFSHCI driver, I will continue to work on
> additional
> > > features and keep the driver up-to-date with the latest specs.
> > > The approximate development plan is as follows:
> > >
> > > - 2025 1H: Implementation of initialization, basic operations, and
> single
> > >            doorbell-based read/write I/O on Intel CPU-based platforms
> > > - 2025 2H: Implementation of MCQ-based read/write I/O, and
> implementation
> > > of
> > >            additional features such as writebooster
> > >
> > > I look forward to receiving your feedback and suggestions.
> > >
> > > Best regards,
> > > Jaeyoon
> > >
> > >
>