Re: NetBSD 11.0 on Netgate SG-1000 AM335x cpsw, KSZ9031 and i2c notes

[Yuri Honegger <yurix%NetBSD.org@localhost>]

Hi,

> Am 17.10.2026 um 06:36 schrieb Try The Post Office <trythepostoffice%gmail.com@localhost>:
> 
> Hi,
> 
> I have NetBSD 11.0 evbarm-earmv7hf running on the Netgate SG-1000,
> the AM3352 box that shipped with pfSense. It's the stock armv7.img
> with a patched am335x-boneblack.dtb and a u-boot.env added to the
> FAT partition. It boots from microSD through Netgate's U-Boot on
> the eMMC and doesn't touch the eMMC. One ethernet port works (WAN),
> gigabit, DHCP/DNS/NTP/pkgin all fine.
> 
> Repo with the dts, scripts, logs and a prebuilt image
> https://github.com/ttpolabs/netbsd-netgate-sg1000
> 
> The build reproduces from the 11.0 armv7.img byte for byte on the
> dts/dtb. Short version of what I found
> 
> cpsw pinctrl. With the stock BBB tree port 1 gets gigabit link but
> nothing comes in. The BBB pinctrl muxes the CPSW pins for MII and
> this board is RGMII. Dropping pinctrl from the switch node so U-Boot's
> pin setup stays fixed it.

Before committing the DT, I’d prefer if you could fix the pinmux configuration
rather than just dropping it.

> if_cpsw.c 1.17 also never reads phy-mode
> or phy-handle and nothing writes GMII_SEL, so the kernel is leaning
> on U-Boot for pin muxing, GMII_SEL (0x3a here) and the KSZ9031 skews.

Most likely, if_cpsw implemented just the minimum required to get the 
supported boards working. You are invited to fix it so it handles the 
additional cases.

> 
> Second port. mii_attach() is called with MII_PHY_ANY and offset 0
> so only the first PHY found attaches (phy 1) and PHY 2 never does.
> Enabling port@2 in the tree changes nothing. FreeBSD ran this board
> as dual EMAC. I'm guessing thats driver work. Is anyone looking at
> dual EMAC for cpsw?
> 
> Forced 100 Mbit doesn't work on port 1. cpsw_init() sets MACCONTROL
> once with GIG set whenever the PHY can do 1000 and cpsw_mii_statchg()
> is empty, so I think the MAC stays in gigabit mode at 100. I've yet
> to read MACCONTROL back to confirm.

Looks like some driver work. You are invited to fix it :)

> 
> KSZ9031 skew. micphy.c has the cpsw skew fixup for the KSZ9021 but
> nothing for the 9031. Netgate values (from ufw.dts, which is in ps/200
> units because of FreeBSD's PS_TO_REG) match what U-Boot leaves in
> PHY 1.
> 
> Disabled i2c nodes still get enumerated. tps@24 with status "disabled"
> and a compatible nothing matches still shows up as
> 
>  tps (sg1000,no-pmic) at iic0 addr 0x24 not configured
> 
> and with only status "disabled" tps65217pmic0 still attached.
> of_enter_i2c_devs() in 11.0 and fdtbus_i2c_enumerate_devices() in
> -current don't check status . Linux only registers available children.
> I'll file a PR for this one unless that's intended.
> 

It is normal that disabled nodes get enumerated. They shouldn’t attach
though. 

However, I’m wondering if disabling hardware is the right approach.
You aren’t building a DT for a BBB, so you can just strip BBB hardware not 
present on your board out.

> omaptimer0 "couldn't enable module". am3_prcm.c has timer1 at CM_WKUP
> offset 0x10. I believe that's DMTIMER0 and timer1 is 0xC4 but I haven't
> confirmed against the TRM table yet.

it is always possible that the drivers need fixes when enabling new hardware.

> 
> Question for the list. I'd like a real SG-1000 dts instead of the
> patched BBB one. As far as I can tell NetBSD imports its device trees
> from Linux (sys/external/gpl2/dts) so I'm guessing upstreaming to
> Linux is the way. Is there a way to carry a board dts in NetBSD in
> the meantime or is it Linux first and wait for the next import?
> 

Long-term, Having it upstream in Linux would make our lives easier, but
it should be possible/I’ll make it possible to carry it NetBSD-only.

In addition to sys/external/gpl2/dts, there is also sys/arch/arm/dts. This is
where NetBSD-only patches to the DTs go. I’d suggest to put your new
device trees there and enable them something like this (with a BBB tree):
https://github.com/recursivetree/netbsd-src/commit/3fd42aa2d3a8ef5505bb0ec65f4eb6f35e36b6bb

> 
> Full details and logs are in the README. Happy to test patches on the
> board.
> 
> Thanks
> 
> Elias Howell

If you have any questions, feel free to ask.

- Yuri