Re: PR 60404: Beaglebone Black: nonfunctional usb wifi
Yuri Honegger <[email protected]> Sat, 11 Jul 2026 11:16:47 +0200
| Newsgroups | gmane.os.netbsd.ports.arm |
|---|---|
| Message-ID | <[email protected]> |
> >> Third, the device tree for the phy contains only the following:
> >>=20
> >> usb_ctrl_mod: control@620 {
> >> compatible =3D "ti,am335x-usb-ctrl-module";
> >> reg =3D <0x620 0x10>,
> >> <0x648 0x4>;
> >> reg-names =3D "phy_ctrl", "wakeup";
> >> };
> >=20
> > That isn't the PHY, it gets referenced by the PHY.
> >=20
> > An entry for one of the PHYs is this:
> >=20
> > usb0_phy: usb-phy@1300 {
> > compatible =3D "ti,am335x-usb-phy";
> > reg =3D <0x1300 0x100>;
> > reg-names =3D "phy";
> > ti,ctrl_mod =3D <&usb_ctrl_mod>;
> > #phy-cells =3D <0>;
> > };
>=20
> Yes, my mistake. Nevertheless, the PHY registers are at offset 0x1300, =
which agrees with the BBB TRM memory map ([1] page 178) corresponding to =
USB0_PHY; the full address of is 0x47401300, which is within a larger =
block for all of USB0 starting at 0x47400000. I believe that these =
blocks are defined hierarchically in the various driver parents and so =
they can be accessed, each within its parent=E2=80=99s block.
>=20
> In addition to these registers, however, the BBB has an entirely =
different set of control registers that start at address 0x44e10000. =
Among other things these control aspects of USB (that I=E2=80=99m trying =
to set here) and the configuration of GPIO pins. The 0x620 referred to =
in usb_ctrl_mod above is within this other block, not within the main =
USB0 registers. As a result, the 0x44e10000 base address for this is not =
in any of the USB PHY parent nodes.
The device tree is not strictly a tree, there can be cross-references. =
In this case, you can follow the ti,ctrl_mod =3D <&usb_ctrl_mod>; =
property on ti,am335x-usb-phy to get the phandle of the =
ti,am335x-usb-ctrl-module and then get the address+size using the new =
phandle.
If you don^t need to set any bits in the registers of =
ti,am335x-usb-phy, just ignore them.
>=20
> How should this split address map be handled in drivers that need to =
access registers from two different blocks?
>=20
> Cheers,
> Brook
>=20
> [1] https://www.ti.com/lit/ug/spruh73q/spruh73q.pdf