> Date: Fri, 25 Nov 2022 00:52:24 +0000
> From: Peter Stuge <pe...@stuge.se>
>
> 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.)
>
>
> > but the version in this dtb breaks my bbb.
>
> In a way it may be making things more correct, just not yet complete.
>
> 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.
>
>
> 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.
Small correction, you mean a "local-mac-address" property instead of a
node.
> (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?
Yes U-Boot will update the FDT with "local-mac-address" properties.
U-Boot typically uses "ethernetN" properties under /aliases to decide
where to place the "local-mac-address" properties. So if those
aliases aren't there you end up without "local-mac-address"
properties.
