Date: Sun, 14 Apr 2019 19:44:48 -0700 From: Mark Millard <marklmi@yahoo.com> To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, Justin Hibbits <chmeeedalf@gmail.com> Subject: Re: A usefdt boot-mode problem: openfirmware->fdt translation use vs. some existing powerpc64 or powerpc FreeBSD code, interrupt-parent examples shown Message-ID: <125F273F-6F0B-49BB-87AE-8B94DE621407@yahoo.com> In-Reply-To: <B9138DF6-72B5-44AB-B7CD-F04F6D40B555@yahoo.com> References: <1E438A62-1B2F-4A1D-9537-B1135CE1C89D@yahoo.com> <B9138DF6-72B5-44AB-B7CD-F04F6D40B555@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[I tried adjusting one thing that I'd listed and it let the PowerMac7.2 get farther into the boot sequence without messing up the PowerMac11,2 or PowerMac3,6 booting.] On 2019-Apr-13, at 23:21, Mark Millard <marklmi@yahoo.com> wrote: > [I added some debug output that shows odd mixes of openfirmware > vs. fdt node ids. This notes an example of what it shows.] >=20 > On 2019-Apr-13, at 19:44, Mark Millard <marklmi at yahoo.com> wrote: >=20 >> I'm going to use interrupt-parent as an example of the type of issue. >>=20 >> In the below ofwdump -ap diff extractions: >>=20 >> - is from without usefdt mode >> + is from with usefdt mode >>=20 >> - Node 0xff963f60: interrupt-controller >> + Node 0x2767c: interrupt-controller >> + phandle: >> + ff 96 3f 60=20 >>=20 >> Note that the Node id changes but a phandle is added hiolding the >> Node id that openfirmware originally had. >>=20 >> Picking an example where interrupt-parent is in use: >>=20 >>=20 >> - Node 0xff964428: extint-gpio1 >> + Node 0x27800: extint-gpio1 >> + phandle: >> + ff 96 44 28=20 >> . . . >> interrupt-parent: >> ff 96 3f 60=20 >> . . . >>=20 >> (openfirmware and fdt are no different for the value >> contained in the interrupt-parent property: it is the >> openfirmware node id, not the FDT one.) >>=20 >> So, for fdt use, comparison to the phandle property value is >> is how to find/match this interrupt-controller via a >> interrupt-parent. Direct use of 0xff963f60 as a node id >> is inappropriate for usefdt mode. >>=20 >> The above is very general and I did not try to match the >> specific nodes to ones the code below would be using, beyond >> initially sticking to interrupt-parent types of references. >>=20 >> I find there is example code around that makes no prevision >> for finding the interrupt-parent via a phandle comparison. >>=20 >> An example is in unin_chip_add_intr : >>=20 >> if (OF_getprop(devnode, "interrupt-parent", &iparent, = sizeof(iparent)) >> <=3D 0) >> panic("Interrupt but no interrupt parent!\n"); >>=20 >> if (OF_searchprop(iparent, "#interrupt-cells", &icells, = sizeof(icells)) >> <=3D 0) >> icells =3D 1; >>=20 >> For usefdt mode iparent's value is an openfirmware node id, not a fdt = one. >> It is the phandle property value that would match. >>=20 >> Another is in unin_chip_attach: >>=20 >> if (OF_getprop(child, "interrupt-parent", = &iparent, >> sizeof(iparent)) <=3D 0) { >> . . . >> } >> /* Add an interrupt number 0 to the parent. */ >> irq =3D MAP_IRQ(iparent, 0); >>=20 >> (It appears MAP_IRQ uses powerpc_get_irq and I do not see a stage >> that can involve the phandle property for matching.) >>=20 >> Another may be macgpio_attach: >>=20 >> OF_searchencprop(child, "interrupt-parent", = &iparent, >> sizeof(iparent)); >> resource_list_add(&dinfo->mdi_resources, = SYS_RES_IRQ, >> 0, MAP_IRQ(iparent, irq[0]), >> MAP_IRQ(iparent, irq[0]), 1); >>=20 >> Other's besides interrupt-parent . . . >>=20 >> There are some gpio-parent properties but I did not find code using >> them. (I may have just missed such.) I quit looking for code use >> but did find more types of references in the fdt itself . . . >>=20 >> l2-cache in, say, a PowerPC,G4 for usefdt mode is another type of >> example. >>=20 >> platform-enableclock and platform-disableclock seem to be be >> examples (references back to uni-n in what I looked at, but >> having the openfirmwire node id, not the fdt one). >>=20 >> I may not have found all the example types of "needs phandle property >> value comparisons instead of direct node id use for usefdt mode". >>=20 >> This is all from a 2-socket/1-core-each G4 PowerMac3,6 example. >>=20 >> [Even any G5 example would be via 32-bit pweorpc FreeBSD. This is >> because (for a long time now) use of ofwdump -ap crashes powerpc64 >> PowerMac's. But I've not gone through a G5 example (yet?).] >=20 > In powerpc_register_pic I added the printf shown below: >=20 > powerpc_register_pic(device_t dev, uint32_t node, u_int irqs, u_int = ipis, > u_int atpic) > . . . > for (idx =3D 0; idx < npics; idx++) { > p =3D &piclist[idx]; > printf("idx,npics: p->node, node, p->dev, dev: %u,%u: = %x, %x, %x, %x\n",idx,npics,p->node,node,p->dev,dev); > if (p->node !=3D node) > continue; > if (node !=3D 0 || p->dev =3D=3D dev) > break; > } > p =3D &piclist[idx]; > p->dev =3D dev; > p->node =3D node; > p->irqs =3D irqs; > p->ipis =3D ipis; > if (idx =3D=3D npics) { > #ifdef DEV_ISA > p->base =3D (atpic) ? 0 : nirqs; > #else > p->base =3D nirqs; > #endif > irq =3D p->base + irqs + ipis; > nirqs =3D MAX(nirqs, irq); > npics++; > } >=20 >=20 > It shows for usefdt mode booting of a 2-socket/1-core-each G5 = PowerMac11,2: >=20 > idx,npics: p->node, node, p->dev, dev: 0,1: ff981488, 4e88, 0, 1e95600 >=20 > So piclist[0].node has a value for/from openfirmware instead of fdt. > But the caller supplied a fdt node value, not an openfirmware one. >=20 > The loop will not match the two, even if the fdt node has a phandle > property that lists the 0xff981488 value. The later code would then > add a separate entry in piclist with the fdt node id and increment > npics. >=20 > Looks to me like the intent for usefdt mode was likely to not have any > openfirmware id value in any piclist[?].node field. (True?) [Note: The above guess work for piclist[?].node seems to be wrong.] > This sort of thing appears to be involved in why usefdt mode crashes > on the example 2-socket/1-core-each G5 PowerMac7,2 . >=20 > The code directly putting the openfirmware value (that it was > given) into the piclist is: >=20 > powerpc_get_irq(uint32_t node, u_int pin) > . . . > piclist[idx].dev =3D NULL; > piclist[idx].node =3D node; > piclist[idx].irqs =3D 124; > piclist[idx].ipis =3D 4; > piclist[idx].base =3D nirqs; > nirqs +=3D (1 << 25); > npics++; > . . . >=20 > This goes back to MAP_IRQ use with openfirmware node id values. I adjusted to be using the following in unin_chip_add_intr : # svnlite diff /usr/src/sys/powerpc/powermac/uninorth.c Index: /usr/src/sys/powerpc/powermac/uninorth.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/powerpc/powermac/uninorth.c (revision 345758) +++ /usr/src/sys/powerpc/powermac/uninorth.c (working copy) @@ -181,7 +181,7 @@ <=3D 0) panic("Interrupt but no interrupt parent!\n"); =20 - if (OF_searchprop(iparent, "#interrupt-cells", &icells, = sizeof(icells)) + if (OF_searchprop(OF_node_from_xref(iparent), = "#interrupt-cells", &icells, sizeof(icells)) <=3D 0) icells =3D 1; =20 This get farther into the boot sequence: subsystem a800000 boot_run_interrupt_driven_config_hooks(0)... max66900: 2 sensors = detected. max66901: 2 sensors detected. ugen1.1: <Apple OHCI root HUB> at usbus1 . . . ada0 at ata2 bus 0 scbus2 target 0 lun 0 ada0: <OWC Mercury Electra 3G SSD 560ABBF0> ATA8-ACS SATA 2.x device ada0: Serial Number OW140507AS1363504 ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 512bytes) ada0: 114473MB (234441648 512 byte sectors) cd0 at ata0 bus 0 scbus0 target 0 lun 0 cd0: <PIONEER DVD-RW DVR-111D 1.23> Removable CD-ROM SCSI device cd0: Serial Number FFDP051360WL cd0: 66.700MB/s transfers (UDMA4, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present But boot_run_interrupt_driven_config_hooks never reports "done.". =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?125F273F-6F0B-49BB-87AE-8B94DE621407>