OpenBIOS March 2005

openbios@openbios.org

3 participants
6 discussions

Mark W Wenning/Austin/IBM is out of the office.

by Mark W Wenning

I will be out of the office starting 03/21/2005 and will not return until 03/25/2005. I will be in a class all week and will not be checking mail. Please contact Colleen Stouffer for SCSI issues, Muhamed Sadic for network issues, and my manager, Cathy Nunez for any other issues.

15 years, 7 months

abort and resume, assembler

by sachin thakur

Hi, Thanks for your inputs.. I have one more querry... 1. I am trying to implement abort and resume (section 7.6.3). After reading the spec my understanding is that when a abort key sequence is pressed the currently running program should halt and control should transfer to the command interpreter. But the openfirmware process model is single-threaded and there is only one, non-preempted program running at a time. So when a program is running how can i detect the abort key sequence? 2. I am trying to implement forth word for the Assembler mentioned In Open Firmware spec., section 7.3.9.3. According to this section user should be able to create machine-level code definition from the command interpreter. My doubt is how forth inner-interpreter will identify the machine dependent assembly mnemonics? Whether Assembler would be invoked to parse the machine level code entered from the command interpreter? In this case, Assembler should be the part of the boot firmware? Regards Sachin -----Original Message----- From: Stefan Reinauer [mailto:stepan@openbios.org] Sent: Thursday, March 17, 2005 8:05 PM To: The OpenBIOS Mailinglist Subject: Re: [OpenBIOS] cpeek, wpeek etc * sachin thakur <koolsachin_26(a)yahoo.co.in> [050317 08:36]: > Hi all > > I am trying to implement the words mentioned in section 5.3.7.1 of > open firmware specification viz. cpeek, wpeek etc. > > For this I have already implemented exception handling, which is in C > and assembly. Sounds interesting. Did you have a look at the exception handling code I checked in a while ago? > Now to implement these words I need to create some flags (variables) > which can be accessed from both forth and C. > > Is there any way by which I can access the same variable from both c > and forth. Yes, look at the handling of "last". Variables in forth are just normal words that push the address of the memory associated with them to the stack. You can use this with the normal forth-c-bindings If you publish a patch of your work people here can likely help you.

15 years, 7 months

tokenizer bug

by Mark Wenning

Greetings, Our "OpenBIOS guy" thinks he found a bug in the tokenizer. Can you comment? What's the procedure for submitting fixes? Looks like my previous post attempt was screwed up by Lotus notes, trying again... ----- Mark Wenning wenning(a)us.ibm.com 1-512-838-6263 Global FirmWare: Networking and I/O, FC lackey ----- Experience is what you get when you were expecting something else. - Anon ----- ----- Forwarded by Mark W Wenning/Austin/IBM on 03/07/2005 10:02 AM ----- David L Paktor/Almaden/IBM 03/04/2005 05:33 PM To wenning(a)us.ibm.com cc Subject Re: Found a serious bug in OpenBios Tokenizer Hi, Mark. As we spoke, I'm giving you some additional detail to describe the bug I found. Here's a recap of what I wrote before: It has to do with fload ; When your source fload s a file, that file is supposed to be a continuation of your source-stream. New definitions, as they are processed in the Tokenizer, are supposed to get successive FCode tokens assigned to them, starting at 0x0800. But when the OpenBios Tokenizer fload s a new file, it resets the FCode token-number, and starts assigning tokens from 0x0800 again. So if you have: definition A definition B definition C definition D \ and then fload File1 \ which has: definition E definition F definition G definition H and then you have something that intends to invoke A B C or D you will instead get E F G or H , respectively.... Here's the additional material: The source of the problem can be traced to the routines: init_stream and init_output in the file stream.c . They are both called at the beginning of tokenization, one to prepare the source from which input will be scanned, and the other to prepare the area to which output will be delivered (broadly speaking). When the fload directive is encountered, the input source is suspended and a new one is activated; when the new one is exhausted, the previous one is re-activated at the point from which it was suspended. So far so good. The init_stream routine is called to effectuate that activation. Unfortunately, the line that initializes the FCode token-numbers being assigning to new definitions -- the variable called nextfcode -- occurs inside the init_stream routine. I believe that moving that line to the init_output routine is sufficient to fix this bug.

15 years, 7 months

cpeek, wpeek etc

by sachin thakur

Hi all I am trying to implement the words mentioned in section 5.3.7.1 of open firmware specification viz. cpeek, wpeek etc. For this I have already implemented exception handling, which is in C and assembly. Now to implement these words I need to create some flags (variables) which can be accessed from both forth and C. Is there any way by which I can access the same variable from both c and forth. Kindly tell me the solution. Regards Sachin

15 years, 7 months

Re: [OpenBIOS] Fw: Found a serious bug in OpenBios Tokenizer

by Stefan Reinauer

Hi, * Mark W Wenning <wenning(a)us.ibm.com> [050307 17:10]: > Our "OpenBIOS guy" thinks he found a bug in the tokenizer. > Can you comment? > What's the procedure for submitting fixes? sorry for the late answer. The best way is to enter it as an issue in the OpenBIOS issue tracker at https://www.openbios.org/roundup/openbios/ Or just report it on this mailing list. > It has to do with fload ; When your source fload s a file, that file is > supposed to be a continuation of your source-stream. > > New definitions, as they are processed in the Tokenizer, are supposed to > get successive FCode tokens assigned to them, starting at 0x0800. > > But when the OpenBios Tokenizer fload s a new file, it resets the FCode > token-number, and starts assigning tokens from 0x0800 again. So if you > have: Oops. This is nasty. Thanks for spotting it. I remember resetting the fcode number to 0x800 to allow multiple files to be tokenized in a row. Obviously this one sneaked in. > I believe that moving that line to the init_output routine is sufficient > to fix this bug. It is. Commited. See stepan(a)openbios.org--devel/openbios--main--1.0--patch-17 and stepan(a)openbios.org--devel/openbios--xml--1.0--patch-9 Stefan

15 years, 7 months

Fw: Found a serious bug in OpenBios Tokenizer

by Mark W Wenning

Greetings, Our "OpenBIOS guy" thinks he found a bug in the tokenizer. Can you comment? What's the procedure for submitting fixes? ----- Mark Wenning wenning(a)us.ibm.com 1-512-838-6263 Global FirmWare: Networking and I/O, FC lackey ----- Experience is what you get when you were expecting something else. - Anon ----- ----- Forwarded by Mark W Wenning/Austin/IBM on 03/07/2005 10:02 AM ----- David L Paktor/Almaden/IB M To wenning(a)us.ibm.com 03/04/2005 05:33 cc PM Subject Re: Found a serious bug in OpenBios Tokenizer(Document link: Mark W Wenning) Hi, Mark. As we spoke, I'm giving you some additional detail to describe the bug I found. Here's a recap of what I wrote before: It has to do with fload ; When your source fload s a file, that file is supposed to be a continuation of your source-stream. New definitions, as they are processed in the Tokenizer, are supposed to get successive FCode tokens assigned to them, starting at 0x0800. But when the OpenBios Tokenizer fload s a new file, it resets the FCode token-number, and starts assigning tokens from 0x0800 again. So if you have: definition A definition B definition C definition D \ and then fload File1 \ which has: definition E definition F definition G definition H and then you have something that intends to invoke A B C or D you will instead get E F G or H , respectively.... Here's the additional material: The source of the problem can be traced to the routines: init_stream and init_output in the file stream.c . They are both called at the beginning of tokenization, one to prepare the source from which input will be scanned, and the other to prepare the area to which output will be delivered (broadly speaking). When the fload directive is encountered, the input source is suspended and a new one is activated; when the new one is exhausted, the previous one is re-activated at the point from which it was suspended. So far so good. The init_stream routine is called to effectuate that activation. Unfortunately, the line that initializes the FCode token-numbers being assigning to new definitions -- the variable called nextfcode -- occurs inside the init_stream routine. I believe that moving that line to the init_output routine is sufficient to fix this bug. The two files attached are the new version of stream.c and a diffs file, going from the old version to the new. Please incorporate this fix into the published code at the earliest possible juncture. 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(See attached file: stream.c) (See attached file: stream.diffs)

15 years, 7 months