On Sat, 20 Feb 2016, Programmingkid wrote:
On Feb 20, 2016, at 10:51 AM, Mark Cave-Ayland wrote:
This is required to enable the ports to be detected by OS X.
Signed-off-by: Mark Cave-Ayland mark.cave-ayland@ilande.co.uk
openbios-devel/drivers/escc.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/openbios-devel/drivers/escc.c b/openbios-devel/drivers/escc.c index f194957..bb7b34c 100644 --- a/openbios-devel/drivers/escc.c +++ b/openbios-devel/drivers/escc.c @@ -466,6 +466,8 @@ escc_add_channel(const char *path, const char *node, phys_addr_t addr, NEWWORLD(set_property(dnode, "interrupts", (char *)&props, 3 * sizeof(cell)));
set_int_property(dnode, "slot-names", 0);
device_end();
uart_init_line((unsigned char*)addr + offset + reg_offsets[legacy][index][0],
-- 1.7.10.4
Sorry but this logical change to the slot-names property does not make Mac OS X happy. The driver will just assume there is more than just a 32-bit number set to this property.
http://www.opensource.apple.com/source/AppleSCCSerial/AppleSCCSerial-126.4.0... This is the source code for the driver Mac OS X uses to read the slot-names property.
tmpName = (char *) s->getBytesNoCopy() + sizeof(UInt32);
The s->getBytesNoCopy() code here is what is used to get the address of the start of the slot-names property's value. The " + sizeof(UInt32); " code is used to just skip over the beginning integer part of the property so that the driver can read the string part.
But if I'm reading it right (I assume this is the AppleSCCSerial::setPortName method we are talking about) this code will not be reached at all because first it will do
UInt32 *nWords = (UInt32*)s->getBytesNoCopy();
and find that no names are specified so the code you've quoted will be skipped as it is enclosed within if (*nWords > 0) { }
Instead it will move on to the last part with the comment saying that for PowerMacX,X ch-a is assumed to be the modem port and ch-b is nothing but even that is only true for PowerMac1,1 so for PowerMac3,1 it will use "none" or "serial" if some debug key is set as default values which may be OK.
In a perfect world the driver for Mac OS 9 and X would just see the zero and not bother trying to use the serial port.
I think it sees the 0 and does not try to get a name from this property and just use some defaults instead as noted above. I'm not sure how does this influence trying to use a modem or something else on the port though.
But unfortunately we don't have drivers that do something so logical. I did submit a patch that sets this property to this: 1 Modem
Why do you think that claiming to have a modem we don't emulate is better than claiming we have an empty port which is what we actually emulate? I think saying we have a modem is more likely to make it try to access it and get an error due to missing emulation than otherwise.
This is the value on real hardware. It also allows the Mac OS X driver to continue past where it would usually fail.
According to device trees I've posted before I've seen both empty slot-names and one saying modem on real hardware so I think both could be correct. I don't know it the modem was removable maybe if it was disabled or removed the slot-name property was empty or the modem was only present on PowerMac1,1 as the driver code suggests.
In any case I was wondering if setting this property to modem just makes it take a detour and try to access the modem and fail before reaching the point it crashes normally so if we emulated a modem we would eventually get to the same crash, only later.
The next thing to fix I would guess is adding dma support to the escc.c file.
It seems more likely to me that this is the reason it is not working now and if this is implemented we may not need the modem slot-name.
Regards, BALATON Zoltan