Added doc that describes initial BMC support in SONiC#2043
Added doc that describes initial BMC support in SONiC#2043ctikku-nexthop wants to merge 8 commits intosonic-net:masterfrom
Conversation
|
/azp run |
|
No pipelines are associated with this pull request. |
…or the implementation
|
/azp run |
|
No pipelines are associated with this pull request. |
|
/azp run |
|
No pipelines are associated with this pull request. |
|
/azp run |
|
No pipelines are associated with this pull request. |
- Add SONIC-dbus-bridge - Add details about standard sonic-installer support Signed-off-by: Chandrasekaran Swaminathan <[email protected]>
|
/azp run |
|
No pipelines are associated with this pull request. |
| - **BMC-SONiC-OS** will use [obmc-console](https://github.com/openbmc/obmc-console) for console management. | ||
| - A clone of this project will be created and added as a submodule in the sonic-buildimage repository. | ||
| - The switch CPU console will be accessible by invoking the obmc-console-client inside the obmc-console docker. | ||
| - The switch CPU console will also be accessible over the network via ssh to a specific port on the BMC. |
There was a problem hiding this comment.
During the HLD discussion in the working group meeting on 28th Jan 2026, @yxieca hinted at the possibility of using sonic-console instead. We have a PR (POC at this point, we plan to make it production ready based on community feedback) sonic-net/sonic-buildimage#25674 that uses sonic-console component (already used/available in Sonic) instead of obmc console component.
There was a problem hiding this comment.
I have a question on that PR (added as a comment). Please take a look.
|
/azp run |
|
No pipelines are associated with this pull request. |
fd6863b to
5dc8af4
Compare
|
/azp run |
|
No pipelines are associated with this pull request. |
Added details about the initial load process and subsequent boots for the SONiC support in OpenBMC.
|
/azp run |
|
No pipelines are associated with this pull request. |
|
Can the files be renamed to use generic names? The proposal is vendor‑independent, and the current names are confusing. |
| - **BMC-SONiC-OS** will deploy BMC functionalities as Docker containers. | ||
| - **Kubernetes** will be used for container orchestration. | ||
|
|
||
| ### 6. Boot Loader Components |
There was a problem hiding this comment.
The doc describes two initial-load options: (a) U-Boot boots a minimal SONiC kernel/initramfs and a script does TFTP + flash, and (b) “if SPI flash is running OpenBMC, boot into that, download a pre-formatted disk image and flash that to eMMC.” How does the user choose between (a) and (b)? Is (a) the path when eMMC is empty and (b) when replacing/installing from an existing OpenBMC? A short flow diagram or decision table would help.
There was a problem hiding this comment.
The two initial load options are stop gap measures till the time we have something like ONIE/SONIE. They are mentioned here to serve as reference. The eval board from aspeed has SPI flash and eMMC. The above lines assume that the SPI flash has one of a) Uboot (OR) Uboot + OpenBMC image. Now, if SPI flash has uboot alone, then one would choose option a), wherein once can tftp the sonic-kernel, minimal initramfs (with tftp/http support) and dtb into RAM (the eval board has 2G RAM). And from the shell spawned by init, download the disk image and write the disk image into eMMC using 'dd'. On the other hand, if the SPI flash has uboot+OpenBMC phosphor image, then one can boot into OpenBMC, mount eMMC, download the disk image and write ('dd') into eMMC. Hope this helps.
| - **Kubernetes** will be used for container orchestration. | ||
|
|
||
| ### 6. Boot Loader Components | ||
| - **BMC-SONiC-OS** will use **U-Boot** as the boot loader. |
There was a problem hiding this comment.
Could you also consider upstreaming the infrastructure for the initial installation?
There was a problem hiding this comment.
I shall update the PR with the emmc image creation script. I didn't do that because that script is a standalone script and is not part of the sonic-aspeed-arm64.bin image. I thought having the script as part of this PR may result in confusion.
| - The image will be installed on an **eMMC partition**. | ||
| - The **OpenBMC image** will continue to serve as the **golden firmware** in the SPI boot flash | ||
| - **Initial Load Process**: | ||
| - Boot the SONiC kernel with a minimal initramfs from U-Boot to launch a shell, and use the included script to download the image via TFTP and flash it to the eMMC. |
There was a problem hiding this comment.
For the “boot minimal initramfs from U-Boot then run TFTP script” path: where does that kernel + initramfs come from initially (SPI partition, network, or other)?
The current names follow the same semantics adopted for various vendors that make switches using broadcom - please see platform/broadcom. The vendor directories under platform/speed are for 1. Eval board from aspeed 2. Our card. I added eval board assuming it will help other vendors in their bringup using the eval board from aspeed. Serves as a useful reference platform. |
|
Is it possible to extend this
I'm talking about file names in this PR. Can you rename: To something like: |
Ah ok, I got confused. |
|
/azp run |
|
No pipelines are associated with this pull request. |
Renamed the files as suggested. |
1st draft, describes addition of BMC support to SONiC