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.
(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
