OpenBIOS

openbios@openbios.org

4297 discussions

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 01 Oct '02

01 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 04 Aug '02

04 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 08 Jul '02

08 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

Jump to page: