It might not be an error - usually it just means that it was already allocated so demote this message to a warning.
Related memory allocation changes:
- Added find_range_exact which searches for an allocation that exactly matches a range.
- Added find_range_contains which searches for an allocation that is completely contained within a range.
- Added find_range_overlaps which searches for an allocation that overlaps any part of a range.
- Added is_range_free which is similar to the above three. It returns false if any allocated range overlaps a range. It reports the regions that it overlaps.
- Fix add_mem_region and add_memio_region so that they don't just check the first byte and last byte.
- Memory allocation logging should include the range (first byte..last byte) and device if possible.
- Log memory allocations.
First, remove name override for subclasses of HWComponent (Chaos and ScsiBus) because HWComponent has its own name field.
HWComponent name should be set as early as possible in the constructor so it can be used in log messages.
PCIDevice should set name of HWComponent (through MMIODevice) in its constructor, using the name that is given to its constructor.
For Bandit and Grackle, they don't need to set the HWComponent name since its PCIDevice constructor will now do it.
Chaos is not a PCIDevice so it should set the MMIODevice name itself.
Why does PCIDevice have a name that is separate from the HWComponent name?
BAR 0 exists on a real Power Mac 8600 and the dingusppc 7500.
On a Power Mac 8600, the initial value is 0x84000003. In Open Firmware, you can write to all bits of the BAR and read the value back except the 2 least significant bits are always %11. Bit 0 indicates I/O space. Bit 1 is reserved and should be zero so maybe this is not a real I/O space BAR. 0x8400000 is written to the BAR by Open Firmware. It doesn't look like a normal I/O address which are usually 16 bits.
On the emulated 7500, 0x02000000 is written to the BAR by Open Firmware sometime during probe-all. The BAR did not behave as it does in the Power Mac 8600. This commit fixes that.
Two questions remain:
1) Which fcode writes to the BAR? Is it the probe fcode or is it the control fcode? There's no config-_! in the control fcode.
2) What is the purpose of the BAR? Writing to it can cause a hang. The testbits code below seems to succeed - it restores the original value after reading the result of testing each bit and before displaying the result. The values shown for the MSB (0x84 on the 8600 and 0x02 on the 7500) could be three flag bits.
```
dev vci0
: testbits { adr ; org }
cr
adr config-l@ dup -> org ." original : " 8 u.r cr
20 0 do
1 1f i - << dup 8 u.r ." : "
adr config-l!
adr config-l@
org adr config-l!
8 u.r cr
loop
;
15810 testbits \ 15810 is the address of the BAR on the emulated 7500.
```
Usually bit 1 of I/O BARs is 0 since it is reserved, but control has an I/O BAR where this bit is set.
bar_cfg is used to determine the default values of the least significant bits (2 bits for I/O BARs and 4 bits for Memory BARs).
The upper bits of bar_cfg determine which bits can be set and also determines the size of the BAR.
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`
The bits that can be set are the enable bit (bit 0) plus the bits represented by exp_bar_cfg which is determined by the size of the ROM which is calculated to be a power of 2 and a minimum of 2K.
