* VR control from the BMC
@ 2020-10-26 23:02 Ed Tanous
2020-10-27 18:55 ` Vijay Khemka
2020-10-27 20:26 ` Patrick Williams
0 siblings, 2 replies; 6+ messages in thread
From: Ed Tanous @ 2020-10-26 23:02 UTC (permalink / raw)
To: OpenBMC Maillist
In the near future, I'm going to have some needs for OpenBMC to be
able to control VRs. These VRs might be on the baseboard itself, or
on detected PCIe add-in-cards, and controlled over PMBus.
Additionally, I will need a "hardware safe" way for the host to be
able to modify the behavior of these VRs (usually different voltage
settings), and to have that interface be constrained in such a way
that the host can never set a value that's outside of a predefined
range that's known to be safe for the hardware, which the BMC will own
the definition of for security purposes.
Does anyone else have similar needs? I've been pointed to
phosphor-regulators which has some similar parallels; As-is, that
solution won't work for me, because it's relying on fixed, platform
specific json scripting to accomplish its goals. My hope would be for
a more generalized linux devicetree based solution, as well as a
representation on dbus that could be modified at runtime by
Redfish/IPMI in band.
Is there any other work I should look into that's similar? Does
anyone have any strong opinions on how this should be organized or how
it could be built?
Thanks,
-Ed
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: VR control from the BMC
2020-10-26 23:02 VR control from the BMC Ed Tanous
@ 2020-10-27 18:55 ` Vijay Khemka
2020-10-27 19:10 ` Ed Tanous
2020-10-27 20:26 ` Patrick Williams
1 sibling, 1 reply; 6+ messages in thread
From: Vijay Khemka @ 2020-10-27 18:55 UTC (permalink / raw)
To: Ed Tanous, OpenBMC Maillist
On 10/26/20, 4:04 PM, "openbmc on behalf of Ed Tanous" <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of edtanous@google.com> wrote:
In the near future, I'm going to have some needs for OpenBMC to be
able to control VRs. These VRs might be on the baseboard itself, or
on detected PCIe add-in-cards, and controlled over PMBus.
Additionally, I will need a "hardware safe" way for the host to be
able to modify the behavior of these VRs (usually different voltage
settings), and to have that interface be constrained in such a way
that the host can never set a value that's outside of a predefined
range that's known to be safe for the hardware, which the BMC will own
the definition of for security purposes.
Does anyone else have similar needs? I've been pointed to
phosphor-regulators which has some similar parallels; As-is, that
solution won't work for me, because it's relying on fixed, platform
specific json scripting to accomplish its goals. My hope would be for
a more generalized linux devicetree based solution,
Voltage limits can certainly be passed via DTS file to limit user
application configuration setting.
as well as a
representation on dbus that could be modified at runtime by
Redfish/IPMI in band.
Is there any other work I should look into that's similar? Does
anyone have any strong opinions on how this should be organized or how
it could be built?
I would also like to add VR firmware upgrades as well in this.
Thanks,
-Ed
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: VR control from the BMC
2020-10-27 18:55 ` Vijay Khemka
@ 2020-10-27 19:10 ` Ed Tanous
2020-10-27 20:11 ` Vijay Khemka
0 siblings, 1 reply; 6+ messages in thread
From: Ed Tanous @ 2020-10-27 19:10 UTC (permalink / raw)
To: Vijay Khemka; +Cc: OpenBMC Maillist
On Tue, Oct 27, 2020 at 11:55 AM Vijay Khemka <vijaykhemka@fb.com> wrote:
>
> On 10/26/20, 4:04 PM, "openbmc on behalf of Ed Tanous" <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of edtanous@google.com> wrote:
>
> In the near future, I'm going to have some needs for OpenBMC to be
> able to control VRs. These VRs might be on the baseboard itself, or
> on detected PCIe add-in-cards, and controlled over PMBus.
> Additionally, I will need a "hardware safe" way for the host to be
> able to modify the behavior of these VRs (usually different voltage
> settings), and to have that interface be constrained in such a way
> that the host can never set a value that's outside of a predefined
> range that's known to be safe for the hardware, which the BMC will own
> the definition of for security purposes.
>
> Does anyone else have similar needs? I've been pointed to
> phosphor-regulators which has some similar parallels; As-is, that
> solution won't work for me, because it's relying on fixed, platform
> specific json scripting to accomplish its goals. My hope would be for
> a more generalized linux devicetree based solution,
>
> Voltage limits can certainly be passed via DTS file to limit user
> application configuration setting.
Anything in the DTS would remove the possibility of controlling VRs
that weren't part of the baseboard, and would be a problem for me.
Also, these limits would likely need to be dynamic, and might rely on
certain calibration constants in the chip. I don't think a hardcoded
DTS limit would meet my needs.
>
> as well as a
> representation on dbus that could be modified at runtime by
> Redfish/IPMI in band.
>
> Is there any other work I should look into that's similar? Does
> anyone have any strong opinions on how this should be organized or how
> it could be built?
>
> I would also like to add VR firmware upgrades as well in this.
I don't have the need to upgrade VR firmware out of band today, but if
you're interested in helping define interfaces that would work for
firmware upgrade or make it easy to add in the future, I'd appreciate
the help.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: VR control from the BMC
2020-10-27 19:10 ` Ed Tanous
@ 2020-10-27 20:11 ` Vijay Khemka
0 siblings, 0 replies; 6+ messages in thread
From: Vijay Khemka @ 2020-10-27 20:11 UTC (permalink / raw)
To: Ed Tanous; +Cc: OpenBMC Maillist
I don't have the need to upgrade VR firmware out of band today, but if
you're interested in helping define interfaces that would work for
firmware upgrade or make it easy to add in the future, I'd appreciate
the help.
I will certainly look into this as this is lower in my priority tasks.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: VR control from the BMC
2020-10-26 23:02 VR control from the BMC Ed Tanous
2020-10-27 18:55 ` Vijay Khemka
@ 2020-10-27 20:26 ` Patrick Williams
2020-10-27 20:54 ` Ed Tanous
1 sibling, 1 reply; 6+ messages in thread
From: Patrick Williams @ 2020-10-27 20:26 UTC (permalink / raw)
To: Ed Tanous; +Cc: OpenBMC Maillist
[-- Attachment #1: Type: text/plain, Size: 1684 bytes --]
On Mon, Oct 26, 2020 at 04:02:22PM -0700, Ed Tanous wrote:
> In the near future, I'm going to have some needs for OpenBMC to be
> able to control VRs. These VRs might be on the baseboard itself, or
> on detected PCIe add-in-cards, and controlled over PMBus.
> Additionally, I will need a "hardware safe" way for the host to be
> able to modify the behavior of these VRs (usually different voltage
> settings), and to have that interface be constrained in such a way
> that the host can never set a value that's outside of a predefined
> range that's known to be safe for the hardware, which the BMC will own
> the definition of for security purposes.
>
> Does anyone else have similar needs? I've been pointed to
> phosphor-regulators which has some similar parallels; As-is, that
> solution won't work for me, because it's relying on fixed, platform
> specific json scripting to accomplish its goals. My hope would be for
> a more generalized linux devicetree based solution, as well as a
> representation on dbus that could be modified at runtime by
> Redfish/IPMI in band.
>
> Is there any other work I should look into that's similar? Does
> anyone have any strong opinions on how this should be organized or how
> it could be built?
>
> Thanks,
>
> -Ed
Are these PMBus VRs? I was able to program limits on a non-BMC project
I was working on using the PMBus interfaces to the VRs we used on that
project.
I did need to write this patch which I'm still suppose to clean up with
some additional clamp_val tweaks to avoid negative numbers.
https://lore.kernel.org/lkml/20191001160407.6265-1-alpawi@amazon.com/
--
Patrick Williams
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: VR control from the BMC
2020-10-27 20:26 ` Patrick Williams
@ 2020-10-27 20:54 ` Ed Tanous
0 siblings, 0 replies; 6+ messages in thread
From: Ed Tanous @ 2020-10-27 20:54 UTC (permalink / raw)
To: Patrick Williams; +Cc: OpenBMC Maillist
On Tue, Oct 27, 2020 at 1:26 PM Patrick Williams <patrick@stwcx.xyz> wrote:
>
> On Mon, Oct 26, 2020 at 04:02:22PM -0700, Ed Tanous wrote:
> > In the near future, I'm going to have some needs for OpenBMC to be
> > able to control VRs. These VRs might be on the baseboard itself, or
> > on detected PCIe add-in-cards, and controlled over PMBus.
> > Additionally, I will need a "hardware safe" way for the host to be
> > able to modify the behavior of these VRs (usually different voltage
> > settings), and to have that interface be constrained in such a way
> > that the host can never set a value that's outside of a predefined
> > range that's known to be safe for the hardware, which the BMC will own
> > the definition of for security purposes.
> >
> > Does anyone else have similar needs? I've been pointed to
> > phosphor-regulators which has some similar parallels; As-is, that
> > solution won't work for me, because it's relying on fixed, platform
> > specific json scripting to accomplish its goals. My hope would be for
> > a more generalized linux devicetree based solution, as well as a
> > representation on dbus that could be modified at runtime by
> > Redfish/IPMI in band.
> >
> > Is there any other work I should look into that's similar? Does
> > anyone have any strong opinions on how this should be organized or how
> > it could be built?
> >
> > Thanks,
> >
> > -Ed
>
> Are these PMBus VRs?
Yes.
> I was able to program limits on a non-BMC project
> I was working on using the PMBus interfaces to the VRs we used on that
> project.
>
> I did need to write this patch which I'm still suppose to clean up with
> some additional clamp_val tweaks to avoid negative numbers.
>
> https://lore.kernel.org/lkml/20191001160407.6265-1-alpawi@amazon.com/
That pointer helps. Thanks.
>
> --
> Patrick Williams
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-10-27 20:55 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-26 23:02 VR control from the BMC Ed Tanous
2020-10-27 18:55 ` Vijay Khemka
2020-10-27 19:10 ` Ed Tanous
2020-10-27 20:11 ` Vijay Khemka
2020-10-27 20:26 ` Patrick Williams
2020-10-27 20:54 ` Ed Tanous
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).