From: Rebecca Cran <rebecca@bsdio.com>
To: Zev Weiss <zev@bewilderbeest.net>
Cc: Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>, Joel Stanley <joel@jms.id.au>,
Andrew Jeffery <andrew@codeconstruct.com.au>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] ARM: dts: aspeed: add device tree for ASRock Rack ALTRAD8 BMC
Date: Mon, 22 Sep 2025 14:30:21 -0600 [thread overview]
Message-ID: <354c5977-2bab-446f-9ae0-b01d678fd74f@bsdio.com> (raw)
In-Reply-To: <66c5bf80-a3ef-4984-82ce-6d1720b15d38@hatter.bewilderbeest.net>
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@altrad8ud-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@altrad8ud-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
next prev parent reply other threads:[~2025-09-22 20:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-17 18:04 [PATCH v2 0/2] Add device tree for ASRock Rack ALTRAD8 BMC Rebecca Cran
2025-09-17 18:04 ` [PATCH v2 1/2] dt-bindings: arm: aspeed: add ASRock Rack ALTRAD8 board Rebecca Cran
2025-09-17 19:17 ` Conor Dooley
2025-09-17 18:04 ` [PATCH v2 2/2] ARM: dts: aspeed: add device tree for ASRock Rack ALTRAD8 BMC Rebecca Cran
2025-09-17 21:04 ` Andrew Lunn
2025-09-17 22:07 ` Rebecca Cran
2025-09-22 6:29 ` Zev Weiss
2025-09-22 20:30 ` Rebecca Cran [this message]
2025-09-18 1:14 ` [PATCH v2 0/2] Add " Rob Herring (Arm)
2025-09-22 2:40 ` Andrew Jeffery
2025-09-22 20:47 ` Rebecca Cran
2025-09-24 2:13 ` Andrew Jeffery
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=354c5977-2bab-446f-9ae0-b01d678fd74f@bsdio.com \
--to=rebecca@bsdio.com \
--cc=andrew@codeconstruct.com.au \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=joel@jms.id.au \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-aspeed@lists.ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh@kernel.org \
--cc=zev@bewilderbeest.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox