Am Fri, Nov 25, 2022 at 12:52:24AM +0000 schrieb Peter Stuge:
> Jan Stary wrote:
> > Here is the cpsw problem:
> >
> > -cpsw0 at omsysc46: version 1.12 (0), address 90:59:af:82:2e:7e
> > +cpsw0 at omsysc46: version 1.12 (0), address 00:00:00:00:00:00
>
> I confirm this on beaglebone black but I'm not sure it's actually a
> dtb bug, more on that below.
>
> I could anyway DHCP and ping with great success with the zero address.
>
>
> > > I reverted the change that switches from the 'old' cpsw switch driver
> > > model to the 'new' one. This should allow is to update the dtbs.
> >
> > I don't know what the old/new model is,
>
> I too am a bit confused, Patrick can you please clarify 'old' and 'new'?
>
>
> Does it have to do with these two sibling fragments?
>
> ethernet@0 {
> compatible = "ti,am335x-cpsw", "ti,cpsw";
>
> switch@0 {
> compatible = "ti,am335x-cpsw-switch", "ti,cpsw-switch";
>
> (Only the former is (currently) matched by OpenBSD if_cpsw.c.)
>
Yup. Apparently the Linux device trees have both, and a commit in Linux
5.15 switched the beaglebone from the one representation style to the
other.
>
> > but the version in this dtb breaks my bbb.
>
> In a way it may be making things more correct, just not yet complete.
Eh, well yes and no. If it causes a regression because our drivers
aren't expecting the changes in the .dts then it's a question of "does
anyone actually adjust our drivers?". I don't have the machine, so
instead of re-writing cpsw(4) to fit the new-style I'd rather have a
small revert that makes OpenBSD continue to work on the machine.
> For one, both the dtb from Nov 1 snapshot miniroot-am335x-72.img and
> Patrick's dtb have mac-address = [00 00 00 00 00 00]; for both slaves
> (= PHYs). (Though I don't believe that this value is ever used.)
>
> Working on the cpsw driver I was silently wondering where the nonzero
> MAC on my beaglebone black comes from and I still don't know the answer.
>
Either local-mac-address or from hardware registers. For cpsw(4) it's
local-mac-address. U-Boot configures those on bootup. Usually there
needs to be a /aliases/ethernet0 or so pointing to the correct node for
U-Boot to set it correctly. It's possible that this changes as well.
I will have a look.
Cheers,
Patrick
>
> Here's a boot log:
>
> --8<-- Nov 1 snapshot miniroot
> U-Boot SPL 2021.10 (Aug 13 2022 - 07:42:11 -0600)
> Trying to boot from MMC1
>
>
> U-Boot 2021.10 (Aug 13 2022 - 07:42:11 -0600)
>
> CPU : AM335X-GP rev 2.1
> Model: TI AM335x BeagleBone Black
> DRAM: 512 MiB
> WDT: Started with servicing (60s timeout)
> NAND: 0 MiB
> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
> Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
> <ethaddr> not set. Validating first E-fuse MAC
> Net: eth2: ethernet@4a100000, eth3: usb_ether
> Hit any key to stop autoboot: 0
> -->8--
>
> Does "<ethaddr> not set. Validating first E-fuse MAC" mean that
> U-Boot reads the fused MAC_ID0 from the am335x control module and
> writes it into the CPSW registers?
>
>
> Booting Patrick's U-Boot (MLO and u-boot.img) with the older snapshot
> dtb I see the same message from U-Boot and cpsw0 has nonzero address.
>
> After also copying Patrick's dtb to the memory card I still see the
> same message from U-Boot but cpsw0 now has zero address.
>
> After writing the full Nov 1 snapshot again and copying only the new dtb
> over it I also see the message from U-Boot but cpsw0 again has zero address.
>
> In all these tries, env print ethaddr in U-Boot always shows nonzero address.
>
>
> As I understand the driver, cpsw0 will always have a zero address if
> the "ti,cpsw" device tree node has either no child nodes at all or
> none named "local-mac-address".
>
> If a "local-mac-address" child node exists then that address is used.
>
> (if_cpsw.c:364 cpsw_attach() calling cpsw_get_port_config() ff.)
>
> Neither the snapshot dtb nor Patrick's dtb contain "local-mac-address" so
> is U-Boot modifying only the older dtb (why!?) or what is going on here?
>
>
> //Peter
>
