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>