ASRock E350M1: Linux reports `piix4_smbus 0000:00:14.0: SMBus base address index region 0xcd6 already in use!`

List overview All Threads
Download

newer

older

List of ideas for coreboot meeting...

Coreboot hackathon hardware

Paul Menzel

28 Mar 2013 28 Mar '13

2:50 p.m.

Dear coreboot folks,

since [1]

commit df729d7778a7e5878fac5545883f68e42372456a Author: Jens Rottmann JRottmann@LiPPERTembedded.de Date: Tue Feb 19 14:46:31 2013 +0100

AMD Fam14 boards: dimmSpd.c: Set `iobase` to `SMBUS0_BASE_ADDRESS` instead of `0xB00`

which I expanded to the ASRock E350M1, overlooking the new error message, Linux complains about an already used base address index region.

calling i2c_piix4_init+0x0/0x1000 [i2c_piix4] @ 559 piix4_smbus 0000:00:14.0: SMBus base address index region 0xcd6 already in use! piix4_smbus: probe of 0000:00:14.0 failed with error -16

The address 0xb00 was used before and this should not have been changed with the patch above. But it did. I looked through the code but could not find where 0xcd6 comes from. Any pointers would be very much appreciated.

Thanks,

Paul

[1] http://review.coreboot.org/2453

Attachments:

signature.asc (application/pgp-signature — 198 bytes)

Show replies by date

Rudolf Marek

30 Mar 30 Mar

11:38 a.m.

...

     calling  i2c_piix4_init+0x0/0x1000 [i2c_piix4] @ 559
     piix4_smbus 0000:00:14.0: SMBus base address index region 0xcd6 already in use!
     piix4_smbus: probe of 0000:00:14.0 failed with error -16

The I2C driver is paranoid and uses the cd6/cd7 pmio register just to obtain the base addr of the i2c controller. Most likely the cd6/cd7 is claimed in ACPI space.

http://lxr.free-electrons.com/ident?v=2.6.39;i=piix4_setup_sb800

Thanks Rudolf

...

The address 0xb00 was used before and this should not have been changed with the patch above. But it did. I looked through the code but could not find where 0xcd6 comes from. Any pointers would be very much appreciated.

Thanks,

Paul

[1] http://review.coreboot.org/2453

Paul Menzel

22 May 22 May

9:04 a.m.

Am Samstag, den 30.03.2013, 11:38 +0100 schrieb Rudolf Marek:

...

     calling  i2c_piix4_init+0x0/0x1000 [i2c_piix4] @ 559
     piix4_smbus 0000:00:14.0: SMBus base address index region 0xcd6 already in use!
     piix4_smbus: probe of 0000:00:14.0 failed with error -16

Starting Linux just with `quiet` on the command line (in GRUB 2), then the message is different.

ACPI: resource piix4_smbus [io 0x0b00-0x0b07] conflicts with ACPI region SMB0 [io 0xb00-0xb0b]

...

The I2C driver is paranoid and uses the cd6/cd7 pmio register just to obtain the base addr of the i2c controller. Most likely the cd6/cd7 is claimed in ACPI space.

http://lxr.free-electrons.com/ident?v=2.6.39;i=piix4_setup_sb800

Rudolf gave me some more hints for debugging, I paste here.

...

Am Donnerstag, den 16.05.2013, 08:45 +0200 schrieb Rudolf Marek:

...

It is not a regression, merely the driver is paranoid and if the cd7/cd6 resources are declared in DSDT tables, it thinks it is used by acpi bytecode and gives up. So if you look when IO ports cd6/cd7 were introduced to ACPI. It could be also in SB code declared as IO_RESERVED and autogenerated.

You can check

acpidump >a.txt acpxtract -a

iasl -d *dat

to decompile all acpi tables and then search for cd7 ;)

$ sudo acpidump > acpi.txt $ sudo acpixtract -a acpi.txt Acpi table [DSDT] - 10971 bytes written to DSDT.dat Acpi table [FACS] - 64 bytes written to FACS.dat Acpi table [FACP] - 244 bytes written to FACP.dat Acpi table [HPET] - 56 bytes written to HPET.dat Acpi table [APIC] - 92 bytes written to APIC.dat Acpi table [HEST] - 40 bytes written to HEST.dat Acpi table [SSDT] - 5774 bytes written to SSDT1.dat Acpi table [SSDT] - 990 bytes written to SSDT2.dat Acpi table [SSDT] - 69 bytes written to SSDT3.dat Acpi table [RSDT] - 64 bytes written to RSDT.dat Acpi table [RSDP] - 20 bytes written to RSDP.dat $ iasl -d *dat

Loading Acpi table from file APIC.dat Acpi Data Table [APIC] decoded Formatted output: APIC.dsl - 3330 bytes Loading Acpi table from file DSDT.dat Acpi table [DSDT] successfully installed and loaded Pass 1 parse of [DSDT] Pass 2 parse of [DSDT] Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed Disassembly completed ASL Output: DSDT.dsl - 107876 bytes Loading Acpi table from file FACP.dat Acpi Data Table [FACP] decoded Formatted output: FACP.dsl - 8970 bytes Loading Acpi table from file FACS.dat Acpi Data Table [FACS] decoded Formatted output: FACS.dsl - 1343 bytes Loading Acpi table from file HEST.dat Acpi Data Table [HEST] decoded Formatted output: HEST.dsl - 1136 bytes Loading Acpi table from file HPET.dat Acpi Data Table [HPET] decoded Formatted output: HPET.dsl - 1840 bytes Loading Acpi table from file RSDP.dat Acpi Data Table [RSD ] decoded Formatted output: RSDP.dsl - 748 bytes Loading Acpi table from file RSDT.dat Acpi Data Table [RSDT] decoded Formatted output: RSDT.dsl - 1556 bytes Loading Acpi table from file SSDT1.dat Acpi table [SSDT] successfully installed and loaded Pass 1 parse of [SSDT] Pass 2 parse of [SSDT] Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed ACPI Error: Argument count mismatch for method _SB_.ALIC 6 2 (20130214/dmextern-448)

Found 1 external control methods, reparsing with new information Pass 1 parse of [SSDT] Pass 2 parse of [SSDT] Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed Disassembly completed ASL Output: SSDT1.dsl - 39554 bytes

iASL Warning: There were 1 external control methods found during disassembly, but additional ACPI tables to resolve these externals were not specified. The resulting disassembler output file may not compile because the disassembler did not know how many arguments to assign to these methods. To specify the tables needed to resolve external control method references, use the one of the following example iASL invocations: iasl -e <ssdt1.aml,ssdt2.aml...> -d <dsdt.aml> iasl -e <dsdt.aml,ssdt2.aml...> -d <ssdt1.aml> Loading Acpi table from file SSDT2.dat Acpi table [SSDT] successfully installed and loaded Pass 1 parse of [SSDT] Pass 2 parse of [SSDT] Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed Disassembly completed ASL Output: SSDT2.dsl - 9915 bytes Loading Acpi table from file SSDT3.dat Acpi table [SSDT] successfully installed and loaded Pass 1 parse of [SSDT] Pass 2 parse of [SSDT] Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed Disassembly completed ASL Output: SSDT3.dsl - 755 bytes $ grep -i cd7 *dsl $ grep -i cd6 *dsl DSDT.dsl: OperationRegion (PIOR, SystemIO, 0x0CD6, 0x02) SSDT1.dsl: OperationRegion (PMIO, SystemIO, 0x0CD6, 0x02) $ grep -i b00 *dsl DSDT.dsl: Name (_HID, EisaId ("PNP0B00")) // _HID: Hardware ID DSDT.dsl: OperationRegion (SMB0, SystemIO, 0x0B00, 0x0C)

Unfortunately, I did not have time yet to look into this further.

Thanks,

Paul

Rudolf Marek

23 May 23 May

11:16 p.m.

...

     ASL Output:    SSDT3.dsl - 755 bytes
     $ grep -i cd7 *dsl
     $ grep -i cd6 *dsl
     DSDT.dsl:                OperationRegion (PIOR, SystemIO, 0x0CD6, 0x02)
     SSDT1.dsl:            OperationRegion (PMIO, SystemIO, 0x0CD6, 0x02)
     $ grep -i b00 *dsl
     DSDT.dsl:                    Name (_HID, EisaId ("PNP0B00"))  // _HID: Hardware ID
     DSDT.dsl:    OperationRegion (SMB0, SystemIO, 0x0B00, 0x0C)

so it is generated in SSDT1 and also not generated in DSDT. you will need to see PIOR and PMIO if they are marked reserved somehow.

Thanks Rudolf

3991

days inactive

4047

days old

coreboot@coreboot.org

3 comments

2 participants

tags (0)

participants (2)

Paul Menzel
Rudolf Marek