Port-mips archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Octeon MMC driver



On Sun, Mar 22, 2026 at 8:44 AM Nick Hudson <nick.hudson%gmx.co.uk@localhost> 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=0x3 root=wedge: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…
>
> The cache lock workaround is “interesting”
>
>
> Don’t 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

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’re 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’s 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 == SD_IO_SEND_OP_COND) {
-               cmd->c_error = ENOTSUP;
+       if (cmd->c_opcode == SD_IO_SEND_OP_COND ||
+           cmd->c_opcode == SD_IO_RW_DIRECT ||
+           cmd->c_opcode == SD_IO_RW_EXTENDED) {
+               cmd->c_error = 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
>
>
>
>
>


Home | Main Index | Thread Index | Old Index