Date: Thu, 21 Sep 2023 00:19:53 -0700 From: Mark Millard <marklmi@yahoo.com> To: "Patrick M. Hausen" <pmh@hausen.com> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Getting a stable MAC address for a RPI CM3+ with ue0 interface Message-ID: <5953C54F-D0A9-4842-AC4C-CF431E095F73@yahoo.com> In-Reply-To: <B8AB54AB-6EDF-4763-8FA5-5A9BA540A0FB@hausen.com> References: <3C1032FF-B914-4863-8A03-759A8B4BE216@hausen.com> <77E70D30-8E7D-42DC-A041-3A783E1C6908@yahoo.com> <5205C76E-BAB4-4AB7-8A03-1E8A2D4353BB@hausen.com> <4C192A4E-8F53-4FE5-B1E3-836943F9A050@hausen.com> <cdddd5cf-c6a5-3a50-9688-8bb65f1c14ce@FreeBSD.org> <3306D438-576B-46A6-A124-1F1D803A2236@hausen.com> <6a842b75-c9ea-d697-c223-c2d8c5653d68@FreeBSD.org> <38325594-6F01-4E43-86A9-D3C92A5151B7@yahoo.com> <B8AB54AB-6EDF-4763-8FA5-5A9BA540A0FB@hausen.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 20, 2023, at 22:35, Patrick M. Hausen <pmh@hausen.com> wrote: > HI all, >=20 >> Am 21.09.2023 um 06:09 schrieb Mark Millard <marklmi@yahoo.com>: >> sysctl -b hw.fdt.dtb | dtc -I dtb -s > current_sorted.dts >=20 > Without the explicit "force_mac_address" line I find this in the = output: >=20 > ----------------- > aliases { >=20 > i2c_arm =3D "/soc/i2c@7e804000"; > i2c =3D "/soc/i2c@7e804000"; > i2c_vc =3D "/soc/i2c0mux/i2c@0"; > serial0 =3D "/soc/serial@7e201000"; > serial1 =3D "/soc/serial@7e215040"; > aux =3D "/soc/aux@7e215000"; > sound =3D "/soc/sound"; > soc =3D "/soc"; > dma =3D "/soc/dma@7e007000"; > intc =3D "/soc/interrupt-controller@7e00b200"; > watchdog =3D "/soc/watchdog@7e100000"; > random =3D "/soc/rng@7e104000"; > mailbox =3D "/soc/mailbox@7e00b880"; > gpio =3D "/soc/gpio@7e200000"; > uart0 =3D "/soc/serial@7e201000"; > uart1 =3D "/soc/serial@7e215040"; > sdhost =3D "/soc/mmc@7e202000"; > mmc =3D "/soc/mmc@7e300000"; > mmc1 =3D "/soc/mmc@7e300000"; > mmc0 =3D "/soc/mmc@7e202000"; > i2s =3D "/soc/i2s@7e203000"; > i2c0 =3D "/soc/i2c0mux/i2c@0"; > i2c1 =3D "/soc/i2c@7e804000"; > i2c10 =3D "/soc/i2c0mux/i2c@1"; > spi0 =3D "/soc/spi@7e204000"; > spi1 =3D "/soc/spi@7e215080"; > spi2 =3D "/soc/spi@7e2150c0"; > usb =3D "/soc/usb@7e980000"; > leds =3D "/leds"; > fb =3D "/soc/fb"; > thermal =3D "/soc/thermal@7e212000"; > axiperf =3D "/soc/axiperf"; > i2c2 =3D "/soc/i2c@7e805000"; > }; No evidence above of any ethernet device. Does the current_sorted.dts have anything in it mentioning "ethernet"? "local-mac-address"? I've no direct knowledge of the CM3+ . What are the details of how ethernet has been provided for your context? Using an RPi3B as an example: it has its "built in" ethernet via usb. So it has an alias like: ethernet0 =3D "/soc/usb@7e980000/usb1@1/usbether@1"; and (more ?? based redaction used): soc { . . . usb@7e980000 { compatible =3D "brcm,bcm2708-usb"; reg =3D <0x7e980000 0x00010000 0x7e006000 = 0x00001000>; interrupts =3D <0x00000001 0x00000009 0x00000002 = 0x00000000>; #address-cells =3D <0x00000001>; #size-cells =3D <0x00000000>; clocks =3D <0x00000014>; clock-names =3D "otg"; phys =3D <0x00000015>; phy-names =3D "usb2-phy"; interrupt-names =3D "usb", "soft"; power-domains =3D <0x00000011 0x00000006>; phandle =3D <0x0000006a>; usb1@1 { compatible =3D "usb424,9514"; reg =3D <0x00000001>; #address-cells =3D <0x00000001>; #size-cells =3D <0x00000000>; usbether@1 { local-mac-address =3D [?? ?? ?? = ?? ?? ??]; compatible =3D "usb424,ec00"; reg =3D <0x00000001>; phandle =3D <0x0000006b>; }; }; }; . . . So, if force_mac_address were to be made to work, it would probably involve creating an alternate *.dtb (or an overlay) that included the alias and something analogous to having that usb device description. In other words, making the ethernet device appear to be built-in. (Not that I've ever done such a thing.) > chosen { >=20 > fixup-applied; > u-boot,version =3D "2023.07.02"; > user-warnings =3D [64 74 65 72 72 6f 72 3a 20 63 61 6e = 27 74 20 66 69 6e 64 20 73 79 6d 62 6f 6c 20 27 75 61 72 74 30 5f 70 69 = 6e 73 27 0a 46 61 69 6c 65 64 20 74 6f 20 72 65 73 6f 6c 76 65 20 6f 76 = 65 72 6c 61 79 20 27 64 69 73 61 62 6c 65 2d 62 74 27 0a]; > rng-seed =3D <0x17f7438c 0x2ab979c8 0xc4352759 = 0x305da3e8 0x4304ea0a 0x6ce10bfb 0xa633ae6 0xcada5dfc 0x854eeecb 0x925b > 1f20 0x12bdb423 0x1ebbf917 0x4b434ef3 0x21939e04 0x4ee3dcc7 = 0xe3f5af57>; > kaslr-seed =3D <0x64f204d4 0x19ed2123>; > os_prefix; > overlay_prefix =3D [6f 76 65 72 6c 61 79 73 2f]; > rpi-boardrev-ext =3D <0x0>; > log =3D <0x3ff80000 0x7ffe0>; > bootargs =3D "coherent_pool=3D1M = snd_bcm2835.enable_headphones=3D0 snd_bcm2835.enable_hdmi=3D1 = bcm2708_fb.fbwidth=3D656 bcm2708_fb.fbheight=3D416 bcm2708_fb.fbswap=3D1 = smsc95xx.macaddr=3DB8:27:EB:09:CB:7D vc_mem.mem_base=3D0x3ec00000 = vc_mem.mem_size=3D0x40000000 force_mac_address=3Db8:27:eb:09:cb:7d"; Making the addr's easy to compare: smsc95xx.macaddr =3DB8:27:EB:09:CB:7D force_mac_address=3Db8:27:eb:09:cb:7d So, as things were set up, they match, up to case. But nothing identifies a specific ethernet to use that address with. So, as is, insufficient context to be automatic? (Again suggesting making the ethernet device appear to be built in if force_mac_address is to be used?) > phandle =3D <0x2f>; > bootloader { >=20 > boot-mode =3D <0x1>; > tryboot =3D <0x0>; > rsts =3D <0x1000>; > partition =3D <0x0>; > }; > }; > ----------------- >=20 > The MAC address shown in the "bootargs" line is matching the serial = number of the CM. So it may be that this route is too complicated if there are other alternatives, given a lack of any already-built-in ethernet. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5953C54F-D0A9-4842-AC4C-CF431E095F73>