On 15/04/16 11:09, Mark Cave-Ayland wrote:
This fixes an intermittent panic in the AppleSCCSerial module for MacOS 10.2 and the g3beige machine during initialisation as the module tries to write to the on-chip registers at 0x130XX rather than calculating the correct address derived from the parent PCI node.
As described in the IEEE-1275 specification: if a "ranges" property exists but has a zero-length property value, the child address space is identical to the parent address space.
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 5fa3139..1990e79 100644 --- a/openbios-devel/drivers/escc.c +++ b/openbios-devel/drivers/escc.c @@ -514,6 +514,7 @@ escc_init(const char *path, phys_addr_t addr) set_property(dnode, "device_type", "escc", strlen("escc") + 1); set_property(dnode, "compatible", "escc\0CHRP,es0", 14);
set_property(dnode, "ranges", "", 0);
fword("finish-device");
@@ -541,6 +542,7 @@ escc_init(const char *path, phys_addr_t addr) set_property(dnode, "device_type", "escc-legacy", strlen("escc-legacy") + 1); set_property(dnode, "compatible", "chrp,es1", 9);
set_property(dnode, "ranges", "", 0);
fword("finish-device");
Note that this fixes a regression with current QEMU git master for g3beige and MacOS 10.2, so unless I hear otherwise then I'm intending to commit this later today and send an upstream pull request in time for the 2.6 release.
ATB,
Mark.