From nobody Tue Jan 21 21:59:26 2025 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Yd1Mb6K3Xz5lfbb for ; Tue, 21 Jan 2025 21:59:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Yd1Mb2fQfz42L8 for ; Tue, 21 Jan 2025 21:59:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1029.google.com with SMTP id 98e67ed59e1d1-2f42992f608so8689452a91.0 for ; Tue, 21 Jan 2025 13:59:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1737496778; x=1738101578; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Fd9CnLmtI+KxEHP94PPjWJKCyj7Mej+fam6KheM4jdI=; b=XOW8nuyvx2jOoeAYEFfoZkWQmFHqEj7YN5INLPMLVY+EcJykAUQUvKPCXB25MTMMpK 2OJnnLkpC9rVU5YmPKSmm2AZC7LlJBUEbxqyaBQWikmX5s7ErL/obntIR6aOzTMggovS a9jag8j8WEvjwI71+ngtlfmFafhsnCi3XCuCE8rDn69wrgHoOlO2/obomI0yh/q+ETZy 378i0pAlvSrDrfyzD3tFtXYrIVuzNKM/emBf0QS25NJy4VQUuwYiQYPg+xlBWHMKin4V XvJfQNFXhwBch9Da6VrMWKqBfKSX3+IDpOum1cpK+5pYQOK20EikYtf91E/pMknL7dAX EJkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737496778; x=1738101578; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Fd9CnLmtI+KxEHP94PPjWJKCyj7Mej+fam6KheM4jdI=; b=evoNrGlX4ax3o5uBS6ukZedFlGK60/m/KKLib5UTndqhWWvyrj8uiFYIz7qUlBNpn1 713dXEyZrCvqhUn/3tcnszbshcyRMkNu2eFtnqzByDGSBG+6lJp4P2b6ZnCjsFOKlnqV Ya7dEOphSizaADHS6ALXME5akLvj3aI2uicvV/Xf/BcEI19o9Sx3NvectMkD6ioTq2rp lW30hRK6jpblyjWyXqnci0xqFBGb2KQa2ftAXGg71yddX0BDkxBsQMKnhpZR9OGvfAD8 r67PvmCkeVDY2tu8XHAPld0mvFdPXOqE6yz9uQic1BX8f+7u6ppiqXDwroh0KHKd/ZmF 754A== X-Gm-Message-State: AOJu0YxbeEA98KNW3edcy1X54rHTA+edwIKOlH3Zx2Ekig/wbegAIis5 irzKlm8Fzgc+HJOJHDrnDzpELxWSirHF09PTzysWnZ77L1lV+kdzWouZr02mkV4HYCxAiFN/bGo tfixLSWb1Qf4dTLdaCKw+vKnbCCrJes2i+rIIkA== X-Gm-Gg: ASbGncu1gXuzgeOqYc8PCLUnHpZWJrXiwDGFImInV+xDKGxZo1kd4o0ps/a/4mmuY/S K8b9ez+Mdecm3pojTmeKxfoi1Ewc0fcVLAa/Ziyt2yg+XcfRZggE= X-Google-Smtp-Source: AGHT+IEhQOT12ZZWmMJeM56HNidbr7b6FHX2ECPzXxIzRF3+O0D0cAd96PJmXMfc0nNuHUNDxRnQ4e9ud5WsOZfux6s= X-Received: by 2002:a05:6a00:3c93:b0:725:e957:1dd1 with SMTP id d2e1a72fcca58-72dafa9ab8bmr22476849b3a.17.1737496777704; Tue, 21 Jan 2025 13:59:37 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: <20250117045346epcms2p61099ea651d3ca3f00e3134dd00e6a9ac@epcms2p6> <20250121002602epcms2p6067990e98b8143ff596d90af0ec54492@epcms2p6> In-Reply-To: <20250121002602epcms2p6067990e98b8143ff596d90af0ec54492@epcms2p6> From: Warner Losh Date: Tue, 21 Jan 2025 14:59:26 -0700 X-Gm-Features: AbW1kvb8YPSKLaOfmbjurmTOEClXVC7GUv7V78611-_T6vDofNUM8iW-XE3-XkA Message-ID: Subject: Re: Universal Flash Storage Driver Proposal To: j_yoon.choi@samsung.com Cc: "freebsd-hackers@FreeBSD.org" Content-Type: multipart/alternative; boundary="0000000000003be423062c3e7e79" X-Rspamd-Queue-Id: 4Yd1Mb2fQfz42L8 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] --0000000000003be423062c3e7e79 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 20, 2025 at 5:26=E2=80=AFPM Jaeyoon Choi 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 |=3D 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_SCS= I 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 b= e > > 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 alrea= dy > > 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, s= o > I > > have > > an interest.... > > > > Warner > > > > On Thu, Jan 16, 2025 at 9:54=E2=80=AFPM Jaeyoon Choi > > 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-sto= rage-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 fo= r > > > OpenBSD, > > > but due to its low spec version (UFSHCI 2.1) and lack of compatibilit= y > 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 > > > > > > > --0000000000003be423062c3e7e79 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jan 20,= 2025 at 5:26=E2=80=AFPM 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 controll= er,
meaning there is only one SCSI target.
UFS supports a subset of SCSI commands, so the CAM periph driver may need t= o
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/v= irtio_scsi.c).

Generally, yes. However,= looking at umass, you'll see that different kinds of USB
thu= mb drives have different subsets of SCSI that are supported. For example, R= BC
is a reduced subset of commands, and umass filters things so t= hat we have the right
length (only READ(10) and WRITE(10) are sup= ported for RBC, for example). I'd image
there'd be a simi= lar 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 forc= e this, but I've not puzzled
through all the layers to find i= t. 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=C2= =A0cpi.hba_misc |=3D PIM_NO_6_BYTE for
the CAM_PATH_INQ xpt reque= st. You may need to create a PIM_NO_10_BYTE if
only the 12 byte v= ariants 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 q= uirk 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= 9;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 quirk= s 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 wit= h the quirk, though some
of that avoidance is because some early = drives hung).

So the SCSI protocol likely can stil= l be used, but some adjustments might be needed
to the SCSI trans= port (though the distinction between the two can get rather confused at
times).=C2=A0 Eg, I think eventually you'll find you'll want= a=C2=A0XPORT_UFS to sit along side
XPORT_FC, XPORT_SPI, XPORT_SA= S, etc. I think the protocol will be PROTO_SCSI
for everything. E= ach of the transports can and do report slightly different things in handle= d
by=C2=A0XPT_GET_TRAN_SETTINGS and=C2=A0XPT_SET_TRAN_SETTINGS me= ssages.

I would greatly appreciate your advice.

<= div>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) s= ome of these details I only think I know and understand, but I'm missin= g something
subtle (if I knew which points, I'd say :).
=

Good luck with everything, and don't hesitate to as= k if you have questions, want some early
code review, design advi= ce, etc.

Warner
=C2=A0
Thank you,
Jaeyoon

> Hi Jaeyoon
>
> This sounds really cool!
>
> What layering scheme did you have in mind to allow multiple storage de= vices
> 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 alre= ady
> have a
> number of subsets that we handle in an ad-hoc way, but maybe we need t= o be
> a little
> more organized about it.
>
> In the past, I've helped with the MMC and NVMe integration intro C= AM, so I
> have
> an interest....
>
> Warner
>
> On Thu, Jan 16, 2025 at 9:54=E2=80=AFPM 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.fr= eebsd.org/archives/freebsd-hackers/2024-July/003385.html
> > Before I begin working on the driver, I would like to share my de= velopment
> > plan
> > with you.
> >
> > Universal Flash Storage (UFS) is a storage device for mobile devi= ces which
> > aims
> > for high performance and low power consumption.
> > UFS is currently used in most smartphones and tablets, and I beli= eve there
> > is a
> > demand for UFS support in FreeBSD.
> >
> > The Universal Flash Storage Driver is named UFSHCI to avoid confu= sion 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://w= ww.jedec.org/standards-documents/focus/flash/universal-flash-storage-ufs
> >
> > My plan is to first implement a PCIe-based driver and then make i= t
> > 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 developmen= t for
> > OpenBSD,
> > but due to its low spec version (UFSHCI 2.1) and lack of compatib= ility 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 ad= ditional
> > 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, an= d single
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 doorbell-based read/writ= e I/O on Intel CPU-based platforms
> > - 2025 2H: Implementation of MCQ-based read/write I/O, and implem= entation
> > of
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 additional features such= as writebooster
> >
> > I look forward to receiving your feedback and suggestions.
> >
> > Best regards,
> > Jaeyoon
> >
> >
--0000000000003be423062c3e7e79--