[PATCH v2 2/2] ARM: dts: aspeed: add device tree for ASRock Rack ALTRAD8 BMC
    Rebecca Cran 
    rebecca at bsdio.com
       
    Tue Sep 23 06:30:21 AEST 2025
    
    
  
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 at 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 at 1 and channel at 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 at 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 at 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
    
    
More information about the Linux-aspeed
mailing list