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

Sun Jul 7 19:19:20 AEST 2024

Hey list!

Sorry for my long radio silence -- I've been busy (with other things, but also)
quietly working at this porting project of mine, and made some imho rather cool
progress. I have also, however, hit a few roadblocks I cannot seem to surmount
on my own, and so I turn to you, dear reader, for advice and/or consolation.

I have my own "meta-gigabyte" layer including a board-specific DTS for u-boot
and linux-aspeed, with results of those that seem mostly OK. The
ultra-barebones bmcweb function is there, and I have iKVM working.

My plan was to get host power control and the ID button/LED working as a next
objective - that way, the most important features from my POV would be there,
and I would feel OK-ish with publishing what I got. For the past few weeks, I
had been living under the impression that poking GPIO 27 the right way did just
that (power up the host), and so I went on to reverse engineer the ID
button/LED stuff with `gpiomon`. I figured out a number of functions this way:

The Front Panel Header (FPH) Power Button corresponds to GPIO 24.
The FPH Reset Button to GPIO 26.
The FPH ID Button (as well as the board-mounted ID button) to GPIO 134.
HDD LED activity seems to be wired to GPIO 111.
The ID LED on the board itself is controlled via GPIO offset 49.

Having poked at all these GPIOs somehow made my GPIO 27 interaction to boot up
the host ineffective, however. That change persisted and survived even a cycle
of going back to the stock firmware, and then flashing OpenBMC again. I have no
idea what went wrong there, but I might have since managed to recover/revise
the procedure, and can get the host to power again as a consequence: After a
*ton* of experimentation, I think I also have figure out the proper minimal
sequence of gpioset and gpioget invocations to make the host boot when the BMC
is online; it seems to be this magic spell:

# gpioget 0 25; gpioset -m time -D open-source -s 1 0 27=1; \
  gpioset 0 25=0; gpioget 0 25

(I cannot help but notice that these pins are adjacent to the RESET and POWER
buttons!)

What I am struggling with now is how I should best make x86-power-control or a
functional equivalent benefit from this knowledge, too, and how I can make it
manage host power state in my stead. I was hoping that someone on this list
would be both knowledgeable and kind enough to give me advice on how to
proceed. The OpenBMC tree has a number of other machines where a shellscript
that's a machine-specific part of "phosphor-state-manager" does the required
`gpioget`/`gpioget` dance and then uses `busctl` to let the rest of the system
know how things are (supposed to be) after that - is that what I should be
purusing, too? Or would it just be a matter of properly naming (*is* there a
canonical (sub)set of GPIO names?) the numeric IDs in the DTS, and I could
expect things to magically fall into place on their own? If there's some
implementation I should be looking at in particular, I'd be happy to do and
then try mimic that.

Also, since right now the FPH pins/buttons don't do anything apart from
registering in gpiomon, I was wondering if it's normal to be the BMC's job to
wait for these event firing, and then doing the proper GPIO magic to perform
what the user asked for pressing the respective button. I guess that is what
has to happen, right? If so, can anyone maybe tell me where to look at for an
example of how this is set up for an existing, working machine?

Furthermore, I am not sure which other operations I'll still have to figure out
GPIO sequences for. Graceful shutdown (I expect this to have to generate an
ACPI Power Button event in the host, or is there some other magic involved?)
probably, "forced" shutdown/cutting power - but what else? And does anyone have
any concrete advice on how to methodically tackle that (find out which GPIO
needs which treatment to generate which event)?

What I also wanted to learn is how I should best integrate my custom .dts and
resulting .dtb in my machine-specific layer(s), so that both the kernel and
u-boot "pick it up" correctly. The kernel part was relatively easy, since the
build infra seems to automatically include any additional .dts named files
placed in the proper location and be able to use that via setting
'KERNEL_DEVICETREE = "gigabyte-mc12-le0.dtb"' (in my instance), but u-boot does
not, and I ended up overwriting arch/arm/dts/ast2500-evb.dts with my own in a
`do_patch:append() {}` block and setting 'UBOOT_DEVICETREE = "ast2500-evb"' in
my machine config.

I guess the *intended*/preferred way is to upstream the (correct and sufficient
- which I do not have yet) DTS artifacts into both kernel and u-boot, and not
to have this problem in the first place? Assuming that's not an option for now,
how should I *properly* integrate my local modification (actually: addition) so
that OpenBMC upstream would be in a position to accept the "meta-gigabyte"
layer including it with good conscience? (That is my eventual goal :))

Thanks a lot for reading this far, and for all the support provided to me off
and on list to get this closer to actually working! :)

-- 
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/20240707/9845ca39/attachment.sig>