RFC: ASRockRack E3C246D4I port

From: Zev Weiss <zweiss@equinix.com>
To: "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>
Subject: RFC: ASRockRack E3C246D4I port
Date: Fri, 12 Mar 2021 02:45:26 +0000	[thread overview]
Message-ID: <YErVxrB4afOz1ejt@packtop> (raw)

Hello all,

We (Equinix Metal, formerly known as Packet) having been working on a
port of OpenBMC to the ASRockRack E3C246D4I board
(https://www.asrockrack.com/general/productdetail.asp?Model=E3C246D4I-2T,
an AST2500-equipped Xeon E-2100 mini-ITX board), and we're now looking to
get some feedback from the community and hopefully start the process of
getting it merged upstream.

It's currently sitting in a Github branch, since at the moment I'm
mostly seeking fairly broad guidance on what sorts of things will need
to happen to get it into a mergeable form (not sure if gerrit is the
right tool for that).  Anyone who'd like to can take a look at:
https://github.com/zevweiss/openbmc/tree/e3c246d4i

Known issues, in approximate descending order of significance (by my
estimate):

  - The kernel situation is...kind of messy.  This mostly stems from
    having a dependency on the PECI code, which is why the branch is
    based on the 2.9.0 tag (the last one before the PECI patchset was
    dropped from the openbmc kernel) instead of something more recent.
    We've got some additional PECI patches on top of that to work around
    some limitations in the PECI support on the particular CPU we're
    working with, some of which is fairly gross hardcoding for that
    specific SKU.  There are also a few non-PECI-related kernel patches
    that I've posted upstream but not yet incorporated the resulting 
    review feedback on.

  - There are various hacks to get things like x86-power-control and
    host-error-monitor compiling and working reasonably, and I'm sort of
    skeptical that the approach I took there would be considered
    desirable.

  - The directory naming is currently meta-equinix/meta-e3c246d4i;
    starting out I was a bit unsure whether to name based on the
    maintainer/developer of the layer or the maker of the hardware and we
    ended up with the former, though I see Ed's in-progress x570d4u port
    has things under meta-asrock, so perhaps that should be renamed?

  - There are some relatively generic patches for dbus-sensors and
    entity-manager that should probably be merged independently.

If anyone can give it a look and let me know what the best way forward
would be for this we'd certainly appreciate it.

Thanks,
Zev Weiss