OpenBIOS August 2006

openbios@openbios.org

8 participants
16 discussions

r74 - / fcode-utils fcode-utils/toke
by svn＠openbios.org 18 Aug '06

18 Aug '06

Author: stepan Date: 2006-08-18 11:07:34 +0200 (Fri, 18 Aug 2006) New Revision: 74 Added: fcode-utils/ fcode-utils/detok/ fcode-utils/romheaders/ fcode-utils/toke/ Removed: fcode-utils/toke/build.xml Log: moving fcode suite to an extra directory Copied: fcode-utils/detok (from rev 71, openbios-devel/utils/detok) Copied: fcode-utils/romheaders (from rev 71, openbios-devel/utils/romheaders) Copied: fcode-utils/toke (from rev 71, openbios-devel/toke) Deleted: fcode-utils/toke/build.xml =================================================================== --- openbios-devel/toke/build.xml 2006-07-23 14:29:29 UTC (rev 71) +++ fcode-utils/toke/build.xml 2006-08-18 09:07:34 UTC (rev 74) @@ -1,13 +0,0 @@ -<build> - - <executable name="toke" target="host"> - <object source="toke.c"/> - <object source="emit.c"/> - <object source="dictionary.c"/> - <object source="stack.c"/> - <object source="stream.c"/> - <object source="macros.c"/> - <object source="scanner.c"/> - </executable> - -</build>

1 0

Re: [OpenBIOS] [ANNOUNCE] New FCode Suite available!
by David L Paktor 17 Aug '06

17 Aug '06

> > Subject: > > [OpenBIOS] [ANNOUNCE] New FCode Suite available! > > Date: > > Thu, 17 Aug 2006 14:29:14 +0200 > > From: > > Stefan Reinauer <stepan(a)coresystems.de> > > Reply-To: > > The OpenBIOS Mailinglist <openbios(a)lists.openbios.org> > > To: > > openbios(a)lists.openbios.org > > > Dear OpenBIOS community, > > today I am very glad to announce a new version of the OpenBIOS FCode > utilities toke and detok. David Paktor, of the IBM corporation, > contributed a couple of significant improvements over the old versions > of those utilities. > > Toke and Detok now have a comprehensive regression test suite > of over 170 tests. This test suite makes it easy to verify > that new contributions do not break existing functionality. > > * among the new features: > > - detailed error reporting > - local value support! See > http://www.openbios.org/fcodesuite/Documents/TokenizerLocalValues.htm > - much better handling of PCI option roms > - improved compatibility to other tokenizers > - bug fixes in flow control and string escape handling > > Please be sure to check the complete list of new features at: > http://www.openbios.org/fcodesuite/Documents/TokenizerNewFeatures.htm > > I want to send a big THANK YOU out to David Paktor at this point. > > NOTE: The contributed changes are not in the main repository yet. > You can download the changed source code and binaries as well as the > test suite and test results as well as documentation from: > http://www.openbios.org/development/fcode.html > > Please send any feedback to this mailing list. > > Best regards, > > Stefan Reinauer > > > -- > coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. > Tel.: +49 761 7668825 • Fax: +49 761 7664613 > Email: info(a)coresystems.de • http://www.coresystems.de/ > > -- > OpenBIOS http://openbios.org/ > Mailinglist: http://lists.openbios.org/mailman/listinfo > Free your System - May the Forth be with you And thank you, Stefan, for your kind words and for the contribution you made initiating and maintaining this project and web-site. I would like to make two small amendments: The test suite contains exactly 162 tests. Still a lot, but let's not mis-advertise even to a small degree. Modesty prohibits me from saying much more than this, but I hope a look at the New Features document, and at the Test Log files, will suffice to demonstrate that "a couple of significant improvements" is very much an understatement... ;-} That being said, let me again express my gratitude for the opportunity to make this contribution to the Open Firmware community. My goal was to create a truly professional-grade tool; I look forward to finding out whether I have achieved it. ----- David L. Paktor System Firmware Developer System and Technology Group Global Firmware Division dlpaktor(a)us.ibm.com David L Paktor/Almaden/IBM@IBMUS 18880 Homestead Rd. Building 9945 Cupertino CA 95014 Room 1026 408-342-6110 T/L 560-6110 "The Bug Stops Here"

1 0

[ANNOUNCE] New FCode Suite available!
by Stefan Reinauer 17 Aug '06

17 Aug '06

Dear OpenBIOS community, today I am very glad to announce a new version of the OpenBIOS FCode utilities toke and detok. David Paktor, of the IBM corporation, contributed a couple of significant improvements over the old versions of those utilities. Toke and Detok now have a comprehensive regression test suite of over 170 tests. This test suite makes it easy to verify that new contributions do not break existing functionality. * among the new features: - detailed error reporting - local value support! See http://www.openbios.org/fcodesuite/Documents/TokenizerLocalValues.htm - much better handling of PCI option roms - improved compatibility to other tokenizers - bug fixes in flow control and string escape handling Please be sure to check the complete list of new features at: http://www.openbios.org/fcodesuite/Documents/TokenizerNewFeatures.htm I want to send a big THANK YOU out to David Paktor at this point. NOTE: The contributed changes are not in the main repository yet. You can download the changed source code and binaries as well as the test suite and test results as well as documentation from: http://www.openbios.org/development/fcode.html Please send any feedback to this mailing list. Best regards, Stefan Reinauer -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: info(a)coresystems.de • http://www.coresystems.de/

1 0

r73 - openbios-devel/drivers
by svn＠openbios.org 12 Aug '06

12 Aug '06

Author: stepan Date: 2006-08-12 11:52:34 +0200 (Sat, 12 Aug 2006) New Revision: 73 Modified: openbios-devel/drivers/esp.c Log: >From Paul Brook: The ESP SCSI driver currently doesn't check whether a DMA requests has completed before checking its status. On older qemu versions this works ok because DMA happens instantly. On never qemu DMA can take an indeterminate amount of time ooto complete, just like on real hardware. The patch waits for the controller to raise the DMA interrupt after initiating a DMA request. Modified: openbios-devel/drivers/esp.c =================================================================== --- openbios-devel/drivers/esp.c 2006-07-28 21:44:07 UTC (rev 72) +++ openbios-devel/drivers/esp.c 2006-08-12 09:52:34 UTC (rev 73) @@ -113,6 +113,8 @@ esp->espdma.regs->cond_reg = 0; // Set ATN, issue command esp->ll->regs[ESP_CMD] = ESP_CMD_SELA | ESP_CMD_DMA; + // Wait for DMA to complete. Can this fail? + while ((esp->espdma.regs->cond_reg & DMA_HNDL_INTR) == 0) /* no-op */; // Check status status = esp->ll->regs[ESP_STATUS]; @@ -129,6 +131,8 @@ esp->espdma.regs->cond_reg = DMA_ST_WRITE; // Transfer esp->ll->regs[ESP_CMD] = ESP_CMD_TI | ESP_CMD_DMA; + // Wait for DMA to complete + while ((esp->espdma.regs->cond_reg & DMA_HNDL_INTR) == 0) /* no-op */; // Check status status = esp->ll->regs[ESP_STATUS];

1 0

sparc esp scsi fixes
by Paul Brook 12 Aug '06

12 Aug '06

The ESP SCSI driver currently doesn't check whether a DMA requests has completed before checking its status. On older qemu versions this works ok because DMA happens instantly. On never qemu DMA can take an indeterminate amount of time ooto complete, just like on real hardware. The patch below waits for the controller to raise the DMA interrupt after initiating a DMA request. Paul Index: drivers/esp.c =================================================================== --- drivers/esp.c (revision 61) +++ drivers/esp.c (working copy) @@ -113,6 +113,8 @@ do_command(esp_private_t *esp, sd_privat esp->espdma.regs->cond_reg = 0; // Set ATN, issue command esp->ll->regs[ESP_CMD] = ESP_CMD_SELA | ESP_CMD_DMA; + // Wait for DMA to complete + while ((esp->espdma.regs->cond_reg & DMA_HNDL_INTR) == 0) /* no-op */; // Check status status = esp->ll->regs[ESP_STATUS]; @@ -129,6 +131,8 @@ do_command(esp_private_t *esp, sd_privat esp->espdma.regs->cond_reg = DMA_ST_WRITE; // Transfer esp->ll->regs[ESP_CMD] = ESP_CMD_TI | ESP_CMD_DMA; + // Wait for DMA to complete + while ((esp->espdma.regs->cond_reg & DMA_HNDL_INTR) == 0) /* no-op */; // Check status status = esp->ll->regs[ESP_STATUS];

2 1

qemu openbios scsi issues.
by Paul Brook 11 Aug '06

11 Aug '06

I'm currenttly converting the qemu scsi emulatin to use async IO. The main effect of this is that DMA tranfers take an indterminate amount of guest time to complete (just like they do on real hardware) instead of completing instantaneously. I've got It working in linux, but OpenBIOS dies when trying to read from the disk/cdrom. The problem appears to be that the openbios ESP drivers isses read commands then blindly continues without waiting for them to complete. The code in question is the end of ecp.c:do_command and its caller. I'm working on a fix, I just wanted to check (a) this hasn't already been fixed, and (b) I'm not on totally the wrong track. Paul

1 0