On 05/07/14 00:23, Piotr Król wrote:
> Hello,
> according to QEMU mailing list [1] and source code [2] QEMU contain i2c.
> I tried to setup i2c tmp105 sensor using [3] guide and read it under
> OVMF. Qemu monitor command 'info qtree' show:
> bus: pci.0
> type PCI
> dev: PIIX4_PM, id ""
> smb_io_base = 45312 (0xb100)
> disable_s3 = 0 (0)
> disable_s4 = 0 (0)
> s4_val = 2 (0x2)
> acpi-pci-hotplug-with-bridge-support = true
> addr = 01.3
> romfile = ""
> rombar = 1 (0x1)
> multifunction = false
> command_serr_enable = true
> class Bridge, addr 00:01.3, pci id 8086:7113 (sub 1af4:1100)
> bus: i2c
> type i2c-bus
> dev: tmp105, id "sensor"
> gpio-out 1
> address = 80 (0x50)
> dev: smbus-eeprom, id ""
> address = 87 (0x57)
>
> So if I understand correctly i2c-bus should be on BDF: 0/1/3, pci command from
> UEFI Shell show that this device have all zeros in BAR. Am I missing
> something ?
i2c-bus seems to be a custom bus that is provided by the PIIX4_PM PCI
device (...function). The latter lives at BDF 00:01.3.
I'm not familiar with i2c-bus, but from the qemu code, it looks like you
should check the output of "info mtree". The pc_init1() function calls
piix4_pm_init() with smb_io_base=0xb100. Again from a superficial
reading of the code, this should later lead to a 64 bytes wide IO
register block (at 0xb100):
piix4_pm_initfn()
pm_smbus_init()
pm_smbus_init()
memory_region_init_io()
memory_region_set_enabled()
memory_region_add_subregion()
I/O
0000000000000000-000000000000ffff (prio 0, RW): io
000000000000b100-000000000000b13f (prio 0, RW): pm-smbus
The registers (SMB*) inside this block seem to be listed in
"hw/i2c/pm_smbus.c". The address of the device on the i2c-bus must be
used inside the smbus command for identification, apparently. For example:
smb_ioport_writeb()
SMBHSTADD: set s->smb_addr to (0x50 << 1 | 1)
smb_ioport_writeb()
SMBHSTCNT: smb_transaction(addr = 0x50, read = 0x01)
smbus_quick_command()
i2c_start_transfer()
tmp105_event(I2C_START_RECV)
tmp105_read()
etc
Maybe the IO port range should show up in a BAR of 00:01.3. Could be a
qemu bug.
> Is there any driver required to access this device ? If not can you point me
> to
> knowledge that help me with implementing this kind of support ?
Not sure what you want to do with the device. If you just want to access
it (eg. from an UEFI application), the functions in
"MdePkg/Include/Library/IoLib.h" should suffice.
Alternatively, you could try to locate the BDF 00:01.3 PCI device with
some protocol handler boot service(s) (eg. LocateDevicePath()), and use
EFI_PCI_IO_PROTOCOL.Io.Read()/Write() on the found PciIo interface, with
EFI_PCI_IO_PASS_THROUGH_BAR.
Laszlo
>
> Regards,
> Piotr Król
>
> [1] https://lists.gnu.org/archive/html/qemu-devel/2007-05/msg00192.html
> [2] https://github.com/qemu/qemu/tree/master/hw/i2c
> [3] https://lists.gnu.org/archive/html/qemu-devel/2014-02/msg02681.html
>
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
> • 3 signs your SCM is hindering your productivity
> • Requirements for releasing software faster
> • Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> _______________________________________________
> edk2-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
