[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <354c5977-2bab-446f-9ae0-b01d678fd74f@bsdio.com>
Date: Mon, 22 Sep 2025 14:30:21 -0600
From: Rebecca Cran <rebecca@...io.com>
To: Zev Weiss <zev@...ilderbeest.net>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Joel Stanley <joel@....id.au>,
Andrew Jeffery <andrew@...econstruct.com.au>, devicetree@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-aspeed@...ts.ozlabs.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] ARM: dts: aspeed: add device tree for ASRock Rack
ALTRAD8 BMC
On 9/22/25 00:29, Zev Weiss wrote:
> Here and on most of the other i2c busses, is there a particular reason
> we want this bus-frequency explicitly specified? 100kHz is the
> default according to
> Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml (and the other
> existing aspeed-bmc-asrock-*.dts files leave it at that implicit
> default, FWIW).
There's no particular reason - I've deleted them.
> It looks like this device only monitors temperatures? If so, perhaps
> temperature-sensor@29 would be a slightly more appropriate node name.
The chip can also monitor power supply voltages and fan speeds but on
this board it's only used as a temperature sensor, so I'll change the
node name.
> channel@1 and channel@2 block bodies look over-indented by one level
> here.
Thanks - fixed.
> Are these correct? On every other ASRock board I've dealt with, the
> eth0 address is at 0x3f80 and eth1 is at 0x3f88.
>
> If so and they are really for some reason swapped on this platform, as
> a slight nitpick I might suggest swapping the order the nodes are
> listed in so they go in order of increasing addresses.
After installing the latest 3.06 BMC firmware from the ASRock website,
I'm seeing:
root@...rad8ud-1l2t:~# ifconfig
eth0 Link encap:Ethernet HWaddr 9C:6B:00:43:0B:F7
inet addr:10.0.0.25 Bcast:10.0.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:457 errors:0 dropped:0 overruns:0 frame:0
TX packets:240 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:88379 (86.3 KiB) TX bytes:17663 (17.2 KiB)
Interrupt:26
eth1 Link encap:Ethernet HWaddr 9C:6B:00:43:0B:BD
inet addr:10.0.0.11 Bcast:10.0.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:368 errors:0 dropped:0 overruns:0 frame:0
TX packets:26 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:88134 (86.0 KiB) TX bytes:3507 (3.4 KiB)
Interrupt:27
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:434 errors:0 dropped:0 overruns:0 frame:0
TX packets:434 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:34479 (33.6 KiB) TX bytes:34479 (33.6 KiB)
usb0 Link encap:Ethernet HWaddr 4E:F6:84:8E:63:B9
inet addr:169.254.0.17 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
root@...rad8ud-1l2t:~# hexdump -C /sys/bus/i2c/devices/7-0057/eeprom
...
*
00003f80 9c 6b 00 43 0b bd ff ff 9c 6b 00 43 0b f7 ff ff
|.k.C.....k.C....|
00003f90 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
|................|
*
00003fd0 1e 90 db 9a 13 ff cb ff 4e f6 84 8e 63 b9 8e ff
|........N...c...|
00003fe0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
|................|
*
00004000
I don't know why they're swapped, but I think keeping them that way
makes sense to avoid people's IP address changing.
> As the DTBS_CHECK lint reported and Andrew Jeffery commented on, these
> two partitions overlapping is a bit surprising -- is that intentional?
It was intentional since I've updated the firmware update script to be
able to program the TF-A or UEFI areas separately, or the entire code
region (i.e. TF-A _and_ UEFI, excluding the data/configuration areas of
the EEPROM). But I'll update the script to not depend on there being a
'code' partition that covers both areas.
--
Rebecca Cran
Powered by blists - more mailing lists