Re: Octeon MMC driver

On Sun, Mar 22, 2026 at 8:44=E2=80=AFAM Nick Hudson <[email protected]>=
 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 rem=
ove the splsdmmc calls.
>
> Something like the attached.

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

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/arc=
h/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/gpl=
2/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 com=
pared
> 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
>
>
>
>
>