Re: Octeon MMC driver

On Sat, Mar 28, 2026 at 12:50=E2=80=AFAM Kevin Bowling <kevin.bowling@kev00=
9.com> wrote:
>
> On Sat, Mar 28, 2026 at 12:49=E2=80=AFAM Kevin Bowling <kevin.bowling@kev=
009.com> wrote:
> >
> > On Sun, Mar 22, 2026 at 8:44=E2=80=AFAM Nick Hudson <[email protected]=
.uk> wrote:
> > >
> > > On 19/03/2026 11:35, Kevin Bowling wrote:
> > > > Hi,
> > > > I have ported OpenBSD's Octeon MMC driver to NetBSD here:
> > > > https://people.freebsd.org/~kbowling/oct_mmc.patch
> > >
> > > Cool. Thanks for working on this.
> > >
> > > > It seems stable with light testing and is now self booting on my ER=
4:
> > > > Octeon ubnt_e100# set bootcmd 'fatload mmc 0 $loadaddr
> > > > netbsd;bootoctlinux $loadaddr coremask=3D0x3 root=3Dwedge:octeon-ro=
ot'
> > > > Octeon ubnt_e100# saveenv
> > > > I would be curious if it works for others and if the code can be
> > > > improved as I am not deeply familiar with Net or Open internals.
> > > > There is a lag when attaching, which I suspect is caused by an SDIO
> > > > check that could be improved.
> > >
> > > Some comments=E2=80=A6
> > >
> > > The cache lock workaround is =E2=80=9Cinteresting=E2=80=9D
> > >
> > >
> > > Don=E2=80=99t use splsdmmc, but instead use your sc_intr_mtx mutex or=
 remove the splsdmmc calls.
> > >
> > > Something like the attached.
> >
> > https://people.freebsd.org/~kbowling/oct_mmc.patch
>
> Sorry the link for my last message should be
> https://people.freebsd.org/~kbowling/oct_mmc_v2.patch
> to track the changes versus the first one.
>
> > That worked.  I had to tweak octmmc_init_bus very slightly to still do
> > the /* Enable the bus */ code before ocmtmmc_acquire(bus) or it hangs
> > on attach.  I think it might be safe because we haven't enabled
> > interrupts yet.
> >
> > >
> > > I guess you=E2=80=99re getting your DTB from a vendor distribution?
> >
> > Hmm interesting.  I guess it's just coming from uboot?  OpenBSD does
> > not have anything additional for e300.
> >
> > We seem to be in the same state as Linux DTS
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree=
/arch/mips/boot/dts/cavium-octeon.
> > I do see compatible files elsewhere like
> > https://git.openwrt.org/openwrt/openwrt/tree/target/linux/octeon/files/=
arch/mips/boot/dts/cavium-octeon.
> >
> > >
> > > ~/netbsd/nbcvs/src % grep -r  "cavium,octeon-[0-9]*-mmc" sys/external=
/gpl2/dts/dist
> > > ~/netbsd/nbcvs/src %
> > >
> > > You should provide patches to
> > >
> > >     sys/arch/mips/dts
> > >
> > > See sys/arch/arm/dts for example how a board=E2=80=99s dts is changed=
 compared
> > > to the Linux mainline upstream
> >
> > I was able to reduce one timeout and quiet an error print with this
> >
> >         * Refuse SDIO probe. Proper SDIO operation is not possible
> >         * because of a lack of card interrupt handling.
> >         */
> > -       if (cmd->c_opcode =3D=3D SD_IO_SEND_OP_COND) {
> > -               cmd->c_error =3D ENOTSUP;
> > +       if (cmd->c_opcode =3D=3D SD_IO_SEND_OP_COND ||
> > +           cmd->c_opcode =3D=3D SD_IO_RW_DIRECT ||
> > +           cmd->c_opcode =3D=3D SD_IO_RW_EXTENDED) {
> > +               cmd->c_error =3D ETIMEDOUT;
> >                return;
> >        }
> >
> > but I have to imagine there is a better way to handle this.  Even with
> > that there seems to be two silent timeout intervals delaying boot by
> > 10s (vs 15s).

Here's a further variant on top of the last with some minor additions
to the sdmmc subsystem to avoid the slower boot.  With this, probe and
root are mounted in around 200ms.

https://people.freebsd.org/~kbowling/oct_mmc_v3.patch

Overall it seems performant and stable, including against unrelated
panics and sudden power loss while trying to MPSAFE cnmac3.

Regards,
Kevin

> > > Nick
> > >
> > >
> > >
> > >
> > >