qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug in Bonito? (mips/fuloong2e)


From: BALATON Zoltan
Subject: Re: Bug in Bonito? (mips/fuloong2e)
Date: Tue, 29 Dec 2020 12:17:15 +0100 (CET)

On Tue, 29 Dec 2020, Philippe Mathieu-Daudé wrote:
On 12/29/20 6:26 AM, Jiaxun Yang wrote:
在 2020/12/29 上午11:26, BALATON Zoltan 写道:
Hello,

While continuing with part two of my vt82c686b clean ups I've tried to
implement SMBus IO base configuration in the vt82c686b-pm part that
I've already done for vt8231 for pegasos2 and it should be the same
for 686B. (In short, writing address to pm config 0x90 sets base
address of smbus regs and bit 0 of 0xd2 enables/disables it.) This is
what the firmware does first and it would allow removing hard coded
0xeee1 value and the property to set it and then I could reuse the
same PM part in VT8231.

[...]

Any idea what this is trying to do and how to fix it?

It's trying to translate Bonito style PCI config space r/w to standard PCI
config space R/W.

A quick galance told me change BONITO_PCICONF_REG_MASK to 0xff
may help.

With Jiaxun's change it works better:

bonito_spciconf_write: bonito_spciconf_write 0000000000000490 size 4 val eee1
bonito_sbridge_pciaddr: cfgaddr 10490 pciaddr 2c90 busno 0 devno 5 funno 4 
regno 144
pci_cfg_write vt82c686b-pm 05:4 @0x90 <- 0xeee1
via_pm_write addr 0x90 val 0xeee1 len 0x4

bonito_writel: bonito_writel 0000000000000018 val 1 saddr 6
bonito_readl: bonito_readl 0000000000000018

bonito_spciconf_write: bonito_spciconf_write 00000000000004d2 size 2 val 1
bonito_sbridge_pciaddr: cfgaddr 104d2 pciaddr 2cd2 busno 0 devno 5 funno 4 
regno 210
pci_cfg_write vt82c686b-pm 05:4 @0xd2 <- 0x1
via_pm_write addr 0xd2 val 0x1 len 0x2
*** Should update smbus io base to eee1, enable

(last line is my debug message). Not sure if this breaks anyhing else but PMON still seems to work (tested with pmon_2e.bin).

Per the datasheet section "5.7.5. Accessing PCI configuration space"
0xfc is the correct value, but the register number starts at the 2nd
bit. So this is not a write access to register 0xd2 but 0x34?

If you can test, this is the snippet I plan to send later:

-- >8 --
diff --git a/hw/pci-host/bonito.c b/hw/pci-host/bonito.c
index a99eced0657..65953766dd0 100644
--- a/hw/pci-host/bonito.c
+++ b/hw/pci-host/bonito.c
@@ -189,3 +189,3 @@ FIELD(BONGENCFG, PCIQUEUE,      12, 1)
#define BONITO_PCICONF_REG_MASK        0xFC
-#define BONITO_PCICONF_REG_OFFSET      0
+#define BONITO_PCICONF_REG_OFFSET      2
---

This does not seem to work, I get all mixed up regs:

bonito_spciconf_write: bonito_spciconf_write 0000000000000490 size 4 val eee1
bonito_sbridge_pciaddr: cfgaddr 10490 pciaddr 2c24 busno 0 devno 5 funno 4 
regno 36
pci_cfg_write vt82c686b-pm 05:4 @0x24 <- 0xeee1
via_pm_write addr 0x24 val 0xeee1 len 0x4

bonito_writel: bonito_writel 0000000000000018 val 1 saddr 6
bonito_readl: bonito_readl 0000000000000018

bonito_spciconf_write: bonito_spciconf_write 00000000000004d2 size 2 val 1
bonito_sbridge_pciaddr: cfgaddr 104d2 pciaddr 2c34 busno 0 devno 5 funno 4 
regno 52
pci_cfg_write vt82c686b-pm 05:4 @0x34 <- 0x1
via_pm_write addr 0x34 val 0x1 len 0x2

So I'll use the first one for now, that allows me to continue with vt82c686b.

Regards,
BALATON Zoltan

reply via email to

[Prev in Thread] Current Thread [Next in Thread]