Re: Proposal: U-Boot MTD (rewriting old story)

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 2551 bytes --]

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@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@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.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]