linux-kernel - Re: [PATCH v2 2/2] ARM: dts: aspeed: add device tree for ASRock Rack ALTRAD8 BMC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<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