Macintosh-Tools/dingusppc
1
0
Fork 0
mirror of https://github.com/dingusdev/dingusppc.git synced 2024-06-05 10:29:31 +00:00
Code Issues Projects Releases Wiki Activity
467e4df7dc
dingusppc/devices/common/pci/bandit.cpp

430 lines
16 KiB
C++
Raw Normal View History

Initial emulation of the Bandit ARBus-to-PCI bridge.
2022-01-16 21:47:04 +00:00
/*
DingusPPC - The Experimental PowerPC Macintosh emulator
Copyright (C) 2018-22 divingkatae and maximum
(theweirdo) spatium
(Contact divingkatae#1017 or powermax#2286 on Discord for more info)
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <https://www.gnu.org/licenses/>.
*/
/** Bandit ARBus-to-PCI Bridge emulation. */
bandit: self-registration with the device registry.
2022-07-17 03:39:39 +00:00
#include <devices/common/pci/bandit.h>
#include <devices/deviceregistry.h>
Initial emulation of the Bandit ARBus-to-PCI bridge.
2022-01-16 21:47:04 +00:00
#include <devices/memctrl/memctrlbase.h>
#include <endianswap.h>
#include <loguru.hpp>
#include <machines/machinebase.h>
#include <memaccess.h>
#include <cinttypes>
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
const int MultiplyDeBruijnBitPosition2[] =
{
0, 1, 28, 2, 29, 14, 24, 3, 30, 22, 20, 15, 25, 17, 4, 8,
31, 27, 13, 23, 21, 19, 16, 7, 26, 12, 18, 6, 11, 5, 10, 9
};
/** finds the position of the bit that is set */
#define WHAT_BIT_SET(val) (MultiplyDeBruijnBitPosition2[(uint32_t)(val * 0x077CB531U) >> 27])
Bandit: use common PCI configuration code.
2022-03-13 19:55:29 +00:00
Bandit::Bandit(int bridge_num, std::string name) : PCIHost(), PCIDevice(name)
Initial emulation of the Bandit ARBus-to-PCI bridge.
2022-01-16 21:47:04 +00:00
{
bandit: self-registration with the device registry.
2022-07-17 03:39:39 +00:00
supports_types(HWCompType::PCI_HOST | HWCompType::PCI_DEV);
Initial emulation of the Bandit ARBus-to-PCI bridge.
2022-01-16 21:47:04 +00:00
this->base_addr = 0xF0000000 + ((bridge_num & 3) << 25);
MemCtrlBase *mem_ctrl = dynamic_cast<MemCtrlBase *>
(gMachineObj->get_comp_by_type(HWCompType::MEM_CTRL));
// add memory mapped I/O region for Bandit control registers
Bandit: use common PCI configuration code.
2022-03-13 19:55:29 +00:00
// This region has the following layout:
Initial emulation of the Bandit ARBus-to-PCI bridge.
2022-01-16 21:47:04 +00:00
// base_addr + 0x000000 --> I/O space
// base_addr + 0x800000 --> CONFIG_ADDR
// base_addr + 0xC00000 --> CONFIG_DATA
Initial emulation of the Platinum Memory controller.
2022-01-17 12:57:01 +00:00
// base_addr + 0x1000000 --> pass-through memory space (not included below)
Initial emulation of the Bandit ARBus-to-PCI bridge.
2022-01-16 21:47:04 +00:00
mem_ctrl->add_mmio_region(base_addr, 0x01000000, this);
// prepare the PCI config header
Bandit: use common PCI configuration code.
2022-03-13 19:55:29 +00:00
this->vendor_id = PCI_VENDOR_APPLE;
this->device_id = 0x0001;
this->class_rev = 0x06000003;
this->cache_ln_sz = 8;
this->command = 0x16;
// make several PCI config space registers read-only
this->pci_wr_cmd = [](uint16_t cmd) {}; // command register
this->pci_wr_cache_lnsz = [](uint8_t val) {}; // cache line size register
bandit: initialize address mask register.
2022-07-25 10:51:55 +00:00
// set the bits in the fine address space field of the address mask register
// that correspond to the 32MB assigned PCI address space of this Bandit.
// This initialization is implied by the device functionality.
this->addr_mask = 3 << ((bridge_num & 3) * 2);
Set Bandit's HWComponent name Bandit has two names: - PCIDevice->pci_name - PCIDevice:MMIODevice:HWComponent->name The latter was not being set.
2022-08-22 07:35:35 +00:00
this->name = name;
Initial emulation of the Bandit ARBus-to-PCI bridge.
2022-01-16 21:47:04 +00:00
}
Bandit: implement address mask register.
2022-04-13 20:38:51 +00:00
uint32_t Bandit::pci_cfg_read(uint32_t reg_offs, uint32_t size)
{
if (reg_offs < 64) {
return PCIDevice::pci_cfg_read(reg_offs, size);
}
Fix PCI config r/w of byte and word and unaligned dingusppc could not read bytes from offset 1,2,3 or words from offset 2. dingusppc did not read words from offset 1,3 and longs from offset 1,2,3 in the same way as a real Power Mac 8600 or B&W G3. This commit fixes those issues. - Added pci_cfg_rev_read. It takes a 32 bit value from offset 0 and returns a value of the specified size using bytes starting from the specified offset. Offsets 4,5, & 6 wrap around to 0,1, & 2 respectively. The result bytes are in flipped order as required by the pci_cfg_read method (so a value of 0x12345678 is returned as 0x78563412) A real Power Mac 8600 might return a random byte for offset 4, 5, 6 for vci0 but usually not for pci1. A B&W G3 seems to always wrap around correctly. We won't read random bytes, and we won't read a default such as 00 or FF. We'll do the wrap around which makes the most sense because writing 0x12345678 to any offset and reading from the same offset should produce the value that was written. - Added pci_cfg_rev_write. It takes a 32 bit value from offset 0, and modifies a specified number of bytes starting at a specified offset with the offset wrapping around to 0 if it exceeds 3. The modified bytes take their new values from the flipped bytes passed to pci_cfg_write. When size is 4, the original value is not used since all bytes will be modified. Basically, those two functions handle all the sizes and all the offsets and replace calls to BYTESWAP_32, read_mem or read_mem_rev, and write_mem or write_mem_rev. read_mem_rev, as it was used by pcidevice and some other places, could read beyond offset 3 if it were ever passed a reg_offs value that did not have offset as 0. Since the offset was always zero, it would always read the wrong byte or word if they were not at offset 0. Same for read_mem as used by mpc106. write_mem_rev, as it was used by pcidevice and some other places, could write beyond offset 3 if it were ever passed a reg_offs value that did not have offset as 0. Since the offset was always zero, it would always write the wrong byte or word if they were not at offset 0. Same for write_mem as used by mpc106. The PCI controllers (bandit, chaos, mpc106) need to encode the offset (0,1,2,3) into the reg_offs parameter passed to pci_cfg_read and pci_cfg_write so they can return or modify the correct bytes of the dword at reg_offs & 3. The pci_cfg_read and pci_cfg_write methods extract the offset from reg_offs and report unaligned accesses. pci_cfg_read uses pci_cfg_rev_read to read from the reg using the size and offset to determine which bytes to read. pci_cfg_write uses pci_cfg_rev_write to write to the reg using the size and offset to determine which bytes to modify. Other changes: - for unimplemented config register reads and writes, bandit and ATIRage now includes offset and size (and value in the case of writes) in log warnings. - for unimplemented config register reads and writes, pcidevice now includes offset in log warnings. - pci_read and pci_write of mpc106 require an offset parameter since config_addr does not contain the offset (it is always a multiple of 4). The offset is included in the log warninings for non-existent PCI devices. - ATIRage uses pci_cfg_rev_read and pci_cfg_rev_write which correctly places user_cfg at byte 0x40 instead of 0x43 and writes the correct byte depending on size and offset. Notes: - pci_cfg_read calls READ_DWORD_LE_A and pci_cfg_write calls WRITE_DWORD_LE_A. When reading or writing memory that is organized as little endian dwords, such as my_pci_cfg_hdr of mpc106, the function should explicitly state that it's little endian so that the emulator may be ported one day to a CPU architecture that is not little endian.
2022-09-02 10:32:28 +00:00
uint32_t offset = reg_offs & 3;
reg_offs &= ~3;
if (~-size & offset) {
LOG_F(
WARNING, "%s: unaligned read @%02x.%c",
this->name.c_str(), reg_offs + offset,
size == 4 ? 'l' : size == 2 ? 'w' : size == 1 ? 'b' : '0' + size
);
}
Bandit: implement address mask register.
2022-04-13 20:38:51 +00:00
Fix PCI config r/w of byte and word and unaligned dingusppc could not read bytes from offset 1,2,3 or words from offset 2. dingusppc did not read words from offset 1,3 and longs from offset 1,2,3 in the same way as a real Power Mac 8600 or B&W G3. This commit fixes those issues. - Added pci_cfg_rev_read. It takes a 32 bit value from offset 0 and returns a value of the specified size using bytes starting from the specified offset. Offsets 4,5, & 6 wrap around to 0,1, & 2 respectively. The result bytes are in flipped order as required by the pci_cfg_read method (so a value of 0x12345678 is returned as 0x78563412) A real Power Mac 8600 might return a random byte for offset 4, 5, 6 for vci0 but usually not for pci1. A B&W G3 seems to always wrap around correctly. We won't read random bytes, and we won't read a default such as 00 or FF. We'll do the wrap around which makes the most sense because writing 0x12345678 to any offset and reading from the same offset should produce the value that was written. - Added pci_cfg_rev_write. It takes a 32 bit value from offset 0, and modifies a specified number of bytes starting at a specified offset with the offset wrapping around to 0 if it exceeds 3. The modified bytes take their new values from the flipped bytes passed to pci_cfg_write. When size is 4, the original value is not used since all bytes will be modified. Basically, those two functions handle all the sizes and all the offsets and replace calls to BYTESWAP_32, read_mem or read_mem_rev, and write_mem or write_mem_rev. read_mem_rev, as it was used by pcidevice and some other places, could read beyond offset 3 if it were ever passed a reg_offs value that did not have offset as 0. Since the offset was always zero, it would always read the wrong byte or word if they were not at offset 0. Same for read_mem as used by mpc106. write_mem_rev, as it was used by pcidevice and some other places, could write beyond offset 3 if it were ever passed a reg_offs value that did not have offset as 0. Since the offset was always zero, it would always write the wrong byte or word if they were not at offset 0. Same for write_mem as used by mpc106. The PCI controllers (bandit, chaos, mpc106) need to encode the offset (0,1,2,3) into the reg_offs parameter passed to pci_cfg_read and pci_cfg_write so they can return or modify the correct bytes of the dword at reg_offs & 3. The pci_cfg_read and pci_cfg_write methods extract the offset from reg_offs and report unaligned accesses. pci_cfg_read uses pci_cfg_rev_read to read from the reg using the size and offset to determine which bytes to read. pci_cfg_write uses pci_cfg_rev_write to write to the reg using the size and offset to determine which bytes to modify. Other changes: - for unimplemented config register reads and writes, bandit and ATIRage now includes offset and size (and value in the case of writes) in log warnings. - for unimplemented config register reads and writes, pcidevice now includes offset in log warnings. - pci_read and pci_write of mpc106 require an offset parameter since config_addr does not contain the offset (it is always a multiple of 4). The offset is included in the log warninings for non-existent PCI devices. - ATIRage uses pci_cfg_rev_read and pci_cfg_rev_write which correctly places user_cfg at byte 0x40 instead of 0x43 and writes the correct byte depending on size and offset. Notes: - pci_cfg_read calls READ_DWORD_LE_A and pci_cfg_write calls WRITE_DWORD_LE_A. When reading or writing memory that is organized as little endian dwords, such as my_pci_cfg_hdr of mpc106, the function should explicitly state that it's little endian so that the emulator may be ported one day to a CPU architecture that is not little endian.
2022-09-02 10:32:28 +00:00
if (reg_offs == BANDIT_ADDR_MASK) {
return pci_cfg_rev_read(this->addr_mask, offset, size);
Bandit: implement address mask register.
2022-04-13 20:38:51 +00:00
}
Fix PCI config r/w of byte and word and unaligned dingusppc could not read bytes from offset 1,2,3 or words from offset 2. dingusppc did not read words from offset 1,3 and longs from offset 1,2,3 in the same way as a real Power Mac 8600 or B&W G3. This commit fixes those issues. - Added pci_cfg_rev_read. It takes a 32 bit value from offset 0 and returns a value of the specified size using bytes starting from the specified offset. Offsets 4,5, & 6 wrap around to 0,1, & 2 respectively. The result bytes are in flipped order as required by the pci_cfg_read method (so a value of 0x12345678 is returned as 0x78563412) A real Power Mac 8600 might return a random byte for offset 4, 5, 6 for vci0 but usually not for pci1. A B&W G3 seems to always wrap around correctly. We won't read random bytes, and we won't read a default such as 00 or FF. We'll do the wrap around which makes the most sense because writing 0x12345678 to any offset and reading from the same offset should produce the value that was written. - Added pci_cfg_rev_write. It takes a 32 bit value from offset 0, and modifies a specified number of bytes starting at a specified offset with the offset wrapping around to 0 if it exceeds 3. The modified bytes take their new values from the flipped bytes passed to pci_cfg_write. When size is 4, the original value is not used since all bytes will be modified. Basically, those two functions handle all the sizes and all the offsets and replace calls to BYTESWAP_32, read_mem or read_mem_rev, and write_mem or write_mem_rev. read_mem_rev, as it was used by pcidevice and some other places, could read beyond offset 3 if it were ever passed a reg_offs value that did not have offset as 0. Since the offset was always zero, it would always read the wrong byte or word if they were not at offset 0. Same for read_mem as used by mpc106. write_mem_rev, as it was used by pcidevice and some other places, could write beyond offset 3 if it were ever passed a reg_offs value that did not have offset as 0. Since the offset was always zero, it would always write the wrong byte or word if they were not at offset 0. Same for write_mem as used by mpc106. The PCI controllers (bandit, chaos, mpc106) need to encode the offset (0,1,2,3) into the reg_offs parameter passed to pci_cfg_read and pci_cfg_write so they can return or modify the correct bytes of the dword at reg_offs & 3. The pci_cfg_read and pci_cfg_write methods extract the offset from reg_offs and report unaligned accesses. pci_cfg_read uses pci_cfg_rev_read to read from the reg using the size and offset to determine which bytes to read. pci_cfg_write uses pci_cfg_rev_write to write to the reg using the size and offset to determine which bytes to modify. Other changes: - for unimplemented config register reads and writes, bandit and ATIRage now includes offset and size (and value in the case of writes) in log warnings. - for unimplemented config register reads and writes, pcidevice now includes offset in log warnings. - pci_read and pci_write of mpc106 require an offset parameter since config_addr does not contain the offset (it is always a multiple of 4). The offset is included in the log warninings for non-existent PCI devices. - ATIRage uses pci_cfg_rev_read and pci_cfg_rev_write which correctly places user_cfg at byte 0x40 instead of 0x43 and writes the correct byte depending on size and offset. Notes: - pci_cfg_read calls READ_DWORD_LE_A and pci_cfg_write calls WRITE_DWORD_LE_A. When reading or writing memory that is organized as little endian dwords, such as my_pci_cfg_hdr of mpc106, the function should explicitly state that it's little endian so that the emulator may be ported one day to a CPU architecture that is not little endian.
2022-09-02 10:32:28 +00:00
LOG_F(
WARNING, "%s: reading from unimplemented config register @%02x.%c",
this->name.c_str(), reg_offs + offset,
size == 4 ? 'l' : size == 2 ? 'w' : size == 1 ? 'b' : '0' + size
);
Fix return value for bad pci config address PCI config read fails should return all 1 bits. All unused registers in an existing PCI device should return 0. Because that's what my Power Mac 8600 returns when I run my Open Firmware lspci command. Any bus/device/function that doesn't exist returns FF and won't be listed by lspci. Any registers that are unused will show as 00 in the lspci output. Make grackle log bus:device.function @register.size in all cases.
2022-08-24 14:12:35 +00:00
return 0;
Bandit: implement address mask register.
2022-04-13 20:38:51 +00:00
}
void Bandit::pci_cfg_write(uint32_t reg_offs, uint32_t value, uint32_t size)
{
if (reg_offs < 64) {
PCIDevice::pci_cfg_write(reg_offs, value, size);
return;
}
Fix PCI config r/w of byte and word and unaligned dingusppc could not read bytes from offset 1,2,3 or words from offset 2. dingusppc did not read words from offset 1,3 and longs from offset 1,2,3 in the same way as a real Power Mac 8600 or B&W G3. This commit fixes those issues. - Added pci_cfg_rev_read. It takes a 32 bit value from offset 0 and returns a value of the specified size using bytes starting from the specified offset. Offsets 4,5, & 6 wrap around to 0,1, & 2 respectively. The result bytes are in flipped order as required by the pci_cfg_read method (so a value of 0x12345678 is returned as 0x78563412) A real Power Mac 8600 might return a random byte for offset 4, 5, 6 for vci0 but usually not for pci1. A B&W G3 seems to always wrap around correctly. We won't read random bytes, and we won't read a default such as 00 or FF. We'll do the wrap around which makes the most sense because writing 0x12345678 to any offset and reading from the same offset should produce the value that was written. - Added pci_cfg_rev_write. It takes a 32 bit value from offset 0, and modifies a specified number of bytes starting at a specified offset with the offset wrapping around to 0 if it exceeds 3. The modified bytes take their new values from the flipped bytes passed to pci_cfg_write. When size is 4, the original value is not used since all bytes will be modified. Basically, those two functions handle all the sizes and all the offsets and replace calls to BYTESWAP_32, read_mem or read_mem_rev, and write_mem or write_mem_rev. read_mem_rev, as it was used by pcidevice and some other places, could read beyond offset 3 if it were ever passed a reg_offs value that did not have offset as 0. Since the offset was always zero, it would always read the wrong byte or word if they were not at offset 0. Same for read_mem as used by mpc106. write_mem_rev, as it was used by pcidevice and some other places, could write beyond offset 3 if it were ever passed a reg_offs value that did not have offset as 0. Since the offset was always zero, it would always write the wrong byte or word if they were not at offset 0. Same for write_mem as used by mpc106. The PCI controllers (bandit, chaos, mpc106) need to encode the offset (0,1,2,3) into the reg_offs parameter passed to pci_cfg_read and pci_cfg_write so they can return or modify the correct bytes of the dword at reg_offs & 3. The pci_cfg_read and pci_cfg_write methods extract the offset from reg_offs and report unaligned accesses. pci_cfg_read uses pci_cfg_rev_read to read from the reg using the size and offset to determine which bytes to read. pci_cfg_write uses pci_cfg_rev_write to write to the reg using the size and offset to determine which bytes to modify. Other changes: - for unimplemented config register reads and writes, bandit and ATIRage now includes offset and size (and value in the case of writes) in log warnings. - for unimplemented config register reads and writes, pcidevice now includes offset in log warnings. - pci_read and pci_write of mpc106 require an offset parameter since config_addr does not contain the offset (it is always a multiple of 4). The offset is included in the log warninings for non-existent PCI devices. - ATIRage uses pci_cfg_rev_read and pci_cfg_rev_write which correctly places user_cfg at byte 0x40 instead of 0x43 and writes the correct byte depending on size and offset. Notes: - pci_cfg_read calls READ_DWORD_LE_A and pci_cfg_write calls WRITE_DWORD_LE_A. When reading or writing memory that is organized as little endian dwords, such as my_pci_cfg_hdr of mpc106, the function should explicitly state that it's little endian so that the emulator may be ported one day to a CPU architecture that is not little endian.
2022-09-02 10:32:28 +00:00
uint32_t offset = reg_offs & 3;
reg_offs &= ~3;
if (~-size & offset) {
LOG_F(
WARNING, "%s: unaligned write @%02x.%c = %0*x",
this->name.c_str(), reg_offs + offset,
size == 4 ? 'l' : size == 2 ? 'w' : size == 1 ? 'b' : '0' + size, size * 2, flip_sized(value, size)
);
}
if (reg_offs == BANDIT_ADDR_MASK) {
this->addr_mask = pci_cfg_rev_write(this->addr_mask, offset, size, value);
Bandit: implement address mask register.
2022-04-13 20:38:51 +00:00
this->verbose_address_space();
Fix PCI config r/w of byte and word and unaligned dingusppc could not read bytes from offset 1,2,3 or words from offset 2. dingusppc did not read words from offset 1,3 and longs from offset 1,2,3 in the same way as a real Power Mac 8600 or B&W G3. This commit fixes those issues. - Added pci_cfg_rev_read. It takes a 32 bit value from offset 0 and returns a value of the specified size using bytes starting from the specified offset. Offsets 4,5, & 6 wrap around to 0,1, & 2 respectively. The result bytes are in flipped order as required by the pci_cfg_read method (so a value of 0x12345678 is returned as 0x78563412) A real Power Mac 8600 might return a random byte for offset 4, 5, 6 for vci0 but usually not for pci1. A B&W G3 seems to always wrap around correctly. We won't read random bytes, and we won't read a default such as 00 or FF. We'll do the wrap around which makes the most sense because writing 0x12345678 to any offset and reading from the same offset should produce the value that was written. - Added pci_cfg_rev_write. It takes a 32 bit value from offset 0, and modifies a specified number of bytes starting at a specified offset with the offset wrapping around to 0 if it exceeds 3. The modified bytes take their new values from the flipped bytes passed to pci_cfg_write. When size is 4, the original value is not used since all bytes will be modified. Basically, those two functions handle all the sizes and all the offsets and replace calls to BYTESWAP_32, read_mem or read_mem_rev, and write_mem or write_mem_rev. read_mem_rev, as it was used by pcidevice and some other places, could read beyond offset 3 if it were ever passed a reg_offs value that did not have offset as 0. Since the offset was always zero, it would always read the wrong byte or word if they were not at offset 0. Same for read_mem as used by mpc106. write_mem_rev, as it was used by pcidevice and some other places, could write beyond offset 3 if it were ever passed a reg_offs value that did not have offset as 0. Since the offset was always zero, it would always write the wrong byte or word if they were not at offset 0. Same for write_mem as used by mpc106. The PCI controllers (bandit, chaos, mpc106) need to encode the offset (0,1,2,3) into the reg_offs parameter passed to pci_cfg_read and pci_cfg_write so they can return or modify the correct bytes of the dword at reg_offs & 3. The pci_cfg_read and pci_cfg_write methods extract the offset from reg_offs and report unaligned accesses. pci_cfg_read uses pci_cfg_rev_read to read from the reg using the size and offset to determine which bytes to read. pci_cfg_write uses pci_cfg_rev_write to write to the reg using the size and offset to determine which bytes to modify. Other changes: - for unimplemented config register reads and writes, bandit and ATIRage now includes offset and size (and value in the case of writes) in log warnings. - for unimplemented config register reads and writes, pcidevice now includes offset in log warnings. - pci_read and pci_write of mpc106 require an offset parameter since config_addr does not contain the offset (it is always a multiple of 4). The offset is included in the log warninings for non-existent PCI devices. - ATIRage uses pci_cfg_rev_read and pci_cfg_rev_write which correctly places user_cfg at byte 0x40 instead of 0x43 and writes the correct byte depending on size and offset. Notes: - pci_cfg_read calls READ_DWORD_LE_A and pci_cfg_write calls WRITE_DWORD_LE_A. When reading or writing memory that is organized as little endian dwords, such as my_pci_cfg_hdr of mpc106, the function should explicitly state that it's little endian so that the emulator may be ported one day to a CPU architecture that is not little endian.
2022-09-02 10:32:28 +00:00
return;
Bandit: implement address mask register.
2022-04-13 20:38:51 +00:00
}
Fix PCI config r/w of byte and word and unaligned dingusppc could not read bytes from offset 1,2,3 or words from offset 2. dingusppc did not read words from offset 1,3 and longs from offset 1,2,3 in the same way as a real Power Mac 8600 or B&W G3. This commit fixes those issues. - Added pci_cfg_rev_read. It takes a 32 bit value from offset 0 and returns a value of the specified size using bytes starting from the specified offset. Offsets 4,5, & 6 wrap around to 0,1, & 2 respectively. The result bytes are in flipped order as required by the pci_cfg_read method (so a value of 0x12345678 is returned as 0x78563412) A real Power Mac 8600 might return a random byte for offset 4, 5, 6 for vci0 but usually not for pci1. A B&W G3 seems to always wrap around correctly. We won't read random bytes, and we won't read a default such as 00 or FF. We'll do the wrap around which makes the most sense because writing 0x12345678 to any offset and reading from the same offset should produce the value that was written. - Added pci_cfg_rev_write. It takes a 32 bit value from offset 0, and modifies a specified number of bytes starting at a specified offset with the offset wrapping around to 0 if it exceeds 3. The modified bytes take their new values from the flipped bytes passed to pci_cfg_write. When size is 4, the original value is not used since all bytes will be modified. Basically, those two functions handle all the sizes and all the offsets and replace calls to BYTESWAP_32, read_mem or read_mem_rev, and write_mem or write_mem_rev. read_mem_rev, as it was used by pcidevice and some other places, could read beyond offset 3 if it were ever passed a reg_offs value that did not have offset as 0. Since the offset was always zero, it would always read the wrong byte or word if they were not at offset 0. Same for read_mem as used by mpc106. write_mem_rev, as it was used by pcidevice and some other places, could write beyond offset 3 if it were ever passed a reg_offs value that did not have offset as 0. Since the offset was always zero, it would always write the wrong byte or word if they were not at offset 0. Same for write_mem as used by mpc106. The PCI controllers (bandit, chaos, mpc106) need to encode the offset (0,1,2,3) into the reg_offs parameter passed to pci_cfg_read and pci_cfg_write so they can return or modify the correct bytes of the dword at reg_offs & 3. The pci_cfg_read and pci_cfg_write methods extract the offset from reg_offs and report unaligned accesses. pci_cfg_read uses pci_cfg_rev_read to read from the reg using the size and offset to determine which bytes to read. pci_cfg_write uses pci_cfg_rev_write to write to the reg using the size and offset to determine which bytes to modify. Other changes: - for unimplemented config register reads and writes, bandit and ATIRage now includes offset and size (and value in the case of writes) in log warnings. - for unimplemented config register reads and writes, pcidevice now includes offset in log warnings. - pci_read and pci_write of mpc106 require an offset parameter since config_addr does not contain the offset (it is always a multiple of 4). The offset is included in the log warninings for non-existent PCI devices. - ATIRage uses pci_cfg_rev_read and pci_cfg_rev_write which correctly places user_cfg at byte 0x40 instead of 0x43 and writes the correct byte depending on size and offset. Notes: - pci_cfg_read calls READ_DWORD_LE_A and pci_cfg_write calls WRITE_DWORD_LE_A. When reading or writing memory that is organized as little endian dwords, such as my_pci_cfg_hdr of mpc106, the function should explicitly state that it's little endian so that the emulator may be ported one day to a CPU architecture that is not little endian.
2022-09-02 10:32:28 +00:00
LOG_F(
WARNING, "%s: writing to unimplemented config register @%02x.%c = %0*x",
this->name.c_str(), reg_offs + offset,
size == 4 ? 'l' : size == 2 ? 'w' : size == 1 ? 'b' : '0' + size, size * 2, flip_sized(value, size)
);
Bandit: implement address mask register.
2022-04-13 20:38:51 +00:00
}
Fix read/write argument names base class uses reg_start so derived classes should do the same. Some derived class already uses reg_start for read method.
2022-08-22 10:16:31 +00:00
uint32_t Bandit::read(uint32_t rgn_start, uint32_t offset, int size)
Initial emulation of the Bandit ARBus-to-PCI bridge.
2022-01-16 21:47:04 +00:00
{
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
int bus_num, dev_num, fun_num;
Refine Bandit config address handling.
2022-01-17 00:28:35 +00:00
uint8_t reg_offs;
uint32_t result, idsel;
Initial emulation of the Bandit ARBus-to-PCI bridge.
2022-01-16 21:47:04 +00:00
if (offset & BANDIT_CONFIG_SPACE) {
if (offset & 0x00400000) {
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
fun_num = (this->config_addr >> 8) & 7;
reg_offs = this->config_addr & 0xFCU;
Initial emulation of the Bandit ARBus-to-PCI bridge.
2022-01-16 21:47:04 +00:00
// access to the CONFIG_DATA pseudo-register causes a Config Cycle
Refine Bandit config address handling.
2022-01-17 00:28:35 +00:00
if (this->config_addr & BANDIT_CAR_TYPE) {
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
bus_num = (this->config_addr >> 16) & 255;
dev_num = (this->config_addr >> 11) & 31;
LOG_F(
WARNING, "%s: read config cycle type 1 not supported yet %02x:%02x.%x @%02x.%c",
this->name.c_str(), bus_num, dev_num, fun_num, reg_offs + (offset & 3),
size == 4 ? 'l' : size == 2 ? 'w' : size == 1 ? 'b' : '0' + size
);
Fix return value for bad pci config address PCI config read fails should return all 1 bits. All unused registers in an existing PCI device should return 0. Because that's what my Power Mac 8600 returns when I run my Open Firmware lspci command. Any bus/device/function that doesn't exist returns FF and won't be listed by lspci. Any registers that are unused will show as 00 in the lspci output. Make grackle log bus:device.function @register.size in all cases.
2022-08-24 14:12:35 +00:00
return 0xFFFFFFFFUL; // PCI spec §6.1
Refine Bandit config address handling.
2022-01-17 00:28:35 +00:00
}
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
idsel = (this->config_addr >> 11) & 0x1FFFFFU;
Initial emulation of the Bandit ARBus-to-PCI bridge.
2022-01-16 21:47:04 +00:00
Refine Bandit config address handling.
2022-01-17 00:28:35 +00:00
if (!SINGLE_BIT_SET(idsel)) {
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
LOG_F(
ERROR, "%s: read invalid IDSEL=0x%X config:0x%X ??:??.%x? @%02x?.%c",
this->name.c_str(), idsel, this->config_addr,
fun_num, reg_offs + (offset & 3),
size == 4 ? 'l' : size == 2 ? 'w' : size == 1 ? 'b' : '0' + size
);
Fix return value for bad pci config address PCI config read fails should return all 1 bits. All unused registers in an existing PCI device should return 0. Because that's what my Power Mac 8600 returns when I run my Open Firmware lspci command. Any bus/device/function that doesn't exist returns FF and won't be listed by lspci. Any registers that are unused will show as 00 in the lspci output. Make grackle log bus:device.function @register.size in all cases.
2022-08-24 14:12:35 +00:00
return 0xFFFFFFFFUL; // PCI spec §6.1
Refine Bandit config address handling.
2022-01-17 00:28:35 +00:00
}
if (idsel == BANDIT_ID_SEL) { // access to myself
Fix PCI config r/w of byte and word and unaligned dingusppc could not read bytes from offset 1,2,3 or words from offset 2. dingusppc did not read words from offset 1,3 and longs from offset 1,2,3 in the same way as a real Power Mac 8600 or B&W G3. This commit fixes those issues. - Added pci_cfg_rev_read. It takes a 32 bit value from offset 0 and returns a value of the specified size using bytes starting from the specified offset. Offsets 4,5, & 6 wrap around to 0,1, & 2 respectively. The result bytes are in flipped order as required by the pci_cfg_read method (so a value of 0x12345678 is returned as 0x78563412) A real Power Mac 8600 might return a random byte for offset 4, 5, 6 for vci0 but usually not for pci1. A B&W G3 seems to always wrap around correctly. We won't read random bytes, and we won't read a default such as 00 or FF. We'll do the wrap around which makes the most sense because writing 0x12345678 to any offset and reading from the same offset should produce the value that was written. - Added pci_cfg_rev_write. It takes a 32 bit value from offset 0, and modifies a specified number of bytes starting at a specified offset with the offset wrapping around to 0 if it exceeds 3. The modified bytes take their new values from the flipped bytes passed to pci_cfg_write. When size is 4, the original value is not used since all bytes will be modified. Basically, those two functions handle all the sizes and all the offsets and replace calls to BYTESWAP_32, read_mem or read_mem_rev, and write_mem or write_mem_rev. read_mem_rev, as it was used by pcidevice and some other places, could read beyond offset 3 if it were ever passed a reg_offs value that did not have offset as 0. Since the offset was always zero, it would always read the wrong byte or word if they were not at offset 0. Same for read_mem as used by mpc106. write_mem_rev, as it was used by pcidevice and some other places, could write beyond offset 3 if it were ever passed a reg_offs value that did not have offset as 0. Since the offset was always zero, it would always write the wrong byte or word if they were not at offset 0. Same for write_mem as used by mpc106. The PCI controllers (bandit, chaos, mpc106) need to encode the offset (0,1,2,3) into the reg_offs parameter passed to pci_cfg_read and pci_cfg_write so they can return or modify the correct bytes of the dword at reg_offs & 3. The pci_cfg_read and pci_cfg_write methods extract the offset from reg_offs and report unaligned accesses. pci_cfg_read uses pci_cfg_rev_read to read from the reg using the size and offset to determine which bytes to read. pci_cfg_write uses pci_cfg_rev_write to write to the reg using the size and offset to determine which bytes to modify. Other changes: - for unimplemented config register reads and writes, bandit and ATIRage now includes offset and size (and value in the case of writes) in log warnings. - for unimplemented config register reads and writes, pcidevice now includes offset in log warnings. - pci_read and pci_write of mpc106 require an offset parameter since config_addr does not contain the offset (it is always a multiple of 4). The offset is included in the log warninings for non-existent PCI devices. - ATIRage uses pci_cfg_rev_read and pci_cfg_rev_write which correctly places user_cfg at byte 0x40 instead of 0x43 and writes the correct byte depending on size and offset. Notes: - pci_cfg_read calls READ_DWORD_LE_A and pci_cfg_write calls WRITE_DWORD_LE_A. When reading or writing memory that is organized as little endian dwords, such as my_pci_cfg_hdr of mpc106, the function should explicitly state that it's little endian so that the emulator may be ported one day to a CPU architecture that is not little endian.
2022-09-02 10:32:28 +00:00
result = this->pci_cfg_read(reg_offs + (offset & 3), size);
Refine Bandit config address handling.
2022-01-17 00:28:35 +00:00
} else {
if (this->dev_map.count(idsel)) {
Fix PCI config r/w of byte and word and unaligned dingusppc could not read bytes from offset 1,2,3 or words from offset 2. dingusppc did not read words from offset 1,3 and longs from offset 1,2,3 in the same way as a real Power Mac 8600 or B&W G3. This commit fixes those issues. - Added pci_cfg_rev_read. It takes a 32 bit value from offset 0 and returns a value of the specified size using bytes starting from the specified offset. Offsets 4,5, & 6 wrap around to 0,1, & 2 respectively. The result bytes are in flipped order as required by the pci_cfg_read method (so a value of 0x12345678 is returned as 0x78563412) A real Power Mac 8600 might return a random byte for offset 4, 5, 6 for vci0 but usually not for pci1. A B&W G3 seems to always wrap around correctly. We won't read random bytes, and we won't read a default such as 00 or FF. We'll do the wrap around which makes the most sense because writing 0x12345678 to any offset and reading from the same offset should produce the value that was written. - Added pci_cfg_rev_write. It takes a 32 bit value from offset 0, and modifies a specified number of bytes starting at a specified offset with the offset wrapping around to 0 if it exceeds 3. The modified bytes take their new values from the flipped bytes passed to pci_cfg_write. When size is 4, the original value is not used since all bytes will be modified. Basically, those two functions handle all the sizes and all the offsets and replace calls to BYTESWAP_32, read_mem or read_mem_rev, and write_mem or write_mem_rev. read_mem_rev, as it was used by pcidevice and some other places, could read beyond offset 3 if it were ever passed a reg_offs value that did not have offset as 0. Since the offset was always zero, it would always read the wrong byte or word if they were not at offset 0. Same for read_mem as used by mpc106. write_mem_rev, as it was used by pcidevice and some other places, could write beyond offset 3 if it were ever passed a reg_offs value that did not have offset as 0. Since the offset was always zero, it would always write the wrong byte or word if they were not at offset 0. Same for write_mem as used by mpc106. The PCI controllers (bandit, chaos, mpc106) need to encode the offset (0,1,2,3) into the reg_offs parameter passed to pci_cfg_read and pci_cfg_write so they can return or modify the correct bytes of the dword at reg_offs & 3. The pci_cfg_read and pci_cfg_write methods extract the offset from reg_offs and report unaligned accesses. pci_cfg_read uses pci_cfg_rev_read to read from the reg using the size and offset to determine which bytes to read. pci_cfg_write uses pci_cfg_rev_write to write to the reg using the size and offset to determine which bytes to modify. Other changes: - for unimplemented config register reads and writes, bandit and ATIRage now includes offset and size (and value in the case of writes) in log warnings. - for unimplemented config register reads and writes, pcidevice now includes offset in log warnings. - pci_read and pci_write of mpc106 require an offset parameter since config_addr does not contain the offset (it is always a multiple of 4). The offset is included in the log warninings for non-existent PCI devices. - ATIRage uses pci_cfg_rev_read and pci_cfg_rev_write which correctly places user_cfg at byte 0x40 instead of 0x43 and writes the correct byte depending on size and offset. Notes: - pci_cfg_read calls READ_DWORD_LE_A and pci_cfg_write calls WRITE_DWORD_LE_A. When reading or writing memory that is organized as little endian dwords, such as my_pci_cfg_hdr of mpc106, the function should explicitly state that it's little endian so that the emulator may be ported one day to a CPU architecture that is not little endian.
2022-09-02 10:32:28 +00:00
result = this->dev_map[idsel]->pci_cfg_read(reg_offs + (offset & 3), size);
Initial emulation of the Bandit ARBus-to-PCI bridge.
2022-01-16 21:47:04 +00:00
} else {
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
dev_num = WHAT_BIT_SET(idsel) + 11;
Initial emulation of the Bandit ARBus-to-PCI bridge.
2022-01-16 21:47:04 +00:00
LOG_F(
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
ERROR, "%s err: read attempt from non-existing PCI device ??:%02x.%x @%02x.%c",
this->name.c_str(), dev_num, fun_num, reg_offs + (offset & 3),
size == 4 ? 'l' : size == 2 ? 'w' : size == 1 ? 'b' : '0' + size
);
bandit: fix return value for empty slots.
2022-08-22 13:05:35 +00:00
return 0xFFFFFFFFUL; // PCI spec §6.1
Initial emulation of the Bandit ARBus-to-PCI bridge.
2022-01-16 21:47:04 +00:00
}
}
} else {
result = this->config_addr;
}
} else { // I/O space access
Bandit: implement I/O space transactions.
2022-04-13 20:39:29 +00:00
// broadcast I/O request to devices that support I/O space
// until a device returns true that means "request accepted"
for (auto& dev : this->io_space_devs) {
if (dev->pci_io_read(offset, size, &result)) {
return result;
}
}
LOG_F(ERROR, "%s: attempt to read from unmapped PCI I/O space, offset=0x%X",
this->name.c_str(), offset);
Initial emulation of the Bandit ARBus-to-PCI bridge.
2022-01-16 21:47:04 +00:00
}
Bandit: use common PCI configuration code.
2022-03-13 19:55:29 +00:00
return result;
Initial emulation of the Bandit ARBus-to-PCI bridge.
2022-01-16 21:47:04 +00:00
}
Fix read/write argument names base class uses reg_start so derived classes should do the same. Some derived class already uses reg_start for read method.
2022-08-22 10:16:31 +00:00
void Bandit::write(uint32_t rgn_start, uint32_t offset, uint32_t value, int size)
Initial emulation of the Bandit ARBus-to-PCI bridge.
2022-01-16 21:47:04 +00:00
{
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
int bus_num, dev_num, fun_num;
Refine Bandit config address handling.
2022-01-17 00:28:35 +00:00
uint8_t reg_offs;
uint32_t idsel;
Initial emulation of the Bandit ARBus-to-PCI bridge.
2022-01-16 21:47:04 +00:00
if (offset & BANDIT_CONFIG_SPACE) {
if (offset & 0x00400000) {
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
fun_num = (this->config_addr >> 8) & 7;
reg_offs = this->config_addr & 0xFCU;
Initial emulation of the Bandit ARBus-to-PCI bridge.
2022-01-16 21:47:04 +00:00
// access to the CONFIG_DATA pseudo-register causes a Config Cycle
Refine Bandit config address handling.
2022-01-17 00:28:35 +00:00
if (this->config_addr & BANDIT_CAR_TYPE) {
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
bus_num = (this->config_addr >> 16) & 255;
dev_num = (this->config_addr >> 11) & 31;
LOG_F(
WARNING, "%s: write config cycle type 1 not supported yet %02x:%02x.%x @%02x.%c = %0*x",
this->name.c_str(), bus_num, dev_num, fun_num, reg_offs + (offset & 3),
Log PCI config write values MSB first Writes to config registers of invalid or non-existent PCI devices are logged. They should be logged with most significant byte first. The values enter the methods in reverse byte order so they need to be byte swapped (except when size is 1) for logging. The result is that this command in Open Firmware: `12345678 16800 config-l!` will log this: `VCI0 err: write attempt to non-existing VCI device ??:0d.0 @00.l = 12345678`
2022-09-02 08:42:52 +00:00
size == 4 ? 'l' : size == 2 ? 'w' : size == 1 ? 'b' : '0' + size, size * 2, flip_sized(value, size)
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
);
Initial emulation of the Bandit ARBus-to-PCI bridge.
2022-01-16 21:47:04 +00:00
return;
}
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
idsel = (this->config_addr >> 11) & 0x1FFFFFU;
Refine Bandit config address handling.
2022-01-17 00:28:35 +00:00
if (!SINGLE_BIT_SET(idsel)) {
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
LOG_F(
ERROR, "%s: write invalid IDSEL=0x%X config:0x%X ??:??.%x? @%02x?.%c = %0*x",
this->name.c_str(), idsel, this->config_addr,
fun_num, reg_offs + (offset & 3),
Log PCI config write values MSB first Writes to config registers of invalid or non-existent PCI devices are logged. They should be logged with most significant byte first. The values enter the methods in reverse byte order so they need to be byte swapped (except when size is 1) for logging. The result is that this command in Open Firmware: `12345678 16800 config-l!` will log this: `VCI0 err: write attempt to non-existing VCI device ??:0d.0 @00.l = 12345678`
2022-09-02 08:42:52 +00:00
size == 4 ? 'l' : size == 2 ? 'w' : size == 1 ? 'b' : '0' + size, size * 2, flip_sized(value, size)
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
);
Refine Bandit config address handling.
2022-01-17 00:28:35 +00:00
return;
}
if (idsel == BANDIT_ID_SEL) { // access to myself
Fix PCI config r/w of byte and word and unaligned dingusppc could not read bytes from offset 1,2,3 or words from offset 2. dingusppc did not read words from offset 1,3 and longs from offset 1,2,3 in the same way as a real Power Mac 8600 or B&W G3. This commit fixes those issues. - Added pci_cfg_rev_read. It takes a 32 bit value from offset 0 and returns a value of the specified size using bytes starting from the specified offset. Offsets 4,5, & 6 wrap around to 0,1, & 2 respectively. The result bytes are in flipped order as required by the pci_cfg_read method (so a value of 0x12345678 is returned as 0x78563412) A real Power Mac 8600 might return a random byte for offset 4, 5, 6 for vci0 but usually not for pci1. A B&W G3 seems to always wrap around correctly. We won't read random bytes, and we won't read a default such as 00 or FF. We'll do the wrap around which makes the most sense because writing 0x12345678 to any offset and reading from the same offset should produce the value that was written. - Added pci_cfg_rev_write. It takes a 32 bit value from offset 0, and modifies a specified number of bytes starting at a specified offset with the offset wrapping around to 0 if it exceeds 3. The modified bytes take their new values from the flipped bytes passed to pci_cfg_write. When size is 4, the original value is not used since all bytes will be modified. Basically, those two functions handle all the sizes and all the offsets and replace calls to BYTESWAP_32, read_mem or read_mem_rev, and write_mem or write_mem_rev. read_mem_rev, as it was used by pcidevice and some other places, could read beyond offset 3 if it were ever passed a reg_offs value that did not have offset as 0. Since the offset was always zero, it would always read the wrong byte or word if they were not at offset 0. Same for read_mem as used by mpc106. write_mem_rev, as it was used by pcidevice and some other places, could write beyond offset 3 if it were ever passed a reg_offs value that did not have offset as 0. Since the offset was always zero, it would always write the wrong byte or word if they were not at offset 0. Same for write_mem as used by mpc106. The PCI controllers (bandit, chaos, mpc106) need to encode the offset (0,1,2,3) into the reg_offs parameter passed to pci_cfg_read and pci_cfg_write so they can return or modify the correct bytes of the dword at reg_offs & 3. The pci_cfg_read and pci_cfg_write methods extract the offset from reg_offs and report unaligned accesses. pci_cfg_read uses pci_cfg_rev_read to read from the reg using the size and offset to determine which bytes to read. pci_cfg_write uses pci_cfg_rev_write to write to the reg using the size and offset to determine which bytes to modify. Other changes: - for unimplemented config register reads and writes, bandit and ATIRage now includes offset and size (and value in the case of writes) in log warnings. - for unimplemented config register reads and writes, pcidevice now includes offset in log warnings. - pci_read and pci_write of mpc106 require an offset parameter since config_addr does not contain the offset (it is always a multiple of 4). The offset is included in the log warninings for non-existent PCI devices. - ATIRage uses pci_cfg_rev_read and pci_cfg_rev_write which correctly places user_cfg at byte 0x40 instead of 0x43 and writes the correct byte depending on size and offset. Notes: - pci_cfg_read calls READ_DWORD_LE_A and pci_cfg_write calls WRITE_DWORD_LE_A. When reading or writing memory that is organized as little endian dwords, such as my_pci_cfg_hdr of mpc106, the function should explicitly state that it's little endian so that the emulator may be ported one day to a CPU architecture that is not little endian.
2022-09-02 10:32:28 +00:00
this->pci_cfg_write(reg_offs + (offset & 3), value, size);
Refine Bandit config address handling.
2022-01-17 00:28:35 +00:00
return;
}
Initial emulation of the Bandit ARBus-to-PCI bridge.
2022-01-16 21:47:04 +00:00
Refine Bandit config address handling.
2022-01-17 00:28:35 +00:00
if (this->dev_map.count(idsel)) {
Fix PCI config r/w of byte and word and unaligned dingusppc could not read bytes from offset 1,2,3 or words from offset 2. dingusppc did not read words from offset 1,3 and longs from offset 1,2,3 in the same way as a real Power Mac 8600 or B&W G3. This commit fixes those issues. - Added pci_cfg_rev_read. It takes a 32 bit value from offset 0 and returns a value of the specified size using bytes starting from the specified offset. Offsets 4,5, & 6 wrap around to 0,1, & 2 respectively. The result bytes are in flipped order as required by the pci_cfg_read method (so a value of 0x12345678 is returned as 0x78563412) A real Power Mac 8600 might return a random byte for offset 4, 5, 6 for vci0 but usually not for pci1. A B&W G3 seems to always wrap around correctly. We won't read random bytes, and we won't read a default such as 00 or FF. We'll do the wrap around which makes the most sense because writing 0x12345678 to any offset and reading from the same offset should produce the value that was written. - Added pci_cfg_rev_write. It takes a 32 bit value from offset 0, and modifies a specified number of bytes starting at a specified offset with the offset wrapping around to 0 if it exceeds 3. The modified bytes take their new values from the flipped bytes passed to pci_cfg_write. When size is 4, the original value is not used since all bytes will be modified. Basically, those two functions handle all the sizes and all the offsets and replace calls to BYTESWAP_32, read_mem or read_mem_rev, and write_mem or write_mem_rev. read_mem_rev, as it was used by pcidevice and some other places, could read beyond offset 3 if it were ever passed a reg_offs value that did not have offset as 0. Since the offset was always zero, it would always read the wrong byte or word if they were not at offset 0. Same for read_mem as used by mpc106. write_mem_rev, as it was used by pcidevice and some other places, could write beyond offset 3 if it were ever passed a reg_offs value that did not have offset as 0. Since the offset was always zero, it would always write the wrong byte or word if they were not at offset 0. Same for write_mem as used by mpc106. The PCI controllers (bandit, chaos, mpc106) need to encode the offset (0,1,2,3) into the reg_offs parameter passed to pci_cfg_read and pci_cfg_write so they can return or modify the correct bytes of the dword at reg_offs & 3. The pci_cfg_read and pci_cfg_write methods extract the offset from reg_offs and report unaligned accesses. pci_cfg_read uses pci_cfg_rev_read to read from the reg using the size and offset to determine which bytes to read. pci_cfg_write uses pci_cfg_rev_write to write to the reg using the size and offset to determine which bytes to modify. Other changes: - for unimplemented config register reads and writes, bandit and ATIRage now includes offset and size (and value in the case of writes) in log warnings. - for unimplemented config register reads and writes, pcidevice now includes offset in log warnings. - pci_read and pci_write of mpc106 require an offset parameter since config_addr does not contain the offset (it is always a multiple of 4). The offset is included in the log warninings for non-existent PCI devices. - ATIRage uses pci_cfg_rev_read and pci_cfg_rev_write which correctly places user_cfg at byte 0x40 instead of 0x43 and writes the correct byte depending on size and offset. Notes: - pci_cfg_read calls READ_DWORD_LE_A and pci_cfg_write calls WRITE_DWORD_LE_A. When reading or writing memory that is organized as little endian dwords, such as my_pci_cfg_hdr of mpc106, the function should explicitly state that it's little endian so that the emulator may be ported one day to a CPU architecture that is not little endian.
2022-09-02 10:32:28 +00:00
this->dev_map[idsel]->pci_cfg_write(reg_offs + (offset & 3), value, size);
Initial emulation of the Bandit ARBus-to-PCI bridge.
2022-01-16 21:47:04 +00:00
} else {
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
dev_num = WHAT_BIT_SET(idsel) + 11;
Initial emulation of the Bandit ARBus-to-PCI bridge.
2022-01-16 21:47:04 +00:00
LOG_F(
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
ERROR, "%s err: write attempt to non-existing PCI device ??:%02x.%x @%02x.%c = %0*x",
this->name.c_str(), dev_num, fun_num, reg_offs + (offset & 3),
Log PCI config write values MSB first Writes to config registers of invalid or non-existent PCI devices are logged. They should be logged with most significant byte first. The values enter the methods in reverse byte order so they need to be byte swapped (except when size is 1) for logging. The result is that this command in Open Firmware: `12345678 16800 config-l!` will log this: `VCI0 err: write attempt to non-existing VCI device ??:0d.0 @00.l = 12345678`
2022-09-02 08:42:52 +00:00
size == 4 ? 'l' : size == 2 ? 'w' : size == 1 ? 'b' : '0' + size, size * 2, flip_sized(value, size)
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
);
Initial emulation of the Bandit ARBus-to-PCI bridge.
2022-01-16 21:47:04 +00:00
}
} else {
Refine Bandit config address handling.
2022-01-17 00:28:35 +00:00
this->config_addr = BYTESWAP_32(value);
Initial emulation of the Bandit ARBus-to-PCI bridge.
2022-01-16 21:47:04 +00:00
}
} else { // I/O space access
Bandit: implement I/O space transactions.
2022-04-13 20:39:29 +00:00
// broadcast I/O request to devices that support I/O space
// until a device returns true that means "request accepted"
for (auto& dev : this->io_space_devs) {
if (dev->pci_io_write(offset, value, size)) {
return;
}
}
LOG_F(ERROR, "%s: attempt to write to unmapped PCI I/O space, offset=0x%X",
this->name.c_str(), offset);
Initial emulation of the Bandit ARBus-to-PCI bridge.
2022-01-16 21:47:04 +00:00
}
}
Bandit: implement address mask register.
2022-04-13 20:38:51 +00:00
void Bandit::verbose_address_space()
{
uint32_t mask;
int bit_pos;
LOG_F(INFO, "%s address spaces:", this->pci_name.c_str());
// verbose coarse aka 256MB memory regions
for (mask = 0x10000, bit_pos = 0; mask != 0x80000000UL; mask <<= 1, bit_pos++) {
if (this->addr_mask & mask) {
uint32_t start_addr = bit_pos << 28;
LOG_F(INFO, "- 0x%X ... 0x%X", start_addr, start_addr + 0x0FFFFFFFU);
}
}
// verbose fine aka 16MB memory regions
for (mask = 0x1, bit_pos = 0; mask != 0x10000UL; mask <<= 1, bit_pos++) {
if (this->addr_mask & mask) {
uint32_t start_addr = (bit_pos << 24) + 0xF0000000UL;
LOG_F(INFO, "- 0x%X ... 0x%X", start_addr, start_addr + 0x00FFFFFFU);
}
}
}
bandit: self-registration with the device registry.
2022-07-17 03:39:39 +00:00
bandit: add Chaos support.
2022-08-06 17:29:45 +00:00
Chaos::Chaos(std::string name) : PCIHost()
{
supports_types(HWCompType::PCI_HOST);
MemCtrlBase *mem_ctrl = dynamic_cast<MemCtrlBase *>
(gMachineObj->get_comp_by_type(HWCompType::MEM_CTRL));
// add memory mapped I/O region for Chaos control registers
// This region has the following layout:
// base_addr + 0x800000 --> CONFIG_ADDR
// base_addr + 0xC00000 --> CONFIG_DATA
mem_ctrl->add_mmio_region(0xF0000000UL, 0x01000000, this);
this->name = name;
}
Fix read/write argument names base class uses reg_start so derived classes should do the same. Some derived class already uses reg_start for read method.
2022-08-22 10:16:31 +00:00
uint32_t Chaos::read(uint32_t rgn_start, uint32_t offset, int size)
bandit: add Chaos support.
2022-08-06 17:29:45 +00:00
{
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
int bus_num, dev_num, fun_num;
bandit: add Chaos support.
2022-08-06 17:29:45 +00:00
uint8_t reg_offs;
uint32_t result, idsel;
if (offset & BANDIT_CONFIG_SPACE) {
if (offset & 0x00400000) {
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
fun_num = (this->config_addr >> 8) & 7;
bandit: add Chaos support.
2022-08-06 17:29:45 +00:00
reg_offs = this->config_addr & 0xFCU;
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
// access to the CONFIG_DATA pseudo-register causes a Config Cycle
if (this->config_addr & BANDIT_CAR_TYPE) {
bus_num = (this->config_addr >> 16) & 255;
dev_num = (this->config_addr >> 11) & 31;
LOG_F(
WARNING, "%s: read config cycle type 1 not supported yet %02x:%02x.%x @%02x.%c",
this->name.c_str(), bus_num, dev_num, fun_num, reg_offs + (offset & 3),
size == 4 ? 'l' : size == 2 ? 'w' : size == 1 ? 'b' : '0' + size
);
Fix return value for bad pci config address PCI config read fails should return all 1 bits. All unused registers in an existing PCI device should return 0. Because that's what my Power Mac 8600 returns when I run my Open Firmware lspci command. Any bus/device/function that doesn't exist returns FF and won't be listed by lspci. Any registers that are unused will show as 00 in the lspci output. Make grackle log bus:device.function @register.size in all cases.
2022-08-24 14:12:35 +00:00
return 0xFFFFFFFFUL; // PCI spec §6.1
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
}
idsel = (this->config_addr >> 11) & 0x1FFFFFU;
bandit: add Chaos support.
2022-08-06 17:29:45 +00:00
if (!SINGLE_BIT_SET(idsel)) {
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
LOG_F(
ERROR, "%s: read invalid IDSEL=0x%X config:0x%X ??:??.%x? @%02x?.%c",
this->name.c_str(), idsel, this->config_addr,
fun_num, reg_offs + (offset & 3),
size == 4 ? 'l' : size == 2 ? 'w' : size == 1 ? 'b' : '0' + size
);
Fix return value for bad pci config address PCI config read fails should return all 1 bits. All unused registers in an existing PCI device should return 0. Because that's what my Power Mac 8600 returns when I run my Open Firmware lspci command. Any bus/device/function that doesn't exist returns FF and won't be listed by lspci. Any registers that are unused will show as 00 in the lspci output. Make grackle log bus:device.function @register.size in all cases.
2022-08-24 14:12:35 +00:00
return 0xFFFFFFFFUL; // PCI spec §6.1
bandit: add Chaos support.
2022-08-06 17:29:45 +00:00
}
if (this->dev_map.count(idsel)) {
Fix PCI config r/w of byte and word and unaligned dingusppc could not read bytes from offset 1,2,3 or words from offset 2. dingusppc did not read words from offset 1,3 and longs from offset 1,2,3 in the same way as a real Power Mac 8600 or B&W G3. This commit fixes those issues. - Added pci_cfg_rev_read. It takes a 32 bit value from offset 0 and returns a value of the specified size using bytes starting from the specified offset. Offsets 4,5, & 6 wrap around to 0,1, & 2 respectively. The result bytes are in flipped order as required by the pci_cfg_read method (so a value of 0x12345678 is returned as 0x78563412) A real Power Mac 8600 might return a random byte for offset 4, 5, 6 for vci0 but usually not for pci1. A B&W G3 seems to always wrap around correctly. We won't read random bytes, and we won't read a default such as 00 or FF. We'll do the wrap around which makes the most sense because writing 0x12345678 to any offset and reading from the same offset should produce the value that was written. - Added pci_cfg_rev_write. It takes a 32 bit value from offset 0, and modifies a specified number of bytes starting at a specified offset with the offset wrapping around to 0 if it exceeds 3. The modified bytes take their new values from the flipped bytes passed to pci_cfg_write. When size is 4, the original value is not used since all bytes will be modified. Basically, those two functions handle all the sizes and all the offsets and replace calls to BYTESWAP_32, read_mem or read_mem_rev, and write_mem or write_mem_rev. read_mem_rev, as it was used by pcidevice and some other places, could read beyond offset 3 if it were ever passed a reg_offs value that did not have offset as 0. Since the offset was always zero, it would always read the wrong byte or word if they were not at offset 0. Same for read_mem as used by mpc106. write_mem_rev, as it was used by pcidevice and some other places, could write beyond offset 3 if it were ever passed a reg_offs value that did not have offset as 0. Since the offset was always zero, it would always write the wrong byte or word if they were not at offset 0. Same for write_mem as used by mpc106. The PCI controllers (bandit, chaos, mpc106) need to encode the offset (0,1,2,3) into the reg_offs parameter passed to pci_cfg_read and pci_cfg_write so they can return or modify the correct bytes of the dword at reg_offs & 3. The pci_cfg_read and pci_cfg_write methods extract the offset from reg_offs and report unaligned accesses. pci_cfg_read uses pci_cfg_rev_read to read from the reg using the size and offset to determine which bytes to read. pci_cfg_write uses pci_cfg_rev_write to write to the reg using the size and offset to determine which bytes to modify. Other changes: - for unimplemented config register reads and writes, bandit and ATIRage now includes offset and size (and value in the case of writes) in log warnings. - for unimplemented config register reads and writes, pcidevice now includes offset in log warnings. - pci_read and pci_write of mpc106 require an offset parameter since config_addr does not contain the offset (it is always a multiple of 4). The offset is included in the log warninings for non-existent PCI devices. - ATIRage uses pci_cfg_rev_read and pci_cfg_rev_write which correctly places user_cfg at byte 0x40 instead of 0x43 and writes the correct byte depending on size and offset. Notes: - pci_cfg_read calls READ_DWORD_LE_A and pci_cfg_write calls WRITE_DWORD_LE_A. When reading or writing memory that is organized as little endian dwords, such as my_pci_cfg_hdr of mpc106, the function should explicitly state that it's little endian so that the emulator may be ported one day to a CPU architecture that is not little endian.
2022-09-02 10:32:28 +00:00
result = this->dev_map[idsel]->pci_cfg_read(reg_offs + (offset & 3), size);
bandit: add Chaos support.
2022-08-06 17:29:45 +00:00
} else {
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
dev_num = WHAT_BIT_SET(idsel) + 11;
bandit: add Chaos support.
2022-08-06 17:29:45 +00:00
LOG_F(
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
ERROR, "%s err: read attempt from non-existing VCI device ??:%02x.%x @%02x.%c",
this->name.c_str(), dev_num, fun_num, reg_offs + (offset & 3),
size == 4 ? 'l' : size == 2 ? 'w' : size == 1 ? 'b' : '0' + size
);
bandit: fix return value for empty slots.
2022-08-22 13:05:35 +00:00
return 0xFFFFFFFFUL; // PCI spec §6.1
bandit: add Chaos support.
2022-08-06 17:29:45 +00:00
}
} else {
result = this->config_addr;
}
} else { // I/O space access
LOG_F(ERROR, "%s: I/O space not supported", this->name.c_str());
return 0;
}
return result;
}
Fix read/write argument names base class uses reg_start so derived classes should do the same. Some derived class already uses reg_start for read method.
2022-08-22 10:16:31 +00:00
void Chaos::write(uint32_t rgn_start, uint32_t offset, uint32_t value, int size)
bandit: add Chaos support.
2022-08-06 17:29:45 +00:00
{
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
int bus_num, dev_num, fun_num;
bandit: add Chaos support.
2022-08-06 17:29:45 +00:00
uint8_t reg_offs;
uint32_t idsel;
if (offset & BANDIT_CONFIG_SPACE) {
if (offset & 0x00400000) {
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
fun_num = (this->config_addr >> 8) & 7;
reg_offs = this->config_addr & 0xFCU;
bandit: add Chaos support.
2022-08-06 17:29:45 +00:00
// access to the CONFIG_DATA pseudo-register causes a Config Cycle
if (this->config_addr & BANDIT_CAR_TYPE) {
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
bus_num = (this->config_addr >> 16) & 255;
dev_num = (this->config_addr >> 11) & 31;
LOG_F(
WARNING, "%s: write config cycle type 1 not supported yet %02x:%02x.%x @%02x.%c = %0*x",
this->name.c_str(), bus_num, dev_num, fun_num, reg_offs + (offset & 3),
Log PCI config write values MSB first Writes to config registers of invalid or non-existent PCI devices are logged. They should be logged with most significant byte first. The values enter the methods in reverse byte order so they need to be byte swapped (except when size is 1) for logging. The result is that this command in Open Firmware: `12345678 16800 config-l!` will log this: `VCI0 err: write attempt to non-existing VCI device ??:0d.0 @00.l = 12345678`
2022-09-02 08:42:52 +00:00
size == 4 ? 'l' : size == 2 ? 'w' : size == 1 ? 'b' : '0' + size, size * 2, flip_sized(value, size)
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
);
bandit: add Chaos support.
2022-08-06 17:29:45 +00:00
return;
}
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
idsel = (this->config_addr >> 11) & 0x1FFFFFU;
bandit: add Chaos support.
2022-08-06 17:29:45 +00:00
if (!SINGLE_BIT_SET(idsel)) {
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
LOG_F(
ERROR, "%s: write invalid IDSEL=0x%X config:0x%X ??:??.%x? @%02x?.%c = %0*x",
this->name.c_str(), idsel, this->config_addr,
fun_num, reg_offs + (offset & 3),
Log PCI config write values MSB first Writes to config registers of invalid or non-existent PCI devices are logged. They should be logged with most significant byte first. The values enter the methods in reverse byte order so they need to be byte swapped (except when size is 1) for logging. The result is that this command in Open Firmware: `12345678 16800 config-l!` will log this: `VCI0 err: write attempt to non-existing VCI device ??:0d.0 @00.l = 12345678`
2022-09-02 08:42:52 +00:00
size == 4 ? 'l' : size == 2 ? 'w' : size == 1 ? 'b' : '0' + size, size * 2, flip_sized(value, size)
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
);
bandit: add Chaos support.
2022-08-06 17:29:45 +00:00
return;
}
if (this->dev_map.count(idsel)) {
Fix PCI config r/w of byte and word and unaligned dingusppc could not read bytes from offset 1,2,3 or words from offset 2. dingusppc did not read words from offset 1,3 and longs from offset 1,2,3 in the same way as a real Power Mac 8600 or B&W G3. This commit fixes those issues. - Added pci_cfg_rev_read. It takes a 32 bit value from offset 0 and returns a value of the specified size using bytes starting from the specified offset. Offsets 4,5, & 6 wrap around to 0,1, & 2 respectively. The result bytes are in flipped order as required by the pci_cfg_read method (so a value of 0x12345678 is returned as 0x78563412) A real Power Mac 8600 might return a random byte for offset 4, 5, 6 for vci0 but usually not for pci1. A B&W G3 seems to always wrap around correctly. We won't read random bytes, and we won't read a default such as 00 or FF. We'll do the wrap around which makes the most sense because writing 0x12345678 to any offset and reading from the same offset should produce the value that was written. - Added pci_cfg_rev_write. It takes a 32 bit value from offset 0, and modifies a specified number of bytes starting at a specified offset with the offset wrapping around to 0 if it exceeds 3. The modified bytes take their new values from the flipped bytes passed to pci_cfg_write. When size is 4, the original value is not used since all bytes will be modified. Basically, those two functions handle all the sizes and all the offsets and replace calls to BYTESWAP_32, read_mem or read_mem_rev, and write_mem or write_mem_rev. read_mem_rev, as it was used by pcidevice and some other places, could read beyond offset 3 if it were ever passed a reg_offs value that did not have offset as 0. Since the offset was always zero, it would always read the wrong byte or word if they were not at offset 0. Same for read_mem as used by mpc106. write_mem_rev, as it was used by pcidevice and some other places, could write beyond offset 3 if it were ever passed a reg_offs value that did not have offset as 0. Since the offset was always zero, it would always write the wrong byte or word if they were not at offset 0. Same for write_mem as used by mpc106. The PCI controllers (bandit, chaos, mpc106) need to encode the offset (0,1,2,3) into the reg_offs parameter passed to pci_cfg_read and pci_cfg_write so they can return or modify the correct bytes of the dword at reg_offs & 3. The pci_cfg_read and pci_cfg_write methods extract the offset from reg_offs and report unaligned accesses. pci_cfg_read uses pci_cfg_rev_read to read from the reg using the size and offset to determine which bytes to read. pci_cfg_write uses pci_cfg_rev_write to write to the reg using the size and offset to determine which bytes to modify. Other changes: - for unimplemented config register reads and writes, bandit and ATIRage now includes offset and size (and value in the case of writes) in log warnings. - for unimplemented config register reads and writes, pcidevice now includes offset in log warnings. - pci_read and pci_write of mpc106 require an offset parameter since config_addr does not contain the offset (it is always a multiple of 4). The offset is included in the log warninings for non-existent PCI devices. - ATIRage uses pci_cfg_rev_read and pci_cfg_rev_write which correctly places user_cfg at byte 0x40 instead of 0x43 and writes the correct byte depending on size and offset. Notes: - pci_cfg_read calls READ_DWORD_LE_A and pci_cfg_write calls WRITE_DWORD_LE_A. When reading or writing memory that is organized as little endian dwords, such as my_pci_cfg_hdr of mpc106, the function should explicitly state that it's little endian so that the emulator may be ported one day to a CPU architecture that is not little endian.
2022-09-02 10:32:28 +00:00
this->dev_map[idsel]->pci_cfg_write(reg_offs + (offset & 3), value, size);
bandit: add Chaos support.
2022-08-06 17:29:45 +00:00
} else {
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
dev_num = WHAT_BIT_SET(idsel) + 11;
bandit: add Chaos support.
2022-08-06 17:29:45 +00:00
LOG_F(
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
ERROR, "%s err: write attempt to non-existing VCI device ??:%02x.%x @%02x.%c = %0*x",
this->name.c_str(), dev_num, fun_num, reg_offs + (offset & 3),
Log PCI config write values MSB first Writes to config registers of invalid or non-existent PCI devices are logged. They should be logged with most significant byte first. The values enter the methods in reverse byte order so they need to be byte swapped (except when size is 1) for logging. The result is that this command in Open Firmware: `12345678 16800 config-l!` will log this: `VCI0 err: write attempt to non-existing VCI device ??:0d.0 @00.l = 12345678`
2022-09-02 08:42:52 +00:00
size == 4 ? 'l' : size == 2 ? 'w' : size == 1 ? 'b' : '0' + size, size * 2, flip_sized(value, size)
changes to pci logging For invalid or unsupported PCI accesses, do the following: - log a device's full pci address using pciutils setpci command format bb:dd.f @rr.s (bus:device:function @register+offset.size). - report as read or write access. - log value for writes. - bus, device, function, and register values cannot be determined from Invalid IDSEL values so they will output as ??. - for invalid IDSEL values, report the entire value of the config_addr. - for valid IDSEL values, the bus number cannot be determined since IDSEL only specifies device number. It's probably bus 00 but we'll show ?? to indicate an IDSEL type access. Add missing config type read access logging for chaos.
2022-08-22 09:29:09 +00:00
);
bandit: add Chaos support.
2022-08-06 17:29:45 +00:00
}
} else {
this->config_addr = BYTESWAP_32(value);
}
} else { // I/O space access
LOG_F(ERROR, "%s: I/O space not supported", this->name.c_str());
}
}
bandit: self-registration with the device registry.
2022-07-17 03:39:39 +00:00
static const DeviceDescription Bandit1_Descriptor = {
Bandit::create_first, {}, {}
};
bandit: add Chaos support.
2022-08-06 17:29:45 +00:00
static const DeviceDescription Chaos_Descriptor = {
Chaos::create, {}, {}
};
bandit: self-registration with the device registry.
2022-07-17 03:39:39 +00:00
REGISTER_DEVICE(Bandit1, Bandit1_Descriptor);
bandit: add Chaos support.
2022-08-06 17:29:45 +00:00
REGISTER_DEVICE(Chaos, Chaos_Descriptor);
Reference in New Issue Copy Permalink