dingusppc/devices/memctrl/mpc106.cpp

363 lines
12 KiB
C++
Raw Normal View History

/*
DingusPPC - The Experimental PowerPC Macintosh emulator
Copyright (C) 2018-23 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/>.
*/
/** MPC106 (Grackle) emulation. */
#include <devices/common/hwcomponent.h>
#include <devices/common/hwinterrupt.h>
#include <devices/deviceregistry.h>
#include <devices/memctrl/memctrlbase.h>
#include <devices/memctrl/mpc106.h>
#include <loguru.hpp>
#include <cinttypes>
2020-05-12 18:55:45 +00:00
#include <cstring>
#include <string>
MPC106::MPC106() : MemCtrlBase(), PCIDevice("Grackle"), PCIHost()
{
supports_types(HWCompType::MEM_CTRL | HWCompType::MMIO_DEV |
HWCompType::PCI_HOST | HWCompType::PCI_DEV);
// populate PCI config header
this->vendor_id = PCI_VENDOR_MOTOROLA;
this->device_id = 0x0002;
this->class_rev = 0x06000040;
this->cache_ln_sz = 8;
this->command = 6;
this->status = 0x80;
// assign PCI device number zero to myself
this->pci_register_device(DEV_FUN(0,0), this);
// add PCI/ISA I/O space, 64K for now
2020-03-31 19:12:06 +00:00
add_mmio_region(0xFE000000, 0x10000, this);
// add memory mapped I/O region for MPC106 registers
add_mmio_region(0xFEC00000, 0x300000, this);
}
int MPC106::device_postinit()
{
std::string pci_dev_name;
static const std::map<std::string, int> pci_slots = {
2023-11-25 12:04:25 +00:00
{"pci_PERCH", DEV_FUN(0xC,0)}, {"pci_A1", DEV_FUN(0xD,0)}, {"pci_B1", DEV_FUN(0xE,0)}, {"pci_C1", DEV_FUN(0xF,0)}, {"pci_GPU", DEV_FUN(0x12,0)}
};
for (auto& slot : pci_slots) {
pci_dev_name = GET_STR_PROP(slot.first);
if (!pci_dev_name.empty()) {
this->attach_pci_device(pci_dev_name, slot.second, std::string("@") + slot.first);
}
}
this->int_ctrl = dynamic_cast<InterruptCtrl*>(
gMachineObj->get_comp_by_type(HWCompType::INT_CTRL));
this->irq_id_PCI_A = this->int_ctrl->register_dev_int(IntSrc::PCI_A );
this->irq_id_PCI_B = this->int_ctrl->register_dev_int(IntSrc::PCI_B );
this->irq_id_PCI_C = this->int_ctrl->register_dev_int(IntSrc::PCI_C );
this->irq_id_PCI_GPU = this->int_ctrl->register_dev_int(IntSrc::PCI_GPU );
this->irq_id_PCI_PERCH = this->int_ctrl->register_dev_int(IntSrc::PCI_PERCH);
return 0;
}
void MPC106::pci_interrupt(uint8_t irq_line_state, PCIBase *dev) {
auto it = std::find_if(dev_map.begin(), dev_map.end(),
[&dev](const std::pair<int, PCIBase*> &p) {
return p.second == dev;
}
);
if (it == dev_map.end()) {
LOG_F(ERROR, "Interrupt from unknown device %s", dev->get_name().c_str());
}
else {
uint32_t irq_id;
switch (it->first) {
case DEV_FUN(0x0C,0): irq_id = this->irq_id_PCI_PERCH; break;
case DEV_FUN(0x0D,0): irq_id = this->irq_id_PCI_A ; break;
case DEV_FUN(0x0E,0): irq_id = this->irq_id_PCI_B ; break;
case DEV_FUN(0x0F,0): irq_id = this->irq_id_PCI_C ; break;
case DEV_FUN(0x12,0): irq_id = this->irq_id_PCI_GPU ; break;
default:
LOG_F(ERROR, "Interrupt from device %s at unexpected device/function %02x.%x", dev->get_name().c_str(), it->first >> 3, it->first & 7);
return;
}
if (this->int_ctrl)
this->int_ctrl->ack_int(irq_id, irq_line_state);
}
}
uint32_t MPC106::read(uint32_t rgn_start, uint32_t offset, int size) {
if (rgn_start == 0xFE000000) {
Add PCI bridge and multi-function device support. Add PCI bridge and multi-function device support. Overview: - A multi-function device is two or more PCIDevices with the same device number but one device is function zero (as with currently implemented PCIDevices) and the other functions have function numbers between 1 and 7. The device number and function number are properties of the PCIDevice's parent PCIHost connection. - A PCIBridge is a PCIHost (it can connect child PCI devices) and a PCIDevice (it has config space, BARs, and expansion ROM). - A PCIDevice has Type 0 header. It has 6 BARs. - A PCIBridge has Type 1 header. It has 2 BARs. The config space registers beginning from offset 0x18 differ from those of a PCIDevice. Possible future modifications: - Add a PCICardBus class. It is a PCIHost. It has Type 2 header. It has one BAR. The first 20 bytes match Type 0 and Type 1 headers. These exist in New World Macs. They allow hot-plug of PCI devices. - Split base PCI registers (first 16 bytes) into a PCIBase class. Type 1 and 2 have two or one BAR but I think all 6 BARs belong in PCIBase class anyway. - Split PCIHost into two classes: Currently existing PCIHosts (Bandit, Grackle) are PCIHost and PCIRoot (they have the broadcast I/O requests functionality) while PCIBridge is PCIHost only - it can propagate I/O requests but does not originate the broadcast. - pci_register_mmio_region should maybe return a pointer to a region struct so that it can be used for unregistering or modifying the region's range. This may be useful for PCI bridges which have ranges that may constrain memory BARs of their downstream devices. PCIDevice - Moved expansion ROM BAR handling to a separate function pci_wr_exp_rom_bar so that it can be used by both PCI devices and PCI bridges which have the ROM BAR in different locations. It now supports unmapping expansion ROM. Also made exp_rom_bar not writable if there's no ROM. - Added num_bars field which specifies the number of valid BARs since Type 0, 1, and 2 headers have different number of BARs. - map_exp_rom_mem now properly unmaps expansion ROM (using new function unmap_exp_rom_mem) before mapping it again. - Added function set_multi_function which modifies hdr_type to indicate if a device has other functions. This is to be applied only to devices with function number 0. PCIHost - When attaching a PCI device, it will check if it's a multi-function device (there exists an attached function that is not zero) and adjust hdr_type of function 0 of the device accordingly. - Attached PCI bridges are added to a list of PCI bridges attached to the host. - Added pci_io_read_loop and pci_io_write_loop which loop through attached PCI devices to find one that will perform the action for the given I/O address without logging an error (since some other device might perform the action). - Added pci_io_read_broadcast and pci_io_write_broadcast which are used by a PCI root (bandit/grackle). They will log an error if the action is not performed. They should probably do a machine check exception to match real Power Macs. - pci_find_device (used by PCI root) will recursively find a PCIDevice for type 1 config register accesses. - Logging from PCIHost now includes the name of the PCIHost instead of just "PCIHost" because there can be multiple PCI hosts. PCIBridge - Sets num_bars to 2 and hdr_type to 1. - I/O ranges set in the config registers are handled correctly by pci_io_read and pci_io_write. - Memory ranges set in the config registers do not currently affect memory mmio regions. It is assumed that Open Firmware and the OS will set the ranges and BARs correctly to allow all BARs to be accessed fully. bandit, mpc106 - Bandit and Grackle now call pci_io_read_broadcast and pci_io_read_broadcast to pass I/O accesses to downstream PCI devices. - Chaos is modified to work like Bandit even though it will never have PCI bridges attached or devices that support I/O accesses. It's simpler this way.
2022-10-26 06:06:12 +00:00
return pci_io_read_broadcast(offset, size);
}
if (offset < 0x200000) {
return this->config_addr;
}
Add PCI bridge and multi-function device support. Add PCI bridge and multi-function device support. Overview: - A multi-function device is two or more PCIDevices with the same device number but one device is function zero (as with currently implemented PCIDevices) and the other functions have function numbers between 1 and 7. The device number and function number are properties of the PCIDevice's parent PCIHost connection. - A PCIBridge is a PCIHost (it can connect child PCI devices) and a PCIDevice (it has config space, BARs, and expansion ROM). - A PCIDevice has Type 0 header. It has 6 BARs. - A PCIBridge has Type 1 header. It has 2 BARs. The config space registers beginning from offset 0x18 differ from those of a PCIDevice. Possible future modifications: - Add a PCICardBus class. It is a PCIHost. It has Type 2 header. It has one BAR. The first 20 bytes match Type 0 and Type 1 headers. These exist in New World Macs. They allow hot-plug of PCI devices. - Split base PCI registers (first 16 bytes) into a PCIBase class. Type 1 and 2 have two or one BAR but I think all 6 BARs belong in PCIBase class anyway. - Split PCIHost into two classes: Currently existing PCIHosts (Bandit, Grackle) are PCIHost and PCIRoot (they have the broadcast I/O requests functionality) while PCIBridge is PCIHost only - it can propagate I/O requests but does not originate the broadcast. - pci_register_mmio_region should maybe return a pointer to a region struct so that it can be used for unregistering or modifying the region's range. This may be useful for PCI bridges which have ranges that may constrain memory BARs of their downstream devices. PCIDevice - Moved expansion ROM BAR handling to a separate function pci_wr_exp_rom_bar so that it can be used by both PCI devices and PCI bridges which have the ROM BAR in different locations. It now supports unmapping expansion ROM. Also made exp_rom_bar not writable if there's no ROM. - Added num_bars field which specifies the number of valid BARs since Type 0, 1, and 2 headers have different number of BARs. - map_exp_rom_mem now properly unmaps expansion ROM (using new function unmap_exp_rom_mem) before mapping it again. - Added function set_multi_function which modifies hdr_type to indicate if a device has other functions. This is to be applied only to devices with function number 0. PCIHost - When attaching a PCI device, it will check if it's a multi-function device (there exists an attached function that is not zero) and adjust hdr_type of function 0 of the device accordingly. - Attached PCI bridges are added to a list of PCI bridges attached to the host. - Added pci_io_read_loop and pci_io_write_loop which loop through attached PCI devices to find one that will perform the action for the given I/O address without logging an error (since some other device might perform the action). - Added pci_io_read_broadcast and pci_io_write_broadcast which are used by a PCI root (bandit/grackle). They will log an error if the action is not performed. They should probably do a machine check exception to match real Power Macs. - pci_find_device (used by PCI root) will recursively find a PCIDevice for type 1 config register accesses. - Logging from PCIHost now includes the name of the PCIHost instead of just "PCIHost" because there can be multiple PCI hosts. PCIBridge - Sets num_bars to 2 and hdr_type to 1. - I/O ranges set in the config registers are handled correctly by pci_io_read and pci_io_write. - Memory ranges set in the config registers do not currently affect memory mmio regions. It is assumed that Open Firmware and the OS will set the ranges and BARs correctly to allow all BARs to be accessed fully. bandit, mpc106 - Bandit and Grackle now call pci_io_read_broadcast and pci_io_read_broadcast to pass I/O accesses to downstream PCI devices. - Chaos is modified to work like Bandit even though it will never have PCI bridges attached or devices that support I/O accesses. It's simpler this way.
2022-10-26 06:06:12 +00:00
if (this->config_addr & 0x80) { // process only if bit E (enable) is set
int bus_num, dev_num, fun_num;
uint8_t reg_offs;
AccessDetails details;
PCIBase *device;
cfg_setup(offset, size, bus_num, dev_num, fun_num, reg_offs, details, device);
details.flags |= PCI_CONFIG_READ;
if (device) {
uint32_t value = device->pci_cfg_read(reg_offs, details);
// bytes 0 to 3 repeat
return pci_conv_rd_data(value, value, details);
}
LOG_READ_NON_EXISTENT_PCI_DEVICE();
return 0xFFFFFFFFUL; // PCI spec §6.1
}
return 0;
}
void MPC106::write(uint32_t rgn_start, uint32_t offset, uint32_t value, int size) {
if (rgn_start == 0xFE000000) {
Add PCI bridge and multi-function device support. Add PCI bridge and multi-function device support. Overview: - A multi-function device is two or more PCIDevices with the same device number but one device is function zero (as with currently implemented PCIDevices) and the other functions have function numbers between 1 and 7. The device number and function number are properties of the PCIDevice's parent PCIHost connection. - A PCIBridge is a PCIHost (it can connect child PCI devices) and a PCIDevice (it has config space, BARs, and expansion ROM). - A PCIDevice has Type 0 header. It has 6 BARs. - A PCIBridge has Type 1 header. It has 2 BARs. The config space registers beginning from offset 0x18 differ from those of a PCIDevice. Possible future modifications: - Add a PCICardBus class. It is a PCIHost. It has Type 2 header. It has one BAR. The first 20 bytes match Type 0 and Type 1 headers. These exist in New World Macs. They allow hot-plug of PCI devices. - Split base PCI registers (first 16 bytes) into a PCIBase class. Type 1 and 2 have two or one BAR but I think all 6 BARs belong in PCIBase class anyway. - Split PCIHost into two classes: Currently existing PCIHosts (Bandit, Grackle) are PCIHost and PCIRoot (they have the broadcast I/O requests functionality) while PCIBridge is PCIHost only - it can propagate I/O requests but does not originate the broadcast. - pci_register_mmio_region should maybe return a pointer to a region struct so that it can be used for unregistering or modifying the region's range. This may be useful for PCI bridges which have ranges that may constrain memory BARs of their downstream devices. PCIDevice - Moved expansion ROM BAR handling to a separate function pci_wr_exp_rom_bar so that it can be used by both PCI devices and PCI bridges which have the ROM BAR in different locations. It now supports unmapping expansion ROM. Also made exp_rom_bar not writable if there's no ROM. - Added num_bars field which specifies the number of valid BARs since Type 0, 1, and 2 headers have different number of BARs. - map_exp_rom_mem now properly unmaps expansion ROM (using new function unmap_exp_rom_mem) before mapping it again. - Added function set_multi_function which modifies hdr_type to indicate if a device has other functions. This is to be applied only to devices with function number 0. PCIHost - When attaching a PCI device, it will check if it's a multi-function device (there exists an attached function that is not zero) and adjust hdr_type of function 0 of the device accordingly. - Attached PCI bridges are added to a list of PCI bridges attached to the host. - Added pci_io_read_loop and pci_io_write_loop which loop through attached PCI devices to find one that will perform the action for the given I/O address without logging an error (since some other device might perform the action). - Added pci_io_read_broadcast and pci_io_write_broadcast which are used by a PCI root (bandit/grackle). They will log an error if the action is not performed. They should probably do a machine check exception to match real Power Macs. - pci_find_device (used by PCI root) will recursively find a PCIDevice for type 1 config register accesses. - Logging from PCIHost now includes the name of the PCIHost instead of just "PCIHost" because there can be multiple PCI hosts. PCIBridge - Sets num_bars to 2 and hdr_type to 1. - I/O ranges set in the config registers are handled correctly by pci_io_read and pci_io_write. - Memory ranges set in the config registers do not currently affect memory mmio regions. It is assumed that Open Firmware and the OS will set the ranges and BARs correctly to allow all BARs to be accessed fully. bandit, mpc106 - Bandit and Grackle now call pci_io_read_broadcast and pci_io_read_broadcast to pass I/O accesses to downstream PCI devices. - Chaos is modified to work like Bandit even though it will never have PCI bridges attached or devices that support I/O accesses. It's simpler this way.
2022-10-26 06:06:12 +00:00
pci_io_write_broadcast(offset, size, value);
return;
}
if (offset < 0x200000) {
this->config_addr = value;
return;
}
if (this->config_addr & 0x80) { // process only if bit E (enable) is set
int bus_num, dev_num, fun_num;
uint8_t reg_offs;
AccessDetails details;
PCIBase *device;
cfg_setup(offset, size, bus_num, dev_num, fun_num, reg_offs, details, device);
details.flags |= PCI_CONFIG_WRITE;
if (device) {
if (size == 4 && !details.offset) { // aligned DWORD writes -> fast path
device->pci_cfg_write(reg_offs, BYTESWAP_32(value), details);
return;
}
// otherwise perform necessary data transformations -> slow path
uint32_t old_val = details.size == 4 ? 0 : device->pci_cfg_read(reg_offs, details);
uint32_t new_val = pci_conv_wr_data(old_val, value, details);
device->pci_cfg_write(reg_offs, new_val, details);
Add PCI bridge and multi-function device support. Add PCI bridge and multi-function device support. Overview: - A multi-function device is two or more PCIDevices with the same device number but one device is function zero (as with currently implemented PCIDevices) and the other functions have function numbers between 1 and 7. The device number and function number are properties of the PCIDevice's parent PCIHost connection. - A PCIBridge is a PCIHost (it can connect child PCI devices) and a PCIDevice (it has config space, BARs, and expansion ROM). - A PCIDevice has Type 0 header. It has 6 BARs. - A PCIBridge has Type 1 header. It has 2 BARs. The config space registers beginning from offset 0x18 differ from those of a PCIDevice. Possible future modifications: - Add a PCICardBus class. It is a PCIHost. It has Type 2 header. It has one BAR. The first 20 bytes match Type 0 and Type 1 headers. These exist in New World Macs. They allow hot-plug of PCI devices. - Split base PCI registers (first 16 bytes) into a PCIBase class. Type 1 and 2 have two or one BAR but I think all 6 BARs belong in PCIBase class anyway. - Split PCIHost into two classes: Currently existing PCIHosts (Bandit, Grackle) are PCIHost and PCIRoot (they have the broadcast I/O requests functionality) while PCIBridge is PCIHost only - it can propagate I/O requests but does not originate the broadcast. - pci_register_mmio_region should maybe return a pointer to a region struct so that it can be used for unregistering or modifying the region's range. This may be useful for PCI bridges which have ranges that may constrain memory BARs of their downstream devices. PCIDevice - Moved expansion ROM BAR handling to a separate function pci_wr_exp_rom_bar so that it can be used by both PCI devices and PCI bridges which have the ROM BAR in different locations. It now supports unmapping expansion ROM. Also made exp_rom_bar not writable if there's no ROM. - Added num_bars field which specifies the number of valid BARs since Type 0, 1, and 2 headers have different number of BARs. - map_exp_rom_mem now properly unmaps expansion ROM (using new function unmap_exp_rom_mem) before mapping it again. - Added function set_multi_function which modifies hdr_type to indicate if a device has other functions. This is to be applied only to devices with function number 0. PCIHost - When attaching a PCI device, it will check if it's a multi-function device (there exists an attached function that is not zero) and adjust hdr_type of function 0 of the device accordingly. - Attached PCI bridges are added to a list of PCI bridges attached to the host. - Added pci_io_read_loop and pci_io_write_loop which loop through attached PCI devices to find one that will perform the action for the given I/O address without logging an error (since some other device might perform the action). - Added pci_io_read_broadcast and pci_io_write_broadcast which are used by a PCI root (bandit/grackle). They will log an error if the action is not performed. They should probably do a machine check exception to match real Power Macs. - pci_find_device (used by PCI root) will recursively find a PCIDevice for type 1 config register accesses. - Logging from PCIHost now includes the name of the PCIHost instead of just "PCIHost" because there can be multiple PCI hosts. PCIBridge - Sets num_bars to 2 and hdr_type to 1. - I/O ranges set in the config registers are handled correctly by pci_io_read and pci_io_write. - Memory ranges set in the config registers do not currently affect memory mmio regions. It is assumed that Open Firmware and the OS will set the ranges and BARs correctly to allow all BARs to be accessed fully. bandit, mpc106 - Bandit and Grackle now call pci_io_read_broadcast and pci_io_read_broadcast to pass I/O accesses to downstream PCI devices. - Chaos is modified to work like Bandit even though it will never have PCI bridges attached or devices that support I/O accesses. It's simpler this way.
2022-10-26 06:06:12 +00:00
return;
}
LOG_WRITE_NON_EXISTENT_PCI_DEVICE();
}
Add PCI bridge and multi-function device support. Add PCI bridge and multi-function device support. Overview: - A multi-function device is two or more PCIDevices with the same device number but one device is function zero (as with currently implemented PCIDevices) and the other functions have function numbers between 1 and 7. The device number and function number are properties of the PCIDevice's parent PCIHost connection. - A PCIBridge is a PCIHost (it can connect child PCI devices) and a PCIDevice (it has config space, BARs, and expansion ROM). - A PCIDevice has Type 0 header. It has 6 BARs. - A PCIBridge has Type 1 header. It has 2 BARs. The config space registers beginning from offset 0x18 differ from those of a PCIDevice. Possible future modifications: - Add a PCICardBus class. It is a PCIHost. It has Type 2 header. It has one BAR. The first 20 bytes match Type 0 and Type 1 headers. These exist in New World Macs. They allow hot-plug of PCI devices. - Split base PCI registers (first 16 bytes) into a PCIBase class. Type 1 and 2 have two or one BAR but I think all 6 BARs belong in PCIBase class anyway. - Split PCIHost into two classes: Currently existing PCIHosts (Bandit, Grackle) are PCIHost and PCIRoot (they have the broadcast I/O requests functionality) while PCIBridge is PCIHost only - it can propagate I/O requests but does not originate the broadcast. - pci_register_mmio_region should maybe return a pointer to a region struct so that it can be used for unregistering or modifying the region's range. This may be useful for PCI bridges which have ranges that may constrain memory BARs of their downstream devices. PCIDevice - Moved expansion ROM BAR handling to a separate function pci_wr_exp_rom_bar so that it can be used by both PCI devices and PCI bridges which have the ROM BAR in different locations. It now supports unmapping expansion ROM. Also made exp_rom_bar not writable if there's no ROM. - Added num_bars field which specifies the number of valid BARs since Type 0, 1, and 2 headers have different number of BARs. - map_exp_rom_mem now properly unmaps expansion ROM (using new function unmap_exp_rom_mem) before mapping it again. - Added function set_multi_function which modifies hdr_type to indicate if a device has other functions. This is to be applied only to devices with function number 0. PCIHost - When attaching a PCI device, it will check if it's a multi-function device (there exists an attached function that is not zero) and adjust hdr_type of function 0 of the device accordingly. - Attached PCI bridges are added to a list of PCI bridges attached to the host. - Added pci_io_read_loop and pci_io_write_loop which loop through attached PCI devices to find one that will perform the action for the given I/O address without logging an error (since some other device might perform the action). - Added pci_io_read_broadcast and pci_io_write_broadcast which are used by a PCI root (bandit/grackle). They will log an error if the action is not performed. They should probably do a machine check exception to match real Power Macs. - pci_find_device (used by PCI root) will recursively find a PCIDevice for type 1 config register accesses. - Logging from PCIHost now includes the name of the PCIHost instead of just "PCIHost" because there can be multiple PCI hosts. PCIBridge - Sets num_bars to 2 and hdr_type to 1. - I/O ranges set in the config registers are handled correctly by pci_io_read and pci_io_write. - Memory ranges set in the config registers do not currently affect memory mmio regions. It is assumed that Open Firmware and the OS will set the ranges and BARs correctly to allow all BARs to be accessed fully. bandit, mpc106 - Bandit and Grackle now call pci_io_read_broadcast and pci_io_read_broadcast to pass I/O accesses to downstream PCI devices. - Chaos is modified to work like Bandit even though it will never have PCI bridges attached or devices that support I/O accesses. It's simpler this way.
2022-10-26 06:06:12 +00:00
}
inline void MPC106::cfg_setup(uint32_t offset, int size, int &bus_num, int &dev_num,
int &fun_num, uint8_t &reg_offs, AccessDetails &details,
PCIBase *&device)
Add PCI bridge and multi-function device support. Add PCI bridge and multi-function device support. Overview: - A multi-function device is two or more PCIDevices with the same device number but one device is function zero (as with currently implemented PCIDevices) and the other functions have function numbers between 1 and 7. The device number and function number are properties of the PCIDevice's parent PCIHost connection. - A PCIBridge is a PCIHost (it can connect child PCI devices) and a PCIDevice (it has config space, BARs, and expansion ROM). - A PCIDevice has Type 0 header. It has 6 BARs. - A PCIBridge has Type 1 header. It has 2 BARs. The config space registers beginning from offset 0x18 differ from those of a PCIDevice. Possible future modifications: - Add a PCICardBus class. It is a PCIHost. It has Type 2 header. It has one BAR. The first 20 bytes match Type 0 and Type 1 headers. These exist in New World Macs. They allow hot-plug of PCI devices. - Split base PCI registers (first 16 bytes) into a PCIBase class. Type 1 and 2 have two or one BAR but I think all 6 BARs belong in PCIBase class anyway. - Split PCIHost into two classes: Currently existing PCIHosts (Bandit, Grackle) are PCIHost and PCIRoot (they have the broadcast I/O requests functionality) while PCIBridge is PCIHost only - it can propagate I/O requests but does not originate the broadcast. - pci_register_mmio_region should maybe return a pointer to a region struct so that it can be used for unregistering or modifying the region's range. This may be useful for PCI bridges which have ranges that may constrain memory BARs of their downstream devices. PCIDevice - Moved expansion ROM BAR handling to a separate function pci_wr_exp_rom_bar so that it can be used by both PCI devices and PCI bridges which have the ROM BAR in different locations. It now supports unmapping expansion ROM. Also made exp_rom_bar not writable if there's no ROM. - Added num_bars field which specifies the number of valid BARs since Type 0, 1, and 2 headers have different number of BARs. - map_exp_rom_mem now properly unmaps expansion ROM (using new function unmap_exp_rom_mem) before mapping it again. - Added function set_multi_function which modifies hdr_type to indicate if a device has other functions. This is to be applied only to devices with function number 0. PCIHost - When attaching a PCI device, it will check if it's a multi-function device (there exists an attached function that is not zero) and adjust hdr_type of function 0 of the device accordingly. - Attached PCI bridges are added to a list of PCI bridges attached to the host. - Added pci_io_read_loop and pci_io_write_loop which loop through attached PCI devices to find one that will perform the action for the given I/O address without logging an error (since some other device might perform the action). - Added pci_io_read_broadcast and pci_io_write_broadcast which are used by a PCI root (bandit/grackle). They will log an error if the action is not performed. They should probably do a machine check exception to match real Power Macs. - pci_find_device (used by PCI root) will recursively find a PCIDevice for type 1 config register accesses. - Logging from PCIHost now includes the name of the PCIHost instead of just "PCIHost" because there can be multiple PCI hosts. PCIBridge - Sets num_bars to 2 and hdr_type to 1. - I/O ranges set in the config registers are handled correctly by pci_io_read and pci_io_write. - Memory ranges set in the config registers do not currently affect memory mmio regions. It is assumed that Open Firmware and the OS will set the ranges and BARs correctly to allow all BARs to be accessed fully. bandit, mpc106 - Bandit and Grackle now call pci_io_read_broadcast and pci_io_read_broadcast to pass I/O accesses to downstream PCI devices. - Chaos is modified to work like Bandit even though it will never have PCI bridges attached or devices that support I/O accesses. It's simpler this way.
2022-10-26 06:06:12 +00:00
{
details.size = size;
details.offset = offset & 3;
Add PCI bridge and multi-function device support. Add PCI bridge and multi-function device support. Overview: - A multi-function device is two or more PCIDevices with the same device number but one device is function zero (as with currently implemented PCIDevices) and the other functions have function numbers between 1 and 7. The device number and function number are properties of the PCIDevice's parent PCIHost connection. - A PCIBridge is a PCIHost (it can connect child PCI devices) and a PCIDevice (it has config space, BARs, and expansion ROM). - A PCIDevice has Type 0 header. It has 6 BARs. - A PCIBridge has Type 1 header. It has 2 BARs. The config space registers beginning from offset 0x18 differ from those of a PCIDevice. Possible future modifications: - Add a PCICardBus class. It is a PCIHost. It has Type 2 header. It has one BAR. The first 20 bytes match Type 0 and Type 1 headers. These exist in New World Macs. They allow hot-plug of PCI devices. - Split base PCI registers (first 16 bytes) into a PCIBase class. Type 1 and 2 have two or one BAR but I think all 6 BARs belong in PCIBase class anyway. - Split PCIHost into two classes: Currently existing PCIHosts (Bandit, Grackle) are PCIHost and PCIRoot (they have the broadcast I/O requests functionality) while PCIBridge is PCIHost only - it can propagate I/O requests but does not originate the broadcast. - pci_register_mmio_region should maybe return a pointer to a region struct so that it can be used for unregistering or modifying the region's range. This may be useful for PCI bridges which have ranges that may constrain memory BARs of their downstream devices. PCIDevice - Moved expansion ROM BAR handling to a separate function pci_wr_exp_rom_bar so that it can be used by both PCI devices and PCI bridges which have the ROM BAR in different locations. It now supports unmapping expansion ROM. Also made exp_rom_bar not writable if there's no ROM. - Added num_bars field which specifies the number of valid BARs since Type 0, 1, and 2 headers have different number of BARs. - map_exp_rom_mem now properly unmaps expansion ROM (using new function unmap_exp_rom_mem) before mapping it again. - Added function set_multi_function which modifies hdr_type to indicate if a device has other functions. This is to be applied only to devices with function number 0. PCIHost - When attaching a PCI device, it will check if it's a multi-function device (there exists an attached function that is not zero) and adjust hdr_type of function 0 of the device accordingly. - Attached PCI bridges are added to a list of PCI bridges attached to the host. - Added pci_io_read_loop and pci_io_write_loop which loop through attached PCI devices to find one that will perform the action for the given I/O address without logging an error (since some other device might perform the action). - Added pci_io_read_broadcast and pci_io_write_broadcast which are used by a PCI root (bandit/grackle). They will log an error if the action is not performed. They should probably do a machine check exception to match real Power Macs. - pci_find_device (used by PCI root) will recursively find a PCIDevice for type 1 config register accesses. - Logging from PCIHost now includes the name of the PCIHost instead of just "PCIHost" because there can be multiple PCI hosts. PCIBridge - Sets num_bars to 2 and hdr_type to 1. - I/O ranges set in the config registers are handled correctly by pci_io_read and pci_io_write. - Memory ranges set in the config registers do not currently affect memory mmio regions. It is assumed that Open Firmware and the OS will set the ranges and BARs correctly to allow all BARs to be accessed fully. bandit, mpc106 - Bandit and Grackle now call pci_io_read_broadcast and pci_io_read_broadcast to pass I/O accesses to downstream PCI devices. - Chaos is modified to work like Bandit even though it will never have PCI bridges attached or devices that support I/O accesses. It's simpler this way.
2022-10-26 06:06:12 +00:00
bus_num = (this->config_addr >> 8) & 0xFF;
dev_num = (this->config_addr >> 19) & 0x1F;
fun_num = (this->config_addr >> 16) & 0x07;
reg_offs = (this->config_addr >> 24) & 0xFC;
if (bus_num) {
details.flags = PCI_CONFIG_TYPE_1;
device = pci_find_device(bus_num, dev_num, fun_num);
}
else {
details.flags = PCI_CONFIG_TYPE_0;
device = pci_find_device(dev_num, fun_num);
}
}
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 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. pcidevice: - The logging macros should be used to handle all config register access logging. - Unaligned PCI config register accesses will be output as ERROR instead of WARNING. - The logging macros include the offset and size. They also include the value for named registers or for writes. - Added MMIODevice read and write methods so that PCIDevice is not abstract if a PCIDevice doesn't override the read and write method since some PCIDevices don't have MMIO. pcihost: - Added pci_find_device stub for handling PCI bridges in future commit. bandit and mpc106: - PCI host controllers will handle all PCI config access alignment and sizing. A PCIDevice will always access config registers as 32 bits on a 4 byte boundary. The AccessDetails passed to a PCIDevice config read or write method is there only for logging purposes. bandit: - Common MMIO code is moved to new BanditHost class so both Bandit and Chaos can use it. PCI related code is moved to new BanditPCI class. - Simplify IDSEL to/from PCI device number conversion by removing the shift or subtract. - Remove BANDIT_ID_SEL check. The IDSEL conversion to PCI device number can find the bandit PCI device. - For logging, make best guess of PCI device number from invalid IDSEL - the result is always reasonable for device 0x00 to 0x0A when accessing config register 0x00 (as one would do when scanning for PCI devices like lspci does). mpc106: - Common config space code is put in cfg_setup. It handles extracting the offset. - Added code to log access to unimplemented config registers of grackle. - Don't call setup_ram when writing to config registers that setup_ram doesn't use. - 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. atirage: - The changes correctly place user_cfg at byte 0x40 instead of 0x43 and writes the correct byte depending on size and offset.
2022-09-02 10:32:28 +00:00
uint32_t MPC106::pci_cfg_read(uint32_t reg_offs, AccessDetails &details) {
if (reg_offs < 64) {
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 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. pcidevice: - The logging macros should be used to handle all config register access logging. - Unaligned PCI config register accesses will be output as ERROR instead of WARNING. - The logging macros include the offset and size. They also include the value for named registers or for writes. - Added MMIODevice read and write methods so that PCIDevice is not abstract if a PCIDevice doesn't override the read and write method since some PCIDevices don't have MMIO. pcihost: - Added pci_find_device stub for handling PCI bridges in future commit. bandit and mpc106: - PCI host controllers will handle all PCI config access alignment and sizing. A PCIDevice will always access config registers as 32 bits on a 4 byte boundary. The AccessDetails passed to a PCIDevice config read or write method is there only for logging purposes. bandit: - Common MMIO code is moved to new BanditHost class so both Bandit and Chaos can use it. PCI related code is moved to new BanditPCI class. - Simplify IDSEL to/from PCI device number conversion by removing the shift or subtract. - Remove BANDIT_ID_SEL check. The IDSEL conversion to PCI device number can find the bandit PCI device. - For logging, make best guess of PCI device number from invalid IDSEL - the result is always reasonable for device 0x00 to 0x0A when accessing config register 0x00 (as one would do when scanning for PCI devices like lspci does). mpc106: - Common config space code is put in cfg_setup. It handles extracting the offset. - Added code to log access to unimplemented config registers of grackle. - Don't call setup_ram when writing to config registers that setup_ram doesn't use. - 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. atirage: - The changes correctly place user_cfg at byte 0x40 instead of 0x43 and writes the correct byte depending on size and offset.
2022-09-02 10:32:28 +00:00
return PCIDevice::pci_cfg_read(reg_offs, details);
}
switch (reg_offs) {
case GrackleReg::CFG10:
return 0;
case GrackleReg::PMCR1:
return (this->odcr << 24) | (this->pmcr2 << 16) | this->pmcr1;
case GrackleReg::MSAR1:
case GrackleReg::MSAR2:
return this->mem_start[(reg_offs >> 2) & 1];
case GrackleReg::EMSAR1:
case GrackleReg::EMSAR2:
return this->ext_mem_start[(reg_offs >> 2) & 1];
case GrackleReg::MEAR1:
case GrackleReg::MEAR2:
return this->mem_end[(reg_offs >> 2) & 1];
case GrackleReg::EMEAR1:
case GrackleReg::EMEAR2:
return this->ext_mem_end[(reg_offs >> 2) & 1];
case GrackleReg::MBER:
return this->mem_bank_en;
case GrackleReg::PICR1:
return this->picr1;
case GrackleReg::PICR2:
return this->picr2;
case GrackleReg::MCCR1:
return this->mccr1;
case GrackleReg::MCCR2:
return this->mccr2;
case GrackleReg::MCCR3:
return this->mccr3;
case GrackleReg::MCCR4:
return this->mccr4;
default:
LOG_READ_UNIMPLEMENTED_CONFIG_REGISTER();
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 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. pcidevice: - The logging macros should be used to handle all config register access logging. - Unaligned PCI config register accesses will be output as ERROR instead of WARNING. - The logging macros include the offset and size. They also include the value for named registers or for writes. - Added MMIODevice read and write methods so that PCIDevice is not abstract if a PCIDevice doesn't override the read and write method since some PCIDevices don't have MMIO. pcihost: - Added pci_find_device stub for handling PCI bridges in future commit. bandit and mpc106: - PCI host controllers will handle all PCI config access alignment and sizing. A PCIDevice will always access config registers as 32 bits on a 4 byte boundary. The AccessDetails passed to a PCIDevice config read or write method is there only for logging purposes. bandit: - Common MMIO code is moved to new BanditHost class so both Bandit and Chaos can use it. PCI related code is moved to new BanditPCI class. - Simplify IDSEL to/from PCI device number conversion by removing the shift or subtract. - Remove BANDIT_ID_SEL check. The IDSEL conversion to PCI device number can find the bandit PCI device. - For logging, make best guess of PCI device number from invalid IDSEL - the result is always reasonable for device 0x00 to 0x0A when accessing config register 0x00 (as one would do when scanning for PCI devices like lspci does). mpc106: - Common config space code is put in cfg_setup. It handles extracting the offset. - Added code to log access to unimplemented config registers of grackle. - Don't call setup_ram when writing to config registers that setup_ram doesn't use. - 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. atirage: - The changes correctly place user_cfg at byte 0x40 instead of 0x43 and writes the correct byte depending on size and offset.
2022-09-02 10:32:28 +00:00
}
return 0; // PCI Spec §6.1
}
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 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. pcidevice: - The logging macros should be used to handle all config register access logging. - Unaligned PCI config register accesses will be output as ERROR instead of WARNING. - The logging macros include the offset and size. They also include the value for named registers or for writes. - Added MMIODevice read and write methods so that PCIDevice is not abstract if a PCIDevice doesn't override the read and write method since some PCIDevices don't have MMIO. pcihost: - Added pci_find_device stub for handling PCI bridges in future commit. bandit and mpc106: - PCI host controllers will handle all PCI config access alignment and sizing. A PCIDevice will always access config registers as 32 bits on a 4 byte boundary. The AccessDetails passed to a PCIDevice config read or write method is there only for logging purposes. bandit: - Common MMIO code is moved to new BanditHost class so both Bandit and Chaos can use it. PCI related code is moved to new BanditPCI class. - Simplify IDSEL to/from PCI device number conversion by removing the shift or subtract. - Remove BANDIT_ID_SEL check. The IDSEL conversion to PCI device number can find the bandit PCI device. - For logging, make best guess of PCI device number from invalid IDSEL - the result is always reasonable for device 0x00 to 0x0A when accessing config register 0x00 (as one would do when scanning for PCI devices like lspci does). mpc106: - Common config space code is put in cfg_setup. It handles extracting the offset. - Added code to log access to unimplemented config registers of grackle. - Don't call setup_ram when writing to config registers that setup_ram doesn't use. - 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. atirage: - The changes correctly place user_cfg at byte 0x40 instead of 0x43 and writes the correct byte depending on size and offset.
2022-09-02 10:32:28 +00:00
void MPC106::pci_cfg_write(uint32_t reg_offs, uint32_t value, AccessDetails &details) {
if (reg_offs < 64) {
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 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. pcidevice: - The logging macros should be used to handle all config register access logging. - Unaligned PCI config register accesses will be output as ERROR instead of WARNING. - The logging macros include the offset and size. They also include the value for named registers or for writes. - Added MMIODevice read and write methods so that PCIDevice is not abstract if a PCIDevice doesn't override the read and write method since some PCIDevices don't have MMIO. pcihost: - Added pci_find_device stub for handling PCI bridges in future commit. bandit and mpc106: - PCI host controllers will handle all PCI config access alignment and sizing. A PCIDevice will always access config registers as 32 bits on a 4 byte boundary. The AccessDetails passed to a PCIDevice config read or write method is there only for logging purposes. bandit: - Common MMIO code is moved to new BanditHost class so both Bandit and Chaos can use it. PCI related code is moved to new BanditPCI class. - Simplify IDSEL to/from PCI device number conversion by removing the shift or subtract. - Remove BANDIT_ID_SEL check. The IDSEL conversion to PCI device number can find the bandit PCI device. - For logging, make best guess of PCI device number from invalid IDSEL - the result is always reasonable for device 0x00 to 0x0A when accessing config register 0x00 (as one would do when scanning for PCI devices like lspci does). mpc106: - Common config space code is put in cfg_setup. It handles extracting the offset. - Added code to log access to unimplemented config registers of grackle. - Don't call setup_ram when writing to config registers that setup_ram doesn't use. - 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. atirage: - The changes correctly place user_cfg at byte 0x40 instead of 0x43 and writes the correct byte depending on size and offset.
2022-09-02 10:32:28 +00:00
PCIDevice::pci_cfg_write(reg_offs, value, details);
return;
}
switch (reg_offs) {
case GrackleReg::CFG10:
// Open Firmware writes 0 to subordinate bus # - we don't care
break;
case GrackleReg::PMCR1:
this->pmcr1 = value & 0xFFFFU;
this->pmcr2 = (value >> 16) & 0xFF;
this->odcr = value >> 24;
break;
case GrackleReg::MSAR1:
case GrackleReg::MSAR2:
this->mem_start[(reg_offs >> 2) & 1] = value;
break;
case GrackleReg::EMSAR1:
case GrackleReg::EMSAR2:
this->ext_mem_start[(reg_offs >> 2) & 1] = value;
break;
case GrackleReg::MEAR1:
case GrackleReg::MEAR2:
this->mem_end[(reg_offs >> 2) & 1] = value;
break;
case GrackleReg::EMEAR1:
case GrackleReg::EMEAR2:
this->ext_mem_end[(reg_offs >> 2) & 1] = value;
break;
case GrackleReg::MBER:
this->mem_bank_en = value & 0xFFU;
break;
case GrackleReg::PICR1:
this->picr1 = value;
break;
case GrackleReg::PICR2:
this->picr2 = value;
break;
case GrackleReg::MCCR1:
if ((value ^ this->mccr1) & MEMGO) {
if (value & MEMGO)
setup_ram();
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 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. pcidevice: - The logging macros should be used to handle all config register access logging. - Unaligned PCI config register accesses will be output as ERROR instead of WARNING. - The logging macros include the offset and size. They also include the value for named registers or for writes. - Added MMIODevice read and write methods so that PCIDevice is not abstract if a PCIDevice doesn't override the read and write method since some PCIDevices don't have MMIO. pcihost: - Added pci_find_device stub for handling PCI bridges in future commit. bandit and mpc106: - PCI host controllers will handle all PCI config access alignment and sizing. A PCIDevice will always access config registers as 32 bits on a 4 byte boundary. The AccessDetails passed to a PCIDevice config read or write method is there only for logging purposes. bandit: - Common MMIO code is moved to new BanditHost class so both Bandit and Chaos can use it. PCI related code is moved to new BanditPCI class. - Simplify IDSEL to/from PCI device number conversion by removing the shift or subtract. - Remove BANDIT_ID_SEL check. The IDSEL conversion to PCI device number can find the bandit PCI device. - For logging, make best guess of PCI device number from invalid IDSEL - the result is always reasonable for device 0x00 to 0x0A when accessing config register 0x00 (as one would do when scanning for PCI devices like lspci does). mpc106: - Common config space code is put in cfg_setup. It handles extracting the offset. - Added code to log access to unimplemented config registers of grackle. - Don't call setup_ram when writing to config registers that setup_ram doesn't use. - 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. atirage: - The changes correctly place user_cfg at byte 0x40 instead of 0x43 and writes the correct byte depending on size and offset.
2022-09-02 10:32:28 +00:00
}
this->mccr1 = value;
break;
case GrackleReg::MCCR2:
this->mccr2 = value;
break;
case GrackleReg::MCCR3:
this->mccr3 = value;
break;
case GrackleReg::MCCR4:
this->mccr4 = value;
break;
default:
LOG_WRITE_UNIMPLEMENTED_CONFIG_REGISTER();
}
}
2019-08-23 19:30:30 +00:00
2020-05-12 18:55:45 +00:00
void MPC106::setup_ram() {
uint32_t bank_start[8];
uint32_t bank_end[8];
int bank_order[8];
int bank_count = 0;
int region_count = 0;
// get non-empty banks
for (int bank = 0; bank < 8; bank++) {
if (this->mem_bank_en & (1 << bank)) {
int b = (bank >= 4);
bank_start[bank_count] = (((ext_mem_start[b] >> bank * 8) & 3) << 28) |
(((mem_start[b] >> bank * 8) & 0xFF) << 20);
bank_end[bank_count] = (((ext_mem_end[b] >> bank * 8) & 3) << 28) |
(((mem_end[b] >> bank * 8) & 0xFF) << 20) | 0xFFFFFUL;
bank_order[bank_count] = bank_count;
bank_count++;
}
}
// sort banks by start address
for (int i = 0; i < bank_count; i++) {
for (int j = i + 1; j < bank_count; j++) {
if (bank_start[bank_order[j]] < bank_start[bank_order[i]]) {
int temp = bank_order[i];
bank_order[i] = bank_order[j];
bank_order[j] = temp;
}
}
}
// squash adjacent banks into memory regions
for (int i = 0; i < bank_count; i++) {
if (region_count > 0 && bank_start[bank_order[i]] == bank_end[bank_order[region_count - 1]] + 1)
bank_end[bank_order[region_count - 1]] = bank_end[bank_order[i]];
else {
bank_order[region_count] = bank_order[i];
region_count++;
}
}
// allocate memory regions
for (int i = 0; i < region_count; i++) {
uint32_t region_size = bank_end[bank_order[i]] - bank_start[bank_order[i]] + 1;
if (!this->add_ram_region(bank_start[bank_order[i]], region_size)) {
LOG_F(WARNING, "Grackle: %d MB RAM allocation 0x%X..0x%X failed (maybe already exists?)",
region_size / (1024 * 1024), bank_start[bank_order[i]], bank_end[bank_order[i]]
);
}
}
}
static const PropMap Grackle_Properties = {
{"pci_PERCH",
new StrProperty("")},
{"pci_A1",
new StrProperty("")},
{"pci_B1",
new StrProperty("")},
{"pci_C1",
new StrProperty("")},
2023-11-25 12:04:25 +00:00
{"pci_GPU",
new StrProperty("")},
};
static const DeviceDescription Grackle_Descriptor = {
MPC106::create, {}, Grackle_Properties
};
REGISTER_DEVICE(Grackle, Grackle_Descriptor);