- OpenBIOS - mail.coreboot.org

Re: [OpenBIOS] Sparc32 progress
by Asif Haswarey 26 Apr '06

26 Apr '06

Hi Segher, Just wanted to mention that it is always safe to stick to the OpenFirmware spec as far as tokens are concerned. "int-property" might break the current Sun's tokenizer, unless "int-property" exists in the tokenizer dictionary or it is explicitly defined earlier in the FCode. The key to increase the credibility and interest of OpenBIOS among the masses is to _not break the OF spec_. (By-the-way, I am not criticizing anyone.) At some point I plan to start testing with OpenBIOS and endorse the support of OpenBIOS in our fibre-channel and iSCSI products. _____________ Asif Haswarey C1069W QLogic Corporation 26650 Aliso Viejo Parkway Aliso Viejo, CA 92656 Phone: 949.389.7607 Fax: 949.389.6308 -----Original Message----- From: openbios-bounces(a)openbios.org [mailto:openbios-bounces@openbios.org] On Behalf Of Segher Boessenkool Sent: Wednesday, April 26, 2006 11:50 AM To: The OpenBIOS Mailinglist Cc: stepan(a)coresystems.de Subject: Re: [OpenBIOS] Sparc32 progress > d# 256 encode-int " mmu-nctx" int-property Use either d# 256 " mmu-nctx" int-property or d# 256 encode-int " mmu-nctx" property (The former is shorter, the latter is standard OF, can be tokenized). Segher -- OpenBIOS http://openbios.org/ Mailinglist: http://www.openbios.org/mailman/listinfo Free your System - May the Forth be with you

2 1

Re: [OpenBIOS] Sparc32 progress
by Stefan Reinauer 26 Apr '06

26 Apr '06

* Blue Swirl <blueswir1(a)hotmail.com> [060425 21:38]: > 2 > cd / ok > 2 > ls > -2c45e0 aliases > -2c453c openprom > -2c42e8 options > -2c4270 chosen > -2c418c builtin > -2bf2f8 packages > -2bdc38 memory > -2bdb94 STP1012PGA > -2bda40 iommu > ok > 2 > cd iommu ok > 2 > ls > -2bd9c8 sbus > ok Very cool! Did you hardcode the amount of memory or do you probe it from the emulator? > Next step would be adding SBus device tree and SCSI devices. Yes. Most likely other parts of the device tree are missing as well. > I have to confess that I don't know much Forth except the RPN notation and > some Sun OBP commands. Can I print the device attributes somehow, like OBP > .attributes command? there's .properties to show device properties and ls to show sub device nodes and words to show methods defined for the current node. > I can't cd to the STP1012PGA node unless the device is renamed to something > shorter. Is this a limitation somewhere? Maybe an unintended one ;) But not a natural limitation. How do you create the node? Stefan -- 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/

3 3

byebye tla
by Stefan Reinauer 26 Apr '06

26 Apr '06

Hi, since nobody except me really dared checking anything into the repository since I switched to GNU arch/tla I decided to move on to something more practical: Subversion It's easier to use, the tools are less buggy and have a less braindead user interface / command line than GNU arch. Go ahead and do a clean checkout with: svn co svn://openbios.org/openbios/openbios-devel You can download the latest snapshot at: http://openbios.org/viewcvs/openbios-devel.tar.gz?root=OpenBIOS&view=tar Watch the tree in your web browser here: http://openbios.org/viewcvs/openbios-devel/?root=OpenBIOS The documentation on the website will be updated asap. Stefan -- 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

Re: [OpenBIOS] Sparc32/64 support
by Blue Swirl 23 Apr '06

23 Apr '06

Hi, I made a first attempt for Sparc32 support, patch attached. Currently we get this far: boot arg = 0x0 0000000000000000-0000000000000000 RAM 0 MB Checksum invalid (d93e0f8c)! forth started. initializing memory...done panic: no dictionary entry point. Unhandled Exception 0x00000002 PC = 0x00000008 NPC = 0x0000000c Stopping execution Any comments or suggestions? _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

1 0

Sparc32/64 support
by Blue Swirl 22 Apr '06

22 Apr '06

Hi, I've been working on Sparc32/64 support for Qemu. Currently Qemu for Sparc32 uses Proll as a system boot rom, but it's not a very good starting point for Sparc64. Basically, Linux expects a bit too much from the OpenFirmware interface, like Forth support etc. I guess OpenBIOS would be a better choice. How complete do you think OpenBIOS is, can it boot Linux for example on some architecture? Is there any support for 64-bit architectures? _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

2 1

Restoring BIOS
by preet 09 Apr '06

09 Apr '06

Hi. Recently cleared the BIOS of my Abit IS7-V2 motherboard. And the result was my system wont display anything on the screen. I can hear the cpu running that is the POST has loaded but not the BIOS. Is that possible that the BIOS has completely lost and is there a way to restore it... THANKS -- View this message in context: http://www.nabble.com/Restoring-BIOS-t1415766.html#a3815516 Sent from the OpenBIOS forum at Nabble.com.

2 4

LinuxFund
by Matyas Sustik 14 Mar '06

14 Mar '06

Hi All, My LinuxFund credit card is up for renewal. OpenBIOS is one of the projects which is supported by LinuxFund. I would like to know whether the OpenBIOS project has a good relationship with LiinuxFund or not. I like the idea that small/new projects are getting support. (I also support Debian and Firefox financially.) If anyone reads this list who knows about the quality of support LinuxFund provides I would be glad to hear about it. Thanks for your comments in advance. Matyas

2 1

Anthony P Ferranti/Raleigh/IBM is out of the office.
by Anthony P Ferranti 08 Dec '05

08 Dec '05

I will be out of the office starting 12/02/2005 and will not return until 12/12/2005. I am in a class but will be checking email. I will respond to your message when I return.

1 0

OpenBIOS/xbox patch
by Rink Springer 29 Oct '05

29 Oct '05

Hi everyone, Based on Ed's work, I've made a patch to really make the XBox support work :-) It contained two minor flaws, both of which are fixed by the patch. If I apply it, I see the OpenBIOS welcome screen. You can download it from http://rink.nu/downloads/xbox-patches/openbios-xbox.diff. Feel free to apply it in the tree. -- Rink P.W. Springer - http://rink.nu "God, root, what is difference?" - Pitr, Userfriendly

1 0

toke core dumps
by Prasanna Kumar 06 Oct '05

06 Oct '05

Hello All, When I try to tokenize a large FCode source file, the tokenizer crashes with Segmentation Fault. Debug messages: tst.fth:6763: debug: tokenizing control word 'endof' tst.fth:6764: debug: read token 'endcase', length=7 tst.fth:6764: debug: matched internal opcode 0x0013 tst.fth:6764: debug: tokenizing control word 'endcase' tst.fth:6764: debug: endcase offset 0x8401 tst.fth:6764: debug: endcase offset 0xffff83f1 ?????????? Segmentation fault (core dumped) When I looked at the code, the offending function was in emit.c : s16 receive_offset(void) { s16 offs=0; if (offs16) { offs= ((*opc)<<8)|(*(opc+1)); } else { offs=(*opc); } return offs; } If the msb of *opc is set 1(Value >0 0x8yyy), the offs gets changed to ffff8yyy. Changing offs to u16 and receive_offset returning value of u16 type would solve the problem. Change the prototype for receive_offset in emit.h as well. Modified code: u16 receive_offset(void) <----This line changed { u16 offs=0; <---- This line changed if (offs16) { offs= ((*opc)<<8)|(*(opc+1)); } else { offs=(*opc); } return offs; } Steps to reproduce the problem very simply: - Create a fcode source file with around 7000 variables. - Use the following simple test code: : test ( -- ) 1 to temp1 2 to temp2 temp1 case 1 of ." One" cr endof 2 of temp2 ." Two" cr endof endcase ; - Run tokenizer on the file. toke will core dump. Regards, Prasanna __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

2 2

Eizo 630L thin client.
by Fco .J. Arias 06 Aug '05

06 Aug '05

Hello, I modified this thin client to run win98 or linux, it becomes with windows ce. But bios General software bios is very bad for PNP, and usb, cs5530 udma, sound,acpi, .., don't work. At the moment xpress vga, serial, parallel, rs232, lan and other components works ok. Can I flash bios of this thinclient (now a useful simple computer, very quiet) with OPENBIOS? Extract actual bios before? -- Fco .J. Arias <javi(a)productshome.com>

3 2

newbie
by Douglas Frank 06 Aug '05

06 Aug '05

Greetings all, I've just subscribed. I've been googling around for quite a while now, looking for an interesting project that isn't already almost done, and that isn't essentially closed to significant contributions from people outside whatever organization sponsors the project. That leaves out a lot of otherwise interesting projects-- such as the kernel trace work at opersys.com, or Fedora, or the crash-dump project (lkcd) just for a few examples. I confess I'm not just interested in "open source" for any altruistic reason-- I'm really looking for a way to establish credentials in the OS "community" (a much-overused word). I bet such be will be increasingly important in future years. A little context: I'm using Fedora (FC3) here at work (nobody seems to mind that I can't read half of HP's internal web pages, which mostly only work right with IE; and I *certainly* don't mind! :-) I naturally poked around Redhat's site looking for Fedora work, but all they really offer is a bugzilla listing. 98% of reported FC bugs are either with badly outdated releases, or expansion hardware I don't have. However there *does* seem to be an issue with FC3 and the 2.6.11 kernel-- with several reports of solid system hangs/lockups, where the computer essentially freezes in place. Now on an Alpha, all you'd have to do is hit the halt button, type "cra" at the ">>>" prompt, and reboot; once in multiuser you'll have a crash dump waiting for your debugging pleasure. But I've never seen the PC that had a halt button that didn't instantly put you in POST, which kinda limits the chances of copying memory to the swap partition. So at least on the PC architecture, there doesn't seem to be a reliable way to do a postmortem on a wedged kernel. Obviously, the BIOS is a problem. Which leads me to you. What needs doing? thanks! -- Douglas Frank HP Co. ZKO 110 Spit Brook Rd. The older I get, 603-884-0501 Nashua, NH USA 03062 the better I was.

5 6

Intel 9IGLM motherboard support?
by Csanyi Pal 27 Jul '05

27 Jul '05

Hello! I have the 9IGLM motherboard with chipset Intel 845 GL. Can I hope that that I can download and install some open BIOS firmware for my motherboard? Thanks! -- Regards, Paul Debian Junior Project, DebianEdu, Moodle -> :-) :-) :-) :-) :-) :-) :-) http://www.ektf.hu/~Csanyi.Pal (Up to now, it is in Hungarian only.)

2 1

OpenBIOS, LinuxBIOS, FreeBIOS ???
by Per Dalgas Jakobsen (OpenBIOS) 18 Jul '05

18 Jul '05

Hi all, General question: I have been googling OpenBIOS, LinuxBIOS and FreeBIOS a bit, but I'm a little confused about the connection between them. Perhaps someone can clarify this for me? Specific questions: I have a Lippert Cool RoadRunner II (CRR2) board, consisting of a National Geode (GX1), a CX5530 and a 256KB Flash BIOS. It is set-up with a compact flash card (connected to the primary EIDE on the board). I would like it to boot up directly into Linux or RTEMS (*fast*). With the current BIOS, I have boot-time (reset to bootloader start) of approx 6 seconds. Any recommendations? Should I stick with the current BIOS? Should I use one or the other Linux-/Open-/Free-BIOS? Any experience with this chipset-combination? How much work would you think is needed to get it to work? Thanks ~Per

3 4

interesting: IBM's "Open source Slimline Open Firmware"
by Brian Sammon 01 Jul '05

01 Jul '05

http://www-128.ibm.com/developerworks/power/library/pa-dw-slof.html

3 2

LH5 / LZH modules in Asus - Award BIOS files
by Borg No. One 01 Jul '05

01 Jul '05

Hi. Can someone help here: http://www.wimsbios.com/phpBB2/viewtopic.php?p=32796#32796 -- Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie! Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl

2 1

chipset info [please, need docs]
by Gordon Freeman 29 Jun '05

29 Jun '05

Hi, i saw that you're writing an OpenBIOS. I like to write hardware management code but i'm not ready for writing code for an "organized project" :D However i'd like to management my chipset (sis645+sis961) but after months of search i have not found the datasheet or other technical doc. I wrote to SiS, ECS (which produce my mother board) but i'm a private (and mainly i'm a single person) so they simply never answer me. If you want to write OpenBIOS you need to management chipset, how do you do this? I have, for example, intel chipset datasheet but i don't think that this is useful for me. THE QUESTION SO IS: have you sis645 datasheet or any sis datasheet? I don't undestand why is possible to buy hardware without datasheet... I'd like to use (and for "to use" i mean "to program") full capabilites of my chipset, i'd like to write my own SMI handler, to allow read-write from 0a0000h-0fffffh and the other configurations that may damage my hardware :D I hope someone answear me. I thank every one who has read this message. Kee Nemesis 241, gorfrman(a)virgilio.it

1 0

on omnibook xe3
by pi 24 May '05

24 May '05

hello list, i want to reflash my omnibook xe3 (PhoenixBios) i never flashed bioses before and don't want to lose the machine so some questions i) is there the possibilety to copy the current "image" ii) if the flash failes is there any way to get the machine running again iii) how much time will this take me? (middle range linuxguy / programmer -- since debian 1.3.6) thanks a lot pi

2 1

RE: [OpenBIOS] problem with strings
by shon＠soc-soft.com 12 May '05

12 May '05

Forth word "begin-package" takes three strings as input begin-package ( arg-str arg-len reg-str reg-len dev-str dev-len -- ) With the current implementation, arg-str will be overwritten. So I think number of pockets should be increased to three. Regards, Shon -----Original Message----- From: Stefan Reinauer [mailto:stepan@openbios.org] Sent: Thursday, May 12, 2005 1:12 PM To: openbios(a)lists.openbios.org Subject: Re: [OpenBIOS] problem with strings * shon(a)soc-soft.com <shon(a)soc-soft.com> [050512 09:10]: > 0 > ok > 0 > " hi" " hello" " bye" " welcome" ok > 8 > .s <8> 4005810c 2 4005800c 5 4005810c 3 4005800c 7 > ok > 8 > > > Above the strings " hi" and " bye" are stored at the same > address(0x4005810c) and also " hello" and " welcome" are stored at the > same address(0x4005800c).This means that the first two strings " hi" and > " hello" are overwritten and therefore lost. Strings defined using ' s" > ' also show the same behavior. The words reading strings from the interpreter into memory are using a "pockets" implementation with two alternating string buffers. This means if you want to put more than two strings on the stack without touching them in between you need to create a copy of those strings. Think of it as a temporary string buffer. > Is this an intended behavior? Please verify the same.Q It is indeed intended, since many forth engines do this the same way. If it is not sufficient, you can raise the number of pockets in forth/bootstrap/bootstrap.fs. Go look for: \ pockets implementation for 7.3.4.1 If you have some reasonable sample code that needs more pockets rather than becoming overly complex, we can raise the number of pockets in the official tree. Regards, Stefan -- OpenBIOS http://openbios.org/ Mailinglist: http://www.openbios.org/mailman/listinfo Free your System - May the Forth be with you The information contained in this e-mail message and in any annexure is confidential to the recipient and may contain privileged information. If you are not the intended recipient, please notify the sender and delete the message along with any annexure. You should not disclose, copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail are those of the individual sender except where the sender specifically states them to be the views of SoCrates Software India Pvt Ltd., Bangalore. -- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/ Free your System - May the Forth be with you

1 0

problem with strings
by shon＠soc-soft.com 12 May '05

12 May '05

Hi I have noticed an abnormal behavior in the string handling. Below is the snapshot of the same. 0 > ok 0 > " hi" " hello" " bye" " welcome" ok 8 > .s <8> 4005810c 2 4005800c 5 4005810c 3 4005800c 7 ok 8 > Above the strings " hi" and " bye" are stored at the same address(0x4005810c) and also " hello" and " welcome" are stored at the same address(0x4005800c).This means that the first two strings " hi" and " hello" are overwritten and therefore lost. Strings defined using ' s" ' also show the same behavior. Is this an intended behavior? Please verify the same. Shon The information contained in this e-mail message and in any annexure is confidential to the recipient and may contain privileged information. If you are not the intended recipient, please notify the sender and delete the message along with any annexure. You should not disclose, copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail are those of the individual sender except where the sender specifically states them to be the views of SoCrates Software India Pvt Ltd., Bangalore.

2 1

Using OpenBios to boot Mac OS on CHRP?
by H S 05 May '05

05 May '05

Hello everyone, I have an RS/6000 7025-F50. It is a CHRP machine from late �98 and it has an awesome open firmware implementation. It even has a great GUI for the usual system configuration. The only thing it seems to be missing is an xcoff-loader package. Thus I am unable to load Apple�s Mac OS X bootloader, BootX. I researched for a time the possibility of an elf version of BootX, but it was beyond me and I could not find anyone interested in helping me. There is not much PowerPC development over at Open Darwin since most people already using PowerPC machines are using Macs, and Apple has already taken care of everything for them. Well I have been following the work with PearPC to bring it OpenBios support, and I got to thinking would it be possible to load OpenBios from my open firmware, which then could load BootX? Something like Open firmware --> OpenBios --> BootX. Plus, my Open firmware has limited Mac-Parts and Mac-Files packages similar to Old World Macs, so it can�t browse HFS+ partitions, which is necessary to locate BootX. OpenBios could kill 2 birds with one stone; locate the bootloader and load it. Without kernel extensions for my hardware, I am not sure how far along it would get. With RTAS maybe it could boot in some sort of �safe mode� with minimal support? Well, even if it kernel panics I would still consider it a victory to see the grey Apple as BootX loads. You can find some information on the F50 at a little site I made about it. http://www.geocities.com/hokutogreatbear/index.htm Hopefully this makes sense to someone! Thanks, Hanns __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs

1 0

Mark W Wenning/Austin/IBM is out of the office.
by Mark W Wenning 21 Mar '05

21 Mar '05

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.

1 0

abort and resume, assembler
by sachin thakur 21 Mar '05

21 Mar '05

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.

1 0

tokenizer bug
by Mark Wenning 18 Mar '05

18 Mar '05

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.

2 2

cpeek, wpeek etc
by sachin thakur 17 Mar '05

17 Mar '05

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

2 1

Re: [OpenBIOS] Fw: Found a serious bug in OpenBios Tokenizer
by Stefan Reinauer 10 Mar '05

10 Mar '05

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

1 0

Fw: Found a serious bug in OpenBios Tokenizer
by Mark W Wenning 07 Mar '05

07 Mar '05

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)

1 0

documentation patch
by Brian Sammon 27 Jan '05

27 Jan '05

Last month when I started experimenting with openbios, I found the documentation to be misleading about which files to call from grub. Here's a patch to the README which I hope clarifies the matter:

2 1

trouble with cygwin
by Mark Wenning 24 Jan '05

24 Jan '05

cygwin ( http://cygwin.com ) is a linux shell /emulator that runs under Windows. It uses standard gcc and ld , We thought this would be the easiest way to get our developers going with OpenBIOS as a development simulator... Is anyone out there running OpenBIOS as an application under Windows (XP or 2000)?

4 3

trouble with cygwin
by Mark Wenning 22 Jan '05

22 Jan '05

Hi guys, I'm trying to build OpenBIOS under Cygwin . I get the following errors when I build it: wenning@SHARPSTICK:~/src/openbios/openbios$ make + Entering libc + Entering kernel + Entering toke + Entering forth + Entering modules + Entering drivers + Entering fs + Entering grubfs + Entering arch/x86 BUILDING plain.image ld: PE operations on non PE file. make[1]: *** [plain.image] Error 1 make: *** [sub-arch/x86-all] Error 2 any ideas?

2 1

bug in toke?
by Mark Wenning 11 Jan '05

11 Jan '05

Hi - We're looking at using toke, detok in our development process. Our current setup to tokenize device drivers uses a "script" similar to this: ----- start kng_sr_script ----- \ define these words for the tokenizer tokenizer[ 0 constant ?SYSTEM-ROM 0 constant COMMENT-OUT 0 constant ?DEBUG-TX 0 constant ?DEBUG-RX h# 0110 constant ibm-Code-Revision-Level h# 17D5 constant ibm-VendorId h# 5831 constant ibm-king-DeviceId h# 020000 constant ClsCode ]tokenizer fload kng_main.of ----- end kng_sr_script ----- Then in kng_main.of, we do: ----- start kng_main.of ----- .... tokenizer[ hex ibm-Code-Revision-Level decimal ]tokenizer SET-REV-LEVEL tokenizer[ hex ibm-VendorId ibm-king-DeviceId ClsCode decimal ]tokenizer PCI-HEADER FCODE-VERSION2 ... ----- start of code...----- The version of toke I downloaded doesn't like this for 2 reasons: 1. Constant declarations in TOKENIZER[ ... ]TOKENIZER blocks emit bytes/tokens to the output, so we get extra stuff before the PCI header. I don't think it should do this; code inside tokenizer blocks should not be in the output FCODE. Is this correct? 2. Previous constant declarations aren't being looked up/interpreted when in Tokenizer mode. For example, tokenizer[ hex ibm-Code-Revision-Level decimal ]tokenizer SET-REV-LEVEL causes a "empty stack: error. I have to change it to tokenizer[ 0110 ]tokenizer SET-REV-LEVEL to make it work. Is this a bug? I'm a little new to this; basically what I'm asking is if this behaviour is what was intended, or should we attempt to fix it and submit a fix to you.

3 4

multiboot image name
by Brian Sammon 20 Dec '04

20 Dec '04

I've downloaded OpenBIOS-0.99.1.tar.bz2 , done "make config" and "make". According to the documentation, I should have a file named "openbios.multiboot". I don't. I have found obj-x86/build/arch/x86/multiboot.image , however. Is this the file I want, or is the file I need missing because something went wrong?

2 2

C bindings.
by Prasanna Kumar 18 Dec '04

18 Dec '04

Hi All, I am also interested in knowing the answer to the questions asked by Sachin. i. How does one get the address of C functions, which I can use while calling "C" functions in my forth code? Thanks in advance. Regards, Prasanna Hi all, I want to call c functions from my forth code. In the mailing list i found following> >>Call C-functions from forth code by pushing the >>address >>of the function on the stack. Something like >> >>call ( function_addr -- <whatever> ) Please tell me how can I get the address of the c function?? Please let me know if there are other issues involved in this as I am very little aware of the whole system trying to get familiar with the things. Thanks in Advance Sachin __________________________________ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250

2 1

Re: Difference between DODOES and ENTER
by Stefan Reinauer 21 Oct '04

21 Oct '04

* sachin.b(a)soc-soft.com <sachin.b(a)soc-soft.com> [041021 13:30]: > > > When and where this DODOES is called? It's called by processxt() when a word is called that has been created with CREATE or $CREATE: : $create header 6 , ['] noop , reveal ; Regards, Stefan

1 0

Difference between DODOES and ENTER
by sachin.b＠soc-soft.com 21 Oct '04

21 Oct '04

Hi Everyone, Could you please tell me what is the difference between DODOES and ENTER. Regards, Sachin The information contained in this e-mail message and in any annexure is confidential to the recipient and may contain privileged information. If you are not the intended recipient, please notify the sender and delete the message along with any annexure. You should not disclose, copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail are those of the individual sender except where the sender specifically states them to be the views of SoCrates Software India Pvt Ltd., Bangalore The information contained in this e-mail message and in any annexure is confidential to the recipient and may contain privileged information. If you are not the intended recipient, please notify the sender and delete the message along with any annexure. You should not disclose, copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail are those of the individual sender except where the sender specifically states them to be the views of SoCrates Software India Pvt Ltd., Bangalore

2 1

Forth code debugging
by sachin.b＠soc-soft.com 14 Oct '04

14 Oct '04

Hi Everyone, I have written some code in forth and trying to integrate it in the Openbios kernel-1.1. Build procedures says: Building final dictionary... failed I look into the obj-x86/openfirmware.log for the reasons of failure. For any undefined reference it straight says "undefined word". But for some logical errors it sys: Segmentation violation at 1 (or some address location) What is this segmentation violation? What information this violation location gives? Could any one tell me how to debug code in this environment? Regards, Sachin The information contained in this e-mail message and in any annexure is confidential to the recipient and may contain privileged information. If you are not the intended recipient, please notify the sender and delete the message along with any annexure. You should not disclose, copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail are those of the individual sender except where the sender specifically states them to be the views of SoCrates Software India Pvt Ltd., Bangalore

1 0

RE: [OpenBIOS] PCI Enumeration and driver Implementation
by Vishu＠soc-soft.com 01 Oct '04

01 Oct '04

Hi Viswa, >> I need to write PCI Bus Driver for MIPS Embedded Processor. In my >> case PCI is a built-in device, need to know the details about writing >> PCI Enumeration -- i.e configuring and enumerating PCI Devices. >Have a look at the sources ;-) The PCI driver is already there in OpenBIOS. See openbios-devel/drivers/pci.* To get it >working for a new platform, you basically need to adapt openbios-devel/include/<arch>/pci.h >Note: The driver does not do much at the moment. IE ROM probing does not work correctly. See the issue tracker for >more details: https://www.openbios.org/roundup/openbios/ >Do you have OpenBIOS running on MIPS hardware? YES I have OpenBIOS running on MIPS Hardware... Running on RAM. I had taken lot older Kernel I believe the director structure doesn't have Drivers directory. openbios-latest.tar been using this tar also removed lot of unwanted Directories like Tokenizer detok fcc but right now after the changes my directory contents Looks like this. openbios: kernel Makefile obj-mips README openbios/kernel: arch Documentation forth include kernel Makefile plugins README Rules.make util openbios/kernel/arch: amd64 mips ppc unix x86 openbios/kernel/arch/amd64: boot.S builtin.c console.c include Kconfig Makefile mboot.S multiboot.c plainboot.c openbios/kernel/arch/amd64/include: io.h multiboot.h openbios/kernel/arch/mips: boot.S builtin.c console.c include Makefile proto.h txsio.h openbios/kernel/arch/mips/include: io.h kxmips.h multiboot.h mipsreg.h mipreg.h openbios/kernel/arch/ppc: Kconfig Makefile openbios/kernel/arch/unix: Kconfig Makefile plugins.c unix.c openbios/kernel/arch/x86: boot.S builtin.c console.c include Kconfig Makefile mboot.S multiboot.c plainboot.c openbios/kernel/arch/x86/include: io.h multiboot.h openbios/kernel/Documentation: AUTHORS Changelog.stepan COPYING dictformat.txt glossary.txt initializers.txt TODO openbios/kernel/forth: administration apic.fs bootstrap.fs builtin.fs debugging device fract.fs hayes.fs interpreter.fs lib Makefile memory.fs packages pci.fs start.fs system test.fs testsuite util vocabulary.fs openbios/kernel/forth/administration: banner.fs callback.fs devices.fs help.fs iocontrol.fs Makefile nvram.fs README reset.fs script.fs security.fs selftest.fs userboot.fs openbios/kernel/forth/debugging: client.fs fcode.fs firmware.fs Makefile see.fs openbios/kernel/forth/device: builtin.fs device.fs display.fs extra.fs fcode.fs feval.fs font.fs logo.fs Makefile missing other.fs package.fs pathres.fs preof.fs property.fs README.device structures.fs table.fs terminal.fs tree.fs openbios/kernel/forth/lib: cbindings.fs lists.fs Makefile split.fs string.fs openbios/kernel/forth/packages: deblocker.fs disklabel.fs Kconfig Makefile obp-tftp.fs packages.fs README terminal-emulator.fs openbios/kernel/forth/system: ciface.fs dummy.fs main.fs Makefile openbios/kernel/forth/testsuite: framebuffer-test.fs Makefile memory-testsuite.fs README splitfunc-testsuite.fs openbios/kernel/forth/util: Makefile pci.fs util.fs openbios/kernel/include: config.h dict.h plugins.h stack.h sysinclude.h openbios/kernel/kernel: bootstrap.c dict.c forth.c internal.c Kconfig lib.c Makefile openbios.c primitives.c stack.c openbios/kernel/obj-mips: dict.o lib.o openbios.o primitives.o Rules.arch stack.o types.h openbios/kernel/plugins: Kconfig loader.c Makefile plugin_pci plugin_qt openbios/kernel/plugins/plugin_pci: Makefile plugin_pci.c plugin_pci.h openbios/kernel/plugins/plugin_qt: fcode.h logo.xpm Makefile pciconfig.h plugin_qt.cpp plugin_qt.h plugin_qt.pro qt_main.cpp qt_rom.fs openbios/kernel/util: bin2hex.c types.sh openbios/obj-mips: kernel openbios/obj-mips/kernel: bin2hex boot.o bootstrap bootstrap.dict bootstrap.log builtin.o console.o dictionary.h dict.o ld.script lib.o loader loader.nostrip loader.o openbios.full openbios.full.nostrip openbios.o openfirmware.dict openfirmware.fs openfirmware.log primitives.o Rules.arch stack.o temp types.h unix unix.nostrip > >Should there be any base enumeration to be written in C program if so > >where is the hook Point in Openbios kernel and then rest in Forth or > >everything (configuring, enumerating, Reading and writing) needs to be >> implemented in Forth using PCI Bus Binding according to Open Firmware. >See the existing driver. Anyway I keep on adding hooks to the same kernel instead of once again making Changes for cross compilation in the new kernel. If u can give me the links and Changes needs to be applied I'll do it myself.... Regards Viswa -- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/ Free your System - May the Forth be with you The information contained in this e-mail message and in any annexure is confidential to the recipient and may contain privileged information. If you are not the intended recipient, please notify the sender and delete the message along with any annexure. You should not disclose, copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail are those of the individual sender except where the sender specifically states them to be the views of SoCrates Software India Pvt Ltd., Bangalore.

1 0

PCI Enumeration and driver Implementation
by Vishu＠soc-soft.com 30 Sep '04

30 Sep '04

Hi Everyone I need to write PCI Bus Driver for MIPS Embedded Processor. In my case PCI is a built-in device, need to know the details about writing PCI Enumeration -- i.e configuring and enumerating PCI Devices. Should there be any base enumeration to be written in C program if so where is the hook Point in Openbios kernel and then rest in Forth or everything (configuring, enumerating, Reading and writing) needs to be implemented in Forth using PCI Bus Binding according to Open Firmware. Regards Viswa The information contained in this e-mail message and in any annexure is confidential to the recipient and may contain privileged information. If you are not the intended recipient, please notify the sender and delete the message along with any annexure. You should not disclose, copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail are those of the individual sender except where the sender specifically states them to be the views of SoCrates Software India Pvt Ltd., Bangalore.

3 2

How primitive words are getting called?
by Swamy＠soc-soft.com 24 Sep '04

24 Sep '04

Hello, I am unable to understand how the forth words are called? The definitions for forth words are maintained in "char *wordnames[]" of "/kernel/bootstrap.c" and in "/kernel/primitive.c" all the functions for primitive words are defined. When we say "dup" what will be the s/w flow? Please let me know how these two files are interconnected. Please give me some input with regard to this. Thanks and Regards Swamy

2 1

Interpreter and Forth Compilation
by Swamy＠soc-soft.com 21 Sep '04

21 Sep '04

Hi, 1) When I enter a command (e.g. dup) on openbios prompt,how does it get linked to corresponding c function fdup()? I understand that the entered command goes through the outer-interpreter and is finally executed using forth word "execute". I am not able to understand how this "execute" gets linked to fdup(). 2) Please let me know how the forth files are compiled and executed? I understand that all the forth source files (*.fs) are converted to (.dict) files using "./bootstrap" executable and is linked to the kernel. Kindly provide some input with regard to this. Can you please provide some link/document with respect to above Regards Swamy

2 1

Re: [OpenBIOS] Cygwin/Linux issues with openbios-devel-20040919-1800.tar.bz2
by Dwight Schauer 21 Sep '04

21 Sep '04

On Tue, 21 Sep 2004 00:45:22 +0200, Stefan Reinauer <stepan(a)openbios.org <mailto:stepan@openbios.org>> wrote: > * Dwight Schauer <das(a)teegra.net <mailto:das@teegra.net>> [040920 00:28]: > > I got the standalone forth from openbios-devel-20040919-1800.tar.bz2 to > > build and run on Cgywin and Linux. > > > > While building I did get this error (had the same problem on linux as well): > > make[2]: *** No rule to make target > > `../../obj-x86/build/arch/unix/../../fs/libfs.a', needed by > > `../../obj-x86/build/arch/unix/unix'. Stop. > > make[1]: *** [sub-arch/unix-all] Error 2 > > Did you disable all filesystem support? Looks like a bug in the build > system. Thanks for reporting this. I believe so, I was trying for a minimum build so I could play around with it on cygwin. >From .config-x86 # # Filesystem Configuration # # CONFIG_DISK_LABEL is not set > > > { ---------------- start clip ----------------------- } > > 0 > : star [char] * emit ; ok > > 0 > : stars 0 ?do star loop ; ok > > 0 > 5 stars ***** ok > > 0 > 10 stars **************** ok > > 0 > bye > > vs: > > > 0 > : star [char] * emit ; ok > > 0 > : stars 0 ?do star loop ; star isn't unique. > > ok > > 0 > star * ok > > 0 > 5 stars stars: undefined word. > > 0 > bye > > > That time I had a problem. Before I entered the "stars" line I hit up > > arrow, and got the "0 > : star [char] * emit ;" back. > > That is what I'd expect. I then pressed up arrow again and got: "0 >" so > > I figured I was on an empty line. After typing the definition for stars > > again, I got the "star is not unique" warning message. > > Sounds like a problem with the command line module (modules/cmdline.c) > > > On linux it acted the same way. > > I can't reproduce this on my system. What terminal are you > using? > the rxvt that comes with Cygwin. Rxvt v2.7.10 - released: 26 MARCH 2003

1 0

Cygwin/Linux issues with openbios-devel-20040919-1800.tar.bz2
by Dwight Schauer 21 Sep '04

21 Sep '04

I got the standalone forth from openbios-devel-20040919-1800.tar.bz2 to build and run on Cgywin and Linux. While building I did get this error (had the same problem on linux as well): make[2]: *** No rule to make target `../../obj-x86/build/arch/unix/../../fs/libfs.a', needed by `../../obj-x86/build/arch/unix/unix'. Stop. make[1]: *** [sub-arch/unix-all] Error 2 Which I was able to correct by going into fs and doing a make from there. ~/openbios/openbios-devel-20040919-1800/fs $ make Compiling ioglue.o : compiling= gcc -I. -I../obj-x86/include -I./include -I../include -I- -Wall -Wmissing-prototypes -g -O2 -fno-builtin -msoft-float -Wp,-MT,../obj-x86/build/fs/ioglue.o,-MD,../obj-x86/deps/fs/ioglue.P -c ioglue.c -o ../obj-x86/build/fs/ioglue.o ok ofiles=`find ../obj-x86/build/fs/.ardst -name '*.o'` ; \ ar cru ../obj-x86/build/fs/libfs.a_ $ofiles && ranlib ../obj-x86/build/fs/libfs.a_ && mv ../obj-x86/build/fs/libfs.a_ ../obj-x86/build/fs/libfs.a ok After that the top level make completed without problem. (This fixed the build issue on linux as well) so I ran it. { ---------------- start clip ----------------------- } $ make run ./obj-x86/build/arch/unix/unix ./obj-x86/build/arch/unix/unix.dict Welcome to OpenBIOS v1.0.RC1 Built on Sep 19 2004 16:22 Type 'help' for detailed information [unix] Booting default not supported. 0 > : star [char] * emit ; ok 0 > : stars 0 ?do star loop ; ok 0 > 5 stars ***** ok 0 > 10 stars **************** ok 0 > bye Farewell! ok { ---------------- end clip ----------------------- } Ok, no problem there (apart from me being momentarily stumped about hex being the default base, but that makes sense), so I tried it again. { ---------------- start clip ----------------------- } $ make run ./obj-x86/build/arch/unix/unix ./obj-x86/build/arch/unix/unix.dict Welcome to OpenBIOS v1.0.RC1 Built on Sep 19 2004 16:22 Type 'help' for detailed information [unix] Booting default not supported. 0 > : star [char] * emit ; ok 0 > : stars 0 ?do star loop ; star isn't unique. ok 0 > star * ok 0 > 5 stars stars: undefined word. 0 > bye Farewell! ok { ---------------- end clip ----------------------- } That time I had a problem. Before I entered the "stars" line I hit up arrow, and got the "0 > : star [char] * emit ;" back. That is what I'd expect. I then pressed up arrow again and got: "0 >" so I figured I was on an empty line. After typing the definition for stars again, I got the "star is not unique" warning message. On linux it acted the same way.

2 1

FCODE Evaluator
by Swamy＠soc-soft.com 15 Sep '04

15 Sep '04

Hello, In one of your earlier mails (Date: Sat, 24 Jul 2004 02:18:05 +0200), u have mentioned that "FCODE Evaluator" has been already implemented and is part of the kernel. We need to support a PCI device which has a FCODE Driver burnt in ROM. My question is: 1. Will the kernel take care of inserting this PCI Driver and mapping the device? Or else do we need to build some evaluator for this? 2. Can you please name some PCI device which has FCODE driver built in Regards Swamy

3 3

RE: [OpenBIOS] Problem with jumping from assembly to c function
by Vishu＠soc-soft.com 13 Sep '04

13 Sep '04

Hi Stefan I'm able to cross compile the OpenBios Kernel for mips board but I cannot mention for which board right now. Sorry to tell this since my company doesn't allow me to expose u the facts. I was successful in doing so with some changes in Makefiles and kept only /openbios/forth and /openbios/kernel. Within these folders I made changes for Host compilation and Target Compilation. The compile image is to boot from RAM right now Initial stage since I wanted to know the kernel booting on the Target Board. Later on I would like to Compile for ROM and run on RAM. For this we have to write a linker file for relocatable code. The problem right now I'm facing is that 1. openbios.full contains "/openbios/obj-mips/kernel/openfirmware.dict" as the final compiled image which is converted to SREC format and downloaded On the Target Board. 2. But it is not including the "/openbios/obj-mips/forth/openfirmware.dict". Copied this file manually from the said directory to "/openbios/obj-mips/kernel/" and tried to boot it used to hang. The same problem is there in X86 system, i cross verified through grub loader as well as for the Target Board. I'm waiting for the reply..... Regards Viswanath -----Original Message----- From: openbios-bounces+vishu=soc-soft.com(a)lists.openbios.org [mailto:openbios-bounces+vishu=soc-soft.com@lists.openbios.org] On Behalf Of Stefan Reinauer Sent: Monday, September 13, 2004 5:26 PM To: The OpenBIOS Mailinglist Subject: Re: [OpenBIOS] Problem with jumping from assembly to c function Hi Viswanath, * Vishu(a)soc-soft.com <Vishu(a)soc-soft.com> [040908 12:03]: > For my previous mail of cross compiling the kernel for mips board. I > resolved the issue As u mentioned of on HOSTCC and CC for Target. > > Is there any other way of compiling forth sources. You can choose a system with the same bit width (32/64bit) and and endianess (big/little endian) and compile the dictionary natively there. Otherwise you will have to wait until OpenBIOS supports cross compiling officially. > And after cross compilation I am facing the problem of jumping from > boot.s to main. Somehow Succeeded in jumping to cmain function. > Openbios function is called from cmain during this period > Context is saved is it necessary to initialize global pointer. Because > once it goes to cmain after some > Execution of instructions the global pointer gets manipulated and > exception occurs. Why is it so. Do you get any output before this? Did you initialize the stack properly in or before boot.S? > But in /arch/x86 example there is only the initilization of stack > pointer. Do u have any example for Cross compilation procedure and > linking the linker script to download to ROM or RAM. Have a look at the current version at http://www.openbios.org/snapshots/ Relocation from rom to ram is currently only done by the underlying ELF loader (ie LinuxBIOS) but we want to support more in the future. Any concrete ideas / patches are welcome. Stefan -- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/ Free your System - May the Forth be with you

1 0

RE: [OpenBIOS] How to enable print statement in the openbios-kernel?
by Swamy＠soc-soft.com 13 Sep '04

13 Sep '04

==>So you are not cross compiling? No, I am using GCC for compilation version - gcc-g77-2.96-110 ==>So you cannot even build all of openbios on your machine? When I compile the kernel with option "#define DEBUG_CONSOLE" (/kernel/include/config.h), it compiles fine. But, If I add single "printk" statements in the each of the functions processxt(), next(), enterforth() in the file /kernel/kernel/internal.c it hangs.... ALSO If I add DEBUG_INTERPRETER OR DEBUG_INTERNAL it still hangs....the output I have mailed at the bottom. ==>Where_ does it hang? - # make Welcome to OpenBIOS.. Creating build directory /home/shon/openbios/obj-x86/kernel Checking types...found 32bit platform, creating "types.h" Endianess definition: glibc. Dynamic linker functions provided by libdl Building common core files for architecture x86 compiling primitives.c... ok compiling stack.c... ok compiling dict.c... ok compiling lib.c... ok compiling openbios.c... ok compiling bootstrap.c... ok linking bootstrap... ok Bootstrapping dictionary... ok Building final dictionary... ok Building binary converter... ok Compiling x86 architecture specific binaries assembling mboot.S... ok compiling multiboot.c... ok assembling boot.S... ok compiling plainboot.c... ok generating linkable dictionary... ok compiling builtin.c... ok compiling console.c... ok Linking: native multiboot kernel for grub... ok native kernel (for LinuxBIOS)... ok native kernel with dictionary... ok Building files for unix hosted bootstrap compiling unix.c... ok compiling plugins.c... ok linking unix bootstrap... ok Building plugins compiling loader.c... ok OpenBIOS build finished for platform x86. Building forth sources: Adding lib specific forth code to dictionary... ok Adding device specific forth code to dictionary... COMPILATION HANGS AT THIS POSITION..........

2 1

RE: [OpenBIOS] How to enable print statement in the openbios-kernel?
by Swamy＠soc-soft.com 13 Sep '04

13 Sep '04

what platform are you using, what compiler? -I am working on Linux (x86). I am using the command "make" to compile the image. what did you try to do? -I need to watch the kernel flow using printk statements what was the exact output? -If I do "make" it takes too much time to compile and will not come out at all for hours. * Swamy(a)soc-soft.com <Swamy(a)soc-soft.com> [040908 11:59]: > > The path is: openbios/kernel/kernel/openbios.c > If this file is not called, Plz let me know the procedure to watch the > print statements of this file? Basically I need to watch the kernel > flow. openbios.c is called. And it's printk statements work fine for me. Can you please be a bit more detailed? - what platform are you using, what compiler? - what did you try to do? - what was the exact output? Please use the snapshots from http://www.openbios.org/snapshots/ Stefan -- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/ Free your System - May the Forth be with you

2 1

Problem with jumping from assembly to c function
by Vishu＠soc-soft.com 13 Sep '04

13 Sep '04

Hi stefan For my previous mail of cross compiling the kernel for mips board. I resolved the issue As u mentioned of on HOSTCC and CC for Target. Is there any other way of compiling forth sources. If so how to eliminate the Hosted compilation Directory i.e. unix directory which is in kernel-1.1/arch/unix. And after cross compilation I am facing the problem of jumping from boot.s to main. Somehow Succeeded in jumping to cmain function. Openbios function is called from cmain during this period Context is saved is it necessary to initialize global pointer. Because once it goes to cmain after some Execution of instructions the global pointer gets manipulated and exception occurs. Why is it so. For example Boot.s contains this RAM address Mnemonics Instructions a0100044: 3c1ca011 lui gp,0xa011 /* Loads the global pointer address */ a0100048: 279c40c8 addiu gp,gp,16584 a010004c: 8f8880a4 lw t0,-32604(gp) /* get the address of cmain which is stored in to (temp register) */ a0100050: 01000008 jr t0 /* jumps to main */ a0100070 <cmain>: a0100070: 3c1c0001 lui gp,0x1 /* don't know why gp is loaded with 0x1 */ a0100074: 279c4058 addiu gp,gp,16472 a0100078: 0399e021 addu gp,gp,t9 a010007c: 27bdffe0 addiu sp,sp,-32 a0100080: afbc0010 sw gp,16(sp) a0100084: 8f848010 lw a0,-32752(gp) /* after this instruction exception is occuring and jumping to 0x80000000 address (RAM) */ a0100088: 00000000 nop But in /arch/x86 example there is only the initilization of stack pointer. Do u have any example for Cross compilation procedure and linking the linker script to download to ROM or RAM. Regards Viswanath

3 2

RE: [OpenBIOS] How to enable print statement in the openbios-kernel?
by Swamy＠soc-soft.com 13 Sep '04

13 Sep '04

The path is: openbios/kernel/kernel/openbios.c If this file is not called, Plz let me know the procedure to watch the print statements of this file? Basically I need to watch the kernel flow. -----Original Message----- From: openbios-bounces+swamy=soc-soft.com(a)lists.openbios.org [mailto:openbios-bounces+swamy=soc-soft.com@lists.openbios.org] On Behalf Of Stefan Reinauer Sent: Wednesday, September 08, 2004 3:14 PM To: The OpenBIOS Mailinglist Subject: Re: [OpenBIOS] How to enable print statement in the openbios-kernel? * Swamy(a)soc-soft.com <Swamy(a)soc-soft.com> [040908 11:21]: > Hello, > > > > I am working on the openbios, I got a kernel from www.openbios.org and > hence built on linux s/s. I have written some "printk" statements for > the verification in kernel files. But after building it using command > "make" and then "make run", I am still unable to get those print > statements. Please let me know the procedure/methods to enable the print > statement. This should work fine. The code where you put the print statements probably never got called. ;-) Where did you put them? -- Stefan -- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/ Free your System - May the Forth be with you

2 1

FCODE Evaluator
by Swamy＠soc-soft.com 09 Sep '04

09 Sep '04

Hello, In one of your earlier mails (Date: Sat, 24 Jul 2004 02:18:05 +0200), u have mentioned that "FCODE Evaluator" has been already implemented and is part of the kernel. We need to support a PCI device which has a FCODE Driver burnt in ROM. My question is: 1. Will the kernel take care of inserting this PCI Driver and mapping the device? Or else do we need to build some evaluator for this? 2. Can you please name some PCI device which has FCODE driver built in Regards Swamy

1 0

How to enable print statement in the openbios-kernel?
by Swamy＠soc-soft.com 08 Sep '04

08 Sep '04

Hello, I am working on the openbios, I got a kernel from www.openbios.org and hence built on linux s/s. I have written some "printk" statements for the verification in kernel files. But after building it using command "make" and then "make run", I am still unable to get those print statements. Please let me know the procedure/methods to enable the print statement. Thanks and Regards Mahadeva Swamy TL

2 1

c-bindings
by sachin thakur 01 Sep '04

01 Sep '04

Hi all, I want to call c functions from my forth code. In the mailing list i found following> >>Call C-functions from forth code by pushing the >>address >>of the function on the stack. Something like >> >>call ( function_addr -- <whatever> ) Please tell me how can I get the address of the c function?? Please let me know if there are other issues involved in this as I am very little aware of the whole system trying to get familiar with the things. Thanks in Advance Sachin

1 0

Cross Compile Error for Different Arch while compiling for dictionary
by Vishu＠soc-soft.com 24 Aug '04

24 Aug '04

Hi Everyone As I saw a mail from Madhu Kiran with regard of forming a final image as part of the Kernel (i.e. dictionary part of the Kenel build). I knew this since openbios.full has kernel and dictionary built to-gether its correct right. The answer corresponds to the answer given by Stefan Reinauer. I'm cross compiling Kernel-1.1 for my embedded processor still I havent updated my BSP part but I'll do it later once the dictionary and kernel independent part is built properly. Is it ok to go in this Way. So while cross compiling kernel-1.1 using cross compiler on Linux based machine was able to compile Kernel part and the unix folder (Host) with changes done in the Makefile. The steps doing so are as follows: 1. In kernel-1.1 arch Documentation forth include kernel Makefile plugins README Rules.make Util In Makefile ARCH := $(shell uname -m | sed -e s/i.86/mips/) Commented forth.html and plugins since I dint want .html to be formed and plugins since is was giving some error When compiled for x86. all: main unix dictionary $(ARCH) # forth.html plugins 2. In directory /util types.sh changes are if [ -z "$CC" ]; then CC=mips_fp_le-gcc # cross compiler option for Target Board fi #echo "void *pointersize;" > types.c #$CC -c -o types.o types.c #PTRSIZE=$(( 8 * 0x`nm types.o| grep pointersize | cut -f1 -d\ ` )) #rm -f types.c types.o PTRSIZE=32 # since my Target is 32-bit processor 3. In arch/unix I made the chages with the following line added as per the little endian option CC := mips_fp_le-gcc include $(TOPDIR)/Rules.make Can we do this .... It even compiles the unix directory with the cross compiler option. 4. It gives problems with dictionary file what may be the problem with the following error code [root@localhost kernel-1.1]# make Welcome to OpenBIOS.. Creating build directory /home/viswa/kernel-1.1/obj-mips Checking types... Checkings in types.sh updated by SoCrates found 32bit platform, creating "types.h" Building common core files for architecture mips compiling primitives.c... ok In Rules.make Compiler Used mips_fp_le-gcc compiling stack.c... ok In Rules.make Compiler Used mips_fp_le-gcc compiling dict.c... ok In Rules.make Compiler Used mips_fp_le-gcc compiling lib.c... ok In Rules.make Compiler Used mips_fp_le-gcc compiling openbios.c... ok In Rules.make Compiler Used mips_fp_le-gcc Building files for unix hosted bootstrap compiling unix.c... ok In Rules.make Compiler Used mips_fp_le-gcc compiling plugins.c... ok [root@localhost obj-mips]# cd .. [root@localhost kernel-1.1]# make clean Cleaning up architecture mips [root@localhost kernel-1.1]# make Welcome to OpenBIOS.. Creating build directory /home/viswa/kernel-1.1/obj-mips Checking types... Checkings in types.sh updated by SoCrates found 32bit platform, creating "types.h" Building common core files for architecture mips compiling primitives.c... ok In Rules.make Compiler Used mips_fp_le-gcc compiling stack.c... ok In Rules.make Compiler Used mips_fp_le-gcc compiling dict.c... ok In Rules.make Compiler Used mips_fp_le-gcc compiling lib.c... ok In Rules.make Compiler Used mips_fp_le-gcc compiling openbios.c... ok In Rules.make Compiler Used mips_fp_le-gcc Building files for unix hosted bootstrap compiling unix.c... ok In Rules.make Compiler Used mips_fp_le-gcc compiling plugins.c... ok In Rules.make Compiler Used mips_fp_le-gcc linking unix bootstrap... -rdynamic -ldl ok Bootstrapping dictionary.../bin/sh: ./unix: cannot execute binary file make[1]: *** [bootstrap.dict] Error 126 make: *** [dictionary] Error 2 This error is due to since we are trying to execute on different architecture to form the dictionary File. Is there anyway to bypass or use Host compiler for dictionary forming and finally use this later along With the final image formation. 5. Is the image openbios.full a binary image or elf format and how to link to ROM i.e using ld sript to Map for the Target ROM address. 6. But with x86 was able to compile the kernel-1.1 without compiler option of forth.html and plugins Which could not find some ./config file what is the correction for it and why the plugins are needed. In advance Thanks Viswa

2 1

Fcode evaluator Information
by madhu.kiran＠soc-soft.com 24 Jul '04

24 Jul '04

Hi, Please send the answers for following questions. 1) We need FCode Evaluator information. We are confused from the spec about how to develop FCode evaluator for particular target hard ware. Please share with us any documentation regarding FCode evaluator. 2) According OpenBIOS software, kernel developed both in C and Forth. WE understand that C language used for generic Kernel, Forth is for Open Firmware specification interfaces. How did you compile both together to put on target? ( If u compile C code separately for target by using cross compiler and FCode translated through the evaluator how link form between these at run time) 3) Do you people have any contact number? Thanks and Regards MadhuKiran .V

2 1

booting a plain binary (no fs involved)
by Samium Gromoff 31 Mar '04

31 Mar '04

Let`s say i want to have a following scenario: 1. create one binary ELF file containing: - linux kernel - openbios binary - openbios dictionary the ELF file should have the kernel sections before the openbios ones, and the entry point will be in the openbios code indeed (this might require to resolve any section name clashes). 2. load the whole blob into target host memory (no openbios involvement here, indeed) 3. enter openbios interface 4. tell openbios to jump into the kernel entry section so that it can take over things from this point And the questions are: - is this currently possible? - if no, then what the first culprit might be? regards, Samium Gromoff

1 0

Re: OpenFirmware and interrupt-map
by Stefan Reinauer 05 Feb '04

05 Feb '04

* Peter Lister <prl(a)peterlister.co.uk> [040205 00:32]: > Digressing slightly, please note that Etherboot is more than just the > drivers - there is a significant amount of network code (now even TCP if > one wants it), and it would benefit us all to share as much as possible; > there is, for instance, an NFS client already. I agree! Etherboots features are really nice. > GRUB people now discuss "porting" Etherboot drivers, which is > disappointing (have a look at the GRUB support forum and FAQ to see > how little help there is on the network code compared to disk and fs). > It would have made far more sense to co-operate on an open firmware > network API, but hey ho... I'd like to see this happening fairly soon, > so that any driver created for Etherboot immediately works with GRUB. > So I encourage OpenBIOS to peacefully co-exist with GRUB and Etherboot > rather than fork which is not a good way to encourage driver writers. It was my initial goal when taking the grub filesystem drivers, to leave them completely untouched. Unfortunately this is only possible when staying with 32bit little endian architectures. So I started cleaning these drivers up. When things are done, I'll try to feed them back into grub, even though I doubt grub will ever make it to non-x86 hw. Well.. there's still hope for PUPA (http://www.nongnu.org/pupa/) and FILO ;-) OpenBIOS' goal is to provide a useful and simple API to driver writers and still allow reusing as much code as possible. Therefore it should coexist nicely with any other project ... Stefan

1 0

Re: OpenFirmware and interrupt-map
by ebiederman＠lnxi.com 05 Feb '04

05 Feb '04

Tarl Neustaedter <Tarl.Neustaedter(a)sun.com> writes: > Stefan Reinauer wrote: > [...] > > So basically there is no real way around having an x86 option rom. It > > seems. Intel is trying to break out and move firmware developers to > > their EFI bytecode, which does the same thing OpenFirmware FCode does, > > just with the need of 4*8MBit Flash to store all of the virtual machine > > Actually, my understanding is that the multi-megabyte flash is only > required for the IA-64 implementation. The IA-32 implementation of EFI > from some vendors is reported to fit comfortably in 1MB. The EFI guys have been working really hard to get their footprint down. IA-64 native code gives you an automatic 3x code bloat so it trivially requires 3x more rom space. > One thing we've discovered recently is that the x86 firmware world > is rife in rumors, FUD, and propaganda. It's pretty startling. > > I've dropped the illusion of getting convinced some day that EFI is the > > way to go, > > It certainly looks good; they seem to have learned a bunch of > lessons from the OpenFirmware experience. Unfortunately, we > got stopped by license issues - to go any further than just the > basic spec, there is a "click to agree" license button on the > web page which our legal team told us not to click. They missed the simplicity part. But they did at least spec something that did not use interrupts. OF was not picked at least in part because they did not want to dilute ACPI. Eric

2 1

Re: OpenFirmware and interrupt-map
by ebiederman＠lnxi.com 05 Feb '04

05 Feb '04

Peter Lister <prl(a)peterlister.co.uk> writes: > On Wed, 2004-02-04 at 14:31, Stefan Reinauer wrote: > > > OpenBIOS is currently only reusing filesystem drivers from grub, but > > an interface for network booting so that etherboot drivers can be used > > should not overtop the fs efforts a lot. > > Digressing slightly, please note that Etherboot is more than just the > drivers - there is a significant amount of network code (now even TCP if > one wants it), and it would benefit us all to share as much as possible; > there is, for instance, an NFS client already. Regardless the etherboot driver model and the open firmware driver model are essentially the same. (Independently derived though). The big difference is I believe OF drivers can have multiple cards working at once. > For some reason best known to themselves, the GRUB developers decided to > use only Etherboot's drivers and brew their own network code. The result > is that GRUB netboot is now lagging noticeably behind Etherboot in > functionality, drivers etc - GRUB people now discuss "porting" Etherboot > drivers, which is disappointing (have a look at the GRUB support forum > and FAQ to see how little help there is on the network code compared to > disk and fs). It would have made far more sense to co-operate on an open > firmware network API, but hey ho... I'd like to see this happening > fairly soon, so that any driver created for Etherboot immediately works > with GRUB. So I encourage OpenBIOS to peacefully co-exist with GRUB and > Etherboot rather than fork which is not a good way to encourage driver > writers. After seeing the GRUB code the amazing part is that it works. The problem is totally GRUB, the etherboot core is much more powerful. Some pieces of GRUB at the periphery are OK, like the FS drivers but the rest is not even worth thinking about. There is a reason GRUB has never been ported to run under LinuxBIOS. > BTW, there is work now on implementing PXE on top of Etherboot - > pxelinux has already been demonstrated on top of Etherboot. This may > force the issue somewhat, since even if PXE isn't the API one wants, it > will at least help focus people into deciding what APIs they *do* want. I've already implemented the API I do want. Open source and no callbacks. Eric

1 0

Re: OpenFirmware and interrupt-map
by ron minnich 04 Feb '04

04 Feb '04

On Wed, 4 Feb 2004, Tarl Neustaedter wrote: > Actually, my understanding is that the multi-megabyte flash is only > required for the IA-64 implementation. The IA-32 implementation of EFI > from some vendors is reported to fit comfortably in 1MB. that may change when people start to use it, not sure. Some of the Intel boards we got recently had really large flash parts. > One thing we've discovered recently is that the x86 firmware world > is rife in rumors, FUD, and propaganda. It's pretty startling. it's pretty weird. I've gotten all kinds of strange stuff from different places :-) > It certainly looks good; they seem to have learned a bunch of lessons > from the OpenFirmware experience. Unfortunately, we got stopped by > license issues - to go any further than just the basic spec, there is a > "click to agree" license button on the web page which our legal team > told us not to click. and that's the way it will stay, I'm told. I'm unhappy with a bios that needs CHKDSK in any event. ron

1 0

Re: OpenFirmware and interrupt-map
by ron minnich 04 Feb '04

04 Feb '04

On Wed, 4 Feb 2004, Stefan Reinauer wrote: > If the concept of having a diversity of hardware architectures available > is going to survive, there has to be a generic solution to the early > initialization issues. I agree completely. It is sad that the generic solution so far is x86 instructions. We can hope this improves, but I am pessimistic. ron

1 0

bk openbios questions.
by Balint Cristian 04 Feb '04

04 Feb '04

Hi ! I played a little bit with today's bk tree, remarked that has lots of feauters and lots of intentions like ide driver. I use grub to play with, but remarked that there is a lot of dictionary, not only the "unix.dict" wich appeal from Makefile via "make run". My question is how can i load via grub all dictionaries, or more than one ? (or i ask stupid thing ?) My grub line --------------------////////---------------------------------> title openbios kernel (hd0,1)/boot/multiboot.image module (hd0,1)/boot/unix.dict ----------------------///////-------------------------------> My second question is how can i convince via grub that openbios to use framebuffer ? I try to make menuconfig and select qt plugin but only VGA console will appear no framebuffer, must pass some extra thing for that ? Thanks, cristian

2 1

Re: [Fwd: Re: OpenFirmware and interrupt-map]
by Stefan Reinauer 04 Feb '04

04 Feb '04

* Tarl Neustaedter <Tarl.Neustaedter(a)sun.com> [040204 01:05]: > >Interesting. The observation that powerful firmware eventually > >becomes an OS so you might as well use an OS, seems true :) > > One benefit we're hoping for is to not have to write multiple drivers > every time we go to a new technology (e.g., infiniband). Right now, > we're facing the possibility of needing to write a Solaris driver, > a Linux driver, an IEEE-1275 FCode driver, and a real-mode BIOS > driver. All for one technology, and with the probability of having > to repeat for the next i/o technology to come along, since we are > going forward with both SPARC and Opteron-based systems. > With LinuxBIOS, it looks like it should be possible to re-use > the Linux driver in the PROM. If so, it would mean that a new > platform based on a particular i/o technology could contain the > drivers for that particular technology (e.g., for Infiniband, > IPoIB and SRP drivers), and not have to worry about option ROMs. Infiniband is a technology that you won't find on expansion cards iirc, so it makes sense to include support in the firmware. But is the setup work you do in firmware really the same as what an operating system driver does? Many device option roms do a completely different job than the appropriate os device driver. As for graphics adapters, there is initialization code in the option rom, that initializes the onboard memory, sets an initial mode and allows some output. You won't get 3d acceleration on firmware level. OTOH, you won't get lowlevel initialization in most drivers. I haven't seen any sun opteron hardware, but it seems that this hardware could, from the os level, be handled very similar to the current sparc hardware when using a combination of LinuxBIOS and OpenBIOS. IEEE 1275 provides a good layer of abstraction while still having the powerful and open LinuxBIOS base that lets you reuse drivers and such. > I can believe it. My task right now is to determine if LinuxBIOS > is feasible, and if so, at what size. We have some flexibility in that > we design our own boards, so if we can justify a large PROM, we > could get it in. Better if we can fit it in a 1MB prom, however. Opteron systems need a lot more complex initialization than most other x86(-like) systems, but with 1MB / 8MBit you won't run into flash rom limits except adding lots of additional code. > A Sun video card comes with an OpenFirmware driver. That means that > Sun has either designed and built the card itself, or has signed a > deal with a vendor to re-sell their video cards after writing a driver > and putting it on the option ROM. The usual arrangement is that this > driver is still intellectual property of the video card vendor, so > that he can maintain secrecy on how to use his card. Don't know why. This reminds me a lot of the discussion I have had with vendors when talking about getting initialization code for LinuxBIOS/OpenBIOS. > To some extent, cards can be moved between Suns, Apples, IBM PowerPC > platforms and some HP systems, all of which use the IEEE 1275 standard. > Each implementation has slightly diverged from each other, and now that > the 1275 committee isn't meeting any more, quirks are tending cause > further divergence. With Hypertransport, Infiniband and other technologies, there might awake some demand for new supplements. Competing with EFI, Open Firmware should have at least recommendations on how to cope with this divergence (which is a natural fact looking at the number of contributors) > Note that an openfirmware video driver isn't particularly feature-rich. > It primarily provides a dumb scrolling ascii text window. There are > definitions for fancier capabilities (cursor positioning, color, > character insertion), but I've never seen anyone use them - or even > know if these capabilities work in our drivers. Are you talking about the CHRP Linear Frame Buffer Display Device Binding and the Recommended Practices for 16 Colors and 8bit Framebuffers? Best regards, Stefan Reinauer

1 0

Re: OpenFirmware and interrupt-map
by Stefan Reinauer 04 Feb '04

04 Feb '04

* ron minnich <rminnich(a)lanl.gov> [040203 22:46]: > I don't expect the cards to come with fcode any time soon, if ever. Four > reasons: first, the market is more or less zero, and the all the non-x86 > systems support x86 emulators to support the x86 option roms; second, > if they support two option roms (fcode, x86) that makes for lots more > work; third, the PC market will probably never go to fcode; and fourth, I > bet they (naively) think that fcode would make reverse engineering easier. I fully agree that using ndisasm is by no means more complicated than using my fcode detokenizer detok. All x86/efi option rom discussion sounds rather like a game of not stepping on the others' toes rather than technologically driven reasoning. OpenBIOS can be used on top of a PC BIOS as well, thus it could allow to use any Open Firmware compliant pci card in a machine that still has different firmware in rom. This is one step towards the great unification.. If the concept of having a diversity of hardware architectures available is going to survive, there has to be a generic solution to the early initialization issues. Best regards, Stefan Reinauer

1 0

Re: OpenFirmware and interrupt-map
by Stefan Reinauer 04 Feb '04

04 Feb '04

CCing the OpenBIOS mailinglist. * Eric W. Biederman <ebiederman(a)lnxi.com> [040203 20:07]: > Tarl Neustaedter <Tarl.Neustaedter(a)sun.com> writes: > > > Eric W. Biederman wrote: > > > Tarl Neustaedter <Tarl.Neustaedter(a)sun.com> writes: > > > > > >>If you have any specific questions about OpenFirmware, I'd be > > >>delighted to provide assistance. I've been doing IEEE 1275 since > > >>1996, and was at one time a voting member of that committee (since > > >>pretty much defunct). The specs are engraved upon my skull by now. :-) That is good to know. There will be a lot of things to clarify when the base implementation of OpenBIOS is complete and operable. > > The main problem is that cards don't usually come with IEEE 1275 FCode > > on them. We've pretty much had to write all of ours, and have gotten > > tired of it - we're actually looking at LinuxBIOS as a way to get > > out of that business, and just build in the drivers we care to in the > > Linux kernel on the prom. But I can answer questions any questions > > about writing FCode, it's most of what I've done in recent years. One big problem in the picture is that there is a certain amount of hardware that assumes firmware did a job before running the linux driver. So basically there is no real way around having an x86 option rom. It seems. Intel is trying to break out and move firmware developers to their EFI bytecode, which does the same thing OpenFirmware FCode does, just with the need of 4*8MBit Flash to store all of the virtual machine in (An OpenBIOS+LinuxBIOS solution easily fits in 2MBit) I've dropped the illusion of getting convinced some day that EFI is the way to go, but if there's a wave of change now anyway, it's high time for some educational advertising of using "long term industry proven standards" instead of KUAI-Implementations. I don't see it all that negative for FCode firmware in option roms. It's just not going to happen in small numbers. For this to happen, there have to be _many_many_many_ machines with an IEEE 1275 compliant boot firmware. Such a system could for example still use expansion cards with x86 pcbios compliant option roms - Generating the needed OpenFirmware wrapper nodes based on the device type (display, block, ... ) is no magic once the initialization of the device itself is done. This would allow to use such cards in an open firmware environment while the OS can rely on the fact that there is a device that can be operated using the Open Firmware interface. > Interesting. The observation that powerful firmware eventually > becomes an OS so you might as well use an OS, seems true :) If you use EFI, you even get all the old DOS tools. > The one problem with using Linux so far has been size constraints. > The primary interim solution has been to use etherboot. You have to > port the Linux drivers to it but it close enough you don't have to > rewrite them from scratch, and it is small. 16K-32K is typical with > one network driver and a IP stack. 128K when you build in all the > network drivers. OpenBIOS is currently only reusing filesystem drivers from grub, but an interface for network booting so that etherboot drivers can be used should not overtop the fs efforts a lot. > The location where option roms come into play in the pc world are > scsi adapters, raid controllers, and video. For scsi adapters and > raid controllers every case I have looked at the linux drivers are > good enough that you don't need the option roms. Video drivers are > still problematic. This is not true for many Opteron boards, ie those coming with the LSI 1020/1030 scsi controllers. There might be a fix for this on the horizon, but it only solves the problem for this specific controller. If there is a way to clean out these issues generically without having to think in terms of single controller or video cards, we should definitely provide this as an option. > How has sun coped with getting video drivers for high end video > cards. I know Apple seems to have succeeded in working with > NVIDIA. I suspect that is with open firmware side but I don't know. Apple succeeded by putting all of the actual driver code in a special property of the device node, and have the fcode rom not initialize the device but just create the device node. A good example of how _not_ to do it. Stefan

1 0

Bootloader
by Alex Owen 06 Jan '04

06 Jan '04

I have been watching this project from the early days and I'm impressed with the recient progress. This is probably old news but a quick search of the archives here did not show anything up. Yaboot. Yaboot is the bootloader used by owners of macintosh and other ppc machines with open firmware to boot linux from openfirmware. The home page seems to be http://penguinppc.org/projects/yaboot/ Perhaps when the time comes to boot an operating system with openbios yaboot and linux will be good candidates. Of course I may be completely off track! Bye for now Alex Owen

5 8

Dictionary Compression vs eXecute In Place
by Stefan Reinauer 20 Nov '03

20 Nov '03

Hi,. since the openbios dictionary is growing and growing as it becomes more complete, I've looked at different ways to optimize the dictionary handling. There's two methods of "safing" memory: compression and execute in place. 1) Compression Some numbers, taking 32bit dictionary (x86) method | size/bytes ---------------+------------- uncompressed | 62668 nrv2b | 22466 gzip | 20982 bzip2 | 19388 The current kernel is slightly below 8k (8172 bytes) * pro: small(er) flash parts can be used. * con: code has to be decompressed to memory first, higher memory usage. 2) XIP (eXecute In Place) If not compressing the dictionary, it could be changed so that all but the readwriteable data can be executed directly from ROM. This would decrease the use of RAM in embedded systems noticeably, but it is also slower on about every system. * pro: extremely low memory usage ( < code size) * con: slow execution. Looking at the amount of code this is about, (2) is pretty much neglectable for most systems whereas (1) is an interesting option. Comments? Stefan

2 1

Device Tree and FCode evaluator
by Stefan Reinauer 19 Nov '03

19 Nov '03

Hi, the current openbios cvs contains a lot of new code from the device interface. We have a device tree now and can evaluate FCode on device option ROMs. Now OpenBIOS lacks a whole lot of Open Firmware "support packages" like the deblocker, tftp booting for network interfaces, the terminal emulator, filesystem support, etc etc. And of course: OpenBIOS needs device drivers! Open Source drivers, vendor FCode, everything that helps OpenBIOS to support a wide range of hardware ;-) I started setting the framework for the support packages in openbios/forth/packages, find one source file per support package. Also, there's an example fcode driver coming with the QT-Plugin of the openbios kernel: openbios/kernel/plugins/plugin_qt/qt_rom.fs I'll attach a simple example to this mail that executes the QT Plugins FCode. To test it, do: ~/openbios $ make ~/openbios $ make rungui < device-example.fs It will use the FCode binary built into the plugin to initialize the virtual graphics hardware and output a character. Next thing I'm going to work on is to finish the terminal emulator and other support packages, then facing the client interface code to finally boot an operating system For the client interface it should make sense to reuse a lot of existing code, i.e filesystem drivers (GRUB), elf booting (Filo, LinuxBIOS), etc. by using the calling interfaces from forth to C and the other way round. Stefan

1 0

APIC 82489 datasheet
by fizjm＠univ.gda.pl 18 Nov '03

18 Nov '03

Hi all, Does anyone have a datasheet for APIC 82489 chip? I could not find it anywhere.. I understand that this chip is a replacement for I8259 used till now as an interrupt controller on a PC/AT. I would like to learn more, and to play with extra IRQs (IRQ15+) it provides. Most modern PC chipsets support this chip am I correct? Thanks for help. Janusz

2 1

Re: lib.fs missing in CVS
by Stefan Reinauer 10 Nov '03

10 Nov '03

Hi, good news. The fcode evaluator is working. init-fcode-table probably needs some work (table.fs) since iirc a child node should be able to see fcode words defined by the parent. At least byte-load now cleanly creates an fcode lookup table in alloc-mem'ed memory and frees it after evaluation which it did not do at all before. The verbosity of the fcode evaluator can be switched on/off with the value ?fcode-verbose. This also enables warnings about missing words during fcode table initialization. The latest code is in CVS. Test with following test-fcode.fs: ------------- 10 30 pci-l@ /n 8 = if 10 34 pci-l@ 20 << or then 0 byte-load bye ------------ After doing a make in the toplevel, do a make rungui < test-fcode.fs bye, Stefan

1 0

[PATCH] variable instatiation support
by Samuel Rydh 04 Nov '03

04 Nov '03

Hi, This patch adds variable instantiation support. It is intended to be used for device node instantiation. Some implementational details: - all template data is put into the dictionary. The thought behind this is to make it possible to put both methods and template data in a single wordlist. - instantiated variables are stored in a continuous block of memory (in contrast to the template data which is spread out in the dictionary). A small example file is also attached to this e-mail. Regards, /Samuiel

1 0

C bindings
by Samuel Rydh 31 Oct '03

31 Oct '03

Wouldn't it make sense to add some C-bindings to the forth kernel? I have examined all the built-in tokens and as far as far as I can tell there is currently no way to call an external function (well, save abusing the inb/outb mechanism). Some background: The forth kernel and the MOL OF loader are statically linked as a single binary (the ROM image). The MOL part of the code contains low-level support for exceptions and similar things. It also contains filesystem support, SCSI support, boot disk search algorithms, device tree handling and the OF client interface (and some other stuff). To make the C-code and the forth code interoperate, I would like to be able to 1. Call C-functions from forth code by pushing the address of the function on the stack. Something like call ( function_addr -- <whatever> ) 2. Be able to invoke the forth interpreter from C-code (I think this can be implementable without modifying the kernel code, but I haven't looked into it yet). I can of course solve the first point be adding a primitive to the words[] table, but wouldn't it make sense also for other projects? I imagine that a real-world implementation will implement some things in C (more people are familiar with C and there are already plenty of code written in C that can be reused; filesystems for instance...). /Samuel

2 6

Re: OpenFirmware and Mac-on-Linux
by Samuel Rydh 26 Oct '03

26 Oct '03

On Sat, Oct 25, 2003 at 02:45:19PM +0200, Stefan Reinauer wrote: > >Yes, I think so. I'm not sure exactly how much work is involved but > >I will give it a go (it is not necessary to do a full OF implementation > >right away...). > > > I can have a look on integrating the MOL OF functionality into > BeginAgain, but for putting BeginAgain into MOL I'd prefer if you could > try this first. Certainly. I don't think putting the MOL OF code directly into BeginAgain is such a good idea, at least not the current incarnation of the of-mol code. My thought was to add the BeginAgain kernel to of-mol and then gradually start to use it for OF client services and for user interaction. > >For MOL, the device tree is loaded from a config file (for MacOS, it is > >essentially a copy of a "real" device tree). Bus probing and > >similar things are not needed (although one could implement this > >if one really wants to). Cloning the device tree at OF startup is > >sufficient > >(just like most parts of the device tree is hardcoded in ROM in most > >machines). > > > Ah.. these device tree files I have seen. It's a really quick way of > setting resources up for different kinds of systems. Are the different > device trees needed for different purposes/machines? Yes, different device trees are used for different purposes. The Mac OS 9 device-tree originates from a B&W G3. Since only certain PCI-bridges and interrupt controllers are suppoerted by the OS, I have to use those in the device-tree. MacOS 9 also expects certain legacy hardware to be present (the via-cuda for instance). In general, I prefer to use virtual MOL hardware rather then emulated real-world hardware since this is much more efficient (the MOL OS side driver just makes "system calls" to MOL rather than accessing hardware through PCI register). The Mac OS X device tree has essentially been built from scratch. It contains more virtual MOL hardware than the Mac OS 9 tree. Since OSX is a much more open architecture, it is possible to write custom MOL drivers for things like interrupt controllers so there is no need to emulate any hardware at all. > Or is it just a matter of emulating the > kind of machine that you have Mol running on? No, MOL is completely hardware independent (except that 601 based CPUs are unsupported). > Do you have scripts for cloning the device tree in OpenFirmware? No, not in OpenFirmware. Under linux, a copy of the device tree is available under /proc/device-tree so it is just a matter of reformatting things into a format more suitable for MOL. > The device tree should actually be hardcoded for all onboard devices > and only expansion cards like PCI should be dynamically added. Yes, this is essentially what MOL does. Only a few minor tweaks are done to the device tree at startup (MOL supports three parallell virtual network cards, but typically only a single one is used). > In BeginAgain I've implemented a plugin > system that allows to emulate PCI cards in a simple manner. I planned to > do the Framebuffer output this way, but since OpenBIOS lacks a PCI > driver and a framebuffer driver you get nothing but a black window that > you can write to with lowlevel functions.. > > If you don't disagree I'd like to move this discussion to > openbios(a)lists.openbios.org in future. Sure. /Samuel

1 0

PC BIOS included in the project?
by Dedeco 25 Oct '03

25 Oct '03

Hello, I am a newbie in this subjet, and thus I do not know if my question is really redundant, but is this project also about PC's BIOS (e.g. American Megatrends)? How can I make something to change my BIOS? (after I understand how PC works (deeply), and know how to code) Thank you. __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com

2 1

Re: [OpenBIOS] First contact
by Stefan Reinauer 14 Oct '03

14 Oct '03

Hi Frank, * Frank Alcantara <frank(a)thyamad.com> [031014 14:00]: > I am a complete newbie in BIOS Area, I am starting this just now. So I > guess the freebios is the best option to my embedded projects. Few day > ago, I saw some posts about a Award bios source, this source should be > very usefully for who is starting, there are this source available? > Where can I find this? There are others bios sources available? I will > starting in freebios studying all possible sources and posting all of my > observations, please help me in this startup. Award BIOS Source code was illegally published quite a long while ago, but it is not advisable to use this for any purpose, since it is Award/Phoenix's intellectual property. See http://www.openbios.org/project/rules.html Since most closed source software is never reviewed by a huge amount of community people, I am deeply convinced that you can learn a lot more about techniques, concepts and implementation from the free firmware variants that are out there, namely LinuxBIOS, OpenBIOS, uboot, gbios, Proll, Tiara. Find the URLs at http://www.openbios.org/docs/links.html Stefan

3 3

EFI noise on slashdot
by Torsten Duwe 14 Oct '03

14 Oct '03

Just to again cause some traffic on this list ;-) If you, like myself, don't read slahdot, here's what I just came across as a search result. It is from end february, but I haven't seen an echo on this list, besides a comment from eric ["boy is EFI a kludge!"] in august which I'm not sure of whether it's related. http://slashdot.org/articles/03/02/20/189208.shtml "BIOS' Days Are Numbered" Set your comment threshold to 5 and/or search for openfirmware !-] It may be a good start to follow up on once we have something usable. Torsten

2 1

First contact
by Frank Alcantara 14 Oct '03

14 Oct '03

Hi I am a complete newbie in BIOS Area, I am starting this just now. So I guess the freebios is the best option to my embedded projects. Few day ago, I saw some posts about a Award bios source, this source should be very usefully for who is starting, there are this source available? Where can I find this? There are others bios sources available? I will starting in freebios studying all possible sources and posting all of my observations, please help me in this startup. Please forgive my awful English and thanks in advance. Frank Alcantara. Thyamad Consultoria. frank(a)thyamad.com http://www.thyamad.com

1 0

[announce] OpenBIOS Forth Kernel V1.1
by Stefan Reinauer 13 Oct '03

13 Oct '03

Dear OpenBIOS community, it's time for another update of BeginAgain, the OpenBIOS forth kernel, and it does deserve version number 1.1 It is available from the OpenBIOS CVS in the directory "kernel/" or at http://www.openbios.org/bin/kernel-1.1.tar.bz2 Changes since 1.0 ----------------- - some code optimizations speed BeginAgain up by an average of 20%, loops are up to 300% faster. - fixes, cleanups.. IO operations work now, compiling on BSD almost works ;-) - new plugin interface allows external plugins to emulate certain hardware. - A PCI plugin allows emulating PCI devices in the Linux/Unix version of BeginAgain - A QT plugin emulates a graphics card providing an 8bit framebuffer. There's currently no fcode driver yet to drive this framebuffer, but it can be accessed from forth. Installation and usage ---------------------- The beginning of documentation is available at http://www.openbios.org/development/kernel.html Bug reports ----------- Any trouble, bugs etc. should be reported to the openbios mailinglist <openbios(a)lists.openbios.org> Best regards, Stefan

1 0

Road-plan and other stuff?
by André-John Mas 07 Oct '03

07 Oct '03

Hi, I am new to the project and had a few questions. I have browsed around the OpenBIOS web site, to get an idea of what is going on and where its at. Looking at the 'progress' page I see that the work currently seems to be focused on the Forth core engine and the Forth base dictionary. As to the other projects there is no information, other than being at 0%. Has any one already suggested a direction for these projects and what they expect from them? For example, the user interface in all open firmware solutions I have seen so far (Sun boxes and Apple Macs, with new world ROM) all have a command line interface. Would it be conceivable to add a PC BIOS style GUI, in addition to the CLI for 'high-level' configuration. In addition, while doing a search on the web I came up with the following documents that might be useful - I hope none of them cause issue: From the Apple site: http://developer.apple.com/technotes/tn/tn1061.html http://developer.apple.com/technotes/tn/tn1044.html http://developer.apple.com/technotes/tn/tn1062.html http://developer.apple.com/hardware/pci/index.html - bottom: "Forth for Open Firmware Basics" tutorial presentations. Other stuff may be of interest. Elsewhere: http://homepage.mac.com/potswa/source/ http://people.cornell.edu/pages/ak234/BootSafe/main.htm http://www.hempeldesigngroup.com/lego/pbForth/ http://www.openppc.org/software.html - some references to open firmware http://www.software-x.com/software-x/bios.html regards André-John

2 1

[announce] OpenBIOS Forth Kernel V1.0 released
by Stefan Reinauer 16 Sep '03

16 Sep '03

Dear OpenBIOS community, After some months of development I am happy to announce the new OpenBIOS forth kernel "BeginAgain". It is available from the OpenBIOS CVS in the directory "kernel/" or at http://www.openbios.org/bin/kernel-1.0.tar.bz2 Features -------- - indirect-threaded forth engine - openfirmware user interface - small and portable - easily enhancable Platform Notes -------------- Currently targets for X86 PCs and AMD64 exist. The OpenBIOS forth kernel was developed using gcc on Linux systems. Minor changes might be necessary in non-linux/gcc build environments. Design Goals ------------ The design goals of "BeginAgain" were: 1) Portability 2) Maintainability 3) Small Size ---------------------------------------------------------------------- 1) Portability BeginAgain, with minimal changes, will work on new systems. There is support for X86 and AMD64 at the moment. Implementing support for new systems only requires adaptions to the start code and system abstraction. The current code has been developed using gcc 3.x, but no explicit GCCisms are used. Since gcc is the most widely spread compiler, it should be a good base for easily porting OpenBIOS to new platforms. 2) Maintainability The code is split into several parts: _________________________________________ | | | Forth dictionary | |_________________________________________| ^ | forth code ________|_________________________|_________ | | | v native code _____________ ___________________ | | | | | Scheduler | ----> | primitive words | |_____________| |___________________| ^ ^ | | | | _____________ ____________________ | | | | -->| Startup | | system abstraction | |_____________| |____________________| Platform dependent part ----------------------- a) After taking control the "scheduler", in forth context called "inner interpreter, reads the forth dictionary, a list of nested word definitions that are built using primitive words. b) These primitive words are written in C, so they take advantage of the compiler's ability to optimize code. They represent the minimum set of forth words that are needed to define all language constructs, including the Open Firmware system. c) The startup code is probably the most platform sensitive code. It's task is simple - get the scheduler up and running and provide a dictionary to execute. OpenBIOS provides multiple boot targets per platform. For example, on x86 it is possible to run the kernel either from Grub or LinuxBIOS. An additional target (available on all platforms) allows running the code from a Unix shell. d) The system abstraction part ought to be kept as small as possible. The primary words provide an interface for non-memory-mapped IO, and there's a small builtin console due to the fact that OpenBIOS has no device tree and/or drivers at the moment. Once these platform dependent parts are in place, they can be used to create an indirect-threaded dictionary file. This dictionary file contains a platform abstracted version of forth code that currently depends on the endianness and pointer (cell) size of the target platform. To keep the forth dictionary and the native code strictly seperate the unix hosted version of the kernel has a small builtin interpreter able to bootstrap all of the base system including a forth written interpreter, which represents part of the openfirmware user interface. In a second stage the advanced forth written interpreter is used to extend the bootstrap dictionary with additional features. As an example, ANS forth wordlist support is added, which will be used in the device tree code. Currently the OpenBIOS dictionary contains a nearly complete implementation of the Open Firmware user interface. It passes the Hayes ANS Forth test suite that is run when OpenBIOS is built, writing it's output to the file forth.html. Since the machine is abstracted as early and completly as possible, porting OpenBIOS to a new platform requires only minor efforts. 3) Small size The less code that needs to be adopted when porting OpenBIOS to a new platform, the quicker new ports can happen. Therefore the OpenBIOS kernel is really small. Here is a sample: size in | x86 | amd64 bytes | gcc 3.3 | gcc 3.3.1 -----------------+---------+---------------- multiboot kernel | 6724 | 15464 -----------------+---------+---------------- LinuxBIOS kernel | 7016 | 15896 -----------------+---------+---------------- LinuxBIOS kernel | | inc. dictionary | 27048 | 52920 -------------------------------------------- Installation and usage ---------------------- Run "make" to compile all binaries and dictionaries required to run the OpenBIOS kernel $ make Per default all binaries will be placed in the directory obj-{platform}. Then you can execute the kernel from a shell, by giving the command $ make run To boot LinuxBIOS from GRUB, copy openbios.multiboot and openfirmware.dict to /boot, then add a new entry to your menu.lst config file which looks like this: -------------------- 8< -------------------- title openbios kernel (hd0,2)/boot/openbios.multiboot module (hd0,2)/boot/openfirmware.dict -------------------- 8< -------------------- (hd0,2) is the equivalent to the Linux partition /dev/hda3 OpenBIOS can be used as a payload to LinuxBIOS (www.linuxbios.org) or booted in EtherBoot (www.etherboot.org). The simplest way is to use the kernel that includes the full dictionary: openbios.full Bug reports ----------- Any trouble, bugs etc. should be reported to the openbios mailinglist <openbios(a)lists.openbios.org> Further Development ------------------- BeginAgain is pretty much complete now. Expect only bugfixes and optimizations in the future. Interpretation mode versions of most loop constructs should be included although they are not really needed to get more development going. The next steps in writing an Open Firmware implementation is to complete the Device and Client Interfaces. These two parts are needed to set up a device tree, initialize hardware, and boot the operating system. Once there is a device tree and some basic device interface functions it will be possible to run fcode drivers for device initialization in OpenBIOS, using the FCode evaluator that resides in the OpenBIOS CVS directory forth/evaluator/. Regards, Stefan

1 0

New Mailinglist!
by Daniele Frijia 26 Aug '03

26 Aug '03

Hello, we moved the mailinglist to lists.openbios.org. So please use openbios(a)lists.openbios.org for posting to the mailinglist. Listinfos are available at http://lists.openbios.org/ The old passwords are not valid anymore! Please send errors regarding the mailinglist to daniele(a)openbios.org Regards, Daniele -- Free your System! | May the forth be with you. http://openbios.org/ List stuff: http://lists.openbios.org/

1 0

source of blank eeprom chips??
by Jack Cawkwell 02 Jul '03

02 Jul '03

Hi, I am having problems finding places to buy empty flash 32 pin eeprom chips, suitable for use as BIOS chips. I would like to experiment with an empty one, rather than risk permanently damaging the existing one. Does any one know a good source of supply. How do you decide what speed is required? How do I go from the writing on the chip to a eeprom spec, eg AE29f2008-12, or 28F1000PPC-12C4, or 208GH213286801SA Thanks Jack _______________________________________________ OpenBIOS mailing list OpenBIOS(a)freiburg.linux.de http://freiburg.linux.de/cgi-bin/mailman/listinfo/openbios

3 2

devbios port to MTD
by Jeremy Jackson 16 Mar '03

16 Mar '03

Hi, I've been hacking away for a few days at the devbios code, my goal being to port it to the MTD framework. Apart from being "the right thing" in my opinion, as well as in the devbios TODO, it solves a few practical problems: It will let BIOS EEPROMS or DoC be programmed in a network card socket (eepro100 only just now with Eric Biederman's patch - PLCC32 socket. I want to do tulip next so I have a DIP32 as well) to avoid having to swap chips with the power on. It also lets the BIOS chip be made read-only, yet have a DoC that is R/W (well they have to be). And many more. So far I have refactored devbios to eliminate global variables (void *bios), and static flashdevice structures. The flash probing routine is now a separate "library", which can use devbios flash_{readb,writeb}, or when linked into MTD, will use the map driver's access routines. The MTD chip driver which uses the probe routine is about half done. Any enhancements to the devbios probe routine "library" will automatically enhance the MTD chip probe routine as well. I plan to make map drivers out of the devbios pcisets.c code in a similar manner. I'm posting this to elicit comments from the respective parties, words of wisdom, cautions, etc. I will post the initial devbios refactoring patch once I've checked it over again. Regards, Jeremy -- Jeremy Jackson <jerj(a)coplanar.net> _______________________________________________ OpenBIOS mailing list OpenBIOS(a)freiburg.linux.de http://freiburg.linux.de/cgi-bin/mailman/listinfo/openbios

2 1

Tiny Open Firmware
by Dwight Schauer 23 Feb '03

23 Feb '03

Have any of you looked at TOF? TOF is Tiny Open Firmware and can be fount at http://www.tinyboot.com >From the site: Tinyboot Ultra-flexible firmware through the magic of Forth. Tiny Open Firmware (TOF) for Coldfire, 68K and 8031 processors It is in the public domain. _______________________________________________ OpenBIOS mailing list OpenBIOS(a)freiburg.linux.de http://freiburg.linux.de/cgi-bin/mailman/listinfo/openbios

2 1

problems compiling pforth
by Dwight Schauer 17 Feb '03

17 Feb '03

From: "Phil Burk" <philburk(a)softsynth.com> To: "Dwight Schauer" <das(a)teegra.net> Date: Sun, 16 Feb 2003 19:52:37 -0800 Hello Dwight, Thanks for the notes. I'll apply the mods for the next rev. ALso you may want to download the "pfthpc21.zip". The project is for Windows but the portable source code will work with Unix and is more recent. Sorry that I haven't updated the UNix rev in a while. Other projects demand my time. Phil Burk ----- Original Message ----- From: "Dwight Schauer" <das(a)teegra.net> To: <philburk(a)softsynth.com> Sent: Sunday, February 16, 2003 7:19 PM Subject: pfthunix19 > Hello Phil, > > I just downloaded pfthunix19.tar.Z > > I compiled it with gcc (GCC) 3.2.1 20021207 (Gentoo Linux 3.2.1-20021207) and > ran into a few problems. I thought I'd let you know, as you set you wanted to > be notified of such things. > > I ran into some problems and had to make a few changes. > > 20:22 < Stepan> csrc/pfcustom.c:85: invalid conversion from `int32 (*)(long > int)' to `void*' > 20:22 < Stepan> csrc/pfcustom.c:85: invalid conversion from `void (*)(long > int, long int)' > > --- pfcustom.c.orig 2003-02-16 20:48:48.000000000 -0600 > +++ pfcustom.c 2003-02-16 20:49:35.000000000 -0600 > @@ -80,8 +80,8 @@ > > void *CustomFunctionTable[] = > { > - CTest0, > - CTest1 > + (void*)CTest0, > + (void*)CTest1 > }; > #endif > > 20:49 < Dwight> objects/pf_cglue.o(.eh_frame+0x11): undefined reference to > `__gxx_personality_v0' > 20:49 < Dwight> objects/pf_core.o(.eh_frame+0x11): undefined reference to > `__gxx_personality_v0' > 20:49 < Dwight> objects/pf_inner.o(.eh_frame+0x11): undefined reference to > `__gxx_personality_v0' > 20:49 < Dwight> objects/pf_main.o(.eh_frame+0x11): undefined reference to > `__gxx_personality_v0' > 20:49 < Dwight> objects/pf_save.o(.eh_frame+0x11): undefined reference to > `__gxx_personality_v0' > 20:49 < Dwight> objects/pf_text.o(.eh_frame+0x11): more undefined references > to > `__gxx_personality_v0' follow > 20:49 < Dwight> collect2: ld returned 1 exit status > 20:49 < Dwight> make: *** [pforth] Error 1 > > --- makefile.orig 1998-04-06 19:43:01.000000000 -0500 > +++ makefile 2003-02-16 20:52:18.000000000 -0600 > @@ -27,7 +27,7 @@ > -Wmissing-declarations > > CCOPTS = -DPF_SUPPORT_FP $(FULL_WARNINGS) > -COMPILER = gcc > +COMPILER = g++ > > EMBCCOPTS = -DPF_NO_INIT -DPF_NO_MALLOC -DPF_NO_FILEIO \ > -DPF_NO_CLIB -DPF_STATIC_DIC > > > pforth -i system.fth > make: pforth: Command not found > make: *** [pforth.dic] Error 127 > > To make, I had to do a "export PATH=$PATH:. make", as pforth was being > executed while not in the path. > > Dwight > > _______________________________________________ OpenBIOS mailing list OpenBIOS(a)freiburg.linux.de http://freiburg.linux.de/cgi-bin/mailman/listinfo/openbios

2 2

mailing list changes
by Stefan Reinauer 08 Jan '03

08 Jan '03

Dear OpenBIOS readers, due to a new installation of freiburg.linux.de the majordomo driven OpenBIOS mailing list has been switched to Mailman, which offers some nice features like a web frontend for administration and users, daily digests etc.. The configuration is now pretty similar to the one used before with majordomo, ie. only subscribers are allowed to post to the list and all topics get the [OpenBIOS] string prepended. As mailman requires a password for changes on the subscription, this password will be mailed to you once per month. You can also have the password sent to you by request via the web frontend. Find the OpenBIOS mailinglist web frontend at the following URL: http://freiburg.linux.de/cgi-bin/mailman/listinfo/openbios If you experience any trouble with the new configuration or the mailing list in general, please write direct email to me. Comments are welcome. Stefan -- The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense. -- E. W. Dijkstra _______________________________________________ OpenBIOS mailing list OpenBIOS(a)freiburg.linux.de http://freiburg.linux.de/cgi-bin/mailman/listinfo/openbios

1 0

��T��O�I�u�f�M��
by mlpi_y_rff0l2dw＠amazon.com 06 Jan '03

06 Jan '03

1 0

THANKS & GOD BLESS
by omorodioneki＠phantomemail.com 06 Jan '03

06 Jan '03

MRS. EKI OMORODION # 8 Queens Drive Ikoyi Lagos. Email:omorodioneki@netscape.net INTRODUCTION: l am Mrs. Eki Omorodion l know this proposal will come to you as a surprise because we have not met before either physically or through correspondence. I have no doubt in your ability to handle this proposal involving huge sum of money. THE SUBJECT: MY HUSBAND CHIEF JOSEPH OMORODION (Now Late) was the Royal Head of my Community, JESSE (an oil rich town)in Nigeria. My late husbandS community produces 3.5% of the total crude oil production in Nigeria and 0.5% of the Dollar value of each barrel is paid to my husband as royalty by the Federal Government. My husband was also the Chairman of OMPADEC,Jesse branch. In his position as the Royal head and Chairman of the OMPADEC, Jesse branch, he made some money which he left for me and our children as the only thing to inherit. The money is Twelve Million US Dollars($12M). Though this said fund accumulated between the period 1976-1998. Due to poor banking system in Nigeria and political instability as a result of past Military rules (1985-1999), he deposited this Money in a Strong Room/safe with an open beneficiary in Apex Bank of Nigeria pending when he would finish arrangement to transfer it abroad as a CONTRACT PAYMENT. He was planning this when he died late last year of Heart Attack. THE PROPOSAL: Just before my husband died he called my attention to the money and charged me to look for a foreigner who would assist me in the transfer / investment of the funds abroad. So l would be very grateful if you could accept to help me archieve this great objective. I promise to give you 20% of the total funds transferred to your vital bank account as compensation for your assistance. Five percent (5%)would be set aside to take care of all expenses we may incure during the transaction. To indicate your interest, contact me urgently and confidentially for more information and the roles you will play in this business. All the legal information concerning this Money will be sent to you as soon as we agree together. Send your reply through this mail box, or see the note below Yours faithfully, MRS. Eki Omorodion. N.B I will like you to provide me immediately with your full names, telephone and fax numbers to enable my eldest son samson Omorodion to contact you. He shall handle this transaction from A-Z on behalf of the family. Alternatively you can call him on his telephone numbers 234-1-7761459, 873-762-533-730, fax 873-762-533-731 Ask him for the code and he shall respond GOODLUCK before discussion. Just to be sure that you are speaking to him. -------------------------------------------------- This email is a free service of Phantom Email available at http://phantomemail.com/. Looking for a date? Check out http://personalinteractions.com/go/p185.

1 0

linux bios
by Deva Seetharam 03 Jan '03

03 Jan '03

Hello, does any know where i can find the latest info about the linux bios project? pls. let me know (i tried their website (linuxbios.org), but is down; sent mails to the authors, didnt get any response.) thanks, Deva Seetharam

4 8

§â´¤§Aªº¤H¥Í¡C
by hanmau2＠www.freel23.idv.tw 26 Dec '02

26 Dec '02

1 0

devbios problems
by Peter Kögel 21 Dec '02

21 Dec '02

Hello, last week a had time to run devbios on my sis735 based motherboard but there are some questions/problems: In sis_activate it seems that address 0x51 of the virtual kernel address space is accessed. // sis_activate(): .. pci_dummy[1]=readb(0x51); .. writeb(pci_dummy[1] & 0x7f, 0x51); .. // sis deactivate(): .. writeb(pci_dummy[1], 0x51); .. This leads to an segmantation fault in my case. Can someone explain me what this code should do? The comment says: /* disable cache */ static void sis_activate(void) { char b; hostbridge = pci_find_class(PCI_CLASS_BRIDGE_HOST<<8,NULL); if (!hostbridge) return; pci_dummy[0]=pci_read(hostbridge, 0x76); --> pci_dummy[1]=readb(0x51); pci_dummy[2]=pci_read(CURRENT, 0x40); pci_dummy[3]=pci_read(CURRENT, 0x45); /* disable shadow */ pci_write(hostbridge, 0x76, 0x00); /* disable cache */ --> writeb(pci_dummy[1] & 0x7f, 0x51); /* Enable 0xFFF8000~0xFFFF0000 decoding on SiS 540/630 */ pci_write(CURRENT, 0x40, pci_dummy[2]|0x0b); /* Flash write enable on SiS 540/630 */ pci_write(CURRENT, 0x45, pci_dummy[3]|0x40); /* The same thing on SiS 950 SuperIO side */ outb(0x87, 0x2e); outb(0x01, 0x2e); outb(0x55, 0x2e); outb(0x55, 0x2e); if (inb(0x2f) != 0x87) { /* printf("Can not access SiS 950\n"); */ return; } outb(0x24, 0x2e); b = inb(0x2f) | 0xfc; outb(0x24, 0x2e); outb(b, 0x2f); outb(0x02, 0x2e); outb(0x02, 0x2f); } The next thing I noticed is that the ATMEL29C010A doesn't like the flash_program_atmel() code. When I use the flash_program -code everything is fine. void flash_program (void) { flash_command(0xa0); } void flash_program_atmel (void) { flash_command(0x80); flash_command(0x20); } The AT29C010A data sheet says that: the code in flash_program() is used: 1. to activate data protection 2. ac "program"-command when data protection is activated the flash_program_atmel() code does switch of the data protection. I dont know why the flash_program_atmel() code doesn't work for me since it agrees with the data sheet. Then there is another problem. (Since the ?? cache disable code ?? (see above) was commented out I switched off all cache options in BIOS setup: BIOS ROM cachable, L1 + L2 Cache of processor.) When loading the devbios module the flashrom is detected correct and I can read it with dd if=/dev/bios | hex|less. I also can write to the flash with dd if=/dev/zero of=/dev/bios bs=128 count=1. After this write access the flashrom can be read with dd to verify that the data is written properly. The problem is that after the write access no more flash commands can be executed. That means that every other write to the bios does fail and when I rmmod bios insmod bios.o then the kernel module doesn't detect the flashrom until next reboot (the identification command does not work). I tried this with the EON29F002NT-flashrom which belongs to the board, but did not write on that, and the ATMEL. Since both flashroms are not detected this cannot be a flashrom problem. I modified bios_write-function to use flash_ready_toggle() instead of flash_ready_poll() and printk timeout variable (the number of toggles+1) to see if the flash accepted my write commands. After rebooting an loading the bios.o module I did a dd if=/dev/zero of=/dev/bios bs=1024 count=1 for the first 128k sector flash_ready_toggle reported timeout=ca. 4000 for all other sectors flash_ready_toggle reported timeout=1 (0 toggles). This means that the first sector write succeeds, but all following fail. I don't understand this becaus in the programming loop of bios_write no strange things are done: while (size>0) { // atmel-specific code commented out - reasons described above: //if ((flashchips[fn].flags & f_manuf_compl) != f_atmel_compl) { flash_program(); //} else { // flash_program_atmel(); //} for (i=0;i<flashchips[fn].pagesize;i++) { flash_writeb(offset+writeoffs+i,clipboard[writeoffs+i]); } if ((flashchips[fn].flags & f_manuf_compl) == f_atmel_compl) { udelay(750); } else { if (flashchips[fn].pagesize==1) udelay(30); else udelay(300); } if (flash_ready_poll(offset+writeoffs+flashchips[fn].pagesize-1, clipboard[writeoffs+flashchips[fn].pagesize-1])) { printk (KERN_ERR "BIOS: Error occured, please repeat write operation.\n"); } flash_command(0xf0); writeoffs += flashchips[fn].pagesize; size -= flashchips[fn].pagesize; } I hope that someone can help me to fix the problems. Regards, Peter Kögel - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

3 3

Re: [OpenBIOS] OpenBIOS for TFTP
by Stefan Reinauer 18 Dec '02

18 Dec '02

Hi Jack, > Many thanks for your useful answer. I do not quite understand > the difference between openbios and linuxbios, to the > uninitiated like me they sound like the same thing. LinuxBIOS was started quite some time ago after the OpenBIOS project only had a little bit of practically useless code. It concentrated on doing the very basic initialization of a machine, i.e. dram init and pci init. Early versions then gave control to a Linux kernel that was able to boot another Linux kernel (so one would gain all the hardware support to load a recent kernel from any device). By now LinuxBIOS has many more options, like using Etherboot or the Bochs bios for booting an OS and it can boot a couple of operating systems (including some windows flavours afaik) OpenBIOS basically starts where LinuxBIOS ends - it aims at implementing an IEEE 1275-1994 Open Firmware system that is able to use the platform independent boot code available on quite some expansion cards. Open Firmware is available commercially on many platforms and at least Linux and BSD know how to communicate with it. Open Firmware has an object oriented driver design which makes it easy to write simple drivers for hardware initialization that is not dependent on the underlying CPU Stefan -- The x86 isn't all that complex - it just doesn't make a lot of sense. -- Mike Johnson, Leader of 80x86 Design at AMD Microprocessor Report (1994) - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

2 1

OpenBIOS for TFTP
by Stefan Reinauer 13 Dec '02

13 Dec '02

Dear Jack, > Can OpenBIOS be used to initiate tftp booting across the ethernet? > The alternatives of making a eprom memory strip, or having an eprom > in the NIC, are more expensive and time consumming, so I am keen > to use OpenBIOS for this. > > I have looked through the news history, and the web site and still > cannot find the answer. (but of course that doesn't mean much) Unfortunately OpenBIOS is not ready for prime time yet. I am currently working on the forth engine and trying to fiddle vocabularies support into it - one big step towards Package (driver) support. You might want to have a look at LinuxBIOS though: www.linuxbios.org. It can be used together with an etherboot payload to boot a kernel loaded via tftp. (I'm doing the same thing on a Geode system) Stefan -- Laissez Faire Economics is the theory that if each acts like a vulture, all will end as doves. - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

2 1

None
by Jack Cawkwell 13 Dec '02

13 Dec '02

Hi, Can OpenBIOS be used to initiate tftp booting across the ethernet? The alternatives of making a eprom memory strip, or having an eprom in the NIC, are more expensive and time consumming, so I am keen to use OpenBIOS for this. I have looked through the news history, and the web site and still cannot find the answer. (but of course that doesn't mean much) Thanks Jack. - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

1 0

forth kernel and dictionary dumping
by Stefan Reinauer 19 Oct '02

19 Oct '02

Hi,.. basically one of the problems we see before we can ever push OpenBIOS to flash is that we need a way of getting Forth code executed that is not part of paflof's unreadable preprocessor magic. I've started writing code to dump a dictionary from within paflof and read it back in. This gives several advantages: * paflof can be used to bootstrap openbios forth code * the c core can be developed seperately from the forth code running on top of it. * the base engine can be changed easily as it will be rewritten in forth instead of generating a binary dictionary with the C preprocessor as it is done now. * it will be easy to change the amount of packages/features that will be flashed. This is needed because we don't want to feed forth source to the C core while running from flash, but rather compiled forth and FCode. Before we can run fcode, we need a way of making the evaluator I wrote accessible from paflof during early bootup. One of the nice side effects is that the C kernel can be reduced in size (it is now 17k, most of it being debugging information) How does the thing work? Currently there's a word DUMP-DICTIONARY which will dump the current dictionary to a relocatable ELF file dict.dump, that will be loaded automatically when paflof is started the next time. There is one minor glitch left to fix, but it can be worked around manually: LAST/LATEST is not set correctly after bootup (well, it is, but it's overwritten again.) When loading, it will tell you "LAST/LATEST=0xDEADBEEF" shortly before the ok prompt. then do a "DEADBEEF DUP LAST ! LATEST !" to make the loaded words actually visible. after that all should work as usual, just with a loaded dictionary. Maybe this glitch can be worked around when moving the engine.in to engine.fs as there will be a new LAST/LATEST. (which will not be used until :, VARIABLE, CONSTANT etc are redefines. It might be enough to just set this to a valid value just before : etc are defined (which would require the dict.dump to be the only dictionary, with no other dictionary left) There's currently three kinds of relocations in the ELF file: Internal, external and CFA relocations. * Internal relocs are just references within the dictionary. To fix these up, the old start address of the dictionary is subtracted and on load, the new address is added. * external relocs. These reference an external word in the dictionary. if you use DUP, for example, it will relocate against that word, no matter whether it's moved around in the dictionary. * CFA relocations are used to relocate against native prim words (code) paflof keeps a list of prim words and relocates them by a list index. This means a dictionary has to be redumped when the number of prim words changes. I also managed to write a new prim word to the dictionary, using HERE LAST @ , \ backlink 0 C, \ flags 3 C, 44 C, 55 C, 50 C, 0 C, 0 C, 0 C, \ 0 padded name (only on 32bit machines) ' DUP @ , \ fetch old prim CFA DUP \ update LAST/LATEST to the beginning of the new word DUP LAST ! LATEST ! What will be the next step in development? We need to finish the engine.fs (a rewrite of engine.in in pure forth) that I already started. this is going to be the next bigger goal in development. After that dictionary scopes will be a lot easier to implement as it does not have to be done in preprocessor macros. Last but not least, get the code at http://www.freiburg.linux.de/OpenBIOS/bin/paflof-dump-20021016.tar.gz Any comments, flames, tests, etc are heavily welcome. Best regards, Stefan Reinauer -- The x86 isn't all that complex - it just doesn't make a lot of sense. -- Mike Johnson, Leader of 80x86 Design at AMD Microprocessor Report (1994) - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

2 2

CREATE in paflof
by Stefan Reinauer 02 Oct '02

02 Oct '02

Hi, I've been trying to get Bernd Paysan's Mini-OOF (find it at http://www.jwdt.com/~paysan/mini-oof.html ) working with paflof. Mini-OOF is a small OO-layer written in Forth which might be interesting in regard to the package handling, which paflof still lacks. The example works fine in gforth, as far as i can see. I'm using these two definitions to let mini-oof compile in paflof without exceptions: ------- 8< ---------- : /string ( addr len n -- addr+n len-n ) tuck - -rot + swap ; 0 cell+ constant cell ------- >8 ---------- Unfortunately there seem to be several problems: * the example mentioned on the page makes paflof segfault at END-CLASS. * paflof and gforth (ANS Forth?) seem to have different opinions about how to implement ['] and ' in compile mode. I.e. the following definition : defines ( xt class -- ) ' >body @ + ! ; leaves an xt on the stack in paflof, as ' is immediately. * CREATE ought to read the create-word's name from the TIB in paflof, using : CREATE PARSE-WORD $CREATE ; Thus, CREATE cannot be used in a colon definition, as there is nothing valid in the text input buffer. In ANS Forth, this should be possible. gforth's definition of CREATE is : Create header reveal dovar: cfa, ; Any ideas how to solve these problems are welcome.. Stefan -- The x86 isn't all that complex - it just doesn't make a lot of sense. -- Mike Johnson, Leader of 80x86 Design at AMD Microprocessor Report (1994) - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

2 1

Debugging using Openbios
by Aman 05 Aug '02

05 Aug '02

Hi All I have PPC440 Eval Kit. With the kit I have got RiscWatch Debugger. The PPC 440GP board has a openbios rom monitor program. I am able to communicate with target from host [Windows 2000] machine. Now I want to write a sample code code like below and download the code to the target using Riscwatch debugger. void main() { printf("hello World\n"); } I have complied the code using hcppc compiler and got the testApp.o file.However when I download to the target, it is not recognizing the code. I am new to open bios so I am facing difficulties. Can anyone tell me how to debug some C code using RiscWatch debugger and openbios. Thanking you in advance regards Aman - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

1 0

memory management
by Stefan Reinauer 02 Aug '02

02 Aug '02

Hi, After quite some silence I've checked in alloc-mem and free-mem today. I used a simple free list allocator that does, unlike a buddy allocator, not distinguish between different block sizes. The free list is always sorted by address range, thus allowing to allocate/insert with a worst case of O(n) (Due to using a linked list). This was the happy medium between having a pretty complex implementation giving optimal run time and ease of reading/debugging which is definitely something you want at this level. The free list entries are kept in place, so no additional space outside the memory space is needed to do the house keeping. A free list entry looks like follows: size | type -------------- cell | length of this entry cell | pointer to next entry len | memory itself. When the memory is allocated, the pointer to the next entry becomes invalid, thus it is used as memory as well. Therefore the length field includes that cell in the usable memory area length. On freeing, boundaries are checked against existing free list entries. If blocks can be merged, they are merged immediately in free-mem. There's also a small test suite that shows it actually works. the memory management stuff itself can be found in CVS at openbios/forth/base/memory.fs the testsuite is at openbios/forth/testsuite/memory-testsuite.fs if memory-testsuite.fs and memory.fs are in the same directory, you can just call the test suite with paflof < memory-testsuite.fs 2>/dev/null (the 2>/dev/null prevents the dictionary dump at program end, because for quickhacked getting a usable memory area i allocated 256k dictionary space. In a working system the memory area to use will probably be parsed from the LinuxBIOS table) Any comments are welcome. Stefan -- The x86 isn't all that complex - it just doesn't make a lot of sense. -- Mike Johnson, Leader of 80x86 Design at AMD Microprocessor Report (1994) - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

1 0

LinuxFund.org
by John R. Hogerhuis 09 Jul '02

09 Jul '02

>From LinuxFund.Org site: "Spring Cycle Funded by Jerritt Collord on 07/04/02 Projects funded for the cycle ending June 1 were: OpenBIOS, Reptile and AnonNet. Thanks to all the LinuxFund.org applicants and we look forward to seeing more ideas from from everyone." Congratulations, guys! -- John. __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

1 0

$find
by Stefan Reinauer 30 Jun '02

30 Jun '02

Hi,.. I just noticed some weirdness with $find when I do 0 > s" constant" $find ok I get 3 > .s 120019b88 0 -1 ok The definition from IEEE 1275-1994 is: $find ( name-str name-len -- xt true | name-str name-len false ) Our definition seems to be wrong: col($FIND LAST @ >R 2DUP R@ COMP-WORD ?BRANCH(9) 2DROP R> DUP >XCODE SWAP CELL+ C@ TRUE EXIT R> @ ?DUP 0= ?BRANCH(-21) 2DROP FALSE) what exactly does "SWAP CELL+ C@" do? should this not just be a NIP ? according to this we would have to change COMPILE-WORD, INTERPRET-WORD, ', POSTPONE and FIND, some of which do the NIP afterwords themselfes, as far as i can see. Any comments? Stefan -- The x86 isn't all that complex - it just doesn't make a lot of sense. -- Mike Johnson, Leader of 80x86 Design at AMD Microprocessor Report (1994) - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

2 8

Re: Paflof update
by Stefan Reinauer 30 Jun '02

30 Jun '02

* Segher Boessenkool <segher(a)chello.nl> [020623 18:15]: > > * use c style comments to not break non gcc compilers (compile > > with -ansi -pedantic) > > Try compiling it on a non-gcc compiler. It won't work. But it's a step closer. > > * implement unaligned-w@, unaligned-w!, unaligned-l@, unaligned-l! > > I'd rather have these implemented in Forth; we have too many primitives > already. I don't agree on this. Unaligned accesses are slower than the aligned versions anyways, plus we need to bloat the forth code with endianess checks where we can solve this in the preprocessor in C. I made Forth versions of these words as well, but while thinking about when you need unaligned accesses, I came to the conclusion that you probably don't want further slowdown. It's ugly that you have to break up atomicity of the access anyways. > > * use conf.pl to create types.h according to compiler capabilities > > (cross compiling possible) (cleaner version then last patch) > > I don't like it yet... What's wrong? > > * move unix host code from prim.code to unix.code > > Please leave it where it is, for now. We'll move it when we compile > stuff from source (as opposed to the current situation: from a precompiled > dictionary). Which reminds me that we also need support for multiple linked dictionaries when doing packages. Though maybe it might be enough to have multiple fcode lookup tables in the fcode evaluator? Is there any trivial way of doing this? Stefan -- The x86 isn't all that complex - it just doesn't make a lot of sense. -- Mike Johnson, Leader of 80x86 Design at AMD Microprocessor Report (1994) - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

2 5

ANSI
by Stefan Reinauer 30 Jun '02

30 Jun '02

Hi,.. I played a bit with the paflof sources and made them compile cleanly using gcc -ansi. I had to remove the C99 specific *restricted stuff (which did not change performance at all) Second issue was to replace C++ style comments as they are not allowed in ANSI C. The patch changes any occurence to either #ifdefs if it's code or C style comments in case of real comments. I checked it against the hayes test and got the same output as with mainstream paflof. I strongly suggest to apply this patch - this would allow a lot more people to use paflof and probably get this compiled on almost any host system. Please comment on the patch. If there is no good reason against it, this is definitely the way to go. Best regards, Stefan Reinauer -- The x86 isn't all that complex - it just doesn't make a lot of sense. -- Mike Johnson, Leader of 80x86 Design at AMD Microprocessor Report (1994)

4 17

FCode Evaluator
by Stefan Reinauer 28 Jun '02

28 Jun '02

Hi.. I uploaded a first version of an FCode evaluator written in Forth to http://www.freiburg.linux.de/OpenBIOS/bin/evaluator-20020628.tar.gz Most of the fcode specific forth words are missing and, like paflof, this evaluator does not know about instances or different dictionaries It can execute simple fcode files and it knows how to define named and external colon definition words, but that's about it. There's a small readme and a little bit of example code with it. Any comments and flames are welcome. If this approach is considered ok, I will go and drop feval from the CVS and the web pages, as we are equally far (actually a lot further) with the paflof+evaluator implementation now. This should be one of the few needed steps to get OpenBIOS towards the point where it can be flashed to ROM with LinuxBIOS as IPL. Stefan -- The x86 isn't all that complex - it just doesn't make a lot of sense. -- Mike Johnson, Leader of 80x86 Design at AMD Microprocessor Report (1994) - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

1 0

Re: [OpenBIOS] Re: Paflof update
by Parag Patel 28 Jun '02

28 Jun '02

>is it legal for an fcode program to overload words defined within the >lower space (i.e. 0x000-0x5ff)? Actually, yes. Look at the PCI bus binding for one example where rl! rl@ rw! and rw@ may be overridden to handle endian issues. -- Parag - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

3 2

Re: [OpenBIOS] $find
by Parag Patel 28 Jun '02

28 Jun '02

>SEE still needs the word's name, which is ugly to get when you have >the XT only. Both SmartFirmware and Sun's Forth OpenBoot implementations will parse the word as a number and use it to lookup an XT, if the initial word lookup fails. This lets you "see" headerless words. -- Parag - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

2 1

Re: [OpenBIOS] Re: Paflof update
by Parag Patel 27 Jun '02

27 Jun '02

In message <20020627152137.GC799(a)suse.de>, Stefan Reinauer writes: >> >> Actually, yes. Look at the PCI bus binding for one example where rl! >> rl@ rw! and rw@ may be overridden to handle endian issues. > >Hmm. Do I get this right? In this case Dunno - I haven't actually been downloading nor looking at your code. :) A few things just sort of jog my memory for non-obvious stuff. SmartFirmware is primarily C-oriented with Forth tacked-on, so my tricks may not apply. -- Parag - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

1 0

Paflof update
by Stefan Reinauer 24 Jun '02

24 Jun '02

Hi, some updates on paflof I made recently: * use c style comments to not break non gcc compilers (compile with -ansi -pedantic) * implement unaligned-w@, unaligned-w!, unaligned-l@, unaligned-l! * implement 2constant * fix typo in dict.source * use conf.pl to create types.h according to compiler capabilities (cross compiling possible) (cleaner version then last patch) * move unix host code from prim.code to unix.code Best regards, Stefan Reinauer -- The x86 isn't all that complex - it just doesn't make a lot of sense. -- Mike Johnson, Leader of 80x86 Design at AMD Microprocessor Report (1994)

2 2

Some thoughts on paflof.
by Stefan Reinauer 14 Jun '02

14 Jun '02

Hi... to get things to a point where smaller projects can be split off OpenBIOS allowing easier and more wide-spread development, we should change paflof to some point where it is usable for development... Some random thoughts that are written down below. Please comment on this.. We got to get it going asap... * according to IEEE 1275 paflof needs to be able to parse words case independant. To achieve this we have to change parse word to uppercase a word before it is looked up. hex : uppercase ( char -- uppercasechar ) dup 61 7a between 20 - ; : uppercases ( addr len -- ) bounds do i c@ uppercase i c! /c +loop ; PARSE-WORD should then contain 2DUP UPPERCASES CHAR uses PARSE-WORD illegaly. it should be replaced by the expanded version of the current PARSE-WORD implementation. * paflof needs load_dictionary and dump_dictionary. for bootstrapping it will be compiled with a primword + minimal dictionary created by the preprocessor. When this is done, the words are defined in normal forth, compiled to dictionary and then the dictionary is dumped. Putting more words into preprocessor magic only bloats this part of the implementation and does not make sense from a project point of view (Several people would have to work on the same part of code, which Segher does not prefer to see anyways) * Having different implementations of load_dictionary will allow us to use either the preprocessor based dictionary or a dumped one, depending on which dictionary target file is linked. In a flashed system load_dictionary would only change the dictionary pointer to a certain address in ram or rom. * The dictionary should be position independant. This will allow to relocate it at will in the flashed bios later on. The host version of paflof should be able to load the dictionary from a plain file at any position. Some enhancements for the flashed version of paflof come to my mind, i.e. having the choice between a full blown and a backup dictionary, i.e comparable to the emergency bios part in current legacy implementations. * The prim words are part of paflof, not the dictionary, logically seen. It does not make sense to make them position independant, as this would probably hurt performance on broken architectures like x86. We need a DOPRIM to connect the prim words to the dictionary then. * Therefore paflof should be stripped down to only contain words needed for bootstrapping the next abstraction level: the forth dictionary. Regards, Stefan -- The x86 isn't all that complex - it just doesn't make a lot of sense. -- Mike Johnson, Leader of 80x86 Design at AMD Microprocessor Report (1994) - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

6 13

Re: [OpenBIOS] Some thoughts on paflof.
by Parag Patel 13 Jun '02

13 Jun '02

>a) C doesn't allow to cast pointers to integers v.v. etc. without > going through a union; That's not true unless you don't want to use type-casts. char *foo; uint bar; foo = (char*)bar; bar = (uint)foo; Gcc will warn if the sizes of "int" warn "char*" are not the same, which is easy to workaround with an additional typecast. char *foo; /* assume 32-bit pointer */ uint64 bar; foo = (char*)(uint)bar; bar = (uint64)(uint)foo; >b) performance is king ;) First make it run, then make it fast. It's a rare problem that requires the wrong results as fast as possible. :) -- Parag - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

2 1

Re: [OpenBIOS] Mailing list policy change
by Christopher Smith 12 Jun '02

12 Jun '02

i would have thought that was a good idea long ago. From: Stefan Reinauer <stepan(a)suse.de> Reply-To: openbios(a)freiburg.linux.de To: openbios(a)elvis.informatik.uni-freiburg.de Subject: [OpenBIOS] Mailing list policy change Date: Wed, 12 Jun 2002 13:19:55 +0200 Hi, Due to raising spam amounts I changed the ML policy to only allow list subscribers to post to the list directly. Stefan -- The x86 isn't all that complex - it just doesn't make a lot of sense. -- Mike Johnson, Leader of 80x86 Design at AMD Microprocessor Report (1994) - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system.. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

1 0

Paflof with case insensitive dictionary lookups.
by Stefan Reinauer 12 Jun '02

12 Jun '02

Hi,.. as described in one of my last mails, case insensitive number parsing and dictionary lookups are needed for IEEE compliance. I made a little patch to Paflof, that does this. As Segher suggested, I created a word COMP-NOCASE, which is used by $FIND instead of the case sensitive COMP word. It uses UPC to uppercase the values while comparing. Additionally I changed DIGIT to uppercase a digit before comparing it to A-F so deadbeef is now a valid hex value, like DEADBEEF is. This should be checked in asap. Stefan -- The x86 isn't all that complex - it just doesn't make a lot of sense. -- Mike Johnson, Leader of 80x86 Design at AMD Microprocessor Report (1994)

1 0

Mailing list policy change
by Stefan Reinauer 12 Jun '02

12 Jun '02

Hi, Due to raising spam amounts I changed the ML policy to only allow list subscribers to post to the list directly. Stefan -- The x86 isn't all that complex - it just doesn't make a lot of sense. -- Mike Johnson, Leader of 80x86 Design at AMD Microprocessor Report (1994) - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

1 0

�°ӷ~�줽�ǥX��
by hcxc5_2gk1525＠allianz.de 10 Jun '02

10 Jun '02

********************** ¯Â°Ó·~¿ì€œ«Ç¥X¯² ********************** ±MªùªA°È°Ó¥Î¿ì€œ«Ç€§©Ó¯²€H¡C ¥x¥_ŠUµ¥¯Å°Ó¥Î¿ì€œ«Ç®×¥ó¡AŸAŠXŠUºØ°Ó·~»ÝšD¡I¡I §ÚÌŸÖŠ³ºZ³qªºžê°T¡BŠ³«ÜŠh¥ß§Yn¥X¯²ªº¿ì€œ«Ç¡A¥¿µ¥«ÝµÛ±zªº¬D¿ï¡A €@©wn¬°±z§äšì€@³B³ÌŸAŠX±z¹ê²{±z¶¯¹Ï§§§Óªº³õ©Ò¡I¡I¡I¡I Á|šÒŠp€U¡G °Ï°ì¡G €jŠw°Ï¡G €¯·Ržô¡BŽ°€Æ«n¡B¥_žô 50-300©W¡]¯²ª÷1200-2500€ž¡^¡B ¯Â¿ì®ð¬£€jŒÓ¡A²{ŠšŠÊžUžËæC¡]§K³»Åýª÷¡^¡B °š€W¥išÏ¥Î «Hžq°Ï¡G «Hžqžô€@¡B€G¡B€T¡B¥|¡B€¬q¡C 30-500©W¡]1200-2100€ž¡^ ¥þ·s®ð¬£€jŒÓ¡Bªñ±¶¹B¯ž€f¡B¥æ³q€è«K ¡]¯²ª÷ŠX²z¡B¥i±Ä³»ù¡^ ªQ€s°Ï¡G «nšÊªFžô€T¡B¥|¡B€¡B¬q 30-450©W¡]¯²ª÷1000-1800€ž¡^ ®ð¬£¡BŽºÆ[µŽšÎ €€€s°Ï¡G ªQŠ¿žô¡BªøŠwªFžô¡A€€€s¥_žô 70¢w400©W¡]¯²ª÷1000-2200€ž¡^ ¯Â¿ì¡B²{Š³žËæC Šè °Ï¡G ©Ÿ§µŠèžô¡BÀ]«ežô¡B©ÓŒwžô¡B¿Å¶§žô 50-500©W ŠÊžUžËæC¡B«K©y¥X¯²¡]Åwªï¬Ý«Î¡^ €ºŽò°Ï¡G «¹º°Ï 80-500©W1300€ž°_¡CœÐ§âŽ€š}Ÿ÷ ¥þ·s®ð¬£€jŒÓ¡B²{Š³žËæC¡B°š€W¥išÏ¥Î ªA°È²Ä€@¡A«~œè«OÃÒ¡CÅwªï¬¢žß. ·ç°T€£°Ê²£ °Ó¥ò³¡ Ápµž€H¡G³³€p©j ·q€W TeL¡]¥Nªíž¹¡^¡G 02-27492314 Šæ°Ê¹qžÜ¡G0937063831 ±zªºº¡·N¡A¬O§ÚÌªºŠšŽN¡I¡I¡I¡I - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

1 0

Re: [OpenBIOS] Defining ." and "
by Parag Patel 08 Jun '02

08 Jun '02

In message <3D020539.41212D60(a)chello.nl>, Segher Boessenkool writes: > >Where does it say it requires two? I can't find no reference to this in >the 1275 spec. The ANS, on the other hand, requires only one, and even >then only *if* you implement S" in interpreting state. Page 102 (A.2 Specification) for " and page 178 for s": "At least two temporary buffers, used alternately, shall be provided." BTW, in implementing the spec, I found I had to read each word's descriptions in detail as there's a lot of small stuff like this tucked away in the bowels of the spec. -- Parag - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

1 0

Re: [OpenBIOS] Defining ." and "
by Parag Patel 08 Jun '02

08 Jun '02

In message <3D0188D6.5999ED4B(a)chello.nl>, Segher Boessenkool writes: > >1) garbage collect. ouch. >2) in dictionary or similar --> never freed >3) in "string buffers" -- either 1 or 2, but both problems >less severe. 3.5) A fixed number of static fixed-length buffers that are treated as a ring of least-recently-used buffers. The Open Firmware spec requires at least two. We typically use two buffers for " and another two for s" just to make sure that they don't step on each other. The idea is that since only two are required by the spec, all development code should be able to run with at least two, and thus increasing the number later or for a specific port won't cause portability problems (as going the other way would). -- Parag - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

3 2

Defining ." and "
by Stefan Reinauer 08 Jun '02

08 Jun '02

Hi,.. I tried the following 2 definitions: HEX 0 > : " 22 PARSE ; IMMEDIATE ok 0 > : ." 22 PARSE TYPE ; IMMEDIATE ok Now I try 0 > ." test" test ok 0 > which works fine. So does 0 > " test" TYPE test ok The following fails as the string is overwritten: 0 > " test" ok 2 > TYPE PEst ok I could not find the reason by quickly looking into it. Any ideas? Stefan -- The x86 isn't all that complex - it just doesn't make a lot of sense. -- Mike Johnson, Leader of 80x86 Design at AMD Microprocessor Report (1994) - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

3 5

[Fwd: Re: [OpenBIOS] patch: machine dependent config]
by Segher Boessenkool 07 Jun '02

07 Jun '02

> > > Just a dumb idea, could we rewrite the preprocessing and testing > > > completely in C? I know that there are a lot of issues with perl on > > > > Nope, cpp can't do all that's necessary. Btw, once we have a working > > Forth compiler, we can use that to bootstrap itself :) > > You're talking about forth -> binary translation? That is not what we > want, I guess. Can you explain? There's three ways to represent a program: 1) Forth source 2) Forth dictionary (binary) 3) Forth dictionary/source (FCode) 3) is limited, but cross-platform; it's the prefered way for device manufacturers to distribute drivers, but there's no reason to implement our internal stuff with FCode. 2) is okay, but machine-specific. 1) is our prefered form. But that leads to a problem: the Forth compiler itself is written in Forth. So the "initial dictionary" will have to be distributed as 2). That's exactly what ref.pl + cpp magic do: they convert "pseudo-forth" source (engine.in) to dictionary. Now, what I said was: when we have the Forth compiler finished, we can have the engine.in compile a engine.fs, to replace itself. > > > newer platforms, which could make it hard to get paflof running on new > > > machines, even if we already have a gcc. Ugly though. If this is > > > > Cross-compilers save the day :) > > Cross compilers is exactly where this stops working. If I cross compile > for SH1 CPUs using a crosscompiler on Intel x86, my perl nor my gcc will > never tell me whether my 'long' is 32 or 64bit on the target platform. > We probably can't even use this to check for TI mode availability Sure you can; you just can't run the target programs, but of course the compiler knows the target data sizes :) > > I hope to finish the "Forth command group" today :) > > How much work has to be done here? One or two days, plus some cleanup, but that can be done later. > How far are we from being able to > read FCode with this (i.e. use the work in the fcode/base/ directory > already done? This is the Forth compiler, not yet the FCode compiler; that one is a lot easier. > Please make sure we don't do duplicate work here. I'll try :) > " text" is the only one missing to get the mandelbrot signature, one > of my toke test programs, running. Then we can start using the example > code and really testing the Fcode layer on top. I'll implement it without things like S" blabla(0d)(0a)blabla" etc., at first. It'll be here later tonight :) Segher - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

1 0

Re: [OpenBIOS] patch: machine dependent config
by Stefan Reinauer 07 Jun '02

07 Jun '02

* Segher Boessenkool <segher(a)chello.nl> [020607 13:23]: > > Except we rely on compiler defines and prerequisites to get towards a > > defined build set (which probably sucks). If we have to use this > > functionality anyways, it might be interesting to look at autoconf. > > But then again we won't get rid of all perl stuff, so using autoconf > > just adds another player to the game. > > Please let's not use autotools :) Besides their implementation is a bit far from the goal (portability), autoconf and friends cause lots of trouble, not only with new platforms but also with newer versions of autoconf etc. We definitely don't want that. > > Just a dumb idea, could we rewrite the preprocessing and testing > > completely in C? I know that there are a lot of issues with perl on > > Nope, cpp can't do all that's necessary. Btw, once we have a working > Forth compiler, we can use that to bootstrap itself :) You're talking about forth -> binary translation? That is not what we want, I guess. Can you explain? > > newer platforms, which could make it hard to get paflof running on new > > machines, even if we already have a gcc. Ugly though. If this is > > Cross-compilers save the day :) Cross compilers is exactly where this stops working. If I cross compile for SH1 CPUs using a crosscompiler on Intel x86, my perl nor my gcc will never tell me whether my 'long' is 32 or 64bit on the target platform. We probably can't even use this to check for TI mode availability > I hope to finish the "Forth command group" today :) How much work has to be done here? How far are we from being able to read FCode with this (i.e. use the work in the fcode/base/ directory already done? Please make sure we don't do duplicate work here. " text" is the only one missing to get the mandelbrot signature, one of my toke test programs, running. Then we can start using the example code and really testing the Fcode layer on top. Stefan -- The x86 isn't all that complex - it just doesn't make a lot of sense. -- Mike Johnson, Leader of 80x86 Design at AMD Microprocessor Report (1994) - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

2 1

patch: machine dependent config
by Stefan Reinauer 07 Jun '02

07 Jun '02

Hi, ok, this time I redid the patch to make paflof sane on 64bit platforms in a cleaner way, using abstracted defines that are dependent on certain platform specifics. As this is platform dependent stuff which has basically nothing to do with paflof itself, I moved it to a new file: machdep.h. I moved the sanity check out of paflof.c into machdep.c, which we will probably not need to link in case we know an architecture/compiler combination is sane. We really need to make sure we are 64bit clean from the beginning so we recognize early what problems we might have to face getting paflof portable. Segher, is this ok to check in from your side? If so, please do! Stefan -- The x86 isn't all that complex - it just doesn't make a lot of sense. -- Mike Johnson, Leader of 80x86 Design at AMD Microprocessor Report (1994)

2 5

Re: [OpenBIOS] 64bit paflof with lots of gnuisms
by Parag Patel 04 Jun '02

04 Jun '02

Re: macros vs sizes of various int/ptr types One reason I used explicit type definitions for INT_64 and PTR_64 is that SmartFirmware can be built with either 32-bit or 64-bit cells on hosts that support both. Thus I can't use the sizeof operators. Also sizeofs within #if macro expressions aren't supported by most compilers. SF doesn't use gcc's label/tables feature either. We just use a separate C function per Forth word. It's more than fast enough for boot-up purposes, but then almost all of the real work is done in C rather than Forth in any case. Just FYI, SF has been compiled with various C compilers including TI's 34020 graphics processor compiler, Metrowerks for several targets, Visual C, Apple's MPW C, and Sun's C/C++ compiler. Barring a few key machine-dependent assembly stubs, of course. -- Parag Patel - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

1 0

Re: [OpenBIOS] 64bit paflof with lots of gnuisms
by Parag Patel 04 Jun '02

04 Jun '02

In message <20020603181539.GB19105(a)suse.de>, Stefan Reinauer writes: > typedef intptr_t type_n; // cell size > typedef uintptr_t type_u; // cell size >+#if defined(__alpha__) || defined(__x86_64__) || \ >+ defined(__ia64__) || defined(ppc64) >+typedef intmax_t type_d __attribute__ ((mode (TI))); // 2 * cell size >+typedef uintmax_t type_du __attribute__ ((mode (TI))); // 2 * cell size >+#else > typedef intmax_t type_d; // 2 * cell size > typedef uintmax_t type_du; // 2 * cell size >+#endif > #else Dunno about the Gnu-isms, 'cause we avoid 'em in SmartFirmware, but as a general rule, you should change your defines to something like this: > typedef intptr_t type_n; // cell size > typedef uintptr_t type_u; // cell size >+#ifdef int64_type >+typedef intmax_t type_d __attribute__ ((mode (TI))); // 2 * cell size >+typedef uintmax_t type_du __attribute__ ((mode (TI))); // 2 * cell size >+#else > typedef intmax_t type_d; // 2 * cell size > typedef uintmax_t type_du; // 2 * cell size >+#endif > #else and have a machine-dependent section that sets int64_type (or whatever) based on the CPU type or some-such. Make the macros reflect the specific feature directly. We use two different macros defined in a machdep.h header file, which is customized for each platform and compiler. One macro determines the presence/absence of 64-bit ints (say INT_64BIT) and another determines if pointers will be 64-bits or not (PTR_64BIT). Only one place needs to specify the settings of these macros, machdep.h, and every other common source file is neatly disconnected from any machine dependancies. As for the Gnu-isms, we wrap the necessary code in #ifdef __GNUC__, in some cases creating a null macro to reduce the subsequent ifdef mess: #ifndef __GNU_C__ #define __attribute__(arg) /* noop */ #endif Obviously, there are other ways to deal with this as well. Just for what it's worth. -- Parag - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

4 4

64bit paflof with lots of gnuisms
by Stefan Reinauer 03 Jun '02

03 Jun '02

Hi there, I played around with paflof on 64bit platforms. As we make heavy use of GNUisms, I got it working using some more. I'll attach 2 patches, one cleans up 64bit compile warnings for the fprintf stuff (cosmetic), the other fixes the double cell issue. Unfortunately it does not compile on 32bit platforms without the ugly #ifdef constructs. The error messages are "no data type for mode `TI'" I am not sure whether this is a gcc bug or rather an error in my thoughts. Any comments? See you, Stefan -- The x86 isn't all that complex - it just doesn't make a lot of sense. -- Mike Johnson, Leader of 80x86 Design at AMD Microprocessor Report (1994)

1 0

Increase Your Business
by Marketing Manager 02 Jun '02

02 Jun '02

1 0

Increase Your Business
by Marketing Manager 02 Jun '02

02 Jun '02

1 0

�M�~�s�Q��y��H�A�ȡI�I
by 1bvccbngn30by＠snb.ch 31 May '02

31 May '02

1 0

cell size in paflof
by Stefan Reinauer 29 May '02

29 May '02

Hi Segher and others, I made a little patch for paflof so it automatically recognizes the cell size of the machine it is compiled on. It can probably be done nicer, but I got sick of changing the code while changing machines ;) Should I commit this? Best regards, Stefan Reinauer -- The x86 isn't all that complex - it just doesn't make a lot of sense. -- Mike Johnson, Leader of 80x86 Design at AMD Microprocessor Report (1994)

2 1

RE: [OpenBIOS] dc motor, gear motor sale
by qunli chen 29 May '02

29 May '02

Dear sirs, Good day to you! We are Renhe Industrial Parts Co., Ltd. from China. I find your company from the internet search and have learnt something about your company. I feel like doing business with your company. Our Renhe Industrial Parts is a big trading company in Ningbo China. The main business in our company is importing and exporting, and quite a lot of other businesses. Our company owns some subcompanies and some business friendship companies. These companies manufacture various products, including molds, casting products, rubber and plastic products. We also can provide you with OEM parts (such as stampings, CNC machining ,weld assemblies, stainless Fabrication and so on). We can find good source for our customers because I have ten years worked in the trading fields and much familiar with the products and factories in our province. We have got rich experiences in trading, especially in exporting die-casting products, casting products, plastic products ,moulds and OEM parts. All these products were sent to many companies in Europe, America, Japan and so on. For instance, some parts have been used in GM company in America, some parts to PHILIP company for Cable TV Case ,and also for power tools ,washing machines , pumps and so on.. All these products are well appraised. Advanced equipment is used in producing, inspection, and testing (such as CMM. PI. Spectrum analysis equipment and so on). Our target is not only in grade of products but in chasing high quality as well. Now most of subcompanies has obtain ISO9002 quality system certification, and also some companies have obtain QS9000 and VDA6.1 certification. If you have any interesting in sourcing from China in casting products, plastic parts, mould and other OEM products, we would be a good partner. Please email me or fax me. I will reply you ASAP. Best Wishes, Chen Qunli Renhe Industrial Parts Tel: 0086-574-87672567, 87806525 Fax: 0086-574-87806761,87672528 Mobil: 0086-13857464822 Add: 206,#5,Lane 18 Zhenda Road, Ningbo, 315000 China

1 0

tokenizer and detokenizer update.
by Stefan Reinauer 27 May '02

27 May '02

Hi, I made some updates to the tokenizer and detokenizer, mainly bug fixes. Toke 0.4 changes since the last release (0.2) --------------------------------------------- * abort" is tokenized now. This is not really defined by IEEE, but it is used in some Apple FCode driver examples, and thus should at least do something. Using abort" in FCode programs emits a warning when running toke. * endif works. In Forth if clauses are written as condition? if ... then However, a lot of forth implementations know if..endif as well as it sounds a bit more natural * name is an alias for device-name. Added to fit common usage. * parsed numbers can contain dots to make reading easier. * fcode number counter resetted when tokenizing multiple files. * hex values that are embedded in strings work properly now. * better IEEE compliance (no definitions within definitions etc) * other small bugfixes. Detok 0.5.2 changes since last release (0.3) -------------------------------------------- * case..endcase expressions are now detokenized correctly case expected an offset value, which is not true according to IEEE * detok is more silent per default now. * compilation on some systems that seem to have broken headers for getopt() should work. (Thanks to Tim Barret) * When an FCode word is unnamed, always print the FCode number (Tim Barret) * Indent size is 4 now to make output more readable. * line numbers or byte offsets within the detokenized fcode file can be shown * checksum calculation works. * Input files are buffered (slightly better performance ;)) * pretty printing of strings with nonprintables fixed. * support for 64bit extension fcode words. * other small bugfixes Additionally I started to put some Forth code into CVS, which implements some of the base fcode words from the IEEE 1275. You can have a look at http://openbios.ph-freiburg.de/cgi-dom/viewcvs.cgi/fcode/base/ Currently some data type conversions and stack operations are implemented, but its far from being complete. This should give you an idea how Forth words of IEEE 1275 can be implemented easily Every section in the source files contains the topic number as described in the ieee 1275 standard. A lot of sections are missing. Feel free to choose one, drop a note on this list that you want to work on it and start coding ;) Any quastions and comments are highly welcome! It's time to get things started - would be a nice christmas present to have the first machine booting some openbios version by the end of this year ;) Stefan -- The x86 isn't all that complex - it just doesn't make a lot of sense. -- Mike Johnson, Leader of 80x86 Design at AMD Microprocessor Report (1994) - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

2 1

How to tokenize abort"
by Stefan Reinauer 23 May '02

23 May '02

Hi, after feeding the SymbiosLogic 825 FCode driver from Apple ( http://www.freiburg.linux.de/OpenBIOS/bin/AAPL-8250.4th ) to the tokenizer I found that the old implementation of abort" was not really doing what it should. According to IEEE 1275 it is an equivalent to -2 throw, which I implemented as a macro. This would not work and not behave like it should, so I replaced it: flag? abort" text" is now tokenized to: flag? if " text" type -2 throw then Is this the wanted behaviour? Any ideas? Best regards, Stefan Reinauer -- The x86 isn't all that complex - it just doesn't make a lot of sense. -- Mike Johnson, Leader of 80x86 Design at AMD Microprocessor Report (1994) - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

2 1

Re: OpenBIOS
by Stefan Reinauer 22 May '02

22 May '02

* John R. Hogerhuis <jhogerhuis(a)yahoo.com> [020521 07:14]: > Ok, I downloaded paflof, got it building. I think > you're right, Segher's code looks pretty clean. Just > out of curiosity, I think there are forth-in-Cs > already implemented under GPL, why not use one of > them? Most of what I've looked at is nice, but uses a different approach than what we really want. Either they compile to native code, which is nice, but not really needed and it makes the thing bigger and more complex than needed. Others try to care for lots of system interoperation issues which we don't really need. Starting from scratch normally looks like a not too smart idea, but in this case i think it is, as we know exactly that we have no overhead whatsoever. Even with lots of optimazation it might be hard to get gforth or alikes down to the size paflof has, or will have, when it's done. Every byte we safe here, means we have more space for the packages that will live on top of paflof, be it the debugging facilities, drivers, ... > How do I know which words still need implementation? > How do I take ownership (make sure no duplication of > work). The only source is the code, and probably Segher ;) None of the highlevel words, like package handling, properties, exceptions, have been touched in connection with paflof. It probably makes sense to push these forward until paflof is far enough to be able to execute fcode. Also the existing tokenizer/detokenizer need a lot of testing, which I can only do little, as I am not a long time forth expert. ;) For taking ownership for a certain task just drop a note to this list about what your ideas are. This list has been low or rather zero traffic for a while; As far as I know only Segher and me are looking at the code currently so chances that you do duplicate work are naturally pretty low. > I've started reading the IEEE 1275 spec, I should be > done soon. For anyone interested, this is the main information source that should be used for implementation - A lot of information is available in the Docs section of the OpenBIOS homepage: http://www.freiburg.linux.de/OpenBIOS/docs/ > Feel free to respond to me on the list rather than > directly. I'm subscribed now, but I wasn't sure how > basic of information you wanted showing up on the > list. I think it is a good idea not to keep this discussion secret, as there's enough to do for _a lot_ of developers ;) Stefan -- The x86 isn't all that complex - it just doesn't make a lot of sense. -- Mike Johnson, Leader of 80x86 Design at AMD Microprocessor Report (1994) - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

2 3

OF1275 Questions
by John R. Hogerhuis 22 May '02

22 May '02

Hello, I'm plodding my way through OF1275. In section 3.2.2.3.1 reference is made to the Forth words DEFER INSTANCE BUFFER: I couldn't find these in the DPANS94 spec... anyone know what these are? I never did much with ANS Forth, so I am not sure why I can't find these words in the docs. Perhaps INSTANCE and BUFFER: are specific to OF? I assume DEFER is for deferred definition/vectored execution words. Why isn't it in ANS spec? Thanks, -- John. __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

3 2

RE: [OpenBIOS] dc motor, gear motor sale
by Nielsen, Roy S 27 Mar '02

27 Mar '02

I would love a catalog or a web link to a catalog of your products!! thanks, -roy -----Original Message----- From: Hing Lung Motor Mfy. [mailto:motorvan@tom.com] Sent: Tuesday, March 26, 2002 8:58 AM To: openbios(a)elvis.informatik.uni-freiburg.de Subject: [OpenBIOS] dc motor, gear motor sale DC MOTOR, GEAR MOTOR. New Offer 2002 For customer's O.E.M are most welcomed If special requested RPM, length of shaft, torque, size, voltage, etc. Please contact us E-mail: motorvan88(a)hotmail.com <mailto:motorvan@tom.com> Please contact with Mr. Van Lee NO: HL101-D-D8xH6 VIBRATOR MOTOR SIZE: 20 x 15.5 x H25 MM PRICE: US$ 0.12/PC NO:HL307 DC MOTOR SIZE: D12 x 19.5 MM PRICE: US$ 0.38/PC NO: HL1011-DC MOTOR FOR WHEELCHAIR, SCOOTER SIZE: D100 x H70 MM OUTPUT: 95 W PRICE: US$ 13.50/PC NO: HL200 GENERATOR MOTOR SIZE: D30.5 x H13 MM PRICE: US$ 2.3 WE PRODUCE MORE THAN 70 DIFFERENT DESIGN AND SIZE OF DC, GEAR AND AC MOTORS, THEY ARE SUITABLE FOR OPERATION TOYS, HOUSEHOLD APPLIANCES, RECORDS, SCOOTER, VIBRATOR, GENERATOR, WHEELCHAIR ETC. -----ANY ENQUIRY ARE WELCOME----- Hing Lung Motor Mfy, Hong Kong Tel : 852-24218309 852-24259526 Fax: 852-24817148

1 0

dc motor, gear motor sale
by Hing Lung Motor Mfy. 26 Mar '02

26 Mar '02

DC MOTOR, GEAR MOTOR. New Offer 2002 For customer's O.E.M are most welcomed If special requested RPM, length of shaft, torque, size, voltage, etc. Please contact us E-mail: motorvan88(a)hotmail.com Please contact with Mr. Van Lee NO: HL101-D-D8xH6 VIBRATOR MOTOR SIZE: 20 x 15.5 x H25 MM PRICE: US$ 0.12/PC NO:HL307 DC MOTOR SIZE: D12 x 19.5 MM PRICE: US$ 0.38/PC NO: HL1011-DC MOTOR FOR WHEELCHAIR, SCOOTER SIZE: D100 x H70 MM OUTPUT: 95 W PRICE: US$ 13.50/PC NO: HL200 GENERATOR MOTOR SIZE: D30.5 x H13 MM PRICE: US$ 2.3 WE PRODUCE MORE THAN 70 DIFFERENT DESIGN AND SIZE OF DC, GEAR AND AC MOTORS, THEY ARE SUITABLE FOR OPERATION TOYS, HOUSEHOLD APPLIANCES, RECORDS, SCOOTER, VIBRATOR, GENERATOR, WHEELCHAIR ETC. -----ANY ENQUIRY ARE WELCOME----- Hing Lung Motor Mfy, Hong Kong Tel : 852-24218309 852-24259526 Fax: 852-24817148

1 0

BIOS output on Video monitor
by prasun kapoor 08 Mar '02

08 Mar '02

Hello All, Right now I am involved in developement of a PC BIOS which works fine when all output is sent to the serial port. I am even able to tftp load binaries, including OS binaries and execute them. My next concern now is to get BIOS messages out to the Video instead of the serial port. I just want the regular text mode 25X80 output and nothing fancy. I want to know what I need to do to get text frame buffer working at b800:0000 working. Do I absolutely need to call VGA BIOS init to get this working? Right now with my BIOS, the monitor does not stop blinking its orange light and writes to b800:0 do not produce anything, but when I insert an Award BIOS chip, I get this blinking of monitor for some time and then it suddenly comes alive with a beep and a green light. I am wondering what does Award BIOS do to achieve this or is it just calling VGA BIOS init? If someone has a code snippet or a pointer to one or just a broad outline to what needs to be done, I will appreciate it very much. Best Regards, Prasun Kapoor __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

3 2

Calling VGA init routine
by prasun kapoor 07 Mar '02

07 Mar '02

hello all, I am writing my own BIOS for an x86 system, and have it running and booting an OS pretty well, as long as everything is on the serial port. I figure I need to call init of the VGA BIOS to have the video card working. I would like to know how I can gop about doing this. If anyone have a code snippet, for calling the VGA BIOS it would be great! I would very much appreciate it if someone has this code handy or give me a pointer to where I can find it. I am using an ASUS P3B-F board with ATI ( Rage II C AGP) video card on it. Thanks in Advance, Prasun Kapoor __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

2 1

Software Best Practices from High Maturity Organizations
by Vikram S. Makhni 21 Feb '02

21 Feb '02

Software Best Practices from High Maturity Organizations Program Details India a.. Tutorials February 25-28, 2002 b.. Conference March 1-2, 2002 Thailand a.. Tutorials March 4-5, 2002 Australia a.. Tutorials March 7-8, 2002 Singapore a.. Tutorials March 18,19 & 21, 2002 b.. Conference March 20, 2002 China a.. Tutorials b.. Conference Registration Details The Software Engineering Process Group ( S E P G ) Conference is the leading international conference for software process and quality professionals who spearhead the quality initiative for software excellence in their organizations. This year QAI India, and Software Engineering Institute, USA, are taking the SEPG Conference on Tour in Asia Pac. Software Gurus, Practitioners, Managers, SEPG heads from several high maturity organizations (CMM level 4 and level 5, PCMM level 5, CMMI level 5) and many others will present their thought leadership through plenary sessions, invited and contributed presentations, tutorials, panel discussions and exhibits. The conference highlights: a.. More than 50 world-class tutorials on topics such as CMM Integrated,People CMM, Six Sigma and many more will be covered across India, Thailand, Australia, Singapore and China. b.. Participation by more than 1000 professionals - CEOs, CIOs, CTOs, Project Managers, Process Group members, Testing professionals from top organizations in Asia Pac. c.. Support of 15 software parks, 5 software associations, many government bodies such as Ministry of Science and Technology China Torch Program, NASSCOM & ESC and SPINs. We invite you to participate and hear what the community has to say about "Engineering Software Excellence” during this event. The conference is an opportunity for professionals to: a.. Learn, share and exchange ideas and learning in software quality & process with practitioners and thought leaders from industry, academia and government. b.. Demystify the secret of success of Indian software industry and mutually benefit from the rich software experience of Asia Pac. c.. Meet and network with potential customers/business partners across Asia Pac. The PDF brochure on www.qaiindia.com/SEPG_minisite/SEPG_brochure.pdf provides complete details including dates, registration form and the program schedule. For registrations please visit www.qaiindia.com/SEPG_minisite/index.htm Should you need any additional information on SEPG on Tour in Asia Pac, you may write to us and we shall be pleased to provide further details. Vikram S. Makhni QAI India Ltd. 1013-1014, Ansal Towers, 38 Nehru Place, New Delhi-19, India Tel : 91 11 621 9792, 6220580 Fax : 91 11 621 8974 email : conferences(a)qaiindia.com ,website :www.qaiindia.com CMM® and Capability Maturity Model are registered in the US Patent and Trademark office. CMMISM, Capability Maturity Model Integration (SM) are service marks of Carnegie Mellon University.

1 0

laptop bios
by Christopher Smith 31 Jan '02

31 Jan '02

first post to the group sorry if this is old news. I am looking for info on what the bios of a dell latitude 433c consists of. specifically, the size of eeprom I can stick in, what if any special functions are implemented there besides the generic ones. I am on the hunt to replace the stock bios of this poor creature with one that is a) open b) optimized to help Linux start up c) faster&lighter on the resources available(486sx@33) in startup and shutdown. I want to stuff as much as possible of the core linux/freeBSD/Xnix into a bios type of storage to reduce the amount of time I am using the HD. Once I find I have not blown up the old dell I my get brave and think about surgery on the new Dell. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

2 1

Please share with me the Award BIOS source code if possible
by Vincent Ma 30 Jan '02

30 Jan '02

All, If you have any kind of Award BIOS source code, please send me ASAP. Thanks in advance. V.M - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

3 2

hello and question(s)
by Gil Hauer 08 Jan '02

08 Jan '02

Hi, I just join this list -- what great work you have done! I'm particularily interested in the fcode tokenizer as (in my novice view) one needs this to start writing some fcode, right? Is anyone working on this? Regards, Gil - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

2 1

Meilleurs Voeux pour 2002 : ann�e de m�moire, de mobilisation, d'action, de justice et de s�r�nit� - Appel au soutien moral et financier
by Habib HAIBI 05 Jan '02

05 Jan '02

Meilleurs Voeux pour 2002 : ann�e de m�moire, de mobilisation, d'action, de justice et de s�r�nit� - Appel au soutien moral et financier ======================== M. Habib HAIBI, 7, Aguesseau St. 69007 LYON - France T�l. 00 33 4 72 73 19 08 - Fax 00 33 4 78 61 39 27 Email : haibi(a)free.fr http://haibi.free.fr Je suis qualifi� pour exprimer mes voeux pour le Nouvel An � tous les survivants et les familles des victimes des attaques terroristes, au peuple am�ricain, ses dirigeants, ses institutions, son pr�sident et tous les combattants de la libert�, loin de leurs foyers, tout autour du monde! Je suis fier de vous dire avec gratitude combien Les USA sont puissants, d�mocratiques et qualifi�s pour d�fendre la libert� et la d�mocratie avec humanisme et s�r�nit�. L'ennemi du progr�s du genre humain peut encore frapper. La libert� et la d�mocratie peuvent �tre encore sous attaques! Personne ne s'imaginait que cela pouvait arriver et c'est arriv� en ce jour pacifique du 11 septembre 2001 Personne ne s'imaginait que cela pouvait arriver� en France et c'est arriv� le 26 f�vrier 2001 quand les magistrats du parquet de Lyon, par impulsion suicidaire et pr�m�dit�e, ont eu recours � l'arbitraire pour entraver l'action Publique mise en Mouvement : ils ont requis l'expertise psychiatrique de la Partie Civile par l'action avant de l'entendre dans ses accusations ! Cette d�rive obscurantiste a d�pass� tout entendement C'est arriv� un jour pacifique pour moi et pour les institutions de la R�publique en France. Le r�quisitoire aux fins de l'expertise psychiatrique de la partie civile par l'action, avant de l'entendre dans ses accusations, constitue une atteinte obscurantiste � l'int�grit� de la personne de la partie civile et surtout un attentat aux valeurs fondamentales de la soci�t� civilis�e et une infamie ass�n�e � la R�publique et ses Institutions: - � tous les martyrs de la libert� qui ont pay� de leur vie la d�fense des personnes et des biens et des valeurs fondamentales et universelles de la R�publique. - � tous ceux qui dans l'exercice de leurs fonctions, au nom du devoir de servir, exposeraient leurs vies, sans h�sitation, pour la d�fense de ces m�mes valeurs - � tous les hommes ou femmes de bonne volont�, citoyens anonymes, �lev�s sur la foi en une soci�t� pacifi�e par l'av�nement de la R�publique, la crainte des lois et l'ind�fectibilit� de l'Etat, de la Justice et des Institutions en D�mocratie. J'�tais, longtemps avant le WTC l'autre "point z�ro" de la plan�te qui a subit les premi�res vagues d'attaque contre les institutions de la R�publique, la libert� et les droits de l'homme � en France ! Il y a eu trois autres attaques avec la m�me d�termination, diabolique et suicidaire, de stopper l'action publique r�guli�rement mise en mouvement ! J'ai fait face � l'adversit� en mettant en accusation 15 magistrats, saisis par la foudre de l'action publique en col�re, nominativement impliqu�s, des deux juridictions de Lyon tout r�le et rang confondus pour abus d'autorit� aggrav� et trafic d'influence aggrav�. Une fois que vous avez pris la mesure de l'attaque contre les valeurs universelles de la libert� et la justice en d�mocratie en France� et assimil� la grandeur de la querelle qui m'anime � Votre r�action sera vivement souhait�e et sollicit�e ! Je recevrai vos contributions morales et financi�res comme une juste consolation pour le grand pr�judice moral que je subis dans l'attente de la r�paration de la faute lourde par la justice et l'Etat. Souvenez-vous que la paix civile fut conquise au prix de feu, de sang et de sacrifices� avec pour objectif le r�gne absolu et �galitaire de la loi. Imaginez les victimes du 11 septembre 2001 dans un monde sans libert�, sans justice et sans d�mocratie� Imaginez tous les sacrifices de tous les combattants de la libert�, depuis deux si�cles et plus, laiss�s pour compte et discr�dit�s en une seule journ�e d'attaques perp�tr�es par les forces diaboliques de l'arbitraire et de l'obscurantisme dans le pays qui a donn� naissance au reigne de la loi, l'av�nement de la R�publique et les droits de l'homme. Une nouvelle �re a commenc� o� le grand pays que sont les Etats Unis vont guider et pour longtemps l'impulsion de l'alerte et de la r�action pour perp�tuer la libert� et la justice en d�mocraties. C'est aussi votre combat et le combat de tous les hommes libres. Merci au pr�sident des Etats Unis pour son leadership, l'immense puissance de son pays et sa s�r�nit�. Merci � tous d'avoir lu et compris ce message. Merci pour vos r�actions et vos contributions. ========================== Ces contributions sont souhait�es � la hauteur de 500 $ ou euros et plus pour tous les repr�sentants �lus des peuples, s�nateurs et d�put�s, quelque soit leur pays et quelque soit le moyen utilis� pour les alerter des attaques contre la d�mocratie et de la col�re de l'action Publique en mouvement : "ma tristesse s'est mu�e en col�re et la col�re en r�solution "! (ma conviction est que si de tels actes ont pu se produire c'est � cause d'un climat de permissivit� qui a pu s'installer par l'absence du contr�le de l'ex�cutif par le pouvoir l�gislatif�). ======= vous pouvez verser directement vos contributions financi�res sur le compte : RIP RELEVE D'IDENTITE BANCAIRE 20041 01007 1112632 F038 69 IBAN IDENTIFIANT INTERNATIONAL FR 53 20041 01007 1112632 F 038 69 Ou envoyer un mandat cash � mon nom et � mon adresse. ================================ Les contributions seront libres et bienvenues de la part de tout autre citoyen sensible � l'id�e de vivre dans une soci�t� pacifi�e par la crainte des lois et la cr�dibilit� des institutions d�mocratiques. ============ Mon objectif est de r�unir 10 000 r�actions � 100 $ ou euros chacune : vous pouvez m'aider � atteindre ce but. Je serai, � coup s�r, un homme riche! Mais je ne recouvrerai la paix int�rieure avant que justice soit faite! 'J'ai un r�ve"! La justice sera faite ! ============ Le site o� est publi� l'ensemble du dossier est en fran�ais, vous pouvez vous aider pour la traduction par un moteur de traduction sur internet. http://haibi.free.fr ============ Cette mailing liste, non exhaustive, est compos�e de 30 000 emails : des repr�sentants �lus, les repr�sentants de l'Etat, hauts fonctionnaires, magistrats, avocats, journalistes, chefs d'entreprise, pr�sident ou membre d'association, profession lib�rale ou tout autre simple citoyen int�ress� par la vie sociale, administrative et judiciaire. ======================= Vous pourrez discuter en circuit interne non publi� sur le net en vous abonnant au groupe cr�� pour cet objet "Il n'y a pas d'alternative � la justice en r�publique en france" Coordonn�es du groupe : Email du groupe : lecitoyen.laloi.larepublique(a)smartgroups.com Email du gestionnaire : lecitoyen.laloi.larepublique-owner(a)smartgroups.com Pour devenir membre : lecitoyen.laloi.larepublique-subscribe(a)smartgroups.com Pour ne plus �tre membre : lecitoyen.laloi.larepublique-unsubscribe(a)smartgroups.com Accueil du groupe : http://smartgroups.wanadoo.fr/groups/lecitoyen.laloi.larepubliqu e ====================== Si vous ne vous sentez pas concern�, vous pouvez demander � ce que votre email soit effacer en exprimant votre volont� � l'adresse email : haibi(a)free.fr Merci encore de participer � l'alerte et au suivi de l'action publique en mouvement, et au soutien moral et financier de la partie civile par l'action. ================================ =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =============================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== ================================================== Vous pourrez recevoir une autre version en anglais. Ceci n'est pas un spam Merci! NEVER SEND SPAM. IT IS BAD. - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

1 0

cvs: viewcvs 0.7 -> 0.8
by Armin Herbert 21 Dec '01

21 Dec '01

Hi all, viewcvs 0.7 has been upgraded to viewcvs 0.8. Clicking on "Download tarball" in the cvsroot will suggest the filename "cvs_root.tar.gz" now instead of just ".tar.gz". Please mail me if you are in trouble with the new version. Thanks Armin -- Armin Herbert herbert(a)ph-freiburg.de "At a time when political correctness is valued over honesty, I would like to say: Right on motherfuckers, everyone is a winner!" - Madonna at Turner Award, 2001 - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

1 0

Kickstarting a revolution ...
by Stefan Reinauer 21 Dec '01

21 Dec '01

Dear OpenBIOS folks, The past few weeks have been silent on this mailing list, but fortunately that was not a bad thing. In fact, if you had a look at the web page, you might have noticed it already. We finally have some code now that aims toward the projects goal, creating a free implementation of IEEE-1275. administrative -------------- The OpenBIOS website has been updated and restructured as it didn't really lead to the right direction for working on OpenBIOS. Have a look at http://www.openbios.net/ or http://www.freiburg.linux.de/OpenBIOS/ For ease of updates the website meta language (wml) is now used for creating the pages. Thanks a lot to Patrick Mauritz for his work. Please check the documentation links on http://www.freiburg.linux.de/OpenBIOS/docs/ for information on Open Firmware, OpenBIOS, Forth, ... If you miss information on the OpenBIOS web page, please drop a note to the list for an update. Second, we have a cvs tree for the OpenBIOS project now. Access is granted read only for anonymous users and read/write for core developers. Read the information on http://www.freiburg.linux.de/OpenBIOS/dev/cvs.html For web access to the cvs tree go to http://openbios.ph-freiburg.de/cgi-dom/viewcvs.cgi/ Thanks to Armin JoLo Herbert for his efforts of finding a machine and setting up the cvs server and viewcvs. detok ----- Detok is a an fcode detokenizer. That's a small utility that "disassembles" fcode bytecode files. It's useful for debugging purposes and it's the first part of the OpenBIOS development suite. Detok follows IEEE-1275-1994 and should work pretty stable. This component should be heavily tested as it is about feature complete. The latest release of detok can be found at http://www.freiburg.linux.de/OpenBIOS/bin/detok-0.2.3.tar.gz feval ----- Feval is the the fcode evaluator needed to execute the cpu independant hardware initialization part of OpenBIOS. It is able to execute simple fcode bytecode files right now, but there are many fcode words missing and it is quite a big step left before this is complete. But it is a clear base to discuss and work on. Feval is tested on IA32, IA64, Alpha, Sparc and m68k and should be endian and 64bit clean. Preliminary support for packages and properties is implemented but not yet ready for prime time. The latest release of feval can be found at http://www.freiburg.linux.de/OpenBIOS/bin/feval-0.2.6.tar.gz Best regards, Stefan Reinauer -- Ok : FC RECURSE DUP 1 > IF DUP 1 - FC * ELSE DROP 1 ENDIF ; 42 FC .

6 6

Documentation on Open Firmware
by Stefan Reinauer 11 Oct '01

11 Oct '01

Hi,... I've added a new link to the OpenBIOS homepage. Under http://docs.sun.com:80/ab2/coll.216.2/@Ab2PDFPrint?Ab2Lang=C&Ab2Enc=iso-885… you find PDF files describing the FCode engine of Open Firmware. I consider this a valuable information source for all developers who do not have the IEEE 1275-1994 specs (which is unfortunately not freely available) Regards, Stefan -- This world is crying to be free; This world is dying, can't you see? We need a turn to do it right; We need a mind revolution To get away from this selfishness. Stop playing blind - BREAK FREE! Your Turn, Helloween '91 - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

1 0

K7 Users and Sellers
by Ronald G Minnich 11 Sep '01

11 Sep '01

Would those of you who are: 1) planning to sell linuxbios or other open source bios on K7 nodes 2) planning or hoping to buy linuxbios or other open source bios on K7 nodes Please write me directly (not the list). I am going to put a list of names together. AMD is trying to get an idea of who is interested in using or doing this work. This will help them make the case for releasing chipset details we need for porting. Please no sermons to the list or to me. I know it is obvious that they should do this. That's not the issue. I just need names of users/builders. thanks ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

http://news.cnet.com/news/0-1003-200-7026026.html?tag=mn_hd (fwd)
by Ronald G Minnich 04 Sep '01

04 Sep '01

Stefan, reference the above URL, I think we should get in touch with those folks named in the article (at AMD and Intel) and let them know what we need, namely the information needed to write a BIOS. If they're serious maybe they'll actually open up the specs to us. Suse gets prominent play in the article so a note from suse might help too. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

[OT] Freebios
by Tobias Diedrich 02 Sep '01

02 Sep '01

I don't know if anyone here is interested in this, but some time ago (1998) I started writing a pc-compatible bios for fun, but never finished it. So in case someone is interested in the little code I wrote you may find it at http://ranmachan.dyndns.org/~ranma/freebios-0.0.1.tar.gz (~67KB) ... [As long as my system is up, which should be nearly 24hours/day, and my internet connection and the dyndns.org dns updates are working...] I stopped because I had trouble figuring out how to enable SDRAM on my Pentium Mobo with Intel chipset... However for an older 486 Chipset there were specs in an old c't magazine, so I was able to boot into dos with this piece of code... (Don't know if it's still working, I did not try it recently... The floppy code is buggy IIRC... No HD support) Of course this probably doesn't help a bit with openbios development, but maybe someone will find it interesting to look at :-) GPL license, no reverse engineering of propriatary BIOSes was involved, I had to go with only a few books (Basically "PC Hardwarebook" and "PC Programmers Guide to low level Functions and Interrupts") -- Tobias PGP-Key: 0x9AC7E0BC - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

4 6

Re: boy is EFI a kludge!
by ebiederman＠lnxi.com 30 Aug '01

30 Aug '01

Ronald G Minnich <rminnich(a)lanl.gov> writes: > > Ron unless you have something better I'd suggest using one of the > > upcoming dual Itanium/P4 chipsets as a starting point. Then you could > > be certain the chipset worked before on x86 before trying to reverse > > engineer the cpu initialization for the Itanium... > > do we have a vendor name yet? I have seen reports that both Intel and IBM are working on chipsets that will support that. I think the reports were talking many way SMP but possibly that is because where Itanium is positioned. This looks like it may be in the McKinley time frame. I have a strange hunch that McKinley will be bus compatible with the P4. This is what I am picking up through osmosis reading the reviews. Eric - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

3 3

Re: [OpenBIOS] award bios source code - end of discussion
by Stefan Reinauer 30 Aug '01

30 Aug '01

* andye <awe(a)ftt.co.uk> [010828 11:09]: > Please send source > Regards Are you able to read more than 2 lines of mail or are you not able to determine what mails to send to whom? _Any_ other Mail to this list regarding stolen protected, stolen, proprietary source code of Award Bios or whatever software will force me to unsubscribe _everyone_ who asked for such from this list without any further notification _plus_ I will make this list moderated. I am sick of it - This is not a warez trader list. If you have anything to say to the subject OpenBIOS or IEEE 1275-1994 say it. If not, listen or leave. Best regards, Stefan Reinauer OpenBIOS project coordinator -- axiom: electronic devices only work if the smoke stays inside. proof: when smoke comes out they don't work anymore. - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

RE: [OpenBIOS] New power-up graphics BIOS.
by Ralph Stickley 29 Aug '01

29 Aug '01

SVGA may be standard, but which chip-set are you using ? The system setup can be highly unique for each CPU (PII, PIII, Celeron, Ultra-Low Power, etc), "co-processor" (440BX, 440TX, et. al.) and/or Super I/O.... These devices must be initialized before DRAM, PCI bus, etc will get started, even before the Video driver is loaded. Interested observer.... Ralph > ---------- > From: Gavin R. Brewer[SMTP:gavinbr@gavinbr.worldonline.co.uk] > Sent: Thursday, August 16, 2001 3:27 PM > To: openbios(a)elvis.informatik.uni-freiburg.de > Subject: RE: [OpenBIOS] New power-up graphics BIOS. > > James, > > I would like to program in Intel generic 8088 mode, and assume an industry > standard SVGA chip. The code is aimed to be as simple as possible. > > All I would like to do, is to be able to program the SVGA registers to > move, > and rescan pixel efficiently. > > This should be done in a few lines of assembler code. Things like > Bresenham's algorithm etc, can be efficiently coded in C++, so there is no > need to overburden ourselves. > > Thanx, > Gavin. <|;-) > > PS. do you know any useful links where I can download asm snippets? > > -----Original Message----- > From: owner-openbios(a)freiburg.linux.de > [mailto:owner-openbios@freiburg.linux.de]On Behalf Of James Logan > Sent: Thursday, August 16, 2001 7:04 PM > To: openbios(a)elvis.informatik.uni-freiburg.de > Subject: Re: [OpenBIOS] New power-up graphics BIOS. > > > > Gavin, > I would love to help. have you started? what > chip will you be using? > James > > > - > To unsubscribe: send mail to majordomo(a)freiburg.linux.de > with 'unsubscribe openbios' in the body of the message > - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

14 36

Re: boy is EFI a kludge!
by ebiederman＠lnxi.com 29 Aug '01

29 Aug '01

ebiederman(a)lnxi.com (Eric W. Biederman) writes: > Ronald G Minnich <rminnich(a)lanl.gov> writes: > > > OK, looking around, it's about what I expected. > > > > However one thing we might be able to use: EFI is called from something > > called SAL. SAL is real low-level stuff you will never see the source to > > that does all the horrible stuff that Intel won't tell us how to do. > > > > You don't need EFI. You need something to link to SAL that replaces EFI. I > > think that's our hook. > > So if intel won't cooperate we need to plan on reverse engineering SAL. Unless > IA64 dies soon it is probably a worthwhile investment. Ron unless you have something better I'd suggest using one of the upcoming dual Itanium/P4 chipsets as a starting point. Then you could be certain the chipset worked before on x86 before trying to reverse engineer the cpu initialization for the Itanium... That isn't a very aggressive plan but unless we start moving in a hurry it is probably a very workable one. Eric - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

abit motherboard
by Tobak Jeno 29 Aug '01

29 Aug '01

Hello! I have an abit bx6v2 motherboard. Can i use openbios with this? Jenci - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

Re: [OpenBIOS] Re: boy is EFI a kludge!
by Ronald G Minnich 29 Aug '01

29 Aug '01

On Tue, 28 Aug 2001, Per Jessen wrote: > >Hhmmm, that's just gratuitous eye candy, no? Besides, it's pretty trivial > >to replace those graphics with logos or other stuff. I think that doing > >things that are new and usefull (like serial consoles) would really help > >get people and hardware manufacturers interested. Imagine being able to > >run a server farm with no graphics cards, just a serial console and > >ethernet... > we make it easier. We do all our admin on linuxbios clusters over ethernet. Serial console admin is not our idea of a good time. To buy, see www.linuxlabs.com ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 3

Re: sorry, it works, K7SEM (fwd)
by Ronald G Minnich 29 Aug '01

29 Aug '01

Just a sample of what can happen. The K7SEM has two ethernet chips on it, both will probe fine. But if you try to really use the build-in sis900 chip, it hangs the board, because there is no PHY installed. So you really need a bios built for that specific motherboard. PC hardware is really just horrible. There ought to be a spec for reading vendor/mainboard ID. But the vendors change it so often that I doubt that would ever really work. ron ---------- Forwarded message ---------- Date: Wed, 29 Aug 2001 09:07:09 +0800 From: Ollie Lho <ollie(a)sis.com.tw> To: Nikolai Vladychevski <niko(a)isl.net.mx> Cc: Ronald G Minnich <rminnich(a)lanl.gov>, linuxbios(a)lanl.gov Subject: Re: sorry, it works, K7SEM Nikolai Vladychevski wrote: > > Ronald G Minnich writes: > > > please send us your kernel output. You can capture the serial output using > > minicom. > > yes, I am doing this, aparently it dies on loading sis900.c code .... I am > compiling the kernel without it, lets see what happends. this is the current > kernel output: > The is the problem. Do not include the SiS 900 driver for any 730 board which does not have PHY with it. Those boards with RTL 8139 as LAN device are in this category. The driver will hang the machine in probing PHY. Ollie - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: [OpenBIOS] Re: boy is EFI a kludge!
by Per Jessen 28 Aug '01

28 Aug '01

On Tue, 28 Aug 2001 14:58:20 -0600 (MDT), Ronald G Minnich wrote: >On Tue, 28 Aug 2001, Per Jessen wrote: > >> >Hhmmm, that's just gratuitous eye candy, no? Besides, it's pretty trivial >> >to replace those graphics with logos or other stuff. I think that doing >> >things that are new and usefull (like serial consoles) would really help >> >get people and hardware manufacturers interested. Imagine being able to >> >run a server farm with no graphics cards, just a serial console and >> >ethernet... > >we make it easier. We do all our admin on linuxbios clusters over >ethernet. Serial console admin is not our idea of a good time. Completely agree - the serial console is only handy when you have no ethernet. We've recently moved a 16 node cluster, which caused a couple of harddrives to give up - the serial consoles came in quite handy. regards, Per Jessen regards, Per Jessen, Principal Engineer, ENIDAN Technologies Ltd http://www.enidan.com - home of the J1 serial console. ---------------------------------------------------------- Please note: This message is intended for the use of the individual to whom it is addressed and may contain information which is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended, or is not the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return email. Thank you. - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: [OpenBIOS] Re: boy is EFI a kludge!
by ebiederman＠lnxi.com 28 Aug '01

28 Aug '01

Ronald G Minnich <rminnich(a)lanl.gov> writes: > On Tue, 28 Aug 2001, Chris Maresca wrote: > > > There was a post on /. today about a BIOS that boots in .8 sec. That > > seems to be pretty good... Now all we need to do is speed up linux > > boot... > > > we talked about that on the linuxbios list. That was a stupid publicity > stunt. .8 sec is actually pretty slow. Well I wouldn't call it slow. I'd say someone has achieved a reasonable BIOS boot time with a stock BIOS. Eric - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: [OpenBIOS] Re: boy is EFI a kludge!
by Per Jessen 28 Aug '01

28 Aug '01

> >The server farm is a cool idea. If you want, I can submit the outline >design idea for my new multiprocessor machine. Building a multiprocesing >server is quite easy, (some dudes in a UK uni. managed to cobble one >together from old 486 CPUs)..the problem is the operating system... See http://www.beowulf.org , http://www.mosix.org, http://www.scyld.com regards, Per regards, Per Jessen, Zurich http://www.enidan.com - home of the J1 serial console. Windows 2001: "I'm sorry Dave ... I'm afraid I can't do that." - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: [OpenBIOS] Re: boy is EFI a kludge!
by Per Jessen 28 Aug '01

28 Aug '01

>On Tue, 28 Aug 2001 02:01:34 -0700 (PDT), Chris Maresca wrote: > >Hhmmm, that's just gratuitous eye candy, no? Besides, it's pretty trivial >to replace those graphics with logos or other stuff. I think that doing >things that are new and usefull (like serial consoles) would really help >get people and hardware manufacturers interested. Imagine being able to >run a server farm with no graphics cards, just a serial console and >ethernet... We're working on it ... <shameless plug> See http://www.enidan.com/j1 We're not quite there yet with the PCI-version, but it's in progress. </shameless plug> For an alternative, see http://www.realweasel.com. regards, Per Jessen regards, Per Jessen, Principal Engineer, ENIDAN Technologies Ltd http://www.enidan.com - home of the J1 serial console. ---------------------------------------------------------- Please note: This message is intended for the use of the individual to whom it is addressed and may contain information which is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended, or is not the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return email. Thank you. - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

[IMPORTANT] Legal Issues.
by Stefan Reinauer 28 Aug '01

28 Aug '01

Dear OpenBIOS project members and other interested parties, There has been a lot of rumours and discussion about the "availability" of sources for Award BIOS and other commercial firmwares on this mailing list recently. These sources were apparently available from their authors accidently. Due to the copyright and patent infringement implied by such actions as well as the fact that reusing faulty commercial concepts for an open-source firmware implementation is simply a bad idea I have to set down the following ground rules in order to achieve a clean implementation of our project goals and avoid possible future prosecution: 1) The goal of this project is to develop a free, open source, architecture independant firmware implementation following, when possible, the IEEE Standard for Boot (Initialization Configuration) Firmware (IEEE 1275-1994). Including not only the implementation of the standard itself but also the required toolkit consisting of a C to FCode compiler, an FCode tokenizer and an FCode detokenizer. This toolkit will simplify driver and API development implementing ANSI C as the development language instead of Forth/FCode as suggested by the IEEE standard. 2) We cannot allow _any_ discussion or use of _any_ copyrighted, patented, or otherwise protected Firmware or BIOS implementations in this project or on the mailing list associated with this project. All members of this project and/or the according mailing lists agree to not disclose or use any copyrighted, patented, or otherwise protected information, ideas or concepts. 3) We do not intend to implement any of the ideas or concepts expressed in the current Intel 32bit architechture, except when these are necessary to insure the compatability with existing hardware. Such ideas and concepts will only be used if such use is not restricted by _any_ laws, copyrights or patents. 4) In order to assure truly universal implementation and/or optimize the functionality and performance it is our expressed wish to work in conjunction with other open source firmware projects. 5) Cooperation with hardware vendors is necessary to implement this project on an architecture-independent basis. In certain cases this may include signing non-disclosure agreements with the aforementioned hardware vendors in an attempt to acquire hardware specific information or support that may not otherwise be available although the results of such cooperation must be freely redistributable. 6) Cooperation with any university, research project, or organization is desired except in such cases where the resulting information is restricted in use or redistributability. 7) Although we agree with the ideas promoted by the free software foundation we do not and/or cannot necessarily agree with all of the rules set by the foundation. In this light it could, to some extent, be a contrast of wishes to become an offical GNU project. If, for whatever reasons, any of the above statements are unacceptable or seem to be inccorect or unclear in _any_ way please do not hesitate to discuss this matter on the mailing list, I am open for suggestions. This is simply an attempt to assure the legal stauts of this project, protecting those involved from legal prosecution as well as to state the general goals of the project. Best regards, Stefan Reinauer <stepan(a)core-systems.de> OpenBIOS project founder. -- Mad, adj.: Affected with a high degree of intellectual independence. -- Ambrose Bierce, "The Devil's Dictionary" - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

7 13

Re: boy is EFI a kludge!
by ebiederman＠lnxi.com 28 Aug '01

28 Aug '01

Ronald G Minnich <rminnich(a)lanl.gov> writes: > OK, looking around, it's about what I expected. > > However one thing we might be able to use: EFI is called from something > called SAL. SAL is real low-level stuff you will never see the source to > that does all the horrible stuff that Intel won't tell us how to do. > > You don't need EFI. You need something to link to SAL that replaces EFI. I > think that's our hook. As a start perhaps. But there is only one thing I have seen that is slower than the native L440GX BIOS. An Itanium Box. And judging by when the video screen came on it looks like it was probably in that mysterious SAL code. And while I have no problem with BIOS code taking it's time. On a personal level I hate to work with slow BIOS's. And when things are unreasonably slow I suspect that there is something that just doesn't work running in there. So if intel won't cooperate we need to plan on reverse engineering SAL. Unless IA64 dies soon it is probably a worthwhile investment. Eric - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

9 23

Re: [OpenBIOS] Re: boy is EFI a kludge!
by Parag Patel 28 Aug '01

28 Aug '01

On Tue, 28 Aug 2001, Gavin Robert Brewer wrote: > Textual interfaces are pretty much obsolete. Real Computers[1] boot and run without graphic interfaces[2]. [1] Servers, mainframes, and embedded systems[3]. [2] Although some may have serial consoles. [3] Which completely outnumber all other computers put together. -- -- Parag Patel Once ... in the wilds of Afghanistan, I lost my corkscrew, and we were forced to live on nothing but food and water for days. -- W. C. Fields, "My Little Chickadee" - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Award BIOS Source code
by Masoud Sharbiani 28 Aug '01

28 Aug '01

Hi, My Name is Masoud Sharbiani, and I am working for OEone corporation (www.oeone.com), a software developement company which is located in Hull, Quebec, Canada. I am interested in the Award BIOS source code for developing Power management aware appliactions and I have to have the BIOS source code. I would be very grateful if you can either send me the tarball you mentioned, or give me a pointer where I can download it. Best Wishes, Masoud - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

5 8

RE: [OpenBIOS] Re: boy is EFI a kludge!
by Jamie Stanley 28 Aug '01

28 Aug '01

The 'Energy Saver' 'graphics' is nothing more than altering the system font (I remember capturing it afew years ago in dos pascal!) and I know that you can alter it to give any charactor a new appearance (like a bunch of them for say 'Energy Saver')... I'll try and dig out the code if required!.... Jamie. :) -----Original Message----- From: Gavin Robert Brewer [mailto:gavinbr@gavinbr.worldonline.co.uk] Sent: 28 August 2001 09:22 To: openbios(a)elvis.informatik.uni-freiburg.de Subject: Re: [OpenBIOS] Re: boy is EFI a kludge! > There was a post on /. today about a BIOS that boots in .8 sec. That > seems to be pretty good... Now all we need to do is speed up linux > boot... There is a lot of spam during linux bootup that strikes me as gratuitous techie garbage. It would be better to find a way of booting directly into the OpenWindows or some such. Not wishing to be negative, but I would really like to ask Linus as to why he chose to have all that spam redirected to the screen at bootup. It is'nt very eyecatching. We can get around this by hand-coding in some basic graphics primitives. Award BIOS managed to do it with the famous 'Energy Saver' trademark we all see when we power up our PC's...so it must be possible for our coders to capitalise on this kind of 'instant graphics'. Bresenhams' algorithm and some other basic scan-conversion primitives are a must. (For more information, see 'Computer Graphics' by Foley et. Al...) Hope this helps, Gavin. - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

RE: [OpenBIOS] award bios source code - please send requests
by Jason Gurtz 28 Aug '01

28 Aug '01

Sure, send a copy my way please ~Jason > having just returned from a weeks sailing in the Ionian Sea, > I remembered > I had a number of requests for a copy of the Award BIOS source code I > mentioned in a previous posting to the list. > > If you're interested, simply reply to this email. - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

Re: [OpenBIOS] award bios source code - please send requests
by Mukaila Olundegun 28 Aug '01

28 Aug '01

I am interested in the AwardBios source code too. Regards. Mukaila -----Original Message----- From: Per Jessen <per(a)computer.org> To: openbios(a)elvis.informatik.uni-freiburg.de <openbios(a)elvis.informatik.uni-freiburg.de> Cc: eddy(a)noc.everquick.net <eddy(a)noc.everquick.net>; clive.jenkins(a)clara.net <clive.jenkins(a)clara.net>; cu0815(a)compuserve.de <cu0815(a)compuserve.de> Date: Sunday, August 26, 2001 8:36 AM Subject: [OpenBIOS] award bios source code - please send requests >All, > >having just returned from a weeks sailing in the Ionian Sea, I remembered >I had a number of requests for a copy of the Award BIOS source code I >mentioned in a previous posting to the list. > >If you're interested, simply reply to this email. > >Note: the gzipped tar-ball is about 5Mb. > > >regards, >Per > > >regards, >Per Jessen, Zurich >http://www.enidan.com - home of the J1 serial console. > >Windows 2001: "I'm sorry Dave ... I'm afraid I can't do that." > > >- >To unsubscribe: send mail to majordomo(a)freiburg.linux.de >with 'unsubscribe openbios' in the body of the message > - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: [OpenBIOS] award bios source code - please send requests
by Kikelomo Molly Olundegun 28 Aug '01

28 Aug '01

-----Original Message----- From: Per Jessen <per(a)computer.org> To: openbios(a)elvis.informatik.uni-freiburg.de <openbios(a)elvis.informatik.uni-freiburg.de> Cc: eddy(a)noc.everquick.net <eddy(a)noc.everquick.net>; clive.jenkins(a)clara.net <clive.jenkins(a)clara.net>; cu0815(a)compuserve.de <cu0815(a)compuserve.de> Date: Sunday, August 26, 2001 8:36 AM Subject: [OpenBIOS] award bios source code - please send requests >All, > >having just returned from a weeks sailing in the Ionian Sea, I remembered >I had a number of requests for a copy of the Award BIOS source code I >mentioned in a previous posting to the list. > >If you're interested, simply reply to this email. > >Note: the gzipped tar-ball is about 5Mb. > > >regards, >Per > > >regards, >Per Jessen, Zurich >http://www.enidan.com - home of the J1 serial console. > >Windows 2001: "I'm sorry Dave ... I'm afraid I can't do that." > > >- >To unsubscribe: send mail to majordomo(a)freiburg.linux.de >with 'unsubscribe openbios' in the body of the message > - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: boy is EFI a kludge!
by ebiederman＠lnxi.com 28 Aug '01

28 Aug '01

Ronald G Minnich <rminnich(a)lanl.gov> writes: > I'm good with reverse engineering SAL then. All the itanium software that > intel ships is just so terrible from what I've seen. Maybe we can help > them a little :-) My rule of thumb is something like if I have some kind feedback 30 seconds after boot, I figure the BIOS is hopeless. And EFI so far meets those criterion. Eric - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

boy is EFI a kludge!
by Ronald G Minnich 28 Aug '01

28 Aug '01

OK, looking around, it's about what I expected. However one thing we might be able to use: EFI is called from something called SAL. SAL is real low-level stuff you will never see the source to that does all the horrible stuff that Intel won't tell us how to do. You don't need EFI. You need something to link to SAL that replaces EFI. I think that's our hook. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: [OpenBIOS] award bios source code - please send requests
by Gavin Robert Brewer 27 Aug '01

27 Aug '01

Per, I dont want that source code any more. Forget it man. It was a great offer, but I dont wanna get caught. Even if I am in the UK. Gavin. - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

Re: [OpenBIOS] award bios source code - please send requests
by Brian Hurt 27 Aug '01

27 Aug '01

On Sun, 26 Aug 2001, Per Jessen wrote: > All, > > having just returned from a weeks sailing in the Ionian Sea, I remembered > I had a number of requests for a copy of the Award BIOS source code I > mentioned in a previous posting to the list. > > If you're interested, simply reply to this email. > I am somewhat concerned about the potiential licensing and intellectual property rights problems distributing a copy of the proprietary BIOS on the open-bios mailing list, or even to a large segment of it's developers, would entail. Perhaps I missed the original message to the list which dealt with this. Has it been discussed? Brian - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

9 16

Re: [OpenBIOS] award bios source code - please send requests
by Hassan OUBENSAID 27 Aug '01

27 Aug '01

Hi, Thanks for your collaboration in this mailing list. I live in france, and I am really interested in BIOS developpement and hardware programming. Therefore, I woulmd really appreciate if you can send me the AWARD source code for educational purpose. Best regards. Hassan OUBENSAID France. ----- Original Message ----- From: "Per Jessen" <per(a)computer.org> To: <openbios(a)elvis.informatik.uni-freiburg.de> Cc: <eddy(a)noc.everquick.net>; <clive.jenkins(a)clara.net>; <cu0815(a)compuserve.de> Sent: Sunday, August 26, 2001 3:43 PM Subject: [OpenBIOS] award bios source code - please send requests > All, > > having just returned from a weeks sailing in the Ionian Sea, I remembered > I had a number of requests for a copy of the Award BIOS source code I > mentioned in a previous posting to the list. > > If you're interested, simply reply to this email. > > Note: the gzipped tar-ball is about 5Mb. > > > regards, > Per > > > regards, > Per Jessen, Zurich > http://www.enidan.com - home of the J1 serial console. > > Windows 2001: "I'm sorry Dave ... I'm afraid I can't do that." > > > - > To unsubscribe: send mail to majordomo(a)freiburg.linux.de > with 'unsubscribe openbios' in the body of the message > - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: [OpenBIOS] award bios source code - please send requests
by Stefan Reinauer 27 Aug '01

27 Aug '01

* Per Jessen <per(a)computer.org> [010827 21:37]: > >somebody made a similar offer a long time ago on the linuxbios mailing > >list. I checked the old emails in that concerning this. About four or five > >people told the person we were not at all interested, since it was a > >proprietary bios and the code probably sucked anyway (that is one thing > >I've learned by talking to people who did have access to this standard > >BIOSes -- hideous assembly code). > > Certainly assembler code - and not particularly pretty either. I don't see it > being used anywhere for anything else than perhaps a learning exercise. Which is indeed enough for getting sued or not being able to work on the project. Someone described the process of reengineering the IBM Bios in the early 80ies some days ago on this mailing list. The OpenBIOS project is not interested in any proprietary crap, neither from AMI nor Award/Phoenix, nor any other commercial Firmware implementation. The idea is exactly to do stuff better by starting a completely new implementation based on IEEE 1275-1994. For this purpose, any proprietary sources are useless anyways. Regarding the fact that this discussion appeared on the OpenBIOS mailing list I have to see what consequences the core maintainance and development team has to make to clarify that no work we did was based on seeing or copying proprietary code from whom whatsoever. Best regards / Mit freundlichen Grüßen, Stefan Reinauer <stepan(a)suse.de> -- Mad, adj.: Affected with a high degree of intellectual independence. -- Ambrose Bierce, "The Devil's Dictionary" - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: [OpenBIOS] award bios source code - please send requests
by Per Jessen 27 Aug '01

27 Aug '01

On Mon, 27 Aug 2001 13:12:15 -0600 (MDT), Ronald G Minnich wrote: >On Mon, 27 Aug 2001, Per Jessen wrote: > >> I certainly have no intention of breaking any laws and/or regulations, >> or violating anybodys copyrights. Most assuredly not. I believe the >> code was already made publicly available a while ago, quite possibly >> via the linuxbios mailing list. > > >somebody made a similar offer a long time ago on the linuxbios mailing >list. I checked the old emails in that concerning this. About four or five >people told the person we were not at all interested, since it was a >proprietary bios and the code probably sucked anyway (that is one thing >I've learned by talking to people who did have access to this standard >BIOSes -- hideous assembly code). Certainly assembler code - and not particularly pretty either. I don't see it being used anywhere for anything else than perhaps a learning exercise. regards, Per regards, Per Jessen, Zurich http://www.enidan.com - home of the J1 serial console. Windows 2001: "I'm sorry Dave ... I'm afraid I can't do that." - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: [OpenBIOS] award bios source code - please send requests
by Ronald G Minnich 27 Aug '01

27 Aug '01

who wants to contact award and find out what's going on? ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: [OpenBIOS] award bios source code - please send requests
by Ronald G Minnich 27 Aug '01

27 Aug '01

On Mon, 27 Aug 2001, Per Jessen wrote: > I certainly have no intention of breaking any laws and/or regulations, > or violating anybodys copyrights. Most assuredly not. I believe the > code was already made publicly available a while ago, quite possibly > via the linuxbios mailing list. somebody made a similar offer a long time ago on the linuxbios mailing list. I checked the old emails in that concerning this. About four or five people told the person we were not at all interested, since it was a proprietary bios and the code probably sucked anyway (that is one thing I've learned by talking to people who did have access to this standard BIOSes -- hideous assembly code). But we've never been willing to go near it. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: [OpenBIOS] award bios source code - please send requests
by Per Jessen 27 Aug '01

27 Aug '01

On Mon, 27 Aug 2001 09:34:50 -0700 (PDT), Chris Maresca wrote: > >Unless, that is, Per Jessen has a license to distribute source code AND >has the authority to release it for inclusion in Open Source licensed >software. The code is copyrighted by Award, and is not for inclusion into anything. Like I said before, I have no intention of violating anybodys copyrights, and if it is felt that this is the case, I shall immediately withdraw the offer. However, the code was made available to me with no conditions, perhaps with the exception that the copyrights were honoured. regards, Per Jessen regards, Per Jessen, Zurich http://www.enidan.com - home of the J1 serial console. Windows 2001: "I'm sorry Dave ... I'm afraid I can't do that." - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: [OpenBIOS] award bios source code - please send requests
by Per Jessen 27 Aug '01

27 Aug '01

On Mon, 27 Aug 2001 10:02:06 -0600 (MDT), Ronald G Minnich wrote: >On Mon, 27 Aug 2001, Brian Hurt wrote: > >> On Sun, 26 Aug 2001, Per Jessen wrote: >> >> > All, >> > >> > having just returned from a weeks sailing in the Ionian Sea, I remembered >> > I had a number of requests for a copy of the Award BIOS source code I >> > mentioned in a previous posting to the list. >> > >> > If you're interested, simply reply to this email. >> > >> >> I am somewhat concerned about the potiential licensing and intellectual >> property rights problems distributing a copy of the proprietary BIOS on >> the open-bios mailing list, or even to a large segment of it's developers, >> would entail. Perhaps I missed the original message to the list which >> dealt with this. Has it been discussed? > >I'm just really glad it's on the openbios list. If this discussion had >appeared on any list I own I would have had to moderate the list or filter >out the offers for BIOS source or just plain reject mail from people who >offered it. >Yes, I think it's a terrible thing. I certainly have no intention of breaking any laws and/or regulations, or violating anybodys copyrights. Most assuredly not. I believe the code was already made publicly available a while ago, quite possibly via the linuxbios mailing list. regards, Per Jessen regards, Per Jessen, Zurich http://www.enidan.com - home of the J1 serial console. Windows 2001: "I'm sorry Dave ... I'm afraid I can't do that." - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: [OpenBIOS] award bios source code - please send requests
by Per Jessen 27 Aug '01

27 Aug '01

On Mon, 27 Aug 2001 09:55:06 -0500 (CDT), Brian Hurt wrote: >On Sun, 26 Aug 2001, Per Jessen wrote: > >> All, >> >> having just returned from a weeks sailing in the Ionian Sea, I remembered >> I had a number of requests for a copy of the Award BIOS source code I >> mentioned in a previous posting to the list. >> >> If you're interested, simply reply to this email. >> > >I am somewhat concerned about the potiential licensing and intellectual >property rights problems distributing a copy of the proprietary BIOS on >the open-bios mailing list, or even to a large segment of it's developers, >would entail. Perhaps I missed the original message to the list which >dealt with this. Has it been discussed? I don't believe it has, and I have no intention of making this is a public distribution. I have invited individuals who have an interest in perusing the code to email me directly. I don't recall where I obtained the code - but I believe it was of some other mailing-list, possibly to do with the linuxbios project. regards, Per regards, Per Jessen, Zurich http://www.enidan.com - home of the J1 serial console. Windows 2001: "I'm sorry Dave ... I'm afraid I can't do that." - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: proprietary BIOS src leagality? (was: RE: [OpenBIOS] award bios...)
by Parag Patel 27 Aug '01

27 Aug '01

In message <HBEEKNPPKIMFLJHGHNHMOEBLCBAA.jason(a)tommyk.com>, "Jason Gurtz" writes: > >As long as none of the proprietary code is used in Open BIOS, what >whould be the harm? Even looking at the proprietary code, then working on anything similar such as the free version is enough to get one sued, at least here in the USA. That's why way back when the Phoenix folks had to do a complete "clean-room" re-implementation of the IBM BIOS, and *still* had to deal with legal hassles. If you really need to look at the proprietary code, you should contact its owner and cut a deal of some sort. Looking at this sort of code without some sort of license or agreement can leave you, and worse, anyone who hires you, in a legal pickle. It's far better to ask questions of someone with legal access to the code and use their answers (but no code) to work on OpenBIOS. -- Parag Patel - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: [OpenBIOS] award bios source code - please send requests
by Ross 27 Aug '01

27 Aug '01

----- Original Message ----- From: Per Jessen <per(a)computer.org> To: <openbios(a)elvis.informatik.uni-freiburg.de> Cc: <eddy(a)noc.everquick.net>; <clive.jenkins(a)clara.net>; <cu0815(a)compuserve.de> Sent: Sunday, August 26, 2001 6:43 AM Subject: [OpenBIOS] award bios source code - please send requests > All, > > having just returned from a weeks sailing in the Ionian Sea, I remembered > I had a number of requests for a copy of the Award BIOS source code I > mentioned in a previous posting to the list. > > If you're interested, simply reply to this email. > > Note: the gzipped tar-ball is about 5Mb. > > > regards, > Per > > > regards, > Per Jessen, Zurich > http://www.enidan.com - home of the J1 serial console. > > Windows 2001: "I'm sorry Dave ... I'm afraid I can't do that." > > > - > To unsubscribe: send mail to majordomo(a)freiburg.linux.de > with 'unsubscribe openbios' in the body of the message > Can you please send me a copy of the Award BIOS source code thank you in advance. ///Ross - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 1

Re: [OpenBIOS] award bios source code - please send requests
by Luca Pellanda 27 Aug '01

27 Aug '01

Can you please send me a copy of the Award BIOS source code thank you in advance. //Luca Per Jessen ha scritto: > All, > > having just returned from a weeks sailing in the Ionian Sea, I remembered > I had a number of requests for a copy of the Award BIOS source code I > mentioned in a previous posting to the list. > > If you're interested, simply reply to this email. > > Note: the gzipped tar-ball is about 5Mb. > > regards, > Per > > regards, > Per Jessen, Zurich > http://www.enidan.com - home of the J1 serial console. > > Windows 2001: "I'm sorry Dave ... I'm afraid I can't do that." > > - > To unsubscribe: send mail to majordomo(a)freiburg.linux.de > with 'unsubscribe openbios' in the body of the message - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: [OpenBIOS] award bios source code - please send requests
by foo bar 27 Aug '01

27 Aug '01

hook me up! >From: "Per Jessen" <per(a)computer.org> >Reply-To: openbios(a)elvis.informatik.uni-freiburg.de >To: "openbios(a)elvis.informatik.uni-freiburg.de" ><openbios(a)elvis.informatik.uni-freiburg.de> >CC: "eddy(a)noc.everquick.net" <eddy(a)noc.everquick.net>, >"clive.jenkins(a)clara.net" <clive.jenkins(a)clara.net>, >"cu0815(a)compuserve.de" <cu0815(a)compuserve.de> >Subject: [OpenBIOS] award bios source code - please send requests >Date: Sun, 26 Aug 2001 15:43:26 +0200 >MIME-Version: 1.0 >Received: from [132.241.6.19] by hotmail.com (3.2) with ESMTP id >MHotMailBD52621A00464004311384F10613D8090; Sun, 26 Aug 2001 08:34:58 -0700 >Received: from wesley.informatik.uni-freiburg.de >(wesley.informatik.uni-freiburg.de [132.230.153.50])by >bengal.ecst.csuchico.edu (8.11.4/8.11.4) with ESMTP id f7QFYi911323for ><icemann(a)ecst.csuchico.edu>; Sun, 26 Aug 2001 08:34:45 -0700 (PDT) >Received: (from majordomo@localhost)by wesley.informatik.uni-freiburg.de >(8.8.8/8.8.8) id RAA09767for openbios-outgoing; Sun, 26 Aug 2001 17:07:53 >+0200 >Received: from avalon.informatik.uni-freiburg.de >(avalon.informatik.uni-freiburg.de [132.230.150.1])by >wesley.informatik.uni-freiburg.de (8.8.8/8.8.8) with ESMTP id RAA09764for ><openbios(a)elvis.informatik.uni-freiburg.de>; Sun, 26 Aug 2001 17:07:50 >+0200 >Received: from mailgateway1.uni-freiburg.de (mailgateway1.uni-freiburg.de >[132.230.1.211])by avalon.informatik.uni-freiburg.de (8.9.0/8.9.0) with >ESMTP id RAA26498for <openbios(a)elvis.informatik.uni-freiburg.de>; Sun, 26 >Aug 2001 17:07:46 +0200 (MET DST) >Received: from mta2n.bluewin.ch ([195.186.1.211])by >mailgateway1.uni-freiburg.de with esmtp (Exim 3.22 #1)id >15b1Vp-0005EH-00for openbios(a)elvis.informatik.uni-freiburg.de; Sun, 26 Aug >2001 17:07:45 +0200 >Received: from uranus (213.3.173.206) by mta2n.bluewin.ch (5.5.042) >id 3B7A7A85003E7E8A; Sun, 26 Aug 2001 17:03:13 +0200 >From owner-openbios(a)elvis.informatik.uni-freiburg.de Sun, 26 Aug 2001 >08:35:06 -0700 >Message-ID: <3B7A7A85003E7E8A(a)mta2n.bluewin.ch> (added by >postmaster(a)bluewin.ch) >X-Mailer: PMMail 98 Professional (2.01.1600) For Windows 95 (4.0.1212) >Sender: owner-openbios(a)elvis.informatik.uni-freiburg.de >Precedence: bulk > >All, > >having just returned from a weeks sailing in the Ionian Sea, I remembered >I had a number of requests for a copy of the Award BIOS source code I >mentioned in a previous posting to the list. > >If you're interested, simply reply to this email. > >Note: the gzipped tar-ball is about 5Mb. > > >regards, >Per > > >regards, >Per Jessen, Zurich >http://www.enidan.com - home of the J1 serial console. > >Windows 2001: "I'm sorry Dave ... I'm afraid I can't do that." > > >- >To unsubscribe: send mail to majordomo(a)freiburg.linux.de >with 'unsubscribe openbios' in the body of the message _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

Odp: [OpenBIOS] award bios source code - please send requests
by Krzysztof Dabrowski 27 Aug '01

27 Aug '01

Hi Per , I'm interested in Award BIOS source code. Regards ----- Original Message ----- From: Per Jessen <per(a)computer.org> To: <openbios(a)elvis.informatik.uni-freiburg.de> Cc: <eddy(a)noc.everquick.net>; <clive.jenkins(a)clara.net>; <cu0815(a)compuserve.de> Sent: Sunday, August 26, 2001 3:43 PM Subject: [OpenBIOS] award bios source code - please send requests > All, > > having just returned from a weeks sailing in the Ionian Sea, I remembered > I had a number of requests for a copy of the Award BIOS source code I > mentioned in a previous posting to the list. > > If you're interested, simply reply to this email. > > Note: the gzipped tar-ball is about 5Mb. > > > regards, > Per > > > regards, > Per Jessen, Zurich > http://www.enidan.com - home of the J1 serial console. > > Windows 2001: "I'm sorry Dave ... I'm afraid I can't do that." > > > - > To unsubscribe: send mail to majordomo(a)freiburg.linux.de > with 'unsubscribe openbios' in the body of the message > - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: [OpenBIOS] award bios source code - please send requests
by Dan Lita 27 Aug '01

27 Aug '01

It would be nice to have the source code. So if you can please send me one Thanks Dan ----- Original Message ----- From: "Per Jessen" <per(a)computer.org> To: <openbios(a)elvis.informatik.uni-freiburg.de> Cc: <eddy(a)noc.everquick.net>; <clive.jenkins(a)clara.net>; <cu0815(a)compuserve.de> Sent: Sunday, August 26, 2001 4:43 PM Subject: [OpenBIOS] award bios source code - please send requests > All, > > having just returned from a weeks sailing in the Ionian Sea, I remembered > I had a number of requests for a copy of the Award BIOS source code I > mentioned in a previous posting to the list. > > If you're interested, simply reply to this email. > > Note: the gzipped tar-ball is about 5Mb. > > > regards, > Per > > > regards, > Per Jessen, Zurich > http://www.enidan.com - home of the J1 serial console. > > Windows 2001: "I'm sorry Dave ... I'm afraid I can't do that." > > > - > To unsubscribe: send mail to majordomo(a)freiburg.linux.de > with 'unsubscribe openbios' in the body of the message > - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: [OpenBIOS] award bios source code - please send requests
by Edwin Rhodes 27 Aug '01

27 Aug '01

i wouldnt say no! :) ----- Original Message ----- From: "Per Jessen" <per(a)computer.org> To: <openbios(a)elvis.informatik.uni-freiburg.de> Cc: <eddy(a)noc.everquick.net>; <clive.jenkins(a)clara.net>; <cu0815(a)compuserve.de> Sent: Sunday, August 26, 2001 2:43 PM Subject: [OpenBIOS] award bios source code - please send requests > All, > > having just returned from a weeks sailing in the Ionian Sea, I remembered > I had a number of requests for a copy of the Award BIOS source code I > mentioned in a previous posting to the list. > > If you're interested, simply reply to this email. > > Note: the gzipped tar-ball is about 5Mb. > > > regards, > Per > > > regards, > Per Jessen, Zurich > http://www.enidan.com - home of the J1 serial console. > > Windows 2001: "I'm sorry Dave ... I'm afraid I can't do that." > > > - > To unsubscribe: send mail to majordomo(a)freiburg.linux.de > with 'unsubscribe openbios' in the body of the message > - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: [OpenBIOS] award bios source code - please send requests
by Gavin Robert Brewer 26 Aug '01

26 Aug '01

I'm game <|;-) - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

award bios source code - please send requests
by Per Jessen 26 Aug '01

26 Aug '01

All, having just returned from a weeks sailing in the Ionian Sea, I remembered I had a number of requests for a copy of the Award BIOS source code I mentioned in a previous posting to the list. If you're interested, simply reply to this email. Note: the gzipped tar-ball is about 5Mb. regards, Per regards, Per Jessen, Zurich http://www.enidan.com - home of the J1 serial console. Windows 2001: "I'm sorry Dave ... I'm afraid I can't do that." - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Platform for the OPENBIOS question
by Lloyd Thomson 23 Aug '01

23 Aug '01

Hi all Maybe I missed it, but for the Open BIOS that is being discussed, is there a specific single board computer (SBC), motherboard, chipset (or ?) that the BIOS will be targeted on. My understanding is that this will be an x86 board, and it sounds like it will be at least partly targeted toward the game industry. However, since my favorite language is actually solder, I am mostly curious. There are a lot of chipset options out there, and each one of these may have a different effect on the workings and architecture of the BIOS. If this has not been discussed, you all may want to do so. Incidentally, I would also recommend that you start with a monitor level input / output / short command structure. It really makes it easier to test code and eliminate problems when you have a basic (NOT BASIC) set of commands that you can use to look at or change control registers and memory locations. On new hardware projects, I also like to either get a serial port working first thing, or will hook up a small ASCII LCD panel to the system. That way I can see what is going on inside by using simple print statements, and can check to see that variables are what I expect, and that certain stages of the software are being executed. Later Lloyd Thomson Sr. Design Engineer One Stop Satellite Solutions 1805 University Cir Ogden, UT 84408-1805 801 626 7272 lloyd.thomson(a)osss.com www.osss.com "If we knew what we were doing, it wouldn't be called research, would it" Albert Einstein

7 24

Re: [OpenBIOS] Platform for the OPENBIOS question
by Nicholas Charles Leippe 22 Aug '01

22 Aug '01

> BTW, does the DS10 you used for your tests have a socketed flash? We have two > here, but both have soldered SMD flash roms. Unfortunately, I did a mistake > when I was flashing LinuxBIOS the last time. As they only do in rom FSB, > there's no way out except calling compaq service. > For about $30 in parts and 20-30 minutes of soldering work you can build your own flash-rom ISA card. Search for "c't flasher". If ppl are interested, I can dig up more links, or perhaps, if ppl are scared off by soldering I could assemble some more myself. I built one for myself already last time I hosed a bios (flashed in the stupid zip file instead of the rom image--doh!) and it's far more cost effective to just build the burner than to buy a single replacement rom--especially since the very next rom image I tried on that board was also a no-go. Nick - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

RE: [OpenBIOS] New power-up graphics BIOS.
by Gavin R. Brewer 20 Aug '01

20 Aug '01

Guys & Gals, I have just printed the USENIX conference notes on LinuxBIOS, and skimming through it, I am impressed with what I see. It would be a really good idea if a group of us were to write a new BIOS, (Mac-style), which was very similar to LinuxBIOS, but links in with Darwin (the MacOS-X Kernel). If we can pull this one off, it will be a serious blow to Micro$oft. Some of the guys in Apple will love us, since we will have finally put the last stake into the heart of closed proprietory systems... Let's do it folks. All the best, Gavin. - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

5 7

Re: [OpenBIOS] New power-up graphics BIOS.
by zechmer 20 Aug '01

20 Aug '01

Hello Per, I would be very glad, if you could send me the A*I BIOS source too. Perhaps I could overcome my keyboard problems then. Thanks Bernhard - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

New power-up graphics BIOS.
by Gavin R. Brewer 19 Aug '01

19 Aug '01

Hi there, I would like to write my own simple BIOS functions for controlling the SVGA CRT directly. With a bit of luck, this should form part of a computer system, (Intel compatible), that boots straight into a GUI. Does anyone wish to help me with this project? All the best, Gavin. - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

3 5

Re: [OpenBIOS] Graphics mode bios
by Arp Kruithof 19 Aug '01

19 Aug '01

From: Arp Kruithof <arpy(a)wish.net> To: "zechmer" <cu0815(a)compuserve.de> Subject: Re: [OpenBIOS] Graphics mode bios Send reply to: arpy(a)wish.net Date sent: Thu, 16 Aug 2001 16:26:05 +0200 Hello Gavin/Bernhard > Hello Gavin, I certainly like the project - have been looking / thinking / dreaming about an open source BIOS for x86 for some years (not openBIOS) and some projects seem to be underway - I just have very little time myself at the moment so for now I'll happily read along ... > I once started writing my own BIOS which started already in > graphics (hercules monochrome graphics) mode back in the 1980's [pure > assembler]. > I gave it up, because I couldn't init the keyboard correctly. > Each time I requested port 60h it didn't leave anything there. > Later I implemented the keyboard code from linux but this > didn't help me and the 286 board at all. > This was so frustrating, that I gave it up. > Perhaps some suggestions? Couldn'r resist reacting to the keyboard issue Bernhard mentioned. That shoudn't be too hard to do I think. A couple of sources might be: - IBM AT Technical Reference which has a complete BIOS source listing - just to pick up on some tech details or ideas (not sugesting you copy the code just that reading it may give you a hint). - 8042 datasheets for timing details etc. on original chip used - Datasheets for popular chipsets that emulate the gate A20 & keyboard interface - they may even come with sample code supplied I should have most of that sitting on the bookshelf here so if you need to 'borough' the books let me know. Good luck Arp ------- End of forwarded message ------- arpy(a)wish.net - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

6 6

Archive ;)
by Daniele Frijia 18 Aug '01

18 Aug '01

Hi, the archive of the mailinglist is repaired again. Has someone a complete mailbox of all mails? I have lost a lot. Regards, Daniele - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

3 2

Recommended Reading List..
by Gavin Robert Brewer 17 Aug '01

17 Aug '01

Guys, Just a quick sneak preview of some new entries to my bookshelf: Anderson, Peter B: A Theory of Computer Semiotics, Cambridge. Wilton, Richard: Programmer's Guide to PC & PS/2 Video Systems, Micro$oft Press. Levine, John: Programming for Graphics Files in C and C++. Wiley Press. All the best, Gavin. - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

RE: [OpenBIOS] New power-up graphics BIOS.
by Per Jessen 17 Aug '01

17 Aug '01

On Fri, 17 Aug 2001 08:35:38 +0100, Gavin R. Brewer wrote: > >>At startup the conventional PC-BIOS searches (scans) for additional >>ROMs, such as VGA-ROM. > >Kewl. Actually I have noticed that my Savage4 card displays stuff on the >screen before the main BIOS is activated. Interesting.. Not at all. Until you have video, your PC is deaf and blind. Hence, the first thing the main BIOS does it look at address 0xC000 to see if it has a BIOS image. If found, it call the init vector defined in it, which will typically carry on initialising the VGA card. Part of the init is displaying that "hello" message. The BIOS start-up sequence is well-documented. >>It is then initialized. So a text startup copyright message of the >>VGA-card would appear on the screen (so does my old SPEA VEGA V7 >>card). > >>How would you overcome this "problem"? I didn't have any ideas, >>because the BIOS needs int 10h for output functions. > >Hmm.. I propose someone port something like MacOS or Linux onto ROM first, >mainly as an improved form of BIOS. I think this has been done. There were discussions on this list (I think) a while ago. The idea was to cut the BIOS down as much as possible, and leave all the setup to Linux. I think the project might been called LinuxBIOS ? > >There is only one way to get around this problem. Consider merging, >integrating and simplifying the VGA-BIOS with the system ROM so that we get >an integrated bootup sequence, with no textual spam. > >Anyone know how to reverse engineer AMI-BIOS for example? I think I have source for an Award BIOS somewhere - you can have that. regards, Per Jessen (will be away for 9 days, so don't expect any quick replies to emails :-) regards, Per Jessen, Zurich http://www.enidan.com - home of the J1 serial console. Windows 2001: "I'm sorry Dave ... I'm afraid I can't do that." - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

RE: [OpenBIOS] Apple Contacts!
by Jamie Stanley 17 Aug '01

17 Aug '01

Here are some UK numbers, for you. United Kingdom (44) 0870 876 0753 (44) 0870 876 0933 *think this is the main one?!?* Jamie -----Original Message----- From: Gavin R. Brewer [mailto:gavinbr@gavinbr.worldonline.co.uk] Sent: 17 August 2001 11:07 To: openbios(a)elvis.informatik.uni-freiburg.de Subject: RE: [OpenBIOS] New power-up graphics BIOS. Jamie, Could you or someone else pls. give me a contact telephone no. for Apple Computers? I desperately need to make a deal with them. All the best, Gavin. - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

RE: [OpenBIOS] New power-up graphics BIOS.
by Jamie Stanley 17 Aug '01

17 Aug '01

Hi there, Was wondering if I could help! At present (too be honest) not too familiar with the OpenBios stuff! But I know its sommit Id like to get into ;) As for references - I am a software engineer (www.systolix.co.uk) and so should be able to contribute in some way ;) let me know. cheers - Jamie. -----Original Message----- From: Gavin R. Brewer [mailto:gavinbr@gavinbr.worldonline.co.uk] Sent: 16 August 2001 22:09 To: openbios(a)elvis.informatik.uni-freiburg.de Subject: RE: [OpenBIOS] New power-up graphics BIOS. Ralph, I am using a reference book on the VESA SVGA standard version 1.1 as a source of code snippets etc: EGA/VGA: A programmer's reference guide By Bradley Dyck Kliewer McGraw Hill Publishers. I know this is really retro, but if we can stick to code which is a little way back down the evolutionary tree of hardware, we might be able to create 'instant' graphics from the BIOS. What would be crucial is some sort of power-up self-testing function, that determines what kind of SVGA chipset is present, (only the largest families considered), and applies different code for each chipset. Clearly this would be much better hand-coded in C++ rather than assembler; lest things get icky. All the best, Gavin. -----Original Message----- From: owner-openbios(a)freiburg.linux.de [mailto:owner-openbios@freiburg.linux.de]On Behalf Of Ralph Stickley Sent: Thursday, August 16, 2001 9:14 PM To: openbios(a)elvis.informatik.uni-freiburg.de; 'openbios(a)freiburg.linux.de' Subject: RE: [OpenBIOS] New power-up graphics BIOS. SVGA may be standard, but which chip-set are you using ? The system setup can be highly unique for each CPU (PII, PIII, Celeron, Ultra-Low Power, etc), "co-processor" (440BX, 440TX, et. al.) and/or Super I/O.... These devices must be initialized before DRAM, PCI bus, etc will get started, even before the Video driver is loaded. Interested observer.... Ralph - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

None
by Gavin R. Brewer 17 Aug '01

17 Aug '01

Hi there, I would like to write my own simple BIOS functions for controlling the SVGA CRT directly. With a bit of luck, this should form part of a computer system, (Intel compatible), that boots straight into a GUI. Does anyone wish to help me with this project? All the best, Gavin. - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

2 1

Re: gnubios
by Edwin Rhodes 27 Jul '00

27 Jul '00

Hi, when i tried to compile openbios i got the following error message: -------------------------- (more before this...) gcc -Wall -02 -I/rom/OpenBIOS-0.0.2/include/ -I/rom/OpenBIOS-0.0.2/firmware/ inclu de -c -o trap_ent.o trap_ent.S ld -r -o init.o head.o main.o video.o console.o traps.o irq.o irq_ent.o timer.o dma.o serial.o nvram.o keyboard.o memtest.o memory.o trap_ent.o make[2]: Leaving directory 'rom/OpenBIOS-0.0.2/firmware/init' make[2]: Entering directory '/rom/OpenBIOS-0.0.2/firmware/lib' gcc -Wall -02 -I/rom/OpenBIOS-0.0.2/include/ -I/rom/OpenBIOS-0.0.2/firmware/ inclu de -c -o vsprintf.o vsprintf.c gcc -Wall -02 -I/rom/OpenBIOS-0.0.2/include/ -I/rom/OpenBIOS-0.0.2/firmware/ inclu de -c -o ctype.o ctype.c gcc -Wall -02 -I/rom/OpenBIOS-0.0.2/include/ -I/rom/OpenBIOS-0.0.2/firmware/ inclu de -c -o string.o string.c ld -r -o lib.o vsprintf.o ctype.o string.o make[2]:Leaving directory '/rom/OpenBIOS-0.0.2/firmware/lib' ld -Ttext 0x1400 -e main_start -o fw init/init.o lib/lib.o init/init.o: In fuction 'main': init/init.o(.text+0x83): undefined reference to 'sio_init' make[1] *** [zfw.bin] Error 1 make[1] Leaving directory '/rom/OpenBIOS-0.0.2/firmware' make[1] Entering directory '/rom/OpenBIOS-0.0.2/boot' make[1] *** No rule to make target '.../firmware/zfw.bin', needed by 'rom.bin'. Stop. make[1]: Leaving directory '/rom/OpenBIOS-0.0.2/boot' make: *** [subdirs] Error 2 SERVERX2:/rom/OpenBIOS-0.0.2 # _ thanks edwin ----------------------------------------------- how do i correct it?? ----- Original Message ----- From: Niklas Ekström <niklas(a)ekstrom.com> To: Edwin Rhodes <edwin_rhodes(a)hotmail.com> Sent: Wednesday, July 26, 2000 2:48 PM Subject: Re: gnubios > Nope, it's not, sorry about that. I have realized that if I'm going to get a > releasable version sometime, I'll have to get somebody else to work with me > on the project; it's just too much work for one person. Unfortunately, I > don't know where to look for people willing to devote their free time on a > bios project. > > / Niklas > > ----- Original Message ----- > From: Edwin Rhodes > To: niklas(a)ekstrom.com > Sent: Monday, July 24, 2000 1:36 PM > Subject: gnubios > > > Hi, What is the current status of gnubios???? > is the source code availiable yet?? > thanks > edwin > > - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

OT: linux kernel problem
by Edwin Rhodes 17 Jul '00

17 Jul '00

when compiling my linux kernel i keep on recieving this message: Warning: Clock Skew Detected Build May Be Incomplete It seams to compile ok. What does this error message mean?? and how can i fix it. thanks edwin ps. I have only been getting this message since i upgraded to an AMD K6-2 500Mhz.

4 3

Good News!! LinuxBIOS Boots with SiS 630 Internal VGA ON !!
by Ollie Lho 12 Jul '00

12 Jul '00

Dear all, We have reach the milestone that we can now turn on the SiS 630 internal VGA under the LinuxBIOS enviroment. At this point, traditional BIOS can be totally replaced with LinuxBIOS on SiS 630. Thanks a lot to our VGA department for their SiS Frame Buffer Device support. Ronald, Jeff, The patch and romimage will be sent to you via another mail with the detail description of how to do it on your side and other (performance) issue we need to address from now on. Ollie - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: [OpenBIOS] what's a k7v
by Ronald G Minnich 06 Jul '00

06 Jul '00

On Thu, 6 Jul 2000, Jeff Garzik wrote: > Probably either Via or AMD... I have a bunch of Via info, if it turns > out to be a Via-based motherboard. To the original posted, use "lspci" > to find out the info on your motherboard's chipset. in general, a good idea. For everyone out there, next time you send a query about your mainboard, attach an 'lspci'. we will be looking at k7v in a few weeks. ron - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0