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

[Johannes Truschnigg]

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 :)

I have a Gigabyte MC12-LE0[0] mainboard in hand, which has an AST2500-based
integrated BMC running AMI-supplied (mildly customized, I gather) BMC firmware.
I would very much like to try to get OpenBMC to boot on this BMC instead of the
stock fw, but have hit a number of walls during my first baby steps with this
over the last few days, which is why I turn to you to seek help and guidance.

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.

Afaict, the AMI BMC firmware lineage uses another (custom, undisclosed?) image
format that seems to be called "FMH" internally. While there are some third
party tools[1] and patches to support it[2] floating around on the net, I
failed to get anywhere with either until now.


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?

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).

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?) Do you have any
hints how I could achieve what I am trying to do? Is this even feasible?

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.

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/

-- 
with best regards:
- Johannes Truschnigg ( johannes at truschnigg.info )

www:   https://johannes.truschnigg.info/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20240520/df451c13/attachment.sig>