On Tue, 1 Mar 2005, Anton Borisov wrote:
Payload is file that holds, for instance, LAN ROM, i.e. software responsible for remoting loading from server. It's just an example. There are FAQs (try to google) which explain much of your questions.
LinuxBIOS (initialises hardware) -> payload (etherboot,OpenBIOS, FILO etc.) (-> operating system)?
Ok, but that was just an example. Technical jargon explanation is still needed to get into linuxbios. For instance: http://www.clustermatic.org/pipermail/linuxbios/2003-March/002240.html
This mail mentions SPD,VID,DID,I2C etc. Does everybody know what these mean? To get more people interested in linuxbios one has to lower the bars, and technical jargon is a major blocker (at least for me). And yes, I do know what i2c is, and I think I know what spd is (ram speed?) but vid & did does not ring a bell. For anyone not knowing what i2c is I'll recommend: http://www.esacademy.com/faq/i2c/index.htm
Best regards
Peter K
On Tue, Mar 01, 2005 at 12:44:23PM +0100, Peter Karlsson wrote:
LinuxBIOS (initialises hardware) -> payload (etherboot,OpenBIOS, FILO etc.) (-> operating system)?
Exactly right. But with the right flash memory on the mainboard you can use the operating system (Linux) as payload directly.
Ok, but that was just an example. Technical jargon explanation is still needed to get into linuxbios. For instance: http://www.clustermatic.org/pipermail/linuxbios/2003-March/002240.html
This mail mentions SPD,VID,DID,I2C etc. Does everybody know what these mean? To get more people interested in linuxbios one has to lower the bars, and technical jargon is a major blocker (at least for me).
I'm not sure I agree that the bar must be lowered. Much of the development going on in LinuxBIOS is _heavily_ technical and spans across quite a few different architectures. It's not right or useful to force developers to work and/or communicate below their capabilities, and certainly not in an open source project. I would hate it if someone tried to do that to me.
I do believe however, that all the technical prerequisite knowledge should be listed, so that people can get up-to-speed on their own. I'll try to work for this and I think that the wiki is a great forum.
And yes, I do know what i2c is, and I think I know what spd is (ram speed?)
SPD is Serial Presence Detect, the name of an I2C bus between the northbridge and all RAM modules. Each RAM module has an EEPROM with more or less correct information about how memory initialization code should set up the memory controller for correct size and optimal performance. Quite frequently the information is busted. :(
but vid & did does not ring a bell.
These are short for Vendor ID and Device ID. VID and DID (or PID, Product ID) are id numbers assigned by organizations such as PCI-SIG and USBIF to hardware manufacturers allowing software to identify hardware in a reliable manner. The ids are stored inside the device, whether it's PCI or USB. Also true for PCMCIA/CardBus.
//Peter
On Tue, 1 Mar 2005, Peter Stuge wrote:
Exactly right. But with the right flash memory on the mainboard you can use the operating system (Linux) as payload directly.
Ok, thanks. I've seen this discussed on this list; dependent on size of flash mem.
I'm not sure I agree that the bar must be lowered. Much of the development going on in LinuxBIOS is _heavily_ technical and spans across quite a few different architectures. It's not right or useful to force developers to work and/or communicate below their capabilities, and certainly not in an open source project. I would hate it if someone tried to do that to me.
I really don't want to force anyone to do anything they don't want to do. My request/suggestion/whatever was merely what someone else suggested ("programmer's manual" etc.), not dumb-down the project as a whole, or "forcing" developers to hand-hold "newbies" like me... I apologise, if it came across like that. Maybe it's my english (it's not my native language).
I do believe however, that all the technical prerequisite knowledge should be listed, so that people can get up-to-speed on their own. I'll try to work for this and I think that the wiki is a great forum.
That's a great idea. And I also think the wiki is a great thing to have. :-)
SPD is Serial Presence Detect, the name of an I2C bus between the northbridge and all RAM modules. Each RAM module has an EEPROM with more or less correct information about how memory initialization code should set up the memory controller for correct size and optimal performance. Quite frequently the information is busted. :(
<snip>
These are short for Vendor ID and Device ID. VID and DID (or PID, Product ID) are id numbers assigned by organizations such as PCI-SIG and USBIF to hardware manufacturers allowing software to identify hardware in a reliable manner. The ids are stored inside the device, whether it's PCI or USB. Also true for PCMCIA/CardBus.
Ok, thanks again for educating me!
Best regards
Peter K
On Wed, 2 Mar 2005, Peter Karlsson wrote:
Ok, thanks again for educating me!
so, peter, you want to accumulate the Glossary for us :-)
ron
On Wed, 2 Mar 2005 08:05:06 -0700 (MST), Ronald G. Minnich rminnich@lanl.gov wrote:
On Wed, 2 Mar 2005, Peter Karlsson wrote:
Ok, thanks again for educating me!
so, peter, you want to accumulate the Glossary for us :-)
A tehnical glossary would be nice but one thing we _really_ need is a listing of all config options and what they do. This was (and still is) one of the largest hurdles for me. And its one of the things that Google won't find much on.
I compiled part of a list for V1 and its in my FAQ I put out but V2 is all new to me.
Richard Smith wrote:
A tehnical glossary would be nice but one thing we _really_ need is a listing of all config options and what they do. This was (and still is) one of the largest hurdles for me. And its one of the things that Google won't find much on.
I compiled part of a list for V1 and its in my FAQ I put out but V2 is all new to me.
If someone can point me in the right direction (in the source, I'd guess) to find all of the configuration options without descriptions I can setup a page dedicated to explaining them one at a time.
Justin
* Justin C. Darby jdarby@powercom.net [050302 16:34]:
If someone can point me in the right direction (in the source, I'd guess) to find all of the configuration options without descriptions I can setup a page dedicated to explaining them one at a time.
freebios2/src/config/Options.lb
On Wed, 2005-03-02 at 08:41, Stefan Reinauer wrote:
- Justin C. Darby jdarby@powercom.net [050302 16:34]:
If someone can point me in the right direction (in the source, I'd guess) to find all of the configuration options without descriptions I can setup a page dedicated to explaining them one at a time.
freebios2/src/config/Options.lb
I think another problem of the config tool is the syntax and semantics of the configure language. Most people have problem understand the keywords used in the language (device, chip, pci_domain). And the language is not context free neither (links <-> number of instances of a device listed). We really need a good documentation on the config tool.
BTW, the config.g is really diffcult to understand too.
Ollie
I've been adding selected info from my V1 FAQ up into the wiki. The following is some info I compiled up on V1 start up.
If someone(s) would update this for V2 and post it t the wiki I think it would be very useful.
================================ Help! I'm a newbie and I'm completely lost in the code.
There seem to be two main parts to linuxbios. The first is arch/{arch}/config/ctr0.base which does the very low level initialization, like turning on memory, etc. The second is arch/{arch}/lib/c_start.S which does whatever else is necessary to call the C function hardwaremain(). hardwaremain() then does whatever else is necessary to load linux.
c_start.S is linked with linuxbios.a, a library containing generic support routines (those found in the lib directory) and anything specified using the 'object' directive in a Config file (and other stuff). The resultant 'executable' is called linuxbios_c. The loader script used to link linuxbios_c is config/linuxbios_c.ld, and is configured to be loaded relative to _RAMBASE.
crt0.base is not linked against anything. Any additional assembly routines you need must be specified using the 'mainboardinit' directive in a Config file. This causes the specified assembly file to be added to "crt0_includes.h" which is in turn included at the start of crt0.base (or at the end in the case of the ppc version). The loader script used to link crt0.base is in arch/{arch}/config/ldscript.base. The resultant 'executable' is called linuxbios and will be loaded at _ROMBASE. The tricky thing is that this loader script will also load the linuxbios_c 'executable' at a location called _payload in this file. The main task of crt0.base is then to initialize enough hardware so that this payload can be copied from rom into ram (which may also involve uncompressing code). Then control is transferred to _start, which is the first location in linuxbios_c.
To get an idea of how crt0.base works, look at the following files. This is the order of execution specified by the configuration file for sis735.
cpu/i386/entry16.inc cpu/i386/entry32.inc superio/sis/950/setup_serial.inc pc80/serial.inc arch/i386/lib/console.inc cpu/k7/earlymtrr.inc northsouthbridge/sis/735/raminit.inc arch/i386/config/crt0.base
Next look at c_start.S which will show you what happens once control is transferred to _start. Finally, look at arch/{arch}/lib/hardwaremain.c to see what other stuff is done to get linux loaded.
Most other files are specific to particular hardware, so it can be pretty confusing to just browse the tree.
* Richard Smith smithbone@gmail.com [050302 17:00]:
I've been adding selected info from my V1 FAQ up into the wiki. The following is some info I compiled up on V1 start up.
If someone(s) would update this for V2 and post it t the wiki I think it would be very useful.
I have an old writeup on this for v2 at home. I'll try to find it (printout) I think this should even go to an extra page.
================================ Help! I'm a newbie and I'm completely lost in the code.
There seem to be two main parts to linuxbios. The first is arch/{arch}/config/ctr0.base which does the very low level initialization, like turning on memory, etc. The second is arch/{arch}/lib/c_start.S which does whatever else is necessary to call the C function hardwaremain(). hardwaremain() then does whatever else is necessary to load linux.
c_start.S is linked with linuxbios.a, a library containing generic support routines (those found in the lib directory) and anything specified using the 'object' directive in a Config file (and other stuff). The resultant 'executable' is called linuxbios_c. The loader script used to link linuxbios_c is config/linuxbios_c.ld, and is configured to be loaded relative to _RAMBASE.
crt0.base is not linked against anything. Any additional assembly routines you need must be specified using the 'mainboardinit' directive in a Config file. This causes the specified assembly file to be added to "crt0_includes.h" which is in turn included at the start of crt0.base (or at the end in the case of the ppc version). The loader script used to link crt0.base is in arch/{arch}/config/ldscript.base. The resultant 'executable' is called linuxbios and will be loaded at _ROMBASE. The tricky thing is that this loader script will also load the linuxbios_c 'executable' at a location called _payload in this file. The main task of crt0.base is then to initialize enough hardware so that this payload can be copied from rom into ram (which may also involve uncompressing code). Then control is transferred to _start, which is the first location in linuxbios_c.
To get an idea of how crt0.base works, look at the following files. This is the order of execution specified by the configuration file for sis735.
cpu/i386/entry16.inc cpu/i386/entry32.inc superio/sis/950/setup_serial.inc pc80/serial.inc arch/i386/lib/console.inc cpu/k7/earlymtrr.inc northsouthbridge/sis/735/raminit.inc arch/i386/config/crt0.baseNext look at c_start.S which will show you what happens once control is transferred to _start. Finally, look at arch/{arch}/lib/hardwaremain.c to see what other stuff is done to get linux loaded.
Most other files are specific to particular hardware, so it can be pretty confusing to just browse the tree.
-- Richard A. Smith _______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
* Stefan Reinauer stepan@openbios.org [050302 17:04]:
- Richard Smith smithbone@gmail.com [050302 17:00]:
I've been adding selected info from my V1 FAQ up into the wiki. The following is some info I compiled up on V1 start up.
If someone(s) would update this for V2 and post it t the wiki I think it would be very useful.
Something along this line. I wrote it about a year ago and never really used it since so it might be wrong here and there.
--> wiki?
Stefan
-----------------------------------------------------------------------
reset16.[inc|lds] ----------------- Description: * code placed at reset vector (0xfffffff0) * jump to _start in entry16.inc * jump to protected_start in entry32.inc (what is this good for??)
Comments: reset16.lds supports ROMBASEs smaller than 0xffff0000. reset16.inc does not. Do we ever need anything else on x86 based systems? If not, I suggest to drop the conditionals. It seems to me that the second jump is later done by entry16.inc, and the reset vector is never reached. Is it used by something else?
entry16.[inc|lds] ----------------- Description: * linker script provides 16bit versions of the addresses (?) * switch to protected mode. * jump to __protected_start in entry32.inc
Comments: Can someone enlighten me on the restriction comments here? given that we are always on a standard x86 system, we are always above 0xffff0000?
entry32.[inc|lds] ----------------- Description: * linker script is a noop. * sets up all segment registers to the same value. (ROM_CODE_SEG) * falls through to bist32.inc
Comments: there's two entry points here, protected_start and __protected_start. Are they both needed? protected_start seems to do the same thing as the end of entry16.inc. The comment states that we do something with memory here. It seems this is wrong, since we are far before enabling memory.
bist32.inc ---------- Description: * Checks EAX for BIST failures. * if everything is ok, falls through (skipping next files that put code in different sections: reset16.inc, cpu_reset.inc, id.inc) On K8 this goes to early_mtrr.inc
early_mtrr.inc -------------- Description: * set up variable and fixed mtrrs. * set up XIP
Comments: Will this hurt C-A-R? Can we somehow derive the XIP addresses from the information that we know, making XIP more solid?
failover.c ---------- Description: * romcc generated code * if normal boot, we jump into normal image. * if cpu reset, we jump into __cpu_reset, which jumps into __main (Where is this one? crt0.base? auto.inc?) * if we're running on the second CPU, we jump into normal/fallback image (???) * if no problems appeared, jump into normal image * otherwise fall through (to auto.c ??)
Comments: What's HAVE_REGPARM_SUPPORT? There's a lot of conditions in this file. I did not follow all the branches yet. Maybe someone can explain more? it seems that __cpu_reset jumps into __main - does this mean the dram init survives a cpu reset?
-------------- part 1: creating init code -----------------------------
- compile romcc
- create option table
- process and compile romcc based code
- create crt0.o from romcc based code
-------------- part 2: creating payload ------------------------------- 5) compile all drivers 6) compile all objects 7) compile static device tree 8) link objects and static tree --> linuxbios.a 9) create linuxbios_c from start.o, drivers and linuxbios.a a) create linuxbios_payload from linuxbios_c (with or w/o nrv2b)
-------------- part 3: final image ------------------------------------ b) create "linuxbios" from crt0.o (including linuxbios_payload via linker script arch/i386/config/ldscript.lb) c) create romimage linuxbios.rom from "linuxbios" with buildrom
On Wed, 2 Mar 2005, Justin C. Darby wrote:
If someone can point me in the right direction (in the source, I'd guess) to find all of the configuration options without descriptions I can setup a page dedicated to explaining them one at a time.
src/config/Options.lb
What's nice is the format greg watson worked up is amenable to processing to produce html. I think this ought to be easy to autmoate.
ron
Ronald G. Minnich wrote:
src/config/Options.lb
What's nice is the format greg watson worked up is amenable to processing to produce html. I think this ought to be easy to autmoate.
ron _______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
I will get out my web programming hat to see if I can get that automated after I run out of other things to do. :)
Justin
* Richard Smith smithbone@gmail.com [050302 16:28]:
A tehnical glossary would be nice but one thing we _really_ need is a listing of all config options and what they do. This was (and still is) one of the largest hurdles for me. And its one of the things that Google won't find much on.
Should this be generated automatically out of Options.lb? There is a lot of description in that file already.
listing of all config options and what they do. This was (and still is) one of the largest hurdles for me. And its one of the things that Google won't find much on.
Should this be generated automatically out of Options.lb? There is a lot of description in that file already.
Thats a good idea. What about adding a "description" section where this info is filled out. Then the config tool would generate some sort of text file in the target directory describing all the options that are set. You could perhaps add some dependency info in there as well.
On Wed, 2 Mar 2005, Richard Smith wrote:
Thats a good idea. What about adding a "description" section where this info is filled out. Then the config tool would generate some sort of text file in the target directory describing all the options that are set.
Makefile.settings
ron
On Wed, 2 Mar 2005, Ronald G. Minnich wrote:
so, peter, you want to accumulate the Glossary for us :-)
Sure. It's the least I could do. What would be required of me? I just downloaded a snapshot (the last time I tried cvs it didn't work), so I'll have a look at the code (I'm not good at C or x86 asm though).
A small start might be: ------------------------------------------ I2C - Inter-Integrated-Circuit, a bidirectional 2-wire bus for efficient inter-IC control. See 'http://www.esacademy.com/faq/i2c/index.htm' for more info.
Code examples(?): ... ------------------------------------------ VID - Vendor ID, a way of identifying the hardware manufacturer. See 'http://www.microsoft.com/whdc/system/bus/PCI/infreq.mspx' and 'http://pciids.sourceforge.net/' for more info.
A way of obtaining info for your hardware is through the 'lspci' command. Simply type 'lspci -n' in the console (or an xterm) or 'lspci -vn' for more verbose output. ------------------------------------------ DID - Device ID, a way of identifying the hardware in question. See above for more info. ------------------------------------------
Is this too "dumbed-down"? I would like some connection with examples, hence the stub in the I2C section. Any suggestions/improvements/critique/comments welcome.
And as someone else mentioned that explanation of config options is needed; why not use doxygen (or similar tool), which seems a really easy way to document the code and outputs, text, html, LaTeX etc.?
Best regards
Peter K
On Thu, 3 Mar 2005, Peter Karlsson wrote:
I2C - Inter-Integrated-Circuit, a bidirectional 2-wire bus for efficient inter-IC control. See 'http://www.esacademy.com/faq/i2c/index.htm' for more info.
this is fine.
And as someone else mentioned that explanation of config options is needed; why not use doxygen (or similar tool), which seems a really easy way to document the code and outputs, text, html, LaTeX etc.?
Actually, when you build a target, you can then type make documentation
and should get docs for that board.
ron
On Tue, 1 Mar 2005, Peter Karlsson wrote:
To get more people interested in linuxbios one has to lower the bars, and technical jargon is a major blocker (at least for me). And yes, I do know what i2c is, and I think I know what spd is (ram speed?) but vid & did does not ring a bell. For anyone not knowing what i2c is I'll recommend: http://www.esacademy.com/faq/i2c/index.htm
so we need a glossary. Good point.
ron
On Tue, 2005-03-01 at 08:52, Ronald G. Minnich wrote:
On Tue, 1 Mar 2005, Peter Karlsson wrote:
To get more people interested in linuxbios one has to lower the bars, and technical jargon is a major blocker (at least for me). And yes, I do know what i2c is, and I think I know what spd is (ram speed?) but vid & did does not ring a bell. For anyone not knowing what i2c is I'll recommend: http://www.esacademy.com/faq/i2c/index.htm
so we need a glossary. Good point.
ron
Ron,
Probably we should seriously consider writing the "Users Manual" and "Programmer's Manual" as I mentioned before?
Ollie
On Tue, 1 Mar 2005, Li-Ta Lo wrote:
Probably we should seriously consider writing the "Users Manual" and "Programmer's Manual" as I mentioned before?
yes, it has to be done.
ron
On Tue, 2005-03-01 at 10:32, Ronald G. Minnich wrote:
On Tue, 1 Mar 2005, Li-Ta Lo wrote:
Probably we should seriously consider writing the "Users Manual" and "Programmer's Manual" as I mentioned before?
yes, it has to be done.
ron
Ron,
Do I have to right to distribute my FREENIX '05 paper? If I can, should I put it on the wiki?
Ollie
On Tue, 1 Mar 2005, Li-Ta Lo wrote:
Do I have to right to distribute my FREENIX '05 paper? If I can, should I put it on the wiki?
yes.
ron
On Tue, 2005-03-01 at 10:45, Ronald G. Minnich wrote:
On Tue, 1 Mar 2005, Li-Ta Lo wrote:
Do I have to right to distribute my FREENIX '05 paper? If I can, should I put it on the wiki?
yes.
even the copyright is assigned to USENIX.org?
Ollie
ron
On Tue, 1 Mar 2005, Li-Ta Lo wrote:
even the copyright is assigned to USENIX.org?
yes, AFAIK you can still post it. I post all my usenix pappers.
ron
Well, I have been googling this board for the last 2 day's and have found nothing. Can any of your guys ID this board? Or perhaps point me in the right direction. I put the BIOS into my programer and grabed a copy of the ROM, but that has given me no new information. I am looking for the pin outs, VGA, PS/2, network. Any ideas?
http://www.etministries.com/webfolders/top.JPG http://www.etministries.com/webfolders/bottom.JPG
-Adam
don't know, but it sure looks like yer basic geode board to me.
ron
Does anybody know of a source for these in Australia, I would love to get my hands on one or two to play with
Geoff
don't know, but it sure looks like yer basic geode board to me.
ron
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
don't no of a source, or even who makes that board.
----- Original Message ----- From: "Geoffrey McRae" gnif@spacevs.com To: "Ronald G. Minnich" rminnich@lanl.gov Cc: "Adam Talbot" talbotx@comcast.net; linuxbios@clustermatic.org Sent: Tuesday, March 01, 2005 6:30 PM Subject: Re: Can any one ID this board?
Does anybody know of a source for these in Australia, I would love to get my hands on one or two to play with
Geoff
don't know, but it sure looks like yer basic geode board to me.
ron
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
I am not worried if its not "That" board, just any embedded board that would be good for an experimenter like myself.
don't no of a source, or even who makes that board.
----- Original Message ----- From: "Geoffrey McRae" gnif@spacevs.com To: "Ronald G. Minnich" rminnich@lanl.gov Cc: "Adam Talbot" talbotx@comcast.net; linuxbios@clustermatic.org Sent: Tuesday, March 01, 2005 6:30 PM Subject: Re: Can any one ID this board?
Does anybody know of a source for these in Australia, I would love to get my hands on one or two to play with
Geoff
don't know, but it sure looks like yer basic geode board to me.
ron
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
-
Adam Talbot -
Geoffrey McRae -
Justin C. Darby -
Li-Ta Lo -
Peter Karlsson -
Peter Stuge -
Richard Smith -
Ronald G. Minnich -
Stefan Reinauer