Author Topic: Developing hardware for x86  (Read 3944 times)

0 Members and 1 Guest are viewing this topic.

Offline ondoTopic starter

  • Contributor
  • Posts: 10
Developing hardware for x86
« on: February 11, 2019, 04:11:48 pm »

Hi I am working on a x86 architecture project, but I'm a little over my head and can't figure out some stuff. If someone has good resources for the hardware design of this architectures I would be eternally grateful.

In any case, there's a lot of smart knowledgeable people around, so I might as well ask some questions:

My SoC (AMD v1000 embedded) has I2C/SMBUS ports. I'm trying to know the actual difference between the two because we need to set up a BMS (Battery Management System, aka fuel gauge) and a USBC compliant charger. AFAIK:

* Both have similar physical layers, and are pretty much compatible except in particular situations
* SMBus has upper layer definitions that I2C doesn't

And the things I'm not sure they are true:
* SMBus compatible devices can be discovered through ACPI.
* I2C interfaces need to be declared on the BIOS to be accesible by the OS
* Both can be accessed by writing a device driver

am I on the right track? is there anything I am missing?

Thank you very much wise elders of the eevblog forum!  ;D
 

Offline tsman

  • Frequent Contributor
  • **
  • Posts: 599
  • Country: gb
Re: Developing hardware for x86
« Reply #1 on: February 11, 2019, 04:34:15 pm »
Just a warning. There can be compatibility issues when using some I2C devices on a SMBus controller as SMBus is a superset of I2C with additional features and restrictions. This is from experience with old motherboards which put I2C devices on the SMBus controller in the south bridge and accessing those devices in certain ways would wedge the controller so badly you'd need to restart to fix it. I don't know forgiving the SMBus controller is in your AMD part.
 

Online ejeffrey

  • Super Contributor
  • ***
  • Posts: 3932
  • Country: us
Re: Developing hardware for x86
« Reply #2 on: February 11, 2019, 05:51:48 pm »
The most important difference between I2C and SMBus is how resets work.

I2C has no explicit reset mechanism. If the bus is in an unknown state (say the master got reset in the middle of a transfer) it is possible that one of the slaves will be asserting the data line low.  This locks up the bus.  The master has to supply clock edges until the slave releases the line and only then it can issue a start.

SMBus requires slaves to implement a timeout.  If the clock line is held low for 35 ms, it needs to reset its interface to idle.

The result is that if you connect a SMBus peripheral to an I2C master, you need to use a minimum clock speed, specified as 10 kHz. 

If you connect an I2C slave to an SMBus master you can have bus lockup because the SMBus master will not be able to do a bus reset.

Most microcontroller I2C peripherals can support either effectively, either directly or by using the GPIO capability to implement the appropriate reset behavior.  One more integrated devices like a CPU with an SMBus sensor bridge, they may not be able to correctly reset I2C periperals.  Unless you have an out-of-band way to do this (such as the ability to trigger a power-on reset to the I2C slaves) you could run into problems.

SMBus also has an interrupt capability that is not part of the I2C spec but that does not pose a compatibility problem. I2C devices simply won't be able to generate interrupts.
 
The following users thanked this post: tsman


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf