Proposal: U-Boot MTD (rewriting old story)

[Bin Meng]

On Fri, Aug 6, 2021 at 3:40 AM Tom Rini <trini at konsulko.com> wrote:
>
> On Thu, Aug 05, 2021 at 01:20:51PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Wed, 4 Aug 2021 at 12:49, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Wed, Aug 04, 2021 at 10:09:55AM -0600, Simon Glass wrote:
> > > > Hi Jagan,
> > > >
> > > > On Tue, 3 Aug 2021 at 09:01, Jagan Teki <jagan at amarulasolutions.com> wrote:
> > > > >
> > > > > Yes, this is the old discussion and triggered again now since we had a
> > > > > discussion on the last U-Boot contributor call.
> > > > >
> > > > > I will brief the main points here, as most of the details are
> > > > > mentioned in previous threads.
> > > > >
> > > > > Here are the couple of old and new implementations on the SPI-NOR side.
> > > > >
> > > > > http://u-boot.10912.n7.nabble.com/PATCH-v10-00-27-dm-Generic-MTD-Subsystem-with-SPI-NOR-interface-tt315694.html#none
> > > > > http://u-boot.10912.n7.nabble.com/PATCH-0-5-mtd-Implement-MTD-UCLASS-use-SPINOR-td419538.html#a419541
> > > > > https://patchwork.ozlabs.org/project/uboot/cover/20200709111709.68904-1-jagan@amarulasolutions.com/
> > > > >
> > > > > Idea is to
> > > > > 1. Create MTD_UCLASS, already present
> > > > > 2. Create DM MTD Operations, above patchset does.
> > > > > 3. Create Flash specific MTD UClass's like
> > > > >     UCLASS_NAND
> > > > >     UCLASS_SPI_NAND
> > > > >     UCLASS_SPI_NOR
> > > > >     UCLASS_NOR
> > > > >     UCLASS_UBI
> > > > > and register to UCLASS_MTD as interface slaves like how MMC, SCSI are
> > > > > registered to UCLASS_BLK
> > > > > 4. Sync only respective flash specific code, and drop __UBOOT__
> > > > > 5. Interface mtd, sf, and nand commands to UCLASS_MTD.
> > > >
> > > > This all seems good to me.
> > > >
> > > > >
> > > > > Hard points:
> > > > > 1. Hard to arrange Linux specific code and drop unneeded _UBOOT_ code,
> > > > > but possible.
> > > > > 2. Requires a lot of testing.
> > > >
> > > > Let's add simple emulators for NAND, SPI_NAND and UBI. We already have
> > > > one for SPI_NOR I believe. That will be a good long-term investment.
> > >
> > > What are our viable options here via QEMU?
> >
> > I don't mean QEMU, just sandbox emulators. They are pretty simple to
> > write and faster/easier to run and debug than qemu.
>
> If something exists in QEMU today, there's nothing to write.  There are
> many things sandbox is good for, and that I wish we made more use of (it
> would be amazing if allyesconfig was viable for sandbox so everything
> outside of arch/ could be static analyzed for example).  But when it
> comes to driver testing, I really want to know what we can do with QEMU
> first.

Agree, I believe we can do something on QEMU ARM/RISC-V virt (NOR) and
RISC-V sifive_u (spi-nor).

Regards,
Bin