Date: Tue, 21 Jan 2025 14:59:26 -0700 From: Warner Losh <imp@bsdimp.com> To: j_yoon.choi@samsung.com Cc: "freebsd-hackers@FreeBSD.org" <freebsd-hackers@freebsd.org> Subject: Re: Universal Flash Storage Driver Proposal Message-ID: <CANCZdfpVZhQ7dO5qzm9XDTA4qirOmoA-NLx-V5QmEpm_-9g43g@mail.gmail.com> In-Reply-To: <20250121002602epcms2p6067990e98b8143ff596d90af0ec54492@epcms2p6> References: <20250117045346epcms2p61099ea651d3ca3f00e3134dd00e6a9ac@epcms2p6> <CGME20250117045346epcms2p61099ea651d3ca3f00e3134dd00e6a9ac@epcms2p6> <CANCZdfotpi0W8ivsShzvWqgaCQhCOU0enb_RrPn7QdMEvvXpnw@mail.gmail.com> <20250121002602epcms2p6067990e98b8143ff596d90af0ec54492@epcms2p6>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <j_yoon.choi@samsung.c= om> 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 <j_yoon.choi@samsu= ng.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-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 <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g= mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jan 20,= 2025 at 5:26=E2=80=AFPM Jaeyoon Choi <<a href=3D"mailto:j_yoon.choi@sam= sung.com">j_yoon.choi@samsung.com</a>> wrote:<br></div><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg= b(204,204,204);padding-left:1ex">Hi Warner<br> <br> Thank you for your reply.<br> I have learned a lot from your presentation and paper.<br> <br> Universal Flash Storage (UFS) only attaches one device to a single controll= er,<br> meaning there is only one SCSI target.<br> UFS supports a subset of SCSI commands, so the CAM periph driver may need t= o<br> restrict requests for certain commands.<br> (e.g. UFS does not support the MODE SENSE(6), READ(12)/WRITE(12) commands).= <br> <br> So, I think I can just use the existing SCSI transport. Am I right?<br> (I'm referring to sys/dev/usb/storage/umass.c and sys/dev/virtio/scsi/v= irtio_scsi.c).<br></blockquote><div><br></div><div>Generally, yes. However,= looking at umass, you'll see that different kinds of USB</div><div>thu= mb drives have different subsets of SCSI that are supported. For example, R= BC</div><div>is a reduced subset of commands, and umass filters things so t= hat we have the right</div><div>length (only READ(10) and WRITE(10) are sup= ported for RBC, for example). I'd image</div><div>there'd be a simi= lar list for UFS and you'd need to arrange for scsi_da to only generate= </div><div>those. It looks like some kind of quirk info is going on to forc= e this, but I've not puzzled</div><div>through all the layers to find i= t. umass also does some minor CDB rewriting for things</div><div>like ATAPI= that are close. UFI also has a different subset that's supported.</div= ><div><br></div><div>Right now that's all handled by the SIM setting=C2= =A0cpi.hba_misc |=3D PIM_NO_6_BYTE for</div><div>the CAM_PATH_INQ xpt reque= st. You may need to create a PIM_NO_10_BYTE if</div><div>only the 12 byte v= ariants are supported, or find some other way to signal to scsi_da that</di= v><div>it must choose a different way to generate commands (if say a single= bit isn't enough,</div><div>or it turns into too much of a specialty q= uirk flag). Though having said that, I kinda think</div><div>we can retire = all the 6-byte command support: we don't need it on anything modern and= </div><div>it really is there for the pre-scsi-1 SASI drives that we don= 9;t support[*]. We may also want</div><div>to rework the number of special = cases we have in scsi_da.c as well. There's a number</div><div>of quirk= s that either go away with no-6-byte commands, or that can be guessed w/o a= loud</div><div>message to the user (which is why we avoid sending them wit= h the quirk, though some</div><div>of that avoidance is because some early = drives hung).</div><div><br></div><div>So the SCSI protocol likely can stil= l be used, but some adjustments might be needed</div><div>to the SCSI trans= port (though the distinction between the two can get rather confused at</di= v><div>times).=C2=A0 Eg, I think eventually you'll find you'll want= a=C2=A0XPORT_UFS to sit along side</div><div>XPORT_FC, XPORT_SPI, XPORT_SA= S, etc. I think the protocol will be PROTO_SCSI</div><div>for everything. E= ach of the transports can and do report slightly different things in handle= d</div><div>by=C2=A0XPT_GET_TRAN_SETTINGS and=C2=A0XPT_SET_TRAN_SETTINGS me= ssages.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"marg= in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e= x">I would greatly appreciate your advice.<br></blockquote><div><br></div><= div>I hope my advice is useful. Also, although I've given talks on this= topic, you should double</div><div>check anything I said in those talks or= that I say here. (a) It will help you learn CAM better</div><div>and (b) s= ome of these details I only think I know and understand, but I'm missin= g something</div><div>subtle (if I knew which points, I'd say :).</div>= <div><br></div><div>Good luck with everything, and don't hesitate to as= k if you have questions, want some early</div><div>code review, design advi= ce, etc.</div><div><br></div><div>Warner</div><div>=C2=A0</div><blockquote = class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol= id rgb(204,204,204);padding-left:1ex"> Thank you,<br> Jaeyoon<br> <br> > Hi Jaeyoon<br> > <br> > This sounds really cool!<br> > <br> > What layering scheme did you have in mind to allow multiple storage de= vices<br> > per<br> > controller? Will it be a new kind of SIM in the CAM layer, or will it = be<br> > SCSI with<br> > a different transport? Is this a full SCSI implementation, or will the= CAM<br> > periph<br> > drivers need to restrict the requests they send down for this? We alre= ady<br> > have a<br> > number of subsets that we handle in an ad-hoc way, but maybe we need t= o be<br> > a little<br> > more organized about it.<br> > <br> > In the past, I've helped with the MMC and NVMe integration intro C= AM, so I<br> > have<br> > an interest....<br> > <br> > Warner<br> > <br> > On Thu, Jan 16, 2025 at 9:54=E2=80=AFPM Jaeyoon Choi <<a href=3D"ma= ilto:j_yoon.choi@samsung.com" target=3D"_blank">j_yoon.choi@samsung.com</a>= ><br> > wrote:<br> > <br> > > Hello,<br> > ><br> > > As I mentioned in my previous email to the mailing list last year= , I am<br> > > planning<br> > > to start developing a Universal Flash Storage Driver.<br> > > - <a href=3D"https://lists.freebsd.org/archives/freebsd-hackers/2= 024-July/003385.html" rel=3D"noreferrer" target=3D"_blank">https://lists.fr= eebsd.org/archives/freebsd-hackers/2024-July/003385.html</a><br> > > Before I begin working on the driver, I would like to share my de= velopment<br> > > plan<br> > > with you.<br> > ><br> > > Universal Flash Storage (UFS) is a storage device for mobile devi= ces which<br> > > aims<br> > > for high performance and low power consumption.<br> > > UFS is currently used in most smartphones and tablets, and I beli= eve there<br> > > is a<br> > > demand for UFS support in FreeBSD.<br> > ><br> > > The Universal Flash Storage Driver is named UFSHCI to avoid confu= sion with<br> > > the<br> > > UFS filesystem, and is located in the /sys/dev/ufshci folder.<br> > ><br> > > The driver will be developed based on the UFS 4.1 (JESD220G) and = UFSHCI 4.1<br> > > (JESD223F) specification documents, which are the latest versions= <br> > > available.<br> > > The latest specifications can be found at the following link:<br> > > -<br> > > <a href=3D"https://www.jedec.org/standards-documents/focus/flash/= universal-flash-storage-ufs" rel=3D"noreferrer" target=3D"_blank">https://w= ww.jedec.org/standards-documents/focus/flash/universal-flash-storage-ufs</a= ><br> > ><br> > > My plan is to first implement a PCIe-based driver and then make i= t<br> > > compatible<br> > > with various smartphone application processors.<br> > > Since UFS uses SCSI commands, we need to use the SCSI I/O path of= the CAM.<br> > ><br> > > Please note that there is currently a UFSHCI driver in developmen= t for<br> > > OpenBSD,<br> > > but due to its low spec version (UFSHCI 2.1) and lack of compatib= ility with<br> > > FreeBSD, I have decided to start from scratch.<br> > ><br> > > The following platforms will be used for testing:<br> > > - QEMU with Emulated UFS device<br> > > - Samsung Galaxy Book S (Intel Lakefield + eUFS)<br> > > - Lenovo Duet3 11ian8 (Intel N100 + eUFS)<br> > ><br> > > After developing the UFSHCI driver, I will continue to work on ad= ditional<br> > > features and keep the driver up-to-date with the latest specs.<br= > > > The approximate development plan is as follows:<br> > ><br> > > - 2025 1H: Implementation of initialization, basic operations, an= d single<br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 doorbell-based read/writ= e I/O on Intel CPU-based platforms<br> > > - 2025 2H: Implementation of MCQ-based read/write I/O, and implem= entation<br> > > of<br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 additional features such= as writebooster<br> > ><br> > > I look forward to receiving your feedback and suggestions.<br> > ><br> > > Best regards,<br> > > Jaeyoon<br> > ><br> > ><br> </blockquote></div></div> --0000000000003be423062c3e7e79--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpVZhQ7dO5qzm9XDTA4qirOmoA-NLx-V5QmEpm_-9g43g>