[OpenBIOS] [PATCH 4/6] escc.c: add empty slot-names property to serial ports

[Mark Cave-Ayland]

On 20/02/16 16:17, 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 at 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/PPCSerialPort.cpp
> 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. 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. 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
> 
> This is the value on real hardware. It also allows the Mac OS X driver to continue past where it would usually fail. The next thing to fix I would guess is adding dma support to the escc.c file. 

So my understanding of this was that failure here was enough to prevent
OS X from booting completely, or have I misunderstood?

I've just discovered a couple of extra fixes so expect a v2 fairly soon.
If you could rebase against that version and confirm that OS X can still
boot, it may be that we can still apply it in time for freeze.


ATB,

Mark.