Date   

DC-SCM 2.0 pinout updated

Qian Wang
 

Dear HWMM participants,

A new version of the DC-SCM 2.0 pinout has been posted in the tracker spreadsheet, tab pinout_4_15_2021.  This would be the final version unless we identify something unexpected.  The tracker spreadsheet can be found on the HWMM wiki and the link below:


Thanks,
Qian


DC-SCM2.0 CS for SCM-HPM SPI interface #poll-notice

Qian Wang
 

New SCM-HPM SPI interface proposal, this requires one additional signal to be added to the connector.  The last un-used pin.
For details, please refer to the SPI tab in the tracker spreadsheet.

Results

See Who Responded


DC-SCM2.0 chassis intrusion #poll-notice

Qian Wang
 

We have a split opinion on a dedicated chassis intrusion pin for the DC-SCI2.0 connector.  Please put in your vote by 3/19/2021.

Results

See Who Responded


Re: RunBMC v1.5 Change RFC

Wszolek, Kasper
 

Hi Eric,

 

For current DC-SCM 2.0 pinout we settled at 6 x I3C minimum and 8 x I2C/I3C 1.8V that will allow to easily move from I2C to I3C in the future without pinout change. The DC-SCM 2.0 decision is driven by expectation that more use cases will be moving from I2C/SMBus to I3C and we’ll be able to utilize all BMC links available + more in the future.

 

--

Thanks,

Kasper

 

From: OCP-HWMgt-Module@OCP-All.groups.io <OCP-HWMgt-Module@OCP-All.groups.io> On Behalf Of Eric Shobe
Sent: Wednesday, March 10, 2021 06:55
To: OCP-HWMgt-Module@OCP-All.groups.io
Cc: Jared Mednick <jared.mednick@...>; Jared Mednick <jaredm@...>
Subject: Re: [OCP-HWMgt-Module] RunBMC v1.5 Change RFC

 

+Jared Mednick - I've been sort of waiting for the DC-SCM spec to see what happens there. 
What is driving the need of 6 if I may ask?

Eric

 

On Fri, Feb 5, 2021 at 10:54 AM Wszolek, Kasper <kasper.wszolek@...> wrote:

Hi Eric,

 

Did you consider adding more I3C interfaces than 4 in the pinout proposal below? I think we should try to define more I3C (total 6) even with some limitations defined in the spec for backward compatibility (level shifting on RunBMC module as an example).  

 

--

Thanks,

Kasper

 

 

From: OCP-HWMgt-Module@OCP-All.groups.io <OCP-HWMgt-Module@OCP-All.groups.io> On Behalf Of Lior Elbaz
Sent: Monday, January 25, 2021 19:14
To: OCP-HWMgt-Module@OCP-All.groups.io; Jared Mednick <jared.mednick@...>; Jared Mednick <jaredm@...>
Subject: Re: [OCP-HWMgt-Module] RunBMC v1.5 Change RFC

 

Hi Eric,

See embedded.

 

From: OCP-HWMgt-Module@OCP-All.groups.io <OCP-HWMgt-Module@OCP-All.groups.io> On Behalf Of Eric Shobe via groups.io
Sent: Monday, January 25, 2021 19:20
To: OCP-HWMgt-Module@OCP-All.groups.io; Jared Mednick <jared.mednick@...>; Jared Mednick <jaredm@...>
Subject: Re: [OCP-HWMgt-Module] RunBMC v1.5 Change RFC

 

 

 

On Mon, Jan 25, 2021 at 7:44 AM Lior Elbaz <lior.albaz@...> wrote:

Hi Eric,

 

Can you elaborate on PFR_RST# signal and what is the different between current BMC_RESET# pin 253 ?

BMC_RESET#  also keep BMC in reset (core reset).

 

BMC_RESET# is to drive "Chip level reset" or "Power-Up Reset".

PFR_RST# is to drive "SOC level reset" or "BMC CPU Reset Input".  

 

Lior> Note that in Nuvoton model we used BMC_RESET# (CPU Reset) pin 253  as "BMC CPU Reset Input" and pin 95 as "Power-Up Reset".

 

 

what is the usage of BMC_PWRGD(output) ? is it from RunBMC to MB signal ?

Note that currently there is PWRGD signal pin 77 from MB to RunBMC.

 

BMC_PWRGD output is from RunBMC to MB. 

BMC_PWRGD output that would indicate the power on the RunBMC module is good. 

 

Lior> so this can be implemented by BMC GPIO that default to low and set high by the FW when BMC is ready. It will indicate FW is running as well.

 

Can you elaborate on PLT_RST# signal ? is it BMC power-on-reset signal ?

 

The PLT_RST# signal rename is to better indicate the usage of this signal with no change in original functionality. 

This is "Platform Reset" instead of "CPU Reset".  This signal will monitor CPU/Platform resets. 

 

In the spec we have this function defined as "Host CPU Reset Monitor" and will change

this to "Host Platform Reset Monitor"

 

Lior> I assume this a new pin assignment regards to V1.0 and not related to pin BMC_RESET#  253.

Note that Nuvoton model currently support it on pin 95.

 

Regards,

Lior.

 

From: OCP-HWMgt-Module@OCP-All.groups.io <OCP-HWMgt-Module@OCP-All.groups.io> On Behalf Of Eric Shobe via groups.io
Sent: Monday, January 25, 2021 08:02
To: OCP-HWMgt-Module@OCP-All.groups.io
Subject: [OCP-HWMgt-Module] RunBMC v1.5 Change RFC

 


Hi all,

 

I want to welcome everyone to comment on the following proposed changes for RunBMC v1.5. 

The change requests we have received so far are the following:

 

  •  Add Display Port Functionality [need to decide]

 

From RunBMC pins perspective the VGA pins could be reused for Display Port assuming 2 Lanes, Aux Lane and presence detect there are exactly 7 pins needed. 

The following high level changes would be needed to support this. 

 

1. Add filtering for TX pairs 

2. Add HW straps on daughter board to support dual function for TX pairs
3. Add HW straps for AUX diff pair
4. Add HW strap HPD presence
5. Describe filtering/circuitry needed near DP connector on mobo

 

The pinout proposal is here. 

 

  • eMMC functionality [proposed]

If the specification was to be changed to say "eMMC may be added on the RunBMC module", we don't see that as changing anything.  Today, with the specification, anyone who wants to design a RunBMC module can choose to add eMMC or not.

If designs add eMMC over the connector some will loose 4 pairs of I2C pins (I2C10 to I2C13).

  • BMC SD interface. Add SD interface

Screen Shot 2021-01-24 at 9.43.18 PM.png

 

  • Add PWRGB signal. [proposed]

We will add pin95(GPIO63) to be BMC_PWRGD(output)

 

95 BMC_PWRGD_GPIO63  

 

  • Add PFR Reset Signal [proposed]

We will add one more reset input pin on pin93(GPIO61) as PFR_RST#

93 PFR_RST#_GPIO61 

CPLD/circuitry can use the signal to let BMC in reset state.

  • Change pin name from CPU_RST# to PLT_RST# [proposed]
  • I3C [proposed]

Add the I3C3-6 pin definition below. (The I3C 1.0/1.2V signals
need to co-lay with following GF pins.) If user need the I3C 1.0V/1.2V function, please add
a level shift logic IC at MB side.

 

Screen Shot 2021-01-24 at 9.57.28 PM.png

 

Thanks,

Eric


The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.


The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.

---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
ul. Słowackiego 173 | 80-298 Gdańsk | Sąd Rejonowy Gdańsk Północ | VII Wydział Gospodarczy Krajowego Rejestru Sądowego - KRS 101882 | NIP 957-07-52-316 | Kapitał zakładowy 200.000 PLN.
Ta wiadomość wraz z załącznikami jest przeznaczona dla określonego adresata i może zawierać informacje poufne. W razie przypadkowego otrzymania tej wiadomości, prosimy o powiadomienie nadawcy oraz trwałe jej usunięcie; jakiekolwiek przeglądanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.

---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
ul. Słowackiego 173 | 80-298 Gdańsk | Sąd Rejonowy Gdańsk Północ | VII Wydział Gospodarczy Krajowego Rejestru Sądowego - KRS 101882 | NIP 957-07-52-316 | Kapitał zakładowy 200.000 PLN.
Ta wiadomość wraz z załącznikami jest przeznaczona dla określonego adresata i może zawierać informacje poufne. W razie przypadkowego otrzymania tej wiadomości, prosimy o powiadomienie nadawcy oraz trwałe jej usunięcie; jakiekolwiek przeglądanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.


Re: RunBMC v1.5 Change RFC

Eric Shobe
 

+Jared Mednick - I've been sort of waiting for the DC-SCM spec to see what happens there. 
What is driving the need of 6 if I may ask?
Eric

On Fri, Feb 5, 2021 at 10:54 AM Wszolek, Kasper <kasper.wszolek@...> wrote:

Hi Eric,

 

Did you consider adding more I3C interfaces than 4 in the pinout proposal below? I think we should try to define more I3C (total 6) even with some limitations defined in the spec for backward compatibility (level shifting on RunBMC module as an example).  

 

--

Thanks,

Kasper

 

 

From: OCP-HWMgt-Module@OCP-All.groups.io <OCP-HWMgt-Module@OCP-All.groups.io> On Behalf Of Lior Elbaz
Sent: Monday, January 25, 2021 19:14
To: OCP-HWMgt-Module@OCP-All.groups.io; Jared Mednick <jared.mednick@...>; Jared Mednick <jaredm@...>
Subject: Re: [OCP-HWMgt-Module] RunBMC v1.5 Change RFC

 

Hi Eric,

See embedded.

 

From: OCP-HWMgt-Module@OCP-All.groups.io <OCP-HWMgt-Module@OCP-All.groups.io> On Behalf Of Eric Shobe via groups.io
Sent: Monday, January 25, 2021 19:20
To: OCP-HWMgt-Module@OCP-All.groups.io; Jared Mednick <jared.mednick@...>; Jared Mednick <jaredm@...>
Subject: Re: [OCP-HWMgt-Module] RunBMC v1.5 Change RFC

 

 

 

On Mon, Jan 25, 2021 at 7:44 AM Lior Elbaz <lior.albaz@...> wrote:

Hi Eric,

 

Can you elaborate on PFR_RST# signal and what is the different between current BMC_RESET# pin 253 ?

BMC_RESET#  also keep BMC in reset (core reset).

 

BMC_RESET# is to drive "Chip level reset" or "Power-Up Reset".

PFR_RST# is to drive "SOC level reset" or "BMC CPU Reset Input".  

 

Lior> Note that in Nuvoton model we used BMC_RESET# (CPU Reset) pin 253  as "BMC CPU Reset Input" and pin 95 as "Power-Up Reset".

 

 

what is the usage of BMC_PWRGD(output) ? is it from RunBMC to MB signal ?

Note that currently there is PWRGD signal pin 77 from MB to RunBMC.

 

BMC_PWRGD output is from RunBMC to MB. 

BMC_PWRGD output that would indicate the power on the RunBMC module is good. 

 

Lior> so this can be implemented by BMC GPIO that default to low and set high by the FW when BMC is ready. It will indicate FW is running as well.

 

Can you elaborate on PLT_RST# signal ? is it BMC power-on-reset signal ?

 

The PLT_RST# signal rename is to better indicate the usage of this signal with no change in original functionality. 

This is "Platform Reset" instead of "CPU Reset".  This signal will monitor CPU/Platform resets. 

 

In the spec we have this function defined as "Host CPU Reset Monitor" and will change

this to "Host Platform Reset Monitor"

 

Lior> I assume this a new pin assignment regards to V1.0 and not related to pin BMC_RESET#  253.

Note that Nuvoton model currently support it on pin 95.

 

Regards,

Lior.

 

From: OCP-HWMgt-Module@OCP-All.groups.io <OCP-HWMgt-Module@OCP-All.groups.io> On Behalf Of Eric Shobe via groups.io
Sent: Monday, January 25, 2021 08:02
To: OCP-HWMgt-Module@OCP-All.groups.io
Subject: [OCP-HWMgt-Module] RunBMC v1.5 Change RFC

 


Hi all,

 

I want to welcome everyone to comment on the following proposed changes for RunBMC v1.5. 

The change requests we have received so far are the following:

 

  •  Add Display Port Functionality [need to decide]

 

From RunBMC pins perspective the VGA pins could be reused for Display Port assuming 2 Lanes, Aux Lane and presence detect there are exactly 7 pins needed. 

The following high level changes would be needed to support this. 

 

1. Add filtering for TX pairs 

2. Add HW straps on daughter board to support dual function for TX pairs
3. Add HW straps for AUX diff pair
4. Add HW strap HPD presence
5. Describe filtering/circuitry needed near DP connector on mobo

 

The pinout proposal is here. 

 

  • eMMC functionality [proposed]

If the specification was to be changed to say "eMMC may be added on the RunBMC module", we don't see that as changing anything.  Today, with the specification, anyone who wants to design a RunBMC module can choose to add eMMC or not.

If designs add eMMC over the connector some will loose 4 pairs of I2C pins (I2C10 to I2C13).

  • BMC SD interface. Add SD interface

Screen Shot 2021-01-24 at 9.43.18 PM.png

 

  • Add PWRGB signal. [proposed]

We will add pin95(GPIO63) to be BMC_PWRGD(output)

 

95 BMC_PWRGD_GPIO63  

 

  • Add PFR Reset Signal [proposed]

We will add one more reset input pin on pin93(GPIO61) as PFR_RST#

93 PFR_RST#_GPIO61 

CPLD/circuitry can use the signal to let BMC in reset state.

  • Change pin name from CPU_RST# to PLT_RST# [proposed]
  • I3C [proposed]

Add the I3C3-6 pin definition below. (The I3C 1.0/1.2V signals
need to co-lay with following GF pins.) If user need the I3C 1.0V/1.2V function, please add
a level shift logic IC at MB side.

 

Screen Shot 2021-01-24 at 9.57.28 PM.png

 

Thanks,

Eric


The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.


The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.

---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
ul. Słowackiego 173 | 80-298 Gdańsk | Sąd Rejonowy Gdańsk Północ | VII Wydział Gospodarczy Krajowego Rejestru Sądowego - KRS 101882 | NIP 957-07-52-316 | Kapitał zakładowy 200.000 PLN.
Ta wiadomość wraz z załącznikami jest przeznaczona dla określonego adresata i może zawierać informacje poufne. W razie przypadkowego otrzymania tej wiadomości, prosimy o powiadomienie nadawcy oraz trwałe jej usunięcie; jakiekolwiek przeglądanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.


Re: FRU EEPROM usage models

Eric Shobe
 

Hi Kasper,
+Jared Mednick . Will look into this and get back to you.
Eric

On Tue, Feb 23, 2021 at 11:47 AM Wszolek, Kasper <kasper.wszolek@...> wrote:

Hi Eric and Jarred,

 

We’re looking for some clarification regarding the usage of FRU EEPROMs defined by RunBMC Spec:

  1. What is the use case of Host accessing EEPROM FRU on the RunBMC module?
  2. Is the RunBMC EEPROM intended to store MAC addresses of the BMC SoC? If so is this a mandatory requirement or other solutions might be acceptable from compliance perspective e.g. storing MAC on System Board EEPROM?
  3. There’s a note in the spec (section 5.2.13) that Host SMBus shall be able to access EEPROM FRU and BMC interface on I2C9 – what is the BMC interface required to be exposed to Host SMBus on I2C9?
  4. Is the access to System Board EEPROM from BMC not mandatory since I2C4 have GPIO alternative usage or can System Board EEPROM be located on different bus?
  5. If I2C4 is used as I3C (RunBMC 1.5 proposal) is BMC intended to support mixed configuration on the bus with I2C EEPROM and I3C devices?

 

--

Thanks,

Kasper

---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
ul. Słowackiego 173 | 80-298 Gdańsk | Sąd Rejonowy Gdańsk Północ | VII Wydział Gospodarczy Krajowego Rejestru Sądowego - KRS 101882 | NIP 957-07-52-316 | Kapitał zakładowy 200.000 PLN.
Ta wiadomość wraz z załącznikami jest przeznaczona dla określonego adresata i może zawierać informacje poufne. W razie przypadkowego otrzymania tej wiadomości, prosimy o powiadomienie nadawcy oraz trwałe jej usunięcie; jakiekolwiek przeglądanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.


Invitation: Hardware Management Modules Sub-Project meeting @ Weekly from 11:30am to 12:30pm on Monday 16 times (CST) (ocp-hwmgt-module@ocp-all.groups.io)

Michael Schill
 

You have been invited to the following event.

Hardware Management Modules Sub-Project meeting

When
Weekly from 11:30am to 12:30pm on Monday 16 times Central Time - Chicago
Calendar
ocp-hwmgt-module@ocp-all.groups.io
Who
Michael Schill - creator
qian.wang@...
ocp-hwmgt-module@ocp-all.groups.io
qian.wang@...
shobe@...
eric.shobe@...
archna@... - optional
Please join my meeting from your computer, tablet or smartphone. 
https://global.gotomeeting.com/join/454746381 

You can also dial in using your phone. 
United States: +1 (646) 749-3112 

Access Code: 454-746-381 

Joining from a video-conferencing room or system? 
Dial: 67.217.95.2##454746381 
Cisco devices: 454746381@... 

First GoToMeeting? Let's do a quick system check: https://link.gotomeeting.com/system-check 

Going (ocp-hwmgt-module@ocp-all.groups.io)?   All events in this series:   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account ocp-hwmgt-module@ocp-all.groups.io because you are an attendee of this event.

To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar.

Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More.


FRU EEPROM usage models

Wszolek, Kasper
 

Hi Eric and Jarred,

 

We’re looking for some clarification regarding the usage of FRU EEPROMs defined by RunBMC Spec:

  1. What is the use case of Host accessing EEPROM FRU on the RunBMC module?
  2. Is the RunBMC EEPROM intended to store MAC addresses of the BMC SoC? If so is this a mandatory requirement or other solutions might be acceptable from compliance perspective e.g. storing MAC on System Board EEPROM?
  3. There’s a note in the spec (section 5.2.13) that Host SMBus shall be able to access EEPROM FRU and BMC interface on I2C9 – what is the BMC interface required to be exposed to Host SMBus on I2C9?
  4. Is the access to System Board EEPROM from BMC not mandatory since I2C4 have GPIO alternative usage or can System Board EEPROM be located on different bus?
  5. If I2C4 is used as I3C (RunBMC 1.5 proposal) is BMC intended to support mixed configuration on the bus with I2C EEPROM and I3C devices?

 

--

Thanks,

Kasper

---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
ul. Słowackiego 173 | 80-298 Gdańsk | Sąd Rejonowy Gdańsk Północ | VII Wydział Gospodarczy Krajowego Rejestru Sądowego - KRS 101882 | NIP 957-07-52-316 | Kapitał zakładowy 200.000 PLN.
Ta wiadomość wraz z załącznikami jest przeznaczona dla określonego adresata i może zawierać informacje poufne. W razie przypadkowego otrzymania tej wiadomości, prosimy o powiadomienie nadawcy oraz trwałe jej usunięcie; jakiekolwiek przeglądanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.


Re: RunBMC v1.5 Change RFC

Wszolek, Kasper
 

Hi Eric,

 

Did you consider adding more I3C interfaces than 4 in the pinout proposal below? I think we should try to define more I3C (total 6) even with some limitations defined in the spec for backward compatibility (level shifting on RunBMC module as an example).  

 

--

Thanks,

Kasper

 

 

From: OCP-HWMgt-Module@OCP-All.groups.io <OCP-HWMgt-Module@OCP-All.groups.io> On Behalf Of Lior Elbaz
Sent: Monday, January 25, 2021 19:14
To: OCP-HWMgt-Module@OCP-All.groups.io; Jared Mednick <jared.mednick@...>; Jared Mednick <jaredm@...>
Subject: Re: [OCP-HWMgt-Module] RunBMC v1.5 Change RFC

 

Hi Eric,

See embedded.

 

From: OCP-HWMgt-Module@OCP-All.groups.io <OCP-HWMgt-Module@OCP-All.groups.io> On Behalf Of Eric Shobe via groups.io
Sent: Monday, January 25, 2021 19:20
To: OCP-HWMgt-Module@OCP-All.groups.io; Jared Mednick <jared.mednick@...>; Jared Mednick <jaredm@...>
Subject: Re: [OCP-HWMgt-Module] RunBMC v1.5 Change RFC

 

 

 

On Mon, Jan 25, 2021 at 7:44 AM Lior Elbaz <lior.albaz@...> wrote:

Hi Eric,

 

Can you elaborate on PFR_RST# signal and what is the different between current BMC_RESET# pin 253 ?

BMC_RESET#  also keep BMC in reset (core reset).

 

BMC_RESET# is to drive "Chip level reset" or "Power-Up Reset".

PFR_RST# is to drive "SOC level reset" or "BMC CPU Reset Input".  

 

Lior> Note that in Nuvoton model we used BMC_RESET# (CPU Reset) pin 253  as "BMC CPU Reset Input" and pin 95 as "Power-Up Reset".

 

 

what is the usage of BMC_PWRGD(output) ? is it from RunBMC to MB signal ?

Note that currently there is PWRGD signal pin 77 from MB to RunBMC.

 

BMC_PWRGD output is from RunBMC to MB. 

BMC_PWRGD output that would indicate the power on the RunBMC module is good. 

 

Lior> so this can be implemented by BMC GPIO that default to low and set high by the FW when BMC is ready. It will indicate FW is running as well.

 

Can you elaborate on PLT_RST# signal ? is it BMC power-on-reset signal ?

 

The PLT_RST# signal rename is to better indicate the usage of this signal with no change in original functionality. 

This is "Platform Reset" instead of "CPU Reset".  This signal will monitor CPU/Platform resets. 

 

In the spec we have this function defined as "Host CPU Reset Monitor" and will change

this to "Host Platform Reset Monitor"

 

Lior> I assume this a new pin assignment regards to V1.0 and not related to pin BMC_RESET#  253.

Note that Nuvoton model currently support it on pin 95.

 

Regards,

Lior.

 

From: OCP-HWMgt-Module@OCP-All.groups.io <OCP-HWMgt-Module@OCP-All.groups.io> On Behalf Of Eric Shobe via groups.io
Sent: Monday, January 25, 2021 08:02
To: OCP-HWMgt-Module@OCP-All.groups.io
Subject: [OCP-HWMgt-Module] RunBMC v1.5 Change RFC

 


Hi all,

 

I want to welcome everyone to comment on the following proposed changes for RunBMC v1.5. 

The change requests we have received so far are the following:

 

  •  Add Display Port Functionality [need to decide]

 

From RunBMC pins perspective the VGA pins could be reused for Display Port assuming 2 Lanes, Aux Lane and presence detect there are exactly 7 pins needed. 

The following high level changes would be needed to support this. 

 

1. Add filtering for TX pairs 

2. Add HW straps on daughter board to support dual function for TX pairs
3. Add HW straps for AUX diff pair
4. Add HW strap HPD presence
5. Describe filtering/circuitry needed near DP connector on mobo

 

The pinout proposal is here. 

 

  • eMMC functionality [proposed]

If the specification was to be changed to say "eMMC may be added on the RunBMC module", we don't see that as changing anything.  Today, with the specification, anyone who wants to design a RunBMC module can choose to add eMMC or not.

If designs add eMMC over the connector some will loose 4 pairs of I2C pins (I2C10 to I2C13).

  • BMC SD interface. Add SD interface

Screen Shot 2021-01-24 at 9.43.18 PM.png

 

  • Add PWRGB signal. [proposed]

We will add pin95(GPIO63) to be BMC_PWRGD(output)

 

95 BMC_PWRGD_GPIO63  

 

  • Add PFR Reset Signal [proposed]

We will add one more reset input pin on pin93(GPIO61) as PFR_RST#

93 PFR_RST#_GPIO61 

CPLD/circuitry can use the signal to let BMC in reset state.

  • Change pin name from CPU_RST# to PLT_RST# [proposed]
  • I3C [proposed]

Add the I3C3-6 pin definition below. (The I3C 1.0/1.2V signals
need to co-lay with following GF pins.) If user need the I3C 1.0V/1.2V function, please add
a level shift logic IC at MB side.

 

Screen Shot 2021-01-24 at 9.57.28 PM.png

 

Thanks,

Eric


The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.


The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.

---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
ul. Słowackiego 173 | 80-298 Gdańsk | Sąd Rejonowy Gdańsk Północ | VII Wydział Gospodarczy Krajowego Rejestru Sądowego - KRS 101882 | NIP 957-07-52-316 | Kapitał zakładowy 200.000 PLN.
Ta wiadomość wraz z załącznikami jest przeznaczona dla określonego adresata i może zawierać informacje poufne. W razie przypadkowego otrzymania tej wiadomości, prosimy o powiadomienie nadawcy oraz trwałe jej usunięcie; jakiekolwiek przeglądanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.


extending Interface survey deadline?

Jeff Booher-Kaeding
 

Hello,

I wanted to request extending the interface survey deadline so our partners can provide a more detailed list of interface usage.
In the meantime Arm will respond with a minimal SBMR server example.

Thanks,
Jeff Bother-Kaeding


Re: RunBMC v1.5 Change RFC

Lior Elbaz
 

Hi Eric,

See embedded.

 

From: OCP-HWMgt-Module@OCP-All.groups.io <OCP-HWMgt-Module@OCP-All.groups.io> On Behalf Of Eric Shobe via groups.io
Sent: Monday, January 25, 2021 19:20
To: OCP-HWMgt-Module@OCP-All.groups.io; Jared Mednick <jared.mednick@...>; Jared Mednick <jaredm@...>
Subject: Re: [OCP-HWMgt-Module] RunBMC v1.5 Change RFC

 

 

 

On Mon, Jan 25, 2021 at 7:44 AM Lior Elbaz <lior.albaz@...> wrote:

Hi Eric,

 

Can you elaborate on PFR_RST# signal and what is the different between current BMC_RESET# pin 253 ?

BMC_RESET#  also keep BMC in reset (core reset).

 

BMC_RESET# is to drive "Chip level reset" or "Power-Up Reset".

PFR_RST# is to drive "SOC level reset" or "BMC CPU Reset Input".  

 

Lior> Note that in Nuvoton model we used BMC_RESET# (CPU Reset) pin 253  as "BMC CPU Reset Input" and pin 95 as "Power-Up Reset".

 

 

what is the usage of BMC_PWRGD(output) ? is it from RunBMC to MB signal ?

Note that currently there is PWRGD signal pin 77 from MB to RunBMC.

 

BMC_PWRGD output is from RunBMC to MB. 

BMC_PWRGD output that would indicate the power on the RunBMC module is good. 

 

Lior> so this can be implemented by BMC GPIO that default to low and set high by the FW when BMC is ready. It will indicate FW is running as well.

 

Can you elaborate on PLT_RST# signal ? is it BMC power-on-reset signal ?

 

The PLT_RST# signal rename is to better indicate the usage of this signal with no change in original functionality. 

This is "Platform Reset" instead of "CPU Reset".  This signal will monitor CPU/Platform resets. 

 

In the spec we have this function defined as "Host CPU Reset Monitor" and will change

this to "Host Platform Reset Monitor"

 

Lior> I assume this a new pin assignment regards to V1.0 and not related to pin BMC_RESET#  253.

Note that Nuvoton model currently support it on pin 95.

 

Regards,

Lior.

 

From: OCP-HWMgt-Module@OCP-All.groups.io <OCP-HWMgt-Module@OCP-All.groups.io> On Behalf Of Eric Shobe via groups.io
Sent: Monday, January 25, 2021 08:02
To: OCP-HWMgt-Module@OCP-All.groups.io
Subject: [OCP-HWMgt-Module] RunBMC v1.5 Change RFC

 


Hi all,

 

I want to welcome everyone to comment on the following proposed changes for RunBMC v1.5. 

The change requests we have received so far are the following:

 

  •  Add Display Port Functionality [need to decide]

 

From RunBMC pins perspective the VGA pins could be reused for Display Port assuming 2 Lanes, Aux Lane and presence detect there are exactly 7 pins needed. 

The following high level changes would be needed to support this. 

 

1. Add filtering for TX pairs 

2. Add HW straps on daughter board to support dual function for TX pairs
3. Add HW straps for AUX diff pair
4. Add HW strap HPD presence
5. Describe filtering/circuitry needed near DP connector on mobo

 

The pinout proposal is here. 

 

  • eMMC functionality [proposed]

If the specification was to be changed to say "eMMC may be added on the RunBMC module", we don't see that as changing anything.  Today, with the specification, anyone who wants to design a RunBMC module can choose to add eMMC or not.

If designs add eMMC over the connector some will loose 4 pairs of I2C pins (I2C10 to I2C13).

  • BMC SD interface. Add SD interface

Screen Shot 2021-01-24 at 9.43.18 PM.png

 

  • Add PWRGB signal. [proposed]

We will add pin95(GPIO63) to be BMC_PWRGD(output)

 

95 BMC_PWRGD_GPIO63  

 

  • Add PFR Reset Signal [proposed]

We will add one more reset input pin on pin93(GPIO61) as PFR_RST#

93 PFR_RST#_GPIO61 

CPLD/circuitry can use the signal to let BMC in reset state.

  • Change pin name from CPU_RST# to PLT_RST# [proposed]
  • I3C [proposed]

Add the I3C3-6 pin definition below. (The I3C 1.0/1.2V signals
need to co-lay with following GF pins.) If user need the I3C 1.0V/1.2V function, please add
a level shift logic IC at MB side.

 

Screen Shot 2021-01-24 at 9.57.28 PM.png

 

Thanks,

Eric


The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.


The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.


Re: RunBMC v1.5 Change RFC

Eric Shobe
 



On Mon, Jan 25, 2021 at 7:44 AM Lior Elbaz <lior.albaz@...> wrote:

Hi Eric,

 

Can you elaborate on PFR_RST# signal and what is the different between current BMC_RESET# pin 253 ?

BMC_RESET#  also keep BMC in reset (core reset).


BMC_RESET# is to drive "Chip level reset" or "Power-Up Reset".
PFR_RST# is to drive "SOC level reset" or "BMC CPU Reset Input".  
 

 

what is the usage of BMC_PWRGD(output) ? is it from RunBMC to MB signal ?

Note that currently there is PWRGD signal pin 77 from MB to RunBMC.


BMC_PWRGD output is from RunBMC to MB. 
BMC_PWRGD output that would indicate the power on the RunBMC module is good. 
 

 

Can you elaborate on PLT_RST# signal ? is it BMC power-on-reset signal ?


The PLT_RST# signal rename is to better indicate the usage of this signal with no change in original functionality. 
This is "Platform Reset" instead of "CPU Reset".  This signal will monitor CPU/Platform resets. 

In the spec we have this function defined as "Host CPU Reset Monitor" and will change
this to "Host Platform Reset Monitor"
 

Note that Nuvoton model currently support it on pin 95.

 

Regards,

Lior.

 

From: OCP-HWMgt-Module@OCP-All.groups.io <OCP-HWMgt-Module@OCP-All.groups.io> On Behalf Of Eric Shobe via groups.io
Sent: Monday, January 25, 2021 08:02
To: OCP-HWMgt-Module@OCP-All.groups.io
Subject: [OCP-HWMgt-Module] RunBMC v1.5 Change RFC

 


Hi all,

 

I want to welcome everyone to comment on the following proposed changes for RunBMC v1.5. 

The change requests we have received so far are the following:

 

  •  Add Display Port Functionality [need to decide]

 

From RunBMC pins perspective the VGA pins could be reused for Display Port assuming 2 Lanes, Aux Lane and presence detect there are exactly 7 pins needed. 

The following high level changes would be needed to support this. 

 

1. Add filtering for TX pairs 

2. Add HW straps on daughter board to support dual function for TX pairs
3. Add HW straps for AUX diff pair
4. Add HW strap HPD presence
5. Describe filtering/circuitry needed near DP connector on mobo

 

The pinout proposal is here. 

 

  • eMMC functionality [proposed]

If the specification was to be changed to say "eMMC may be added on the RunBMC module", we don't see that as changing anything.  Today, with the specification, anyone who wants to design a RunBMC module can choose to add eMMC or not.

If designs add eMMC over the connector some will loose 4 pairs of I2C pins (I2C10 to I2C13).

  • BMC SD interface. Add SD interface

Screen Shot 2021-01-24 at 9.43.18 PM.png

 

  • Add PWRGB signal. [proposed]

We will add pin95(GPIO63) to be BMC_PWRGD(output)

 

95 BMC_PWRGD_GPIO63  

 

  • Add PFR Reset Signal [proposed]

We will add one more reset input pin on pin93(GPIO61) as PFR_RST#

93 PFR_RST#_GPIO61 

CPLD/circuitry can use the signal to let BMC in reset state.

  • Change pin name from CPU_RST# to PLT_RST# [proposed]
  • I3C [proposed]

Add the I3C3-6 pin definition below. (The I3C 1.0/1.2V signals
need to co-lay with following GF pins.) If user need the I3C 1.0V/1.2V function, please add
a level shift logic IC at MB side.

 

Screen Shot 2021-01-24 at 9.57.28 PM.png

 

Thanks,

Eric


The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.


Re: RunBMC v1.5 Change RFC

Lior Elbaz
 

Hi Eric,

 

Can you elaborate on PFR_RST# signal and what is the different between current BMC_RESET# pin 253 ?

BMC_RESET#  also keep BMC in reset (core reset).

 

what is the usage of BMC_PWRGD(output) ? is it from RunBMC to MB signal ?

Note that currently there is PWRGD signal pin 77 from MB to RunBMC.

 

Can you elaborate on PLT_RST# signal ? is it BMC power-on-reset signal ?

Note that Nuvoton model currently support it on pin 95.

 

Regards,

Lior.

 

From: OCP-HWMgt-Module@OCP-All.groups.io <OCP-HWMgt-Module@OCP-All.groups.io> On Behalf Of Eric Shobe via groups.io
Sent: Monday, January 25, 2021 08:02
To: OCP-HWMgt-Module@OCP-All.groups.io
Subject: [OCP-HWMgt-Module] RunBMC v1.5 Change RFC

 


Hi all,

 

I want to welcome everyone to comment on the following proposed changes for RunBMC v1.5. 

The change requests we have received so far are the following:

 

  •  Add Display Port Functionality [need to decide]

 

From RunBMC pins perspective the VGA pins could be reused for Display Port assuming 2 Lanes, Aux Lane and presence detect there are exactly 7 pins needed. 

The following high level changes would be needed to support this. 

 

1. Add filtering for TX pairs 

2. Add HW straps on daughter board to support dual function for TX pairs
3. Add HW straps for AUX diff pair
4. Add HW strap HPD presence
5. Describe filtering/circuitry needed near DP connector on mobo

 

The pinout proposal is here. 

 

  • eMMC functionality [proposed]

If the specification was to be changed to say "eMMC may be added on the RunBMC module", we don't see that as changing anything.  Today, with the specification, anyone who wants to design a RunBMC module can choose to add eMMC or not.

If designs add eMMC over the connector some will loose 4 pairs of I2C pins (I2C10 to I2C13).

  • BMC SD interface. Add SD interface

Screen Shot 2021-01-24 at 9.43.18 PM.png

 

  • Add PWRGB signal. [proposed]

We will add pin95(GPIO63) to be BMC_PWRGD(output)

 

95 BMC_PWRGD_GPIO63  

 

  • Add PFR Reset Signal [proposed]

We will add one more reset input pin on pin93(GPIO61) as PFR_RST#

93 PFR_RST#_GPIO61 

CPLD/circuitry can use the signal to let BMC in reset state.

  • Change pin name from CPU_RST# to PLT_RST# [proposed]
  • I3C [proposed]

Add the I3C3-6 pin definition below. (The I3C 1.0/1.2V signals
need to co-lay with following GF pins.) If user need the I3C 1.0V/1.2V function, please add
a level shift logic IC at MB side.

 

Screen Shot 2021-01-24 at 9.57.28 PM.png

 

Thanks,

Eric


The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.


RunBMC v1.5 Change RFC

Eric Shobe
 


Hi all,

I want to welcome everyone to comment on the following proposed changes for RunBMC v1.5. 
The change requests we have received so far are the following:

  •  Add Display Port Functionality [need to decide]

From RunBMC pins perspective the VGA pins could be reused for Display Port assuming 2 Lanes, Aux Lane and presence detect there are exactly 7 pins needed. 
The following high level changes would be needed to support this. 

1. Add filtering for TX pairs 
2. Add HW straps on daughter board to support dual function for TX pairs
3. Add HW straps for AUX diff pair
4. Add HW strap HPD presence
5. Describe filtering/circuitry needed near DP connector on mobo

The pinout proposal is here. 

  • eMMC functionality [proposed]
If the specification was to be changed to say "eMMC may be added on the RunBMC module", we don't see that as changing anything.  Today, with the specification, anyone who wants to design a RunBMC module can choose to add eMMC or not.
If designs add eMMC over the connector some will loose 4 pairs of I2C pins (I2C10 to I2C13).
  • BMC SD interface. Add SD interface
Screen Shot 2021-01-24 at 9.43.18 PM.png

  • Add PWRGB signal. [proposed]

We will add pin95(GPIO63) to be BMC_PWRGD(output)

95 BMC_PWRGD_GPIO63  
 
  • Add PFR Reset Signal [proposed]
We will add one more reset input pin on pin93(GPIO61) as PFR_RST#

93 PFR_RST#_GPIO61 

CPLD/circuitry can use the signal to let BMC in reset state.

  • Change pin name from CPU_RST# to PLT_RST# [proposed]

  • I3C [proposed]
Add the I3C3-6 pin definition below. (The I3C 1.0/1.2V signals
need to co-lay with following GF pins.) If user need the I3C 1.0V/1.2V function, please add
a level shift logic IC at MB side.

Screen Shot 2021-01-24 at 9.57.28 PM.png

Thanks,
Eric


RunBMC support for I3C

Wszolek, Kasper
 

Hi Eric,

 

Can you please share the details of supporting I3C links with new version of RunBMC Spec i.e.:

  1. How many I3C links are going to be supported?
  2. What pins are going to support I3C signals (I’m assuming this will be alternative function to existing pins)?
  3. What is the plan for supporting various I3C bus voltage levels?

 

--

Thanks,

Kasper

---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
ul. Słowackiego 173 | 80-298 Gdańsk | Sąd Rejonowy Gdańsk Północ | VII Wydział Gospodarczy Krajowego Rejestru Sądowego - KRS 101882 | NIP 957-07-52-316 | Kapitał zakładowy 200.000 PLN.
Ta wiadomość wraz z załącznikami jest przeznaczona dla określonego adresata i może zawierać informacje poufne. W razie przypadkowego otrzymania tej wiadomości, prosimy o powiadomienie nadawcy oraz trwałe jej usunięcie; jakiekolwiek przeglądanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.


Invitation: Hardware Management Modules Sub-Project meeting @ Weekly from 12:30pm to 1:30pm on Monday 8 times (EST) (ocp-hwmgt-module@ocp-all.groups.io)

Michael Schill
 

You have been invited to the following event.

Hardware Management Modules Sub-Project meeting

When
Weekly from 12:30pm to 1:30pm on Monday 8 times Eastern Time - New York
Calendar
ocp-hwmgt-module@ocp-all.groups.io
Who
Michael Schill - creator
qian.wang@...
ocp-hwmgt-module@ocp-all.groups.io
qian.wang@...
archna@... - optional
Please join my meeting from your computer, tablet or smartphone. 
https://global.gotomeeting.com/join/454746381 

You can also dial in using your phone. 
United States: +1 (646) 749-3112 

Access Code: 454-746-381 

Joining from a video-conferencing room or system? 
Dial: 67.217.95.2##454746381 
Cisco devices: 454746381@... 

First GoToMeeting? Let's do a quick system check: https://link.gotomeeting.com/system-check 

Going (ocp-hwmgt-module@ocp-all.groups.io)?   All events in this series:   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account ocp-hwmgt-module@ocp-all.groups.io because you are an attendee of this event.

To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar.

Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More.


Re: Display Port support in RunBMC

Wszolek, Kasper
 

Hi Eric,

 

Thank you for providing the options below. First option (VGA pins reuse) is more preferable in my opinion and it’s exactly how I pictured adding DP support to RunBMC.

 

Here are some comments on both options:

  • It looks like the backward compatibility will be broken for both options. HW straps (as you indicated below) will be needed to maintain compatibility between different implementations on HW-level (if compatibility is required for particular design).
  • VGA vs. DP is more of a system design choice: it goes with video output standard choice and different electrical requirements for the main board as well, video connector options etc. In my opinion from RunBMC perspective it’s very similar case as with 1GbE PHY options – it’s not possible to support both 1GbE PHY configurations at the time with current version of the spec as well (without HW changes).
  • With second option (GPIO only) more GPIOs will be repurposed to DP than when reusing VGA pins.
  • DC-SCM example designs go with DP. DP connectors are much smaller and easier to integrate on front panel. I think that we can expect more adoptions of DP vs. VGA in the future due to size constrains and VGA availability on the displays.

 

Can we schedule to discuss this topic on one of sub-project meeting you are planning to set up?

 

--

Thanks,

Kasper

 

 

From: Eric Shobe <eric.shobe@...>
Sent: Tuesday, December 1, 2020 23:34
To: Wszolek, Kasper <kasper.wszolek@...>; OCP-HWMgt-Module@OCP-All.groups.io
Cc: Jared Mednick <jared.mednick@...>; Eric Shobe <shobe@...>; Jared Mednick <jaredm@...>
Subject: Re: Display Port support in RunBMC

 

Hi Kasper, 

 

I cc'ed the alias for OCP HW Mgmt. 

To support Display Port here are the changes.  

 

Pins

Requester

High Level Changes

DPAUXP
DPAUXN
DPTXP0
DPTXN0
DPHPD
DPTXP1
DPTXN1

Intel

1. Add filtering for TX pairs
2. Add HW straps on daughter board to support dual function for TX pairs
3. Add HW straps for AUX diff pair
4. Add HW strap HPD presence
5. Describe filtering/circuitry needed near DP connector on mobo
6. Can't share all on VGA because block already has dual function and backward compat would be lost. However we could use DACR/G/B and partial GPIO block OR all GPIO block

 

Looking at the possible pin-out changes: 

 

Pinout to share VGA block.  We would loose backward compat with 4 GPIO signals

DACG_DPAUXP

10

DACB_DPAUXN

12

DACR_DPHPD

14

VGAHS_GPIO2DPTXPO

16

VGAVS_GPIO4DPTXNO

18

DDCCLK_GPIO6DPTXP1

20

DDCDAT_GPIO8DPTXN1

22

 

 

Pintout to share GPIO block. Would need to add HW multiplex via resistor straps and filtering. 

 

GPIO19_DPAUXP

36

GPIO20_DPAUXN

38

....

GPIO38_DPHPD

66

GPIO39_DPTXP0

68

GPIO40_DPTXN0

70

GPIO42_DPTXP1

72

GPIO44_DPTXN1

74

 

 

Which one seems preferable from your side?

 

Eric

 

On Sat, Nov 28, 2020 at 1:44 PM Wszolek, Kasper <kasper.wszolek@...> wrote:

Hi Eric and Jared,

 

Hope you guys are doing great. I’ve enjoyed your presentation on OCP TECH WEEK – thank you for nice words about our RunBMC module and the demo 😊 I just want to let you know that we are still working internally on the process to eventually contribute our RunBMC module design to OCP. We’re bringing up the second version of the module now with some additional fixes we did based on the first version we showed on the demo.

 

I noted down your objectives to be addresses in the next version of the spec but I don’t recall that you mentioned Display Port support option in new spec version? I’m wondering if you explored it already? We are looking for a way to support that with RunBMC and it seems that from RunBMC pins perspective the VGA pins could be reused for Display Port assuming 2 Lanes, Aux Lane and presence detect there are exactly 7 pins needed. I’d assume it would have to be the similar option as you defined for 1GbE PHY solution i.e. either VGA or DP made as design decision. I’m wondering what’s you vision for that. I can also start this thread in management module discussion if you’d like to keep it there.

 

--

Thanks,

Kasper

---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
ul. Słowackiego 173 | 80-298 Gdańsk | Sąd Rejonowy Gdańsk Północ | VII Wydział Gospodarczy Krajowego Rejestru Sądowego - KRS 101882 | NIP 957-07-52-316 | Kapitał zakładowy 200.000 PLN.
Ta wiadomość wraz z załącznikami jest przeznaczona dla określonego adresata i może zawierać informacje poufne. W razie przypadkowego otrzymania tej wiadomości, prosimy o powiadomienie nadawcy oraz trwałe jej usunięcie; jakiekolwiek przeglądanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.

---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
ul. Słowackiego 173 | 80-298 Gdańsk | Sąd Rejonowy Gdańsk Północ | VII Wydział Gospodarczy Krajowego Rejestru Sądowego - KRS 101882 | NIP 957-07-52-316 | Kapitał zakładowy 200.000 PLN.
Ta wiadomość wraz z załącznikami jest przeznaczona dla określonego adresata i może zawierać informacje poufne. W razie przypadkowego otrzymania tej wiadomości, prosimy o powiadomienie nadawcy oraz trwałe jej usunięcie; jakiekolwiek przeglądanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.


Re: Display Port support in RunBMC

Eric Shobe
 

Hi Kasper, 

I cc'ed the alias for OCP HW Mgmt. 
To support Display Port here are the changes.  

PinsRequesterHigh Level Changes
DPAUXP
DPAUXN
DPTXP0
DPTXN0
DPHPD
DPTXP1
DPTXN1
Intel1. Add filtering for TX pairs
2. Add HW straps on daughter board to support dual function for TX pairs
3. Add HW straps for AUX diff pair
4. Add HW strap HPD presence
5. Describe filtering/circuitry needed near DP connector on mobo
6. Can't share all on VGA because block already has dual function and backward compat would be lost. However we could use DACR/G/B and partial GPIO block OR all GPIO block

Looking at the possible pin-out changes: 

Pinout to share VGA block.  We would loose backward compat with 4 GPIO signals
DACG_DPAUXP10
DACB_DPAUXN12
DACR_DPHPD14
VGAHS_GPIO2DPTXPO16
VGAVS_GPIO4DPTXNO18
DDCCLK_GPIO6DPTXP120
DDCDAT_GPIO8DPTXN122


Pintout to share GPIO block. Would need to add HW multiplex via resistor straps and filtering. 

GPIO19_DPAUXP36
GPIO20_DPAUXN38
....
GPIO38_DPHPD66
GPIO39_DPTXP068
GPIO40_DPTXN070
GPIO42_DPTXP172
GPIO44_DPTXN174


Which one seems preferable from your side?

Eric

On Sat, Nov 28, 2020 at 1:44 PM Wszolek, Kasper <kasper.wszolek@...> wrote:

Hi Eric and Jared,

 

Hope you guys are doing great. I’ve enjoyed your presentation on OCP TECH WEEK – thank you for nice words about our RunBMC module and the demo 😊 I just want to let you know that we are still working internally on the process to eventually contribute our RunBMC module design to OCP. We’re bringing up the second version of the module now with some additional fixes we did based on the first version we showed on the demo.

 

I noted down your objectives to be addresses in the next version of the spec but I don’t recall that you mentioned Display Port support option in new spec version? I’m wondering if you explored it already? We are looking for a way to support that with RunBMC and it seems that from RunBMC pins perspective the VGA pins could be reused for Display Port assuming 2 Lanes, Aux Lane and presence detect there are exactly 7 pins needed. I’d assume it would have to be the similar option as you defined for 1GbE PHY solution i.e. either VGA or DP made as design decision. I’m wondering what’s you vision for that. I can also start this thread in management module discussion if you’d like to keep it there.

 

--

Thanks,

Kasper

---------------------------------------------------------------------
Intel Technology Poland sp. z o.o.
ul. Słowackiego 173 | 80-298 Gdańsk | Sąd Rejonowy Gdańsk Północ | VII Wydział Gospodarczy Krajowego Rejestru Sądowego - KRS 101882 | NIP 957-07-52-316 | Kapitał zakładowy 200.000 PLN.
Ta wiadomość wraz z załącznikami jest przeznaczona dla określonego adresata i może zawierać informacje poufne. W razie przypadkowego otrzymania tej wiadomości, prosimy o powiadomienie nadawcy oraz trwałe jej usunięcie; jakiekolwiek przeglądanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.


Re: [OCP-DC-SCM] OCP DC-SCM spec version 0.6(Internet mail)

Eric Shobe
 

Hi everyone!

This is really good timing.  A couple of procedural topics:
  • We want to review the DC-SCM specification in the HW Management Module sub-group.  I can work with Priya to upload to our twiki space for review. 
  • The HW Management Module sub-group is under the HW Management project, with Hemal and Bob Steven as leads. 
  • Our next meeting invite will be sent out to OCP-DC-SCM and OCP-HWMgt-Module email alias. Targeting mid December. After this we will plan to deprecate the OCP-DC-SCM alias and merge to OCP-HWmgt-Module alias.  Please use the latter!
Let's plan the mid-December meeting to cover spec!

Thanks,
Eric



On Wed, Nov 11, 2020 at 7:32 AM <tim.lambert@...> wrote:
URL resolved.


Re: Test for HWMGT alias

Jared Mednick
 

It worked!


On Wed, Oct 21, 2020 at 2:17 PM Eric Shobe <eric.shobe@...> wrote:
Test only. Want to make sure I have this setup correctly :)
Eric

41 - 60 of 61