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

[Johannes Truschnigg <johannes@truschnigg.info>]

[-- Attachment #1: Type: text/plain, Size: 6133 bytes --]

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


For posterity and completeness, this is what culvert has to say about the
BMC's state now that it runs OpenBMC:

```
root@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.


On Wed, May 29, 2024 at 10:22:09AM +0930, Andrew Jeffery wrote:
> On Tue, 2024-05-28 at 20:37 +0200, Johannes Truschnigg wrote:
> > [...]
> > Understood. Is that always the case for OpenBMC kernel images with default
> > config?
> 
> Depends on what you mean by default. Which platform did you build for?

I built obmc-phosphor-image for evb-ast2500.


> > [...]
> 
> Right, culvert is likely missing some trick with initialising the flash
> controller. I'm trying to understand what that might be :)

I was hoping you were going to say that! 8-)


> > [...]
> > 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! :)


> > [...]
> 
> The least-effort hack would be to place the stock firmware at
> /run/initramfs/image-bmc and reboot OpenBMC - this will write the stock
> firmware image back to the flash for you.

Thanks; this reads like a very easy way to revert to stock - I will play
around with OpenBMC on the physical thing some more before actually trying
that out, though!


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


> > Can you perhaps offer me advice on how to flash arbitrary new SPI flash
> > contents from either OpenBMC's u-boot or an OpenBMC root shell, or what I would
> > need to look at in detail to learn how to do that?
> 
> See the comment above regarding /run/initramfs/image-bmc. However you
> can also boot to an initrd and use flashcp. The main thing is you need
> to make sure no other accesses to the mtd device are taking place
> (hence suggesting the initrd environment).

Thanks again also for this! One of my problems is that I have no idea what
userland support utils/components even *exist* for that kind of embedded hw, so
I am very much in the dark what my options could be without such hints.


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


[0]: https://johannes.truschnigg.info/tmp/strace_gigaflash_initial_.3305.zst

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

www:   https://johannes.truschnigg.info/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]