OpenBIOS January 2013

openbios@openbios.org

14 participants
55 discussions

Re: [OpenBIOS] G3Beige OpenFirmware Tree?
by Mark Cave-Ayland 26 Jan '13

26 Jan '13

On 25/01/13 20:54, Artyom Tarasenko wrote: >> Thanks for doing this. So I've had a play with PearPC and I can make the >> CMD646ATA fail during its start method similar to the way that QEMU does by >> commenting out the IDE interface IRQ entry from the "interrupt-map" >> property. This seems to support my theory that the problem is related to >> interrupt mapping. > > Looks very similar to sparc64/sun4u problems I struggled ~ a half a year ago. Great - thanks for the insight! >> Now AIUI g3beige is an "Old World" Mac and so the interrupt information >> should be held in the "AAPL,interrupts" property. I've verified that both >> QEMU and OpenBIOS calculate the irq_line in the same way (based upon device >> id), however I do see that some of the "AAPL,interrupts" values contain more >> than one integer. I wonder what this is supposed to represent? > > Could it be that the irq line is wired to the interrupt controller not > as a PCI irq line? Similarly to the sun4u machines? > Have you looked in the Linux/PPC cmd646 driver for the insights? I've checked in the QEMU/OpenBIOS source that the PCI irq_line is set correctly, and that does go through a Grackle <-> PCI IRQ mapping function so I would think it is okay. Aside from ProgrammingKid's comments, AFAICT from my test images here the Linux CMD64x driver appears to be working okay - at least the driver loads and manages to probe the CDROM correctly. ATB, Mark.

2 1

[PATCH] SPARC32 : Clear FP register
by Olivier DANET 26 Jan '13

26 Jan '13

The Frame Pointer register is used in "__switch_context_nosave" (switch.S) which is called at the end of the startup sequence (entry.S). This register should be initialized before use. (The SparcV8 standard states, page 75 : "Supervisor software may not assume that any particular processor or memory state, except for the PSR’s ET and S bits, has been initialized after a reset trap." diff a/openbios-devel/arch/sparc32/entry.S b/openbios-devel/arch/sparc32/entry.S --- a/openbios-devel/arch/sparc32/entry.S +++ b/openbios-devel/arch/sparc32/entry.S @@ -452,6 +452,7 @@ highmem: wr %g3, PSR_ET, %psr WRITE_PAUSE + set 0, %fp call __switch_context_nosave nop Signed-off-by: Olivier DANET <odanet(a)caramail.com>

2 1

[PATCH] SPARC32 : WIM register update delay
by Olivier DANET 26 Jan '13

26 Jan '13

The SparcV8 standard states, page 134 : "If any of the three instructions after a write state register instruction reads any ﬁeld that was changed by the original write state register instruction, the contents of that ﬁeld read by that instruction are undeﬁned." The restore instruction depends on the %WIM register, three NOPs must be inserted. diff a/openbios-devel/arch/sparc32/wuf.S b/openbios-devel/arch/sparc32/wuf.S --- a/openbios-devel/arch/sparc32/wuf.S +++ b/openbios-devel/arch/sparc32/wuf.S @@ -121,7 +121,7 @@ fnwin_patch1: srl %t_wim, 7, %twin_tmp2 fnwin_patch2: and %twin_tmp1, 0xff, %twin_tmp1 wr %twin_tmp1, 0x0, %wim /* Make window 'I' invalid */ - + WRITE_PAUSE restore %g0, %g0, %g0 /* Restore to window 'O' */ /* Trapped from kernel, we trust that the kernel does not Signed-off-by: Olivier DANET <odanet(a)caramail.com>

2 2

[commit] r1096 - trunk/openbios-devel/arch/sparc32
by repository service 26 Jan '13

26 Jan '13

Author: blueswirl Date: Sat Jan 26 13:50:15 2013 New Revision: 1096 URL: http://tracker.coreboot.org/trac/openbios/changeset/1096 Log: SPARC32: WIM register update delay The SparcV8 standard states, page 134: "If any of the three instructions after a write state register instruction reads any field that was changed by the original write state register instruction, the contents of that field read by that instruction are undefined." The restore instruction depends on the %WIM register, three NOPs must be inserted. Signed-off-by: Olivier DANET <odanet(a)caramail.com> Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> Modified: trunk/openbios-devel/arch/sparc32/wuf.S Modified: trunk/openbios-devel/arch/sparc32/wuf.S ============================================================================== --- trunk/openbios-devel/arch/sparc32/wuf.S Sat Jan 26 13:50:13 2013 (r1095) +++ trunk/openbios-devel/arch/sparc32/wuf.S Sat Jan 26 13:50:15 2013 (r1096) @@ -131,6 +131,7 @@ /* LOCATION: Window 'O' */ restore %g0, %g0, %g0 + WRITE_PAUSE /* LOCATION: Window 'W' */

1 0

[commit] r1095 - trunk/openbios-devel/arch/sparc32
by repository service 26 Jan '13

26 Jan '13

Author: blueswirl Date: Sat Jan 26 13:50:13 2013 New Revision: 1095 URL: http://tracker.coreboot.org/trac/openbios/changeset/1095 Log: SPARC32: Clear FP register The Frame Pointer register is used in "__switch_context_nosave" (switch.S) which is called at the end of the startup sequence (entry.S). This register should be initialized before use. (The SparcV8 standard states, page 75: "Supervisor software may not assume that any particular processor or memory state, except for the PSR's ET and S bits, has been initialized after a reset trap." Signed-off-by: Olivier DANET <odanet(a)caramail.com> Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> Modified: trunk/openbios-devel/arch/sparc32/entry.S Modified: trunk/openbios-devel/arch/sparc32/entry.S ============================================================================== --- trunk/openbios-devel/arch/sparc32/entry.S Mon Jan 21 00:49:16 2013 (r1094) +++ trunk/openbios-devel/arch/sparc32/entry.S Sat Jan 26 13:50:13 2013 (r1095) @@ -452,6 +452,7 @@ wr %g3, PSR_ET, %psr WRITE_PAUSE + set 0, %fp call __switch_context_nosave nop

1 0

Re: [OpenBIOS] G3Beige OpenFirmware Tree?
by Artyom Tarasenko 25 Jan '13

25 Jan '13

On Fri, Jan 25, 2013 at 9:54 PM, Artyom Tarasenko <atar4qemu(a)gmail.com> wrote: > Hi Mark, > > On Fri, Jan 25, 2013 at 5:20 PM, Mark Cave-Ayland > <mark.cave-ayland(a)ilande.co.uk> wrote: >> On 25/01/13 09:48, Mark Morgan Lloyd wrote: >> >>>> On 24/01/13 09:27, Mark Morgan Lloyd wrote: >>>> >>>>> I've got one of those machines, set up for OS and Linux (i.e. it's a bit >>>>> fragile and I'd rather not try installing anything else on it). If that >>>>> sounds useful tell me what to do. >>>> >>>> >>>> Thanks! I think perhaps a tarball of /proc/device-tree from Linux is >>>> what I need? There may be a utility to dump the tree from OS X too, >>>> but I'm not exactly sure what it is. >>> >>> >>> My OS is 9 (I think), I only use it for transferring control to Linux. >>> You have off-list mail created as below, note error messages of the type >>> indicated: >>> >>> 0 2>root@pye-dev-05:/# tar -czf proc_device-tree.tar.gz /proc/device-tree >>> tar: Removing leading `/' from member names >>> tar: /proc/device-tree/perch: file changed as we read it >>> .. >>> >>> Let me know if there's anything else I can do to help. >> >> >> Hi Mark, >> >> Thanks for doing this. So I've had a play with PearPC and I can make the >> CMD646ATA fail during its start method similar to the way that QEMU does by >> commenting out the IDE interface IRQ entry from the "interrupt-map" >> property. This seems to support my theory that the problem is related to >> interrupt mapping. > > Looks very similar to sparc64/sun4u problems I struggled ~ a half a year ago. > >> Now AIUI g3beige is an "Old World" Mac and so the interrupt information >> should be held in the "AAPL,interrupts" property. I've verified that both >> QEMU and OpenBIOS calculate the irq_line in the same way (based upon device >> id), however I do see that some of the "AAPL,interrupts" values contain more >> than one integer. I wonder what this is supposed to represent? > > Could it be that the irq line is wired to the interrupt controller not > as a PCI irq line? Similarly to the sun4u machines? A comment in FreeBSD ofw_pcibus.c says: /* * Any AAPL,interrupts property gets priority and is * fully specified (i.e. does not need routing) */ https://github.com/oza/FreeBSD-8.0-dyntick/blob/master/sys/powerpc/ofw/ofw_… Could it be that multiple entries in the AAPL,interrupts properties mean that the corresponding device has multiple interrupt lines? Artyom -- Regards, Artyom Tarasenko http://tyom.blogspot.com/search/label/qemu

1 0

Re : Re: [PATCH] ESP : Debug SCSI command
by Olivier DANET 21 Jan '13

21 Jan '13

>----- Message d'origine ----- >De : Blue Swirl >Envoyés : 20.01.13 16:58 >À : Mark Cave-Ayland >Objet : Re: [OpenBIOS] [PATCH] ESP : Debug SCSI command > >On Sun, Jan 20, 2013 at 3:23 PM, Mark Cave-Ayland ><mark.cave-ayland(a)ilande.co.uk> wrote: >> On 17/01/13 20:32, Blue Swirl wrote: >> >>> On Mon, Jan 14, 2013 at 9:26 PM, Olivier DANET<odanet(a)caramail.com> >>> wrote: >>>> >>>> [PATCH] ESP : Debug SCSI command >>> >>> >>> Please drop this line in the future. >>> >>>> The SCSI command code is at position 1, the first byte is the message_out >>>> byte (=0x80, constant) >>>> >>>> diff a/openbios-devel/drivers/esp.c b/openbios-devel/drivers/esp.c >>>> --- a/openbios-devel/drivers/esp.c >>>> +++ b/openbios-devel/drivers/esp.c >>>> @@ -106,7 +106,7 @@ do_command(esp_private_t *esp, sd_privat >>>> // Clear interrupts to avoid guests seeing spurious interrupts >>>> (void)esp->ll->regs[ESP_INTRPT]; >>>> >>>> - DPRINTF("do_command: id %d, cmd[0] 0x%x, status 0x%x\n", sd->id, >>>> esp->buffer[0], status); >>>> + DPRINTF("do_command: id %d, cmd[0] 0x%x, status 0x%x\n", sd->id, >>>> esp->buffer[1], status); >>>> >>>> /* Target didn't want all command data? */ >>>> if ((status& ESP_STAT_TCNT) != ESP_STAT_TCNT) { >>>> >>>> >>>> >>>> Signed-off-by: Olivier DANET<odanet at caramail.com> >>> >>> >>> See the other message. >>> >>> Otherwise the patch is correct. >> >> >> Do you want me to tidy up and commit these patches? I'm happy to do that >> with the Signed-off-by. > >That would be most kind of you, thank you. > >> >> >> ATB, >> >> Mark. Thank you both for reviewing these patches. I will post others soon, they will not change much to QEMU though. Regards Olivier

2 1

[commit] r1094 - trunk/openbios-devel/drivers
by repository service 21 Jan '13

21 Jan '13

Author: mcayland Date: Mon Jan 21 00:49:16 2013 New Revision: 1094 URL: http://tracker.coreboot.org/trac/openbios/changeset/1094 Log: esp.c: fix SCSI command code displayed in do_command() debug statement. The SCSI command code is at position 1, the first byte is the message_out byte (=0x80, constant). Signed-off-by: Olivier DANET <odanet(a)caramail.com> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/drivers/esp.c Modified: trunk/openbios-devel/drivers/esp.c ============================================================================== --- trunk/openbios-devel/drivers/esp.c Mon Jan 21 00:49:14 2013 (r1093) +++ trunk/openbios-devel/drivers/esp.c Mon Jan 21 00:49:16 2013 (r1094) @@ -106,7 +106,7 @@ // Clear interrupts to avoid guests seeing spurious interrupts (void)esp->ll->regs[ESP_INTRPT]; - DPRINTF("do_command: id %d, cmd[0] 0x%x, status 0x%x\n", sd->id, esp->buffer[0], status); + DPRINTF("do_command: id %d, cmd[0] 0x%x, status 0x%x\n", sd->id, esp->buffer[1], status); /* Target didn't want all command data? */ if ((status & ESP_STAT_TCNT) != ESP_STAT_TCNT) {

1 0

[commit] r1093 - trunk/openbios-devel/drivers
by repository service 21 Jan '13

21 Jan '13

Author: mcayland Date: Mon Jan 21 00:49:14 2013 New Revision: 1093 URL: http://tracker.coreboot.org/trac/openbios/changeset/1093 Log: esp.c: fix TEST_UNIT_READY SCSI command length. "TEST UNIT READY" is a 6 bytes SCSI command (00h/LUN/reserved/reserved/reserved/Control) and it is preceded by a IDENTIFY (0x80) message_out byte. The ESP transfer size is therefore 7 bytes. Signed-off-by: Olivier DANET <odanet(a)caramail.com> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/drivers/esp.c Modified: trunk/openbios-devel/drivers/esp.c ============================================================================== --- trunk/openbios-devel/drivers/esp.c Thu Jan 17 00:05:39 2013 (r1092) +++ trunk/openbios-devel/drivers/esp.c Mon Jan 21 00:49:14 2013 (r1093) @@ -197,11 +197,11 @@ test_unit_ready(esp_private_t *esp, sd_private_t *sd) { /* Setup command = Test Unit Ready */ - memset(esp->buffer, 0, 6); + memset(esp->buffer, 0, 7); esp->buffer[0] = 0x80; esp->buffer[1] = TEST_UNIT_READY; - if (do_command(esp, sd, 6, 0)) { + if (do_command(esp, sd, 7, 0)) { DPRINTF("test_unit_ready id %d failed\n", sd->id); return 0; }

1 0

Re: [OpenBIOS] [PATCH] ESP : Debug SCSI command
by Mark Cave-Ayland 20 Jan '13

20 Jan '13

On 17/01/13 20:32, Blue Swirl wrote: > On Mon, Jan 14, 2013 at 9:26 PM, Olivier DANET<odanet(a)caramail.com> wrote: >> [PATCH] ESP : Debug SCSI command > > Please drop this line in the future. > >> The SCSI command code is at position 1, the first byte is the message_out byte (=0x80, constant) >> >> diff a/openbios-devel/drivers/esp.c b/openbios-devel/drivers/esp.c >> --- a/openbios-devel/drivers/esp.c >> +++ b/openbios-devel/drivers/esp.c >> @@ -106,7 +106,7 @@ do_command(esp_private_t *esp, sd_privat >> // Clear interrupts to avoid guests seeing spurious interrupts >> (void)esp->ll->regs[ESP_INTRPT]; >> >> - DPRINTF("do_command: id %d, cmd[0] 0x%x, status 0x%x\n", sd->id, esp->buffer[0], status); >> + DPRINTF("do_command: id %d, cmd[0] 0x%x, status 0x%x\n", sd->id, esp->buffer[1], status); >> >> /* Target didn't want all command data? */ >> if ((status& ESP_STAT_TCNT) != ESP_STAT_TCNT) { >> >> >> Signed-off-by: Olivier DANET<odanet at caramail.com> > > See the other message. > > Otherwise the patch is correct. Do you want me to tidy up and commit these patches? I'm happy to do that with the Signed-off-by. ATB, Mark.

2 1