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

[Andrew Jeffery]

On Thu, 2024-05-30 at 17:37 +0200, Johannes Truschnigg wrote:
> Hi list!
> 
> First things first, I wanted to share the good news that I can now boot the
> host with OpenBMC running the show on the BMC: Fiddling with GPIO #539 on the
> OpenBMC root shell in the right way makes the host power up a few seconds
> later. I do it like this for now:
> 
> ```
> echo 539 > /sys/class/gpio/export
> echo out > /sys/class/gpio/gpio539/direction
> echo 0 > /sys/class/gpio/gpio539/value
> sleep 1
> echo 1 > /sys/class/gpio/gpio539/value
> ```
> 
> I'd like to say thanks to my friend Paul on IRC here in public, because
> without your patient guidance and steady flow of information and ideas, this
> 100% wouldn't have been possible!! :)

Nice work. For the record, the GPIO sysfs interface is deprecated and
likely to go away soon. Useful for PoCs, but longer term you should
look to the libgpiod APIs and tools[1].

[1]: https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/about/

> 
> 
> For posterity and completeness, this is what culvert has to say about the
> BMC's state now that it runs OpenBMC:
> 
> ```
> root at grml ~ # /tmp/culvert -v -v probe
> [*] Found 5 registered bridge drivers
> [*] Trying bridge driver l2a
> [*] Failed to initialise L2A bridge: -95
> [*] Trying bridge driver ilpc
> [*] Probing ilpc
> [*] Probing 0x2e for SuperIO
> [*] Unlocking SuperIO: 0
> [*] Selecting SuperIO device 2 (SUART1): 0
> [*] Found device 255 selected: 0
> [*] Locking SuperIO
> [*] Probing 0x4e for SuperIO
> [*] Unlocking SuperIO: 0
> [*] Selecting SuperIO device 2 (SUART1): 0
> [*] Found device 255 selected: 0
> [*] Locking SuperIO
> [*] SuperIO disabled
> [*] Trying bridge driver devmem
> [*] failed to initialise devmem bridge: -1
> [*] Trying bridge driver debug-uart
> [*] Unrecognised argument list for debug interface (0)
> [*] Trying bridge driver p2a
> [*] Probing p2a
> [*] Probing for SoC revision registers
> [*] ahb_readl: 0x1e6e2004: 0xffffffff
> [*] ahb_readl: 0x1e6e207c: 0xffffffff
> [*] Found revision 0xffffffff
> [*] Revision 0xffffffff is unsupported
> [*] Failed P2A probe: -19
> [*] Accessing the BMC's AHB via the ilpc bridge
> [*] Probing for SoC revision registers
> [*] ahb_readl: 0x1e6e2004: 0xffffffff
> [*] ahb_readl: 0x1e6e207c: 0xffffffff
> [*] Found revision 0xffffffff
> [*] Revision 0xffffffff is unsupported
> [*] Failed to probe SoC revision: -19
> [*] Failed to probe SoC, exiting: -19
> 
> ```
> 
> I haven't tried to execute gigaflash on the booted host yet, but it is on my
> list of things to try next.

What you can see from the output above is that OpenBMC has disabled all
the hardware backdoors that culvert tries to exploit.

The consequence of this is that gigaflash will (... should?) now also
fail to function.

You may want to play with these u-boot options:

https://github.com/openbmc/u-boot/blob/v2019.04-aspeed-openbmc/arch/arm/mach-aspeed/Kconfig#L48-L85

Or we can add support to culvert for enabling and disabling the
backdoors at runtime, and run it with /dev/mem enabled on the BMC (set
mem.devmem=1 on the kernel commandline). Adding support to culvert
should just be a matter of wiring up some command-line UI - what bits
to flip and the necessary abstractions are already provided in the
implementation.
> 
> 
> > > [...]
> > > I do have strace capture of `gigaflash` running for the first time after a
> > > reboot, but all the juicy bits seem to hide behind mmap() anyway, so I will
> > > only provide it upon request.
> > 
> > Well, consider this a request :D What it's mapping is of interest to
> > me, along with what it's opening more broadly, and any calls to
> > ioperm() or iopl().
> 
> I've uploaded the zstd-compressed trace result (it contains a lot of the
> actual ROM content dumped with how I called strace/gigaflash) to [0]. I really
> hope it helps chasing down what you're looking for! :)

Given some of the discussion on the culvert issue, it may not, but I'll
take a look. And indeed they're using the P2A, so we'll need to
consider another approach to tracing the accesses.

> 
> 
> > > Once I have established a surefire and straightfoward way to do what I have
> > > done in such meandering and clumsy attempts, I would like to learn more about
> > > how the "M" is actually put into this whole "BMC" thing, and see how far I can
> > > take that. The stock fw has some interesting description files regarding i2c
> > > configs that might come in handy, but I am just not educated enough (yet, I
> > > hope) to make real sense of it :)
> > 
> > Yeah, the I2C configs will certainly help.
> > 
> > Breaking into the stock firmware on the hardware and tracing things
> > like GPIO accesses would go a long way. With the tools at hand it
> > shouldn't be too difficult :)
> 
> Yeah that would be cool, but I had established with Paul that the stock fw
> kernel doesn't come with debugfs and missing userspace tooling for tracing
> syscalls, so it will certainly be a challenge (at least for me, equipped with
> my current skillset, and the time constraints of having a day job with some
> other meatspace activity on top of that :D).

If you can coax it past u-boot under qemu you can trace the hardware
accesses via the qemu models (without requiring support from the OS).


> Meanwhile, due to a friendly user on a German web forum who led me to similar
> matters discussed about an ASRock Rack-series motherboard (which also comes
> with AST2500 for its BMC purposes), I think I have properly identified the
> relevant IC where the BMC's firmware actually resides, and it looks like
> SOIC-8 in direct vicinity to the AST2500 itself. I will have some new gear for
> my electronics drawer delivered soon to see how/if I can deal with it! :)

For the record, Zev (who also helps out with culvert) is the OpenBMC
maintainer for the ASRock Rack platforms, so should be able to assist
you there as well.

Andrew