Could you please he= lp to create a new repository for phosphor-bittware?

On Thu, May 07, 2020 at 06:=
07:44AM +0000, Be=
n_Pai at wistron.com wrote:
> Could you please he=
lp to create a new repository for phosphor-bittware?<=
/pre>

Out of curiousity for other=
s who aren't aware of what 'bittware' is,
could you describe a little=
 about this repository?  It seems to be a
hardware vendor, so it woul=
d be interesting to know what the BMC will be
doing with it.

Examples:=

  * What is the overal=
l purpose of the code in this repository?
  * Is there an existi=
ng architecture that this code will be following
    or is th=
ere some new design that you are persuing (and needs to be
    document=
)?
  * Are there existing=
 phosphor-dbus-interfaces that you will be
    implemen=
ting?  Are there new dbus interfaces you are proposing to
    implemen=
t the functionality you want from this repository?

-- 

I want to implement related fun=
ctions for the bittware 250-SoC card.
For example: Sensor reading, VP=
D information, led control and Brick Protection mechanism.

We don’t need to modify p=
hosphor-dbus-interfaces.

Best Regards,=

Ben

Hi Patrick

> I looked briefly at=
 the datasheet for this hardware [1].  It appears to=

> expose an SMBus int=
erface for the features you mentioned.  The most=

> straight-forward wa=
y to get this implemented is to create a kernel
> driver for most of =
the features you mentioned.  If you implement a<=
/pre>
> driver for this har=
dware that interacts with the hwmon, eeprom, and LED/GPIO=

> subsystems in the k=
ernel(*), you'll be able to reuse a lot of existing
> OpenBMC functionali=
ty without rewriting any userspace code.
> 
> - Sensor=

>   &n=
bsp; - Kernel: hwmon
>   &n=
bsp; - Userspace: phosphor-hwmon or dbus-sensors
> - VPD
>   &n=
bsp; - Kernel: eeprom
>   &n=
bsp; - Userspace: entity-manager (I think)
> - LED control<=
/o:p>
>   &n=
bsp; - Kernel: LED / GPIO
>   &n=
bsp; - Userspace: phosphor-led-manager
> 
> The only part that =
wouldn't be covered would be the "Brick Protection".
> We'd need to see so=
me more information on how this is exposed but you
> might be able to wo=
rk it into the existing phosphor-bmc-code-mgmt
> repository.  F=
or power supplies, they did create a separate repository<=
/i>

> (phosphor-psu-code-=
mgmt) but I think they relied on some kernel APIs for=

> doing part of the w=
ork.
> 
> (*) Depending on ho=
w the bittware hardware is implemented at an SMBus
>   &n=
bsp; level you may end up with multiple smaller drivers (this is better).
>   &n=
bsp; If there is a single SMBus address for all these functions, you'll
>   &n=
bsp; likely end up with one big driver.
> 
> 1. https://www.bittware.com/wp-content/uploads/datas=
heets/ds-250-soc.pdf

Sorry for late reply.

Because the 250-soc card needs to adjust the io expander to=
 get the relevant information (e.g. temperature, VPD ...).
I think a dynamic detection function may be needed to handl=
e the presence of the card and dynamically adjust the io expander.
On the other hand, I just want to be able to integrate all =
the functions.

Best Regards,=

Ben