Re: Octeon MMC driver

On Sat, Mar 28, 2026 at 12:49=E2=80=AFAM Kevin Bowling <kevin.bowling@kev00=
9.com> wrote:
>
> On Sun, Mar 22, 2026 at 8:44=E2=80=AFAM Nick Hudson <[email protected]=
k> 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 ER4:
> > > Octeon ubnt_e100# set bootcmd 'fatload mmc 0 $loadaddr
> > > netbsd;bootoctlinux $loadaddr coremask=3D0x3 root=3Dwedge:octeon-root=
'
> > > 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 r=
emove 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/a=
rch/mips/boot/dts/cavium-octeon.
> I do see compatible files elsewhere like
> https://git.openwrt.org/openwrt/openwrt/tree/target/linux/octeon/files/ar=
ch/mips/boot/dts/cavium-octeon.
>
> >
> > ~/netbsd/nbcvs/src % grep -r  "cavium,octeon-[0-9]*-mmc" sys/external/g=
pl2/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 c=
ompared
> > 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).
>
> > Nick
> >
> >
> >
> >
> >