RE: General SMBus questions

And what if the problem is:

“I have one or more low-bandwidth auxiliary devices that I would like to
attach to the system easily and inexpensively. I need to query these devices
occasionally. I DON’T have control of the BIOS, and am considering the
possibility of using the SMBus to control these devices”

Would the only way be to insert an extra chip on SMBus and control it
through a KMDF driver, so that the new chip generates our custom SMBus
streams?
Or just forget SMBus if we don’t have control of the BIOS?

Thanks in advance,
Aitortxo.

(I’d like to apologize for the use of capitals, but I think they were
needed)

Aitor Garmendia wrote:

And what if the problem is:

“I have one or more low-bandwidth auxiliary devices that I would like
to attach to the system easily and inexpensively. I need to query
these devices occasionally. I DON’T have control of the BIOS, and am
considering the possibility of using the SMBus to control these devices”

Would the only way be to insert an extra chip on SMBus and control it
through a KMDF driver, so that the new chip generates our custom SMBus
streams?
Or just forget SMBus if we don’t have control of the BIOS?

Your final sentence is the correct one. SMBus was designed for BIOSes.
It is being perverted into other uses, but that inevitably leads to tears.

The right answer, in my opinion, is to put your device on USB. Simple,
universal, well-understood, easy.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

>SMBus was designed for BIOSes.

It is being perverted into other uses, but that inevitably leads to tears.

Oh dear…

Please check the thread http://www.osronline.com/showThread.cfm?link=180247 - you seem to have been speaking very differently just few months ago. What happened??? Did my wish about testing a “masterpiece” like that right on your laptop as an end user (post 32 on that thread) come true - after all, you are speaking about tears here…

Do you finally admit that my “sarcasm generator” on that thread was…ugh, “not-so-unfounded”, so to say…

Anton Bassov

(ignoring Anton cuz I have NO idea what he’s talking about)

While i’m not willing to go quite as far as Tim, I *will* happily agree that without control of the BIOS (or some predetermined knowledge that the BIOS you’re using has made the SMBUS available for your use from the host side) you have to forget using SMBUS from the host.

On your average system, lots of shit goes on across the SMBUS… Probably a ton of which you haven’t considered ( do you realize the DRAM timings are set using info from SPD that’s read over SMBUS? The NIC often has a connection? POST codes display via it? These are just a couple of examples).

The SMBUS isn’t configured on most systems to support general, random, connections. It needs to be used in concert with the BIOS. Unless the BIOS approves your use, forget it.

Peter
OSR

> ignoring Anton cuz I have NO idea what he’s talking about)

Just check the thread in question then - I provided the link (IIRC, you were one of its participants)…

The SMBUS isn’t configured on most systems to support general, random, connections. It needs to be
used in concert with the BIOS. Unless the BIOS approves your use, forget it.

Actually, I would say that SMBus is just not meant to be directly user-accessible or user-configurable, in the first place. Certainly, you can try messing around with SMBus controller directly the way the original poster on the thread I referred to was trying to do, but don’t get surprised if you end up with the hardware damaged beyond the repair at some point. I was laughing at that poster’s endeavors all the way along and telling him just to give it up, but Tim was somewhat supportive of them, telling him that he needs
“some low-level advice”, etc. Check it anyway - it is a good laugh, especially the part where the poster takes
DA:FB (device A -function B) notation in chipset documentation for the physical address 0xDAFB…

Anton Bassov

xxxxx@hotmail.com wrote:

> SMBus was designed for BIOSes.
> It is being perverted into other uses, but that inevitably leads to tears.
Oh dear…

Please check the thread http://www.osronline.com/showThread.cfm?link=180247 - you seem to have been speaking very differently just few months ago. What happened???

I don’t know what you’re trying to imply here, but allow me to quote
from my post on that very thread:

SMBus is a shadowy netherworld that exists somewhere between BIOS and
operating system. It was designed to be used from the BIOS. I thought
I understood from past messages that the Windows support for SMBus was
awkward at best. I think he really does need some low-level advice here.

As near as I can tell, my position now is exactly consistent with my
position then.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

> As near as I can tell, my position now is exactly consistent with my position then.

Oh, I see…

Therefore, you still think that someone who messes around with SMBus controller directly needs some advice other than the one to give it up on the spot…

Anton Bassov

Thanks for the replies, not the news I wanted, but many more than spected.

Ok, so, leaving the sarcasm thread issues, the resulting idea would be:

SMBus in a PC has an owner and that is the BIOS.
If you have friends on the BIOS of your PC, you can sugest them to implement
SMBus messages you need.
Once the messages are implemented, the access is simple using WMI stuff.

So, ok, forgotten.

Unfortunatelly my boss “thinks” (insists) not to forget it.
Just to convince him - as these threads in OSRonline were not enough -,
please, any article, or official web page, with which he could come to our
side and start forgetting?


And now (some day, once my boss is convinced about contacting our PC
provider… to contact their BIOS provider… to modify it), after KMDF…
lets start learning WMI, ACPI, ASL, MOF, … At least this way it should be
someday-ending (as opposed to never-ending). Go for it.

Thanks for convincing,
Aitortxo.

Unfortunately, unless he can be convinced by the LACK of articles - which is
telling - I can’t think of anything.

Good luck,

mm

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Aitor Garmendia
Sent: Thursday, September 30, 2010 4:51 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] RE: General SMBus questions

Thanks for the replies, not the news I wanted, but many more than spected.

Ok, so, leaving the sarcasm thread issues, the resulting idea would be:

SMBus in a PC has an owner and that is the BIOS.
If you have friends on the BIOS of your PC, you can sugest them to implement
SMBus messages you need.
Once the messages are implemented, the access is simple using WMI stuff.

So, ok, forgotten.

Unfortunatelly my boss “thinks” (insists) not to forget it.
Just to convince him - as these threads in OSRonline were not enough -,
please, any article, or official web page, with which he could come to our
side and start forgetting?


And now (some day, once my boss is convinced about contacting our PC
provider… to contact their BIOS provider… to modify it), after KMDF…
lets start learning WMI, ACPI, ASL, MOF, … At least this way it should be
someday-ending (as opposed to never-ending). Go for it.

Thanks for convincing,
Aitortxo.
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

No need to hack BIOS. Some mobo vendors provide custom smbus and other
useful APIs for their systems.
Just select for your project a board that has such API.

(for example, Advantech 5788, we recently worked with, has, besides of
smbus,
API for GPIO, fans and temp. monitors, watchdog, and others).
–pa

“Aitor Garmendia” wrote in message
news:xxxxx@ntdev…
> Thanks for the replies, not the news I wanted, but many more than spected.
>
> Ok, so, leaving the sarcasm thread issues, the resulting idea would be:
>
> SMBus in a PC has an owner and that is the BIOS.
> If you have friends on the BIOS of your PC, you can sugest them to
> implement
> SMBus messages you need.
> Once the messages are implemented, the access is simple using WMI stuff.
>
> So, ok, forgotten.
>
> Unfortunatelly my boss “thinks” (insists) not to forget it.
> Just to convince him - as these threads in OSRonline were not enough -,
> please, any article, or official web page, with which he could come to our
> side and start forgetting?
>
> - - -
>
> And now (some day, once my boss is convinced about contacting our PC
> provider… to contact their BIOS provider… to modify it), after KMDF…
> lets start learning WMI, ACPI, ASL, MOF, … At least this way it should
> be
> someday-ending (as opposed to never-ending). Go for it.
>
> Thanks for convincing,
> Aitortxo.
>

No question about it - if this an option, this is the way to go.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: Thursday, September 30, 2010 6:27 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] RE: General SMBus questions

No need to hack BIOS. Some mobo vendors provide custom smbus and other
useful APIs for their systems.
Just select for your project a board that has such API.

(for example, Advantech 5788, we recently worked with, has, besides of
smbus,
API for GPIO, fans and temp. monitors, watchdog, and others).
–pa

“Aitor Garmendia” wrote in message
news:xxxxx@ntdev…
> Thanks for the replies, not the news I wanted, but many more than spected.
>
> Ok, so, leaving the sarcasm thread issues, the resulting idea would be:
>
> SMBus in a PC has an owner and that is the BIOS.
> If you have friends on the BIOS of your PC, you can sugest them to
> implement
> SMBus messages you need.
> Once the messages are implemented, the access is simple using WMI stuff.
>
> So, ok, forgotten.
>
> Unfortunatelly my boss “thinks” (insists) not to forget it.
> Just to convince him - as these threads in OSRonline were not enough -,
> please, any article, or official web page, with which he could come to our
> side and start forgetting?
>
> - - -
>
> And now (some day, once my boss is convinced about contacting our PC
> provider… to contact their BIOS provider… to modify it), after KMDF…
> lets start learning WMI, ACPI, ASL, MOF, … At least this way it should
> be
> someday-ending (as opposed to never-ending). Go for it.
>
> Thanks for convincing,
> Aitortxo.
>


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer