PDF 原檔：報告_OCP2026_華擎ASRockRack_AI推論系統_20261015_original.pdf

講者公開簡報（OCP 官方 Recorded Content 頁提供下載）。文字以 PyMuPDF 逐頁抽取，### p<n> 為頁碼；圖表內容見原檔。

圖片清單（已驗證 2026-10-19）

原始內容

p1

（本頁無可抽取文字，內容在圖中）

p2

• Board • Mechanical • Signal integrity simulation • Thermal simulation • BIOS • OpenBMC • System assembly • L10/L11 validation • Rack integration Validation Service Design Production • HW and FW function • EA • Thermal • Power • EMI and Safety • Reliability • Firmware customization • Firmware update • On-site support From System Design to Data Center

p3

Server Boards OCP Mainstream Multi-Node 4U18N 2U4N 1U2N2G 4U36L6E 2U12L 1U4L4E 1U2S 4OU12N 1OU3N 2U24E 1U12E 1U24E1S 4U8X/4U8M (SXM/OAM) 4U8G/4U10G 1U1G 4UMGX 2U2G 2U1G All-Flash AI GPU 6U8X/6U8M (SXM/OAM) Built for AI Infrastructure ── GPU to CPU 2U16E3S 2UMGX Storage 1U12L 4U60L 1OU1N 2OU3N MGX Rack

p4

4 AI is Redefining Compute Scaling of AI Models Increased Demand for AI Applications Agentic / On-Device AI Design Complexity & Cost Power & Energy Constraints Supply Chain Management & Operations

p5

Agentic explosion *Based on GitHub adoption trends 2012 2026 2024 2022 2020 2018 2016 2014 100k 200k GitHub stars OpenClaw Linux

p6

Answer 3-5X more CPUs needed to balance agent flow Agents AI data center Cloud CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU CPU orchestrates Accelerators generate tokens CPU ACCELERATOR ACCELERATOR ACCELERATOR ACCELERATOR CPU AI agent

p7

C U S T O M I Z AT I O N SoC Arch CSS IP Chiplet

p8

8 Arm Platform for AI System Delivery Firmware Compute Standards The image part with relationship ID was not found in the file. The image part with relationship ID was not found in the file. The image part with relationship ID was not found in the file. The image part with relationship ID was not found in the file. I O M E M O R Y S Y S T E M S E C U R I T Y OPTIMIZED ARM CPU CHIPLETS INTEGRATED AND VALIDATED SUBSYSTEMS The image part with relationship ID was not found in the file. The image part with relationship ID was not found in the file. To From Architecture Software Enablement Kernel libraries Subsystems *CSA, AMBA, UCIe Instruction Set BIOS, BMC AI application System Demands Feedback Loop AI is the full stack Platform

p9

9 C P U M M U S Y S T E M I P C M N C P U M M U S Y S T E M I P C M N IP Build your own Deploy faster Accelerate your design Compute Subsystems (CSS) One platform: multiple entry points Silicon

p10

Performance Scale Efficiency World’s most efficient agentic CPU

p11

Memory tuned for compute 6GB/s memory BW / core 6TB per chip capacity Up to DDR5-8800 World class Arm efficiency Incredible 3nm efficiency Maximum compute density 300 watt TDP I/O for composable AI systems 96x lanes PCIe Gen6 CXL 3.0 – memory expansion and more AMBA CHI extension links Latency-optimized memory access Dual chiplet design Memory and I/O on same die Sub 100ns memory latency Up to 136 Arm Neoverse V3 cores Dedicated 2MB L2 cache per core Up to 3.7Ghz frequency Responsive performance

p12

Arm contributions across the full stack Server designs Chiplet enablement Server standardization + Diverse silicon ecosystem Helping OxMs launch Arm servers faster Software just works on Arm servers • Standardized server architecture (SBSA, SBMR)* • Compliance and validation framework (ADAC) • Built-in system management and security • Foundation Chiplet System Architecture (FCSA) • Modular integration of compute, memory, and I/O • Reduced design complexity for custom silicon • Pre-defined server hardware specifications^ • Aligned with Meta Yosemite V5 rack design • Firmware development frameworks * Contributions in progress ^ Future contribution

p13

ASRock Rack OCP Journey OCP Server AMD EPYC8005 1OU1N DC-MHS OCP NIC 3.0 1OU3N ORv2 ORv3 2OU1N 2OU3N 4OU12N AMD EPYC9005 Intel Xeon 6 DC-SCM AMD EPYC4005 M-DNO M-FLW AST 2700 AST 2600 x86 ARM AMD EPYC8005 AMD EPYC9005 Intel Xeon 6 2OU3N3G AMD EPYC9005 Intel Xeon 6

p14

44 OU 36 Nodes Arm AGI CPU up to 136 cores 12 DDR5 RDIMM 8000MT/s 6 E3.S (PCIe 6.0) OCP NIC 3.0 (PCIe 6.0) Open Rack V3 EDK II UEFI OpenBMC 2OU2N-ARM

p15

OPENBMC PORTING · ASROCK RACK INC. How meta-asrockrack turns per-board bring-up into config, not code engineering overview

p16

AGENDA What We’ll Cover ASRock Rack Inc. | OpenBMC Porting Framework 02 • Maximize shared code across every platform • The Framework — meta-asrockrack layer structure • Per-Board Config — prjconfig.bbclass • Config → Code — generated headers & GPIO names... • Chassis ID — one image, many systems • Release Engineering & Factory Provisioning • Fast Dev Iteration — TFTP/NFS network boot • Status & Roadmap

p17

THE GOAL Maximize Shared Code Across Every Platform ASRock Rack Inc. | OpenBMC Porting Framework 03 • Motherboard SKUs in the tree today — GNR, Genoa, Turin, AM5, EPYC, W680, AST2500, AST2600, AST2700 and Nuvoton NPCM845 • Even the same motherboard ships in multiple physical system configurations (chassis, backplane, sensor, fan, led). • Every new board traditionally meant re-doing BMC bring-up almost from scratch. • RD headcount doesn't scale with SKU count — it has to be the other way around n board overlays, 4 SoC platforms 1 shared meta-common pattern, every board How: Push per-board differences down into some config files, not a forked codebase.

p18

THE FRAMEWORK meta-asrockrack: One Layer, Many Boards ASRock Rack Inc. | OpenBMC Porting Framework 04 meta-asrockrack Top-level BSP layer for all boards meta-ast2500 / 2600 / 2700 / npcm845 Split only where the SoC or vendor differs meta-common Shared services, recipes, u-boot/kernel, image policy meta- Per-board overlay: prjconfig.bbclass + dts + config deltas New SKU checklist: add a meta- overlay, modify prjconfig.bbclass, wire the dts, write sensors, leds config file. meta-asrockrack layer tree meta-asrockrack ├── meta-ast2500 ├── meta-ast2600 │ ├── meta-common (SoC-specific) │ │ linux-aspeed, u-boot-aspeed-sdk, ... │ ├── meta-am5d4id-2t │ ├── meta-genoad8hm3 │ ├── meta-gnr2d32mgx │ ├── meta-armd12m3 │ └── ... more boards ├── meta-ast2700 ├── meta-npcm845 └── meta-common (shared by all SoCs) ipmi-oem, fancontrol, inventory, dbus-sensors, multi-node, autosnmp, ...

p19

PER-BOARD CONFIG prjconfig.bbclass: Every Board Knob, One File ASRock Rack Inc. | OpenBMC Porting Framework 05 • Every hardware difference for a board lives in exactly one file. • EEPROM layout, fan/PWM map, GPIO pins, BIOS- update behavior, dual-image support, RAID bus mapping, SNMP config... • Same shared services (platform-control, ipmi-oem, u- boot) read this file through every board. • Porting a new board = filling in this file, not writing new services. MODEL_NAME ?= “ARMD12M3" VER_MAJOR ?= "1" VER_MINOR ?= "0" EEPROM_I2C_BUS ?= "0" EEPROM_I2C_ADDRESS ?= "0x57" EEPROM_CHASSIS_ID_OFFSET ?= "0x3f60" NUM_FAN_SUPPORTED ?= "8" FAN1_DEFAULT_DUTY ?= "30" ...

BIOS update function

BIOS_SPI_GPIO_BMC_LEVEL ?= "1" BIOS_UPDATE_FORCE_HOST_OFF ?= "1" PWMIC_FW_I2C_BUS ?= "6" PWMIC_FW_SLAVE_ADDR ?= "0x60" ... inherit prjcommon meta-/classes/prjconfig.bbclass

p20

CONFIG BECOMES CODE prjcommon.bbclass Turns Bitbake Vars into C++ Headers ASRock Rack Inc. | OpenBMC Porting Framework 06 • The bbclass walks every variable at build time. • Auto-generates prjconfig.hpp:

define CONFIG_

• Every shared C/C++ service and u-boot module #includes it — config and code can never drift apart. // Auto-generated by prjconfig.bbclass

define CONFIG_EEPROM_I2C_BUS 0

define CONFIG_NUM_FAN_SUPPORTED 8

define CONFIG_FAN1_DEFAULT_DUTY 30

define CONFIG_BIOS_UPDATE_FORCE_HOST_OFF 1

define CONFIG_GPIO_MFG_MODE 0x...

generated: include/prjconfig.hpp One bitbake variable, One build step, Zero hand-maintained header files per board.

p21

CONFIG BECOMES CODE (2) The Board .dts Is the Source of Truth for GPIO, SPI, MAC... ASRock Rack Inc. | OpenBMC Porting Framework 07 • Parses gpio-line-names straight out of the board's kernel .dts. • Auto-generates GPIO_ bitbake variables — no separate GPIO table to keep in sync. • Give warning if missing GPIO definition in dts for enabled features. • Retrieve SPI/MAC used by the platform to update the header file to build the source. &gpio0 { gpio-line-names = "BMC_MFG_MODE_L", ...; }; → GPIO_BMC_MFG_MODE_L = "GPIOA3" board .dts Single source of truth: the pin name lives once, in the dts that already describes the hardware.

p22

SAME MB, DIFFERENT SYSTEMS Chassis ID: One Image, Many System SKUs ASRock Rack Inc. | OpenBMC Porting Framework 08 • Chassis ID is written into an EEPROM field on the assembly line. • u-boot reads it and picks the matching device tree config to boot. • The BMC service matches it against config.json, runs the matching sku-manager script, and publishes SystemId over D- Bus for every other service to consume. { "chassisid": "ASRR", "run": ".../platform_asrr.sh" }, { "chassisid": "2OU2N-ARM", "run": ".../platform_2ou2n_arm.sh" } meta-genoad8hm3/.../platform-control/config.json // asrrcommon.c (u-boot) if (chassis_id == "$Your_ID") conf = "...-other.dtb"; else conf = "...-asrr.dtb"; dynamic FIT config selection Real example: meta-armd12m3 ships BOTH platform_asrr.sh and platform_2ou2n_arm.sh in the same build — the chassis ID picked up at boot decides which one runs. One image, two physical systems.

p23

RELEASE ENGINEERING Release Folders Build Themselves ASRock Rack Inc. | OpenBMC Porting Framework 09 • MC_FW_VERSION is computed from the board's own VER_MAJOR / VER_MINOR / VER_AUX in prjconfig. • Every .mtd / .tar output is auto-copied into RELEASE_DIR/... • No manual renaming or copying between boards or versions. • Fewer release mistakes, faster hand-off to QA and to customers. inherit prjconfig RELEASE_DIR = "${IMGDEPLOYDIR}/${MC_FW_VERSION}" do_mk_static_symlinks:append() { cp image.static.mtd \ ${RELEASE_DIR}/${MACHINE}${MC_FW_VERSION}.mtd } obmc-phosphor-image.bbappend

p24

FACTORY LINE ECONOMICS Pre-Formatted rwfs = Faster First Boot = Cheaper to Build ASRock Rack Inc. | OpenBMC Porting Framework 10 • Normally the read-write overlay (rwfs) formats itself on first boot — and that's slow. • Pre-builds a padded jffs2 image at build time, matching the exact partition size and erase-block size from the board's dts. • Shipped pre-formatted inside the release mtd — first boot on the line is fast. • Less time per unit on the production line, at real production volume, is real money saved. obmc-phosphor-image.bbappend do_generate_formatted_rwfs_static() { RWFS_SIZE_HEX=$(printf "0x%x" ${RWFS_SIZE}) ERASE_SIZE_HEX=$(printf "0x%x" ${ERASE_BLOCK_SIZE}) # pad + erase-block match the board's dts rwfs partition, # so it drops in ready to flash mkfs.jffs2 --root=${S}/rootfs_rw \ --faketime \ --output=${IMAGE_LINK_NAME}.jffs2 }

p25

FASTER DEVELOPMENT ITERATION Network-Boot Over TFTP/NFS Instead of Reflashing ASRock Rack Inc. | OpenBMC Porting Framework 11 • Copies the build’s fitImage + initramfs into a TFTP root and unsquashfs's rofs into an NFS-exported directory — no SPI programming per test cycle. • A drop-in /sbin/init replaces the initramfs default: it fetches the kernel over TFTP and mounts the rootfs from NFS through the same overlayfs + jffs2 rwfs scheme as a real flash boot. • Modify boot command in u-boot environment to boot from remote server. • Updates the test image finish in seconds, not minutes. setenv model bmcs setenv nfssvr 192.168.xx.xx:/nfs/${model} setenv tftpsvr 192.168.xx.xx:${model} setenv rambootargs "root=/dev/nfs rw ip=dhcp nfsroot=${nfssvr},v3 console=ttyS4,115200n8" setenv rambootcmd "dhcp; tftp 0x83000000 ${tftpsvr}/fitImage; tftp 0x93000000 ${tftpsvr}/initrd; bootm 0x83000000 - 0x93000000" u-boot setenv script Full reflash cycles take minutes; TFTP/NFS iteration takes seconds — the BMC just re-mounts a network rootfs, it never reprograms flash.

p26

WHERE THIS GETS US Scales Forward, Not Just Sideways ASRock Rack Inc. | OpenBMC Porting Framework 12 n board SKUs on one shared core 4 SoC platforms, same framework a few files per-board porting surface (prjconfig...) • New board = overlay + prjconfig.bbclass + dts + board config, not a new codebase. • Same chassis-ID mechanism already lets one image serve multiple physical systems. • AST2500, AST2600, AST2700, and Nuvoton NPCM845 all landed in the same framework — only the SoC-specific layer changes. • Result: less RD time per board, fewer regressions, faster releases, cheaper factory boot. Arm AGI platform landed as one more overlay, with no new codebase.

p27

Booth D37 Booth C72 Efficiency by design. Built for agentic.