OpenBMC replacing AMI AST2500 BMC fw on Gigabyte MC12-LE0 - questions

Tue May 21 11:05:34 AEST 2024

Hello,

On Mon, 2024-05-20 at 19:32 +0200, Johannes Truschnigg wrote:
> Dear list,
> 
> I am new to this whole BMC-innards thing, and the very opposite of familiar
> with embedded devices, so please bear with me on this :)

:)

> 
> The BMC implementation seems lean very much onto the AST2500 Evaluation Board
> (the unchanged name pops up in a number of places in the stock firmware), so I
> would guess that the OpenBMC evb-ast2500 machine should be able to get
> somewhere (and even if it's just to see OpenBMC's instead of AMI's Linux start,
> and then crash hard due to some subtle incompatibility :)) at least.

Perhaps. While the SoC itself is obviously supported, how it's
integrated into the rest of the platform will likely be very different
to how things are wired up on the EVB.

> My understanding is that there are two paths forward:
> 
> 1.) To make OpenBMC's build artifacts into FMH-style BLOBs, and find a way to
> feed them to the stock fw's u-boot, which would ideally result in OpenBMC being
> able to boot this way.
> 
> 2.) To replace the stock fw's u-boot release with an OpenBMC u-boot that can
> load the evb-ast2500 artifacts natively, and have the BMC boot OpenBMC that
> way.
> 
> Can you please confirm that this assessment is sane, or correct me if it isn't?

Yeah, that's sane. I'm not familiar with FMH so can't really comment on
how feasible that approach might be, but my intuition is it's probably
a bunch of pain.

> 
> If so, I would presume option 2.) to be the easier road to travel, but I am
> somewhat stumped as to how I can get OpenBMC's u-boot onto the BMC, *ideally*
> (but not necessarily) in a non-destructive way (as I do not know how to or have
> a way to revert to the original state without access to the bootloader or even
> stock firmware running).

Something to consider is using qemu to boot the proprietary firmware,
and do your experiments there. That way it's non-destructive in the
sense that it's all just software and you won't need to break out a
flash programmer.

A quick look at the BMC firmware from your [1] shows Gigabyte do their
usual thing and ship the entire flash image. I downloaded the zip file,
unpacked it, and booted it like

```
0 andrew at heihei:~$ mkdir /tmp/mc12-le0
0 andrew at heihei:~$ cd !$
cd /tmp/mc12-le0
0 andrew at heihei:/tmp/mc12-le0$ unzip ~/Downloads/server_firmware_ast2500_AMI_12.x.zip
Archive:  /home/andrew/Downloads/server_firmware_ast2500_AMI_12.x.zip
   creating: 126121/
  inflating: 126121/bmc_fw_update_linux.sh
  inflating: 126121/bmc_fw_update_uefi.nsh
  inflating: 126121/bmc_fw_update_win.bat
  inflating: 126121/BMC_Release_Note_126121.doc
   creating: 126121/fw/
  inflating: 126121/fw/126121.bin
  inflating: 126121/fw/rom.ima_enc
  inflating: 126121/GBT_BMC_Firmware_Upgrade_User_Guide_v006_pre.pdf
  inflating: 126121/projects.txt
   creating: 126121/Tools/
  inflating: 126121/Tools/gigaflash
  inflating: 126121/Tools/gigaflash.efi
  inflating: 126121/Tools/gigaflash.exe
  inflating: 126121/Tools/gigaflash_arm
  inflating: 126121/Tools/gigaflash_arm.efi
  inflating: 126121/Tools/gigaflash_x64
  inflating: 126121/Tools/gigaflash_x64.exe
   creating: 126121/Tools/x64/
  inflating: 126121/Tools/x64/astio.cat
  inflating: 126121/Tools/x64/astio.sys
   creating: 126121/Tools/x64_Win8/
  inflating: 126121/Tools/x64_Win8/astio.cat
  inflating: 126121/Tools/x64_Win8/astio.Inf
  inflating: 126121/Tools/x64_Win8/astio.sys
   creating: 126121/Tools/x86/
  inflating: 126121/Tools/x86/astio.sys
0 andrew at heihei:/tmp/mc12-le0$ cd 126121/fw
0 andrew at heihei:/tmp/mc12-le0/126121/fw$ binwalk 126121.bin

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
163848        0x28008         CRC32 polynomial table, little endian
213604        0x34264         CRC32 polynomial table, little endian
393216        0x60000         JFFS2 filesystem, little endian
5636096       0x560000        CramFS filesystem, little endian, size: 40951808, version 2, sorted_dirs, CRC 0x417607BC, edition 0, 27801 blocks, 6575 files
46596160      0x2C70040       uImage header, header size: 64 bytes, header CRC: 0x596F847A, created: 2024-03-12 06:08:06, image size: 2792592 bytes, Data Address: 0x80008000, Entry Point: 0x80008000, data CRC: 0xC9C2F025, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: none, image name: "Linux-3.14.17-ami"
46596224      0x2C70080       Linux kernel ARM boot executable zImage (little-endian)
46613079      0x2C74257       gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null date)
49479680      0x2F30000       JFFS2 filesystem, little endian
50003968      0x2FB0000       CramFS filesystem, little endian, size: 5963776, version 2, sorted_dirs, CRC 0xBCBB0E63, edition 0, 1566 blocks, 131 files

0 andrew at heihei:/tmp/mc12-le0/126121/fw$ truncate -s 64M 126121.bin
0 andrew at heihei:/tmp/mc12-le0/126121/fw$ qemu-system-arm -M ast2500-evb,fmc-model=n25q512a -drive file=126121.bin,if=mtd,format=raw -nographic
qemu-system-arm: warning: Aspeed iBT has no chardev backend

U-Boot 2013.07 (Mar 12 2024 - 14:08:49)

I2C:   ready
DRAM:  424 MiB
eSPI Handshake complete
OEM_BOARD_INIT - Start (BMC)
LPC mode
OEM_BOARD_INIT - End
Flash: Found SPI Chip Micron/Numonyx N25Q512A(0x20ba) 2x I/O READ, NORMAL WRITE
64 MiB
MMC:   
*** Warning - bad CRC, using default environment

Un-Protected 1 sectors
Erasing Flash...
Erasing sector  4 ... ok.
Erased 1 sectors
Writing to Flash... done
Protected 1 sectors
Net:   RTL8211E, EEECR = 0x00
RTL8211E, EEEAR = 0x00
RTL8211E, EEELPAR = 0x00
RTL8211E, LACR = 0x00
RTL8211E, LCR = 0x00
ast_eth0, ast_eth1
DRAM ECC enabled
Hit any key to stop autoboot:  0 
Image to be booted is 1
EMMC and EXT4 is not enabled - Cannot locate kernel file in Root
Initing KCS...done
Uboot waiting for firmware update to start...
Uboot waiting for fwupdate to start timed out
Disabling Watchdog 2 Timer
AST2500EVB>
```

Not sure how productive that is, but maybe you can experiment.

If you enable networking and tftp on the qemu command-line you could
potentially boot your own kernels. Or you could mess with booting the
OpenBMC firmware as well.

If you want to do something more destructive and overwrite the firmware
on the flash, then you should probably have a flash programmer handy,
and/or become familiar with something like culvert (which I maintain):

https://github.com/amboar/culvert

Note that gigabyte do ship "gigaflash" in that zip file above, which is
a closed-source application similar to culvert, that derives from
Aspeed's own "socflash" tool.

> 
> So far, I tried to put the u-boot-evb-ast2500-v2019.04+git-r0.bin artifact from
> my OpenBMC build results into a memory location on the BMC using TFTP, and `go`
> to that address afterwards - but that effectively reloaded the *original*
> u-boot from the vendor fw. I don't know enough about the inner workings of an
> AST2500 or u-boot (or any other embedded bootloader, really), but if you could
> enlighten me as to what has happened there, I'd be very grateful (... maybe
> u-boot does a check if it's already reloacted itself towards end of phys.
> memory, and directly jump there if that is deemed the case?)
> 

u-boot is linked at 0 and uses XIP from the SPI-NOR (which is memory-
mapped at 0), so I suspect it has read out the vendor copy again.

>  Do you have any
> hints how I could achieve what I am trying to do? Is this even feasible?

Given the above, you'd have to replace u-boot on the hardware.

> 
> I did find a Github issue[3] from 2017 which hints at others having tried
> something like this, but no documented successes.
> 
> I'd be very grateful for your input on this matter. Please keep my address CC'd
> as I am currently not subscribed to this list.

A potential collaborator on Gigabyte stuff is bielids. I don't have
their contact details, but you can find some of our past discussion
here:

https://github.com/amboar/culvert/issues/51

Andrew

> 
> Thank you all very much for your time reading this! :)
> 
> 
> PS: I've included some potentially useful u-boot monitor output from the stock
> firmware at [4], as I am not sure if attachments of this size (or inline text)
> would be OK on-list.
> 
> 
> [0]: https://www.gigabyte.com/Enterprise/Server-Motherboard/MC12-LE0-rev-1x
> [1]: https://github.com/ya-mouse/bmc-ami
> [2]: https://github.com/ami-megarac/OSSW/blob/master/SPX-12/Kernel_amiext_ex-src/12-drivers_mtd_maps_fmh.h
> [3]: https://github.com/openbmc/openbmc/issues/1649
> [4]: https://paste.debian.net/hidden/43509e70/
> 