Re: LinuxBIOS & Pentium-M embedded boards
* Ronald G. Minnich [050414 21:10]: > no, as Intel does not want it to happen. They are determined to ensure > that no future Intel hardware can run linuxbios. They have stated as much > to me directly. I am hoping this situation will change at some point, > however, as some larger customers are starting to ask for LinuxBIOS. Whereas these customers should be advised to buy AMD until Intel stops hiding details about what they sell to their customers. They sure have their reasons ;-) Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Wiki instructions for download-- problems with the old CVS, and such
Hi, > As the title implies I went to the Wiki to work out how to download > everything to bring myself into synch. It happens that the ones for > the old CVS storage need to be revised. Sometime ago those crazy > people at Source Forge rewrote the mechanisms behind the root for CVS, > instead of the one here, > cvs.freebios.sourceforge.net:/cvsroot/freebios, they deleted the > project name from the server handle. It is only used at the slash > entries, such as cvs.sourceforge.net:/cvsroot/freebios . then do > everything the Wiki says to do. Ok I fixed this, though using CVS is highly discouraged. It is not current anymore. > Once that was done, and I pulled over the stuff for the two versions > there, I decided to use the mirror functions for the current Arch > based repository. Using the wget program to create a mirror of the > site, works. If you just want to check out the sources to use them, you should follow section 1.1 of the Download page: http://wiki.linuxbios.org/index.php/Download_freebios_v2#Anonymous_access Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: post code "fe" means what ?
* Huang-Jen Wang <[EMAIL PROTECTED]> [050412 06:10]: > Hi All, > I tried to build a linuxbios for Arima Hdama, but the rom can't work > I use a debug card , and it shows post code "fe" > what dose it mean? Did you attach a serial console? Does it say anything? Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Amlcode structure generation [PMX:#]
* Ronald G. Minnich [050329 23:32]: > > > > just a note, please use [EMAIL PROTECTED] from here on out. I will linuxbios@openbios.org > give this transition a few more days. Please fix your address books! Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] Re: "Options.lb 2 XML" the 2nd
* Steve Milo <[EMAIL PROTECTED]> [050320 20:39]: > Pardon me but, am I to understand that XML is implemented in a firmware > environment?! for the purpose of automatically creating up to date documentation from the code, yes indeed. There is no xml involved on the firmware level itself. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: "Options.lb 2 XML" the 2nd
* Florian Zeitz <[EMAIL PROTECTED]> [050313 16:17]: > I would like to contribute the following to the LinuxBIOS wiki in case > it's useable: > 1. I have written a rather small python script to convert the Options.lb > to a XML file which is much more useable for the web in most cases. > 2. I have written a XSLT to convert the XML file to (X)HTML to be able > to present it as a table. > 3. I have attached this plus an already converted version to this mail. > It could (your decision of course) be used as the "Configuration > Options" page in the wiki or be a placeholder for the upcoming work so > people have at least something to look at for now. Ok, I checked the script into the arch repository now, utils/optionlist. I changed the xsl sheet slightly so it works with my version of xsltproc and saxon. Which xsl processor are you using? Thanks for your work Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: [LinuxBIOS] cutting over
* Ronald G. Minnich [050314 17:59]: > > > On Mon, 14 Mar 2005, Tyson Sawyer wrote: > > > Do we need to move ourselves over or will the existing list of subscribers > > be > > moved? > > gets moved automagically, (i.e. stefan) but you should be getting dup mail > emails from [EMAIL PROTECTED] All people have been moved over to the new list, except those that were excessively bouncing or those that have subscibed in the last 2 days. Sorry for the inconvenience caused by the move. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: To webmaster.
* Tony S. <[EMAIL PROTECTED]> [050312 03:22]: > I was looking at the wiki page and I thought it would look cool with > the linuxbios logo with a transparent background so I edited it :) > Hope you guys like it :) Very nice, thanks! It definitely looks better. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: LinuxBios support for the ELAN SC520
* Robin Randhawa <[EMAIL PROTECTED]> [050222 17:12]:
> Hi Stefan.
> Thanks for your prompt response.
> That would be nice.
>
> Will look forward to checking out your code. Do let me know when you
> would be able to hand it over,
Hi Robin,
Sorry for not coming back to you earlier. I attach the dram code I
started to this mail. It should go somewhere to northbridge/amd/sc520
but there is quite some other code missing around it, and it is probably
not really correct.
Stefan
/*
*
*
*/
#define DRCCTL*(char*)0x0fffef010 // DRAM control register
#define DRCTMCTL *(char*)0x0fffef012 // DRAM timing control register
#define DRCCFG*(char*)0x0fffef014 // DRAM bank configuration register
#define DRCBENDADR*(char*)0x0fffef018 // DRAM bank ending address register
#define ECCCTL*(char*)0x0fffef020 // DRAM ECC control register
#define DBCTL *(char*)0x0fffef040 // DRAM buffer control register
#define CACHELINESZ 0x0010 // size of our cache line (read buffer)
#define COL11_ADR *(unsigned int *)0x0e001e00 // 11 col addrs
#define COL10_ADR *(unsigned int *)0x0e000e00 // 10 col addrs
#define COL09_ADR *(unsigned int *)0x0e000600 // 9 col addrs
#define COL08_ADR *(unsigned int *)0x0e000200 // 8 col addrs
#define ROW14_ADR *(unsigned int *)0x0f00 // 14 row addrs
#define ROW13_ADR *(unsigned int *)0x0700 // 13 row addrs
#define ROW12_ADR *(unsigned int *)0x0300 // 12 row addrs
#define ROW11_ADR *(unsigned int *)0x0100 // 11 row addrs/also bank switch
#define ROW10_ADR *(unsigned int *)0x // 10 row addrs/also bank switch
#define COL11_DATA 0x0b0b0b0b // 11 col addrs
#define COL10_DATA 0x0a0a0a0a // 10 col data
#define COL09_DATA 0x09090909 // 9 col data
#define COL08_DATA 0x08080808 // 8 col data
#define ROW14_DATA 0x3f3f3f3f // 14 row data (MASK)
#define ROW13_DATA 0x1f1f1f1f // 13 row data (MASK)
#define ROW12_DATA 0x0f0f0f0f // 12 row data (MASK)
#define ROW11_DATA 0x07070707 // 11 row data/also bank switch (MASK)
#define ROW10_DATA 0x // 10 row data/also bank switch (MASK)
#define dummy_write() *(short *)CACHELINESZ=0x1010
int nextbank(int bank)
{
int rows,banks;
start:
/* write col 11 wrap adr */
COL11_ADR=COL11_DATA;
if(COL11_ADR!=COL11_DATA)
goto bad_ram;
/* write col 10 wrap adr */
COL10_ADR=COL10_DATA;
if(COL10_ADR!=COL10_DATA)
goto bad_ram;
/* write col 9 wrap adr */
COL9_ADR=COL9_DATA;
if(COL9_ADR!=COL9_DATA)
goto bad_ram;
/* write col 8 wrap adr */
COL8_ADR=COL8_DATA;
if(COL8_ADR!=COL8_DATA)
goto bad_ram;
/* write row 14 wrap adr */
ROW14_ADR=ROW14_DATA;
if(ROW14_ADR!=ROW14_DATA)
goto bad_ram;
/* write row 13 wrap adr */
ROW13_ADR=ROW13_DATA;
if(ROW13_ADR!=ROW13_DATA)
goto bad_ram;
/* write row 12 wrap adr */
ROW12_ADR=ROW12_DATA;
if(ROW12_ADR!=ROW12_DATA)
goto bad_ram;
/* write row 11 wrap adr */
ROW11_ADR=ROW11_DATA;
if(ROW11_ADR!=ROW11_DATA)
goto bad_ram;
/* write row 10 wrap adr */
ROW10_ADR=ROW10_DATA;
if(ROW10_ADR!=ROW10_DATA)
goto bad_ram;
/*
* read data @ row 12 wrap adr to determine # banks,
* and read data @ row 14 wrap adr to determine # rows.
* if data @ row 12 wrap adr is not AA, 11 or 12 we have bad RAM.
* if data @ row 12 wrap == AA, we only have 2 banks, NOT 4
* if data @ row 12 wrap == 11 or 12, we have 4 banks
*/
banks=2;
if (ROW12_ADDR != ROW10_DATA) {
banks=4;
if(ROW12_ADDR != ROW11_DATA) {
if(ROW12_ADDR != ROW12_DATA)
goto bad_ram;
}
}
/* validate row mask */
i=ROW14_ADDR;
if (iROW14_DATA)
goto bad_ram;
/* verify all 4 bytes of dword same */
if(i&0x!=(i>>16)&0x)
goto bad_ram;
if(i&0xff!=(i>>8)&0xff)
goto bad_ram;
/* validate column data */
i=COL11_ADDR;
if(iCOL11_DATA)
goto bad_ram;
/* verify all 4 bytes of dword same */
if(i&0x!=(i>>16)&0x)
goto bad_ram;
if(i&0xff!=(i>>8)&0xff)
goto bad_ram;
if(banks==4)
i+=8; /* <-- i holds merged value */
/* fix ending addr mask*/
/*FIXME*/
ending_adr=0xff;
bad_reint:
/* issue all banks recharge */
DRCCTL=0x02;
dummy_write();
/* update ending address register */
*(DRCBENDADR+)=ending_adr;
/* update config register */
DRCCFG=DRCCFG&YYY|;
Re: diff help
* Richard Smith <[EMAIL PROTECTED]> [050309 17:58]: > > I always do something like > > cvs update | grep ^? | cut -f2 -d\ |while read name > > do > > diff -uN /dev/null $name >> mypatch.newfiles.diff > > done > > > > but it is not exactly elegant > > I can't seem to make that work. Do I have to protect something from > the shell? I get a bash: syntax error near unexpected token 'done' What version of bash are you using? It seems to work fine here. echo $BASH_VERSION 3.00.0(1)-release Try replacing the diff with an echo $name to see what's wrong. You also need to watch the space after '-d\ ' Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: diff help
* Richard Smith <[EMAIL PROTECTED]> [050309 17:06]: > I'm trying to create the patch for my 440bx stuff but I need some > help. I have a bunch of new files that I added in the tree. So 'cvs > diff' dosen't know about these files and dosen't show anything on the > diffs. > > If I check out a new copy of the repository and then diff vs that I > get loads of changes in the CVS directories. > > Whats the best way to do this? Can I make diff ignore certain > directory patterns? I don't see anything in the man page about > excluding directories just files. I always do something like cvs update | grep ^? | cut -f2 -d\ |while read name do diff -uN /dev/null $name >> mypatch.newfiles.diff done but it is not exactly elegant ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Anyone tried LinuxBIOS with freeBSD?
* yhlu <[EMAIL PROTECTED]> [050309 04:27]: > 1. LinuxBIOS need to pass the position pirq table to loader.s --- put > that in CMOS or loader.s search that in RAM "PIR" > 2. LinuxBIOS need to pass the entries in e820 at 1MB to loader.s, or > put that in CMOS in LinuxBIOS stage. what standard need to put > this in CMOS... > 3. VGA BIOS already be copied by LinuxBIOS, but should still need let > ADLO know the dev and fun of that .--- put that in CMOS? > 4. mptable is alredy in the RAM. Should that information not go to the LinuxBIOS table instead of CMOS? Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: we need to sequence this
* Ronald G. Minnich [050308 22:08]: > we need a 'controlled shutdown' of the cvs project so we can do a clean > cut over to tla. > Can we pick a day and time? midnight this saturday or some such? Do we all > trust tla enough to go for it? I've not seen any problems since OpenBIOS is using it. And a growing number of projects are switching, http://arch.debian.org/ http://www.sourcecontrol.net/ > What stepan could do is an import, and at the same time we shut down > commits to the cvs. Weekend sounds good. I am reimporting a cvs tree at the moment while preserving the authors of the changes. I can sync in any changes that happen until saturday. How does closing the tree work? We can also tag it and leave it sitting there with a notice that it is obsolete. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: we need to sequence this
* YhLu <[EMAIL PROTECTED]> [050308 22:32]: > why does the Linux kernel use bitkeeper? Back when Linus decided to switch, Arch did not have enough momentum and it seemed the people around Tom Lord would always go for the concept rather than for the user. They were right back then, and today there are a lot of people working on making life with arch easier, like bazaar, archzoom/viewarch, or archway. Personally I was never really concerned about the restrictive license, but all the wasteful "politics" of Larry McVoy on LKML and elsewhere seem to help no one, really. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Version Control
* Eric W. Biederman [050308 20:20]: > For more information look at: > http://www.openbios.org/experience/gnuarch.html > http://wiki.gnuarch.org/ Especially this part of the wiki is probably interesting: http://wiki.gnuarch.org/moin.cgi/Learning_20Arch_20commands_20for_20CVS_20users Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Version Control
* Li-Ta Lo <[EMAIL PROTECTED]> [050308 20:13]: > [EMAIL PROTECTED]/freebios--devel--2.0 > > what is the tla command for > > cvs -d:xxx login > cvs -d:xxx co freebios2 You would do: * once (preperation to use arch in general and on the openbios.org repos): # make TLA know about you tla my-id "Li-Ta Lo <[EMAIL PROTECTED]>" # make TLA know about where to find the code tla register-archive ftp://ftp.openbios.org/pub/arch/[EMAIL PROTECTED] # register key wget http://www.openbios.org/~stepan/gpg/openbios-arch.pub gpg --import openbios-arch.pub * then everytime you do a fresh checkout: tla get [EMAIL PROTECTED]/freebios--devel--2.0 freebios2 will fetch the tree calling the target directory freebios2 Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Version Control
* yhlu <[EMAIL PROTECTED]> [050308 18:56]: > Can we put the server in US instead of EU? > > YH The machine is hanging off the second hop from the Frankfurt backbone over to the US, 7 hops from tyan.com... This should be a _lot_ faster than sourceforge.net Have you had throughput/latency problems? Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Version Control
* Eric W. Biederman [050308 10:37]: > The next piece to investigate is how we plan on publishing and > committing changes. The bread and butter of a version control > system. Ron are you far enough along in playing with arch > that you are ready for that piece of the conversation? http://www.openbios.org/experience/gnuarch.html and http://www.openbios.org/cgi-bin/viewarch.cgi/[EMAIL PROTECTED]/ will likely help a bit. Got to add a commit section (which is fairly easy, doing "tla commit" and maybe some hints for branching and merging.) We could either use pqm or add ssh keys for each commiter. How many are there currently? Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Does anybody needs LinuxBIOS for VMware virtual machines?
* Dmitriy Budko <[EMAIL PROTECTED]> [050307 22:28]: > Does anybody needs LinuxBIOS for VMware virtual machines? > If you want it please describe why do you want it. This sounds very interesting. Having a possibility to test LinuxBIOS+payload in vmware would allow easy and comfortable payload development in projects such as OpenBIOS, filo or etherboot. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Version Control
* Ronald G. Minnich [050304 17:39]: > On Thu, 3 Mar 2005, Eric W. Biederman wrote: > > > Ron does this sound like something you would be willing to look at? > > by all means! The repository is there now. Note: The caches have not been built on the server, so viewarch is relly slow. This will change soon. freebios2: http://www.openbios.org/cgi-bin/viewarch.cgi/[EMAIL PROTECTED]/freebios--devel--2.0 freebios: http://www.openbios.org/cgi-bin/viewarch.cgi/[EMAIL PROTECTED]/freebios--devel--1.0 ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Version Control
* Eric W. Biederman [050304 06:02]: > For the web pages I don't care. But for the sources I SVN does not solve > one of our major problems: Multiple repositories. With the Wiki the web page issue has solved. > So arch aka tla appears to be the sane way to go. It can act as > a shared repository with multiple commiters. It also handles forks > well. Arch among other things is drop dead simple to setup. Pretty > much you need an ssh account that you can place all of your developers > public keys in .ssh/authorized_keys. From there all of the logic > happens remotely with sftp. Stefan can probably testify to that a > little more than I can. Either the authorized_key or a gate keeper can be used. > I am in the process of prototyping it internally to verify that > everything works properly. I have already converted my internal > linuxbios tree with 903 changesets. And have just started doing > a little bit of development on it. So far all of the important > cases involving multiple branches and multiple repositories > seem to work and are relatively easy to handle. after solving the usual python issues I have cscvs working nicely here as well. I am in the progress of setting up a tla version of the repository that is publicly available on openbios.org. It will also be fed into the repository browser viewarch Which one are you using? I have: [EMAIL PROTECTED]/cscvs--hun--1.2 > Ron does this sound like something you would be willing to look at? Let the public import finish and then have a look at the repository on openbios.org. There you can play and find out if you like it. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
* ramesh bios <[EMAIL PROTECTED]> [050304 05:12]:
> Ok, so I tried this specific sequence and it failed.
>
> making region read/write
> done making region read/write
> Verifing priq routing tables copy at 0xf...failed,
> f=b0 while 87c0=24
>
> Could it be that f is mapped to the flash? I'm
> trying to figure out whether that is technically
> possible for a gx1? Could the hardware somehow have a
> control that maps the 2Mbit flash to that block?
In /dev/bios I've been using the following code to switch between the
ram image and the rom image. I don't have the specs at hand, but you
should look into the specs of device 0x1078:0x0100
static void cs5530_activate(void)
{
/* Save modified registers for later reset */
pci_dummy[0]=pci_read(CURRENT,0x52);
/* enable rom write access */
pci_write(CURRENT, 0x52, pci_dummy[0]|0x06);
}
static void cs5530_deactivate(void)
{
pci_write(CURRENT, 0x52, pci_dummy[0]);
}
___
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Want to stay up to date?
* Li-Ta Lo <[EMAIL PROTECTED]> [050303 23:10]: > > Server down? > > Server error! > The server encountered an internal error and was unable to complete your > request. Either the server is overloaded or there was an error in a CGI > script. > > If you think this is a server error, please contact the webmaster. Big sorry! I'm currently reconfiguring things to make life easier (Nicer URLs, better nav menu etc) but I broke something temporarily. It should work again now Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Want to stay up to date?
Hi, for all those of you using an RSS news reader (like KNewsTicker), you can get informed about changes of the LinuxBIOS wiki with the following rss feeds: Recently changed pages: http://wiki.linuxbios.org/index.php?title=Special:Recentchanges&feed=rss New pages: http://wiki.linuxbios.org/index.php?title=Special:Newpages&feed=rss I have not succeeded yet putting the News page into an RSS stream yet Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: FAQ question fixup
* Stefan Reinauer <[EMAIL PROTECTED]> [050302 17:04]: > * Richard Smith <[EMAIL PROTECTED]> [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 (0xfff0) * 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 0x. 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 0x? 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 - > 1) compile romcc > 2) create option table > 3) process and compile romcc based code > 4) 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 ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: FILO dependencies
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [050302 19:40]: > > I'm using FILO with nVidia reference board with a CK804. I've got > LinuxBIOS to load FILO and FILO sees the IDE controller but not the > drive. I thought FILO was device independent, but could the IDE > controllers on the CK804 require FILO changes? Thanks. You should be using 0.4.2 and be sure to set PCI_BRUTE_SCAN = 1 You probably end up with filo not looking at anything but bus 0. Common problem on amd64 boards. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: FAQ question fixup
* Richard Smith <[EMAIL PROTECTED]> [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.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 A. Smith
> ___
> 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
Re: Fw: Re: Documentation [was: new FSF campaign ..]
* Justin C. Darby <[EMAIL PROTECTED]> [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 ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Fw: Re: Documentation [was: new FSF campaign ..]
* Richard Smith <[EMAIL PROTECTED]> [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. ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Porting Linuxbios to Via P4m266A
* Peter Karlsson <[EMAIL PROTECTED]> [050302 13:31]: > Ok, it's just that I have an intel m/b (i875-based) and from what I've > gathered there's no support for any newer intel chips than the 440xX, so a > hack like that would perhaps enable me to experiment (me play to ;-). Of > course I need to get a hold of a bios-saviour kit first since this is my > only 'puter (currently)... A good way for the adventurous is to boot the machine, swap the chip while it is running, flash the new chip, and reboot. This way you only need a decent chip claw for not even 10 bucks. Yes, you do risk wasting your motherboard theoretically, and no, it never happened to me in the last 5 ys Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: error in making bios
* Ramesh Chhaba <[EMAIL PROTECTED]> [050302 12:19]: > I was just trying to make a linuxBIOS for epic. > at last step it gives error . > > ././buildrom linuxbios.strip linuxbios.rom > ../../../../../lnxieepro100.ebi 0x1 0x2 > ../../../../../lnxieepro100.ebi: No such file or directory > > Can anybody tell how this error can be removed Yes, fix the path to the payload in freebios2/targets/via/epia/Config.lb You might want to use a different payload. Have a look at: http://wiki.linuxbios.org/index.php/Payloads Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: wiki.linuxbios.org
* Martin Ley <[EMAIL PROTECTED]> [050302 11:30]: > The next thing is, how do I get the ROM image to the flash? The flash is > a SST39SF020A. The best solution would be that I use a second flash to > play with linuxbios, but I can't find a distributor in germany willing > to sell small quantities. You might try Conrad or any other electronics shop. Be sure to purchase a chip of the same family (39xx0y0) http://wiki.linuxbios.org/index.php/FAQ#How_do_I_.28re-.29flash_the_BIOS.3F > My colleage has a programmer, which supports that flash. The idea is, > that he saves the standard BIOS and writes linuxbios to it. In case the > linuxbios image does not work, the original BIOS could be rewritten to > it. Would that work? Yes. This will work, I did such a lot of times. With the flash_rom utility mentioned in the FAQ you can also easily create a rom backup file of your original bios. (Be sure to copy it to another machine or floppy before erasing the flash chip though ;) Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Porting Linuxbios to Via P4m266A
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [050302 06:03]: > I have written back asking for permission to disclose the contents > without NDA. I have pointed out the benefits they are going to derive. > Let's see how it goes. > I have a feeling that they may allow disclosure without NDA. Many vendors accept releasing the code produced after reading such specs while they don't allow the specs themselfes to be revealed. Also, you can offer them to review the code before releasing it. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
* ramesh bios <[EMAIL PROTECTED]> [050301 12:22]: > Would I be able to test if Linux 2.6.10 is able to > parse the normal BIOS' PIRQ table by booting linux > with acpi=off? If it does work at that point, then I > could assume that the area to be fixed would be the > PIRQ table generation in LinuxBIOS. If not, then it'd > be time to examine the kernel's pirq code. Yes. Something along that line. For the one Geode system I had, I wrote the interrupt configuration myself, avoiding to fiddle with kernel pirq code (still needs a somewhat correct pirq table) > I'm still somewhat confused though. At the point that > LB calls the kernel, shoudn't LB have used the IRQ > table values to set the PCI config space registers to > write IRQ values to the PCI config registers and such? > And if that were done, Linux would not need to parse a > PIRQ table, yes? LinuxBIOS does not do that, it provides the tables and requires the OS to do so. ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Geode GX1 and IRQ tables
* ramesh bios <[EMAIL PROTECTED]> [050301 08:19]: > That's odd. My understanding might be lacking. > > I think the PIRQ table parser in 2.6.10 seems to work > because it works when I use the normal BIOS. Sure normal BIOS does not provide ACPI instead? In such case, PIRQ stays mostly untouched. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: new free software foundation crusade: http://www.fsf.org/campaigns/free-bios.html
* Ronald G. Minnich [050228 17:08]: > > if you see errors let me know (I did not write this but they will take > input). I know the comment about linuxbios being stripped-down linux is > not quite right; anything else? The number of supported boards is really small and includes LinuxBIOS v1 only. No entry newer than 2003 .. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Python config file options
* corentin hache <[EMAIL PROTECTED]> [050224 15:33]: > Hello, > > I am newbie in LinuxBios, and I Would like to know where I can find > documentation about the python config file (epia.config in my case). > > Is there a file or a website where I can find informations about all > possibles options ? Have a look at http://www.openbios.org/LinuxBIOS-AMD64.pdf - It has been written for AMD64, but it might also be useful for other platforms. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Porting Linuxbios to Via P4m266A
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [050223 12:26]: > Argh!!. That would take forever if at all.Isnt there another way? > Like simulator or gdb or reading up stuff from the kernel since that > already works with the motherboard. As a first step, yes. But you want dynamic detection of dram and other things. By looking at a picture you can't see which line was painted first and why. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Embedded Linux
* Gin <[EMAIL PROTECTED]> [050222 12:47]: > >If it's just about reading a file from usb and writing it to flash, you > >might want to have a look at filo. It should be easy to integrate the > >functionality of flash_rom into it, so you don't need a full blown > linux > >system in flash. > > That will be a good idea if FILO can launch the flash_rom program but I > thought FILO is excepting a bootable image. > So I guess the effort will be in "How to make FILO run an executable?" > Don't' know if I miss anything. The idea is rather to add the code of flash_rom into filo and have filo's filesystem layer only load the flash image from usb. This should be doable in a whole of 30k I would bet. Since both filo and flash_rom are rather small and clean, integration should not be too much of an effort. Otherwise you would have to add minimal console and libc functionality to flash_rom which filo already has. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: LinuxBios support for the ELAN SC520
* Robin Randhawa <[EMAIL PROTECTED]> [050222 16:40]: > After a bit of digging around, I've narrowed down my choice of > bootloaders to telios' ALIOS and Linuxbios from you good people. Alios > seems to support only the ELAN SC400 and I am not sure of the existing > Linuxbios support for the ELAN SC520. > > Could someone please inform me if this microcontroller is currently > supported ? I've started a port a while ago but I never found the time to get it working. I'll dig it up so you can have a look somewhen this week. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Embedded Linux
* Gin <[EMAIL PROTECTED]> [050222 10:07]: > Don't know if anyone has a good tool package in mind that I can use to > develop an Embedded Linux. We want a linux that is just enough to run > the flash_rom program+usb support and we hope it would be small enough > so we can fit it into a Bios chip. It's all for the convenience of > updating Bios in the future. As you image, we are closed to support > Linuxbios officially in our products. If it's just about reading a file from usb and writing it to flash, you might want to have a look at filo. It should be easy to integrate the functionality of flash_rom into it, so you don't need a full blown linux system in flash. Otherwise it is very much dependent on your flash size whether you can fit Linux in there or not. 512k _might_ be enough if you really squeeze, but unlikely. ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: totalimpact briq?
* Greg Watson <[EMAIL PROTECTED]> [050214 16:02]: > Hi Stefan, > > I did it this way because the JTAG debugger understands elf headers, so > can automatically work out where to program the image in rom. I guess > it should really be called linuxbios.elf. Feel free to change things if > you feel the need. Ah, good to know.. I'm not sure whether I really need to change anything, but I would like to play with LinuxBIOS in qemu some more, as it has working ppc, x86, amd64 and sparc system emulation. Arm and sparc64 to come.. Together with it's speed, this gives a pretty unique testing utility for OpenBIOS, but I need some lower level firmware under it, so I decided to go LinuxBIOS since there already is a weirdly broken qemu-i386 port and the totalimpact briq worked with openbios before... Stefan. ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: totalimpact briq?
* Eric W. Biederman [050214 00:13]:
> Generally I would ask if you are seeing the payload at the top
> of the romimage. But that is one of the ppc targets isn't it?
For experimenting i build with a payload of /dev/null (as generated by
abuild.sh). The binary is around 200k instead of an expected size of 2^x
with x from {17,18,19,20}
> I guess that is a question for Greg.
It is a ppc target, so basically, yes.
Stefan
___
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
totalimpact briq?
Hi, how should the totalimpact briq target work? When I build it, I get an elf image as the resulting linuxbios.rom. Is this intended? Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Hi & 440lx chipset
* Ronald G. Minnich [050212 00:27]: > > May I recommend having a wiki? > > I'll see what stefan thinks. A rather thought about closing dowd the existing linuxbioswiki http://openbios.org/linuxbioswiki since it was never used. Maybe people did not feel well with "moinmoin wiki" but would rather prefer Plone or another system. Whatever people prefer, we can do it. Static pages seem more robust in _my_ opinion, but I am for sure no hero when it comes down to updating web _content_ regularly ;) No matter what, the solution in the end should suit the people who feed the web pages with new information. The OpenBIOS web site is kept in an arch repository (could be any other versioning system) and can be updated on checkin to the repository. Have a look at http://www.openbios.org/cgi-bin/viewarch.cgi/[EMAIL PROTECTED]/openbios--website--1.0--patch-27/ to get an idea how the web page content is stored. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Hi & 440lx chipset
* Paul Millar <[EMAIL PROTECTED]> [050211 23:39]: > A random extra bit of info, I just found this page: > http://www.openbios.org/development/devbios.html > > I haven't tried it yet, but if it works, it would make flashing new > images a lot easier. A link from your web-page might be a good idea. It's not really up to date. I've got the impression that freebios2/util/flash_and_burn/ works better. ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Via passing out linuxbios with out GPL?
* Peter Karlsson <[EMAIL PROTECTED]> [050210 19:58]: > Try to load Linux(0x%x) at dev 0x%x > LinuxBIOS > LinuxBIOS > Jump to Linux(0x%lx, 0x%lx) > Jump to Linux(0x%lx, 0x%lx) > Found file system used by Linux.(File System ID = 0x%x) > LinuxBIOS > Try to load Linux(0x%x) at dev 0x%x [..] >From those strings it actually doesn't look like they are using LinuxBIOS but rather chose the same name. But then again, changing a couple of strings is nothing too hard. The way to go is rather to convince them to go with the real LinuxBIOS[tm] in future. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: VGA option rom code broken?
* Li-Ta Lo <[EMAIL PROTECTED]> [050208 22:32]: > On Tue, 2005-02-08 at 13:53, Stefan Reinauer wrote: > > No, do I need to? What is the exact benefit except only having to > > mention one apic_cluster? If this is the problem we will have to change > > it in most ports I guess. > > > > It should not matter for your case but I am not sure. Can you > send me the whole log file? Here it is.. island_vga.log.gz Description: application/gunzip
Re: VGA option rom code broken?
* YhLu <[EMAIL PROTECTED]> [050209 01:48]: > Stefan, > > What's the onboard VGA? are your talking about onboard one? > > YH Yes, it is an onboard rage xl. Pretty much the same as on all opteron boards i guess. It looks like x86emu can't see the rom itself? I manually checked the image and it looks ok Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: VGA option rom code broken?
* Li-Ta Lo <[EMAIL PROTECTED]> [050208 21:22]: > YhLu reversed the order of apic_cluster and northbridge in mainboard > config file. Did you change your config file too? No, do I need to? What is the exact benefit except only having to mention one apic_cluster? If this is the problem we will have to change it in most ports I guess. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: VGA option rom code broken?
* Li-Ta Lo <[EMAIL PROTECTED]> [050208 19:24]: > There is no change to the emulator since last Friday. I tested the > (then) current CVS tree on that day. Did the emulator ever work > on your platform? Last time I tried before was 2005-01-25. It worked fine then. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
VGA option rom code broken?
Hi, with the latest code I don't seem to get VGA initialized anymore on the island/aruma (builtin option rom for onboard card). rom address for PCI: 04:04.0 = fff8 int1a vector at 0 int1a vector at 0 [...] int42 vector at ff065 int6d vector at c16a3 int10 vector at c16a3 int6d vector at c16a3 int10 vector at c16a3 int10 vector at c16a3 int10 vector at c16a3 int10 vector at c16a3 [..] halt_sys: file /home/stepan/cvsroots/freebios2/src/devices/emulator/x86emu/ops.c, line 4400 Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: [BULK] RFC: Generic shadow mechanism useable from a payload
* Richard Smith <[EMAIL PROTECTED]> [050131 17:20]: > > something I have been wondering. Suppose someone starts working on that > > IDE driver to fix it for once in bochs bios. Won't we find out that > > getting it work right is chip-set specific thing? > > > > curently bochs bios is based on intel 440fx chipset or some such. > > I don't think so. FILO does it right. Is it chipset specific? It just uses the generic IDE io interface. No chipset specifics are needed for IDE. Booting USB or PCMCIA is a bit trickier though. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Where to start.....
* G.Marshall <[EMAIL PROTECTED]> [050131 14:13]: > At Stefan's suggestion, I have downloaded the latest V2 snapshot. I > expected a Makefile, configure or README in the base directory which told > me where to start and how to progress. I have found some details > regarding a 2.4.0 kernel, but that appears to relate to V1. I have also > looked at the LinuxBIOS.pdf by Anthony Stone. Assuming you just want to flash the bios with a given rom image, go to freebios2/util/flash_and_burn/ and do make there. The resulting flash_rom utility might help. For detailed information how to build LinuxBIOS itself for a given platform, see http://www.openbios.org/LinuxBIOS-AMD64.pdf The SIS6x0 is not yet supported by the LinuxBIOS v2 tree yet. Which means you cannot replace your motherboard bios with LinuxBIOS on those systems. > Openbios did not work for me, bios.ko had problems with my NIC. >From what I can see, flash_and_burn contains support for all chipsets and most if not all flashchips that /dev/bios supports, plus it is less intrusive, being a userspace program. I should probably drop /dev/bios completely. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: fallback/normal
* Dave Peterson <[EMAIL PROTECTED]> [050121 20:36]: > - The fallback image differs from the normal image in the layout > it uses for accessing the CMOS parameters. In other words it > uses a different cmos.layout file. My image only uses cmos for normal booting. For fallback booting it is hardcoded. Might be some issue with the reserved K8 areas in CMOS or the position of the checksums? Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: fallback/normal
Hi, just to give some final feedback on this one. Using cmos_util worked fine whereas lxbios seemed to work "sometimes" but I did not track the exact issues down. Thanks for the hints. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Open Source BIOS is not only choice.
* Ronald G. Minnich [050127 21:10]: > > > On Fri, 28 Jan 2005, Digital Infra, Inc. wrote: > > > You can say you never use windows any more once you start to use LinuxBIOS? > > Yes, I can. I will never use windows again. I have no use for it. Otherwise VMware or Qemu would be the solution of choice anyways :) Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Boot Windows Please!
* Adam Talbot <[EMAIL PROTECTED]> [050127 06:52]: > -Ron (Linuxbios team) > Humm, had one of my strange ideas. Would it be possible to use the > linuxbios kernel as the system kernel?? So instead of calling a new kernel > through FILO or booting from etherboot, could I just have Linux bios call > INIT, like a normal kernel. I am looking to get the best possible boot > time. 1 kernel loads MUCH faster then 2 kernels. > You thoughts?? It has no scheduler, but otherwise the payload is pretty much "init". No libc and such, too Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Hypertransport Speed
* Greg Lindahl <[EMAIL PROTECTED]> [050126 22:48]: > You mean you tested for a short time and didn't see the AMD 8131 bug, > and so you are going to run production at the higher speed? > > This is not so smart. The bug in the 8131 HT core is rare, but big > clusters will see it fairly frequently. So you have experiences with the occurence of this bug? I'd like to hear about it, since all I really know is in the public revision guide. I could not reproduce this on modern systems yet. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: RFC: Generic shadow mechanism useable from a payload
* Richard Smith <[EMAIL PROTECTED]> [050126 18:40]:
> What if we created a shadow.c file that was in the northbridge
> directory with a simple API type setup that enabled and disabled the
> various shadow ranges.
What about going the LinuxBIOS table way, providing an array of writes
typedef struct {
device_t dev;
unsigned pos;
unsigned and_val;
unsigned or_val;
} modifier_t;
and then provide two arrays of modifier_t for enable_shadow and
disable_shadow.
or whatever the according s-record representation will be in future ;-)
Then we're on the safe side without hurting philosophy.
Stefan
___
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Hypertransport Speed
* YhLu <[EMAIL PROTECTED]> [050126 18:50]: > For 2) > That bit only control x4 DIMM, So please don't do that on x8 or x16. All the > Normal BIOS only compare that to 4 only, and AMD document only said x4 > Only. At least one commercial bios vendor does this for x8 as well, and it is definitely needed on the system with x8 Rams that I have been porting to. I would not see any other possibility to get this system integrated in LinuxBIOS, since this type of RAM is what they use per default. I would assume there were no x8 RAMs when this AMD document was written? Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Boot Windows Please!
* Digital Infra, Inc. <[EMAIL PROTECTED]> [050126 15:20]: > > And it boots Windows XP? AFAIK only Win2k, but it could be advanced. The current URL is http://www.missl.cs.umd.edu/sebos.html The code is in LinuxBIOS v1 CVS Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Boot Windows Please!
* Digital Infra, Inc. <[EMAIL PROTECTED]> [050126 13:51]: > > Hello. > > As my understanding, current LinuxBIOS can not boot Windows and > the reason for it is that it depends on 16bit bios feature much. > So far is right? If right, how about this way. Have you noticed already? > > First, LinuxBIOS is loaded from flash ROM. Then, it moves itself to > uppder 16M area. and it loads some free 16bit BIOS image from somewhere ( e.g. > HDD, USB memory or even network) to under 1M area. And LinuxBIOS jumps to > 16bit BIOS. Of course, this sequence should not be invoked automatically but > by user command, e.g. run_windows or such. Something like this has been done before, it's called ADLO. Check the mailinglist archives for more information... Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Hypertransport Speed
Hi,
I would like to check the applied patch into LinuxBIOS CVS if nobody
happens to disagree loudly:
1) hypertransport clocking
This patch allows to disable the speed cuts during hypertransport
setup using cmos variables "amdk8_1GHz" and "amd8131_800MHz".
I've tried them on hardware which worked perfectly fine
with the higher speed links for both devices (K8 and 8131).
Since it is disabled per default and needs cmos and compile time
activation, it will not break anything.
Affected files:
src/config/Options.lb
src/devices/hypertransport.c
src/northbridge/amd/amdk8/coherent_ht.c
src/northbridge/amd/amdk8/incoherent_ht.c
2) ram init
This patch allows to use 8x (and probably 16x) dimms with LinuxBIOS
on K8.
Affected files:
src/northbridge/amd/amdk8/raminit.c
3) Debugging
This patch will print the pci vendor/device id in print_pci_devices()
which makes determining the early bus structure a lot easier.
It also only prints the first 128 bytes of SPDROM during
dump_spd_registers() since they are defined to be 128byte.
Affected files:
src/northbridge/amd/amdk8/debug.c
Stefan
Index: src/config/Options.lb
===
RCS file: /cvsroot/freebios/freebios2/src/config/Options.lb,v
retrieving revision 1.56
diff -u -r1.56 Options.lb
--- src/config/Options.lb 14 Jan 2005 21:54:16 - 1.56
+++ src/config/Options.lb 26 Jan 2005 09:50:04 -
@@ -815,3 +815,13 @@
export never
comment "Configure briQ with PowerPC G4"
end
+###
+# Options for amd k8
+###
+define ALLOW_HT_OVERCLOCKING
+ default 0
+ export always
+ comment "Allow K8 and AMD8131 to operate at maximum speed"
+end
+
+
Index: src/devices/hypertransport.c
===
RCS file: /cvsroot/freebios/freebios2/src/devices/hypertransport.c,v
retrieving revision 1.12
diff -u -r1.12 hypertransport.c
--- src/devices/hypertransport.c19 Jan 2005 01:19:37 - 1.12
+++ src/devices/hypertransport.c26 Jan 2005 09:50:04 -
@@ -7,6 +7,9 @@
#include
#include
#include
+#if (ALLOW_HT_OVERCLOCKING==1) && (USE_FALLBACK_IMAGE==0)
+#include
+#endif
static device_t ht_scan_get_devs(device_t *old_devices)
{
@@ -29,6 +32,9 @@
{
/* Handle bugs in valid hypertransport frequency reporting */
unsigned freq_cap;
+#if (ALLOW_HT_OVERCLOCKING==1) && (USE_FALLBACK_IMAGE==0)
+ int on;
+#endif
freq_cap = pci_read_config16(dev, pos);
freq_cap &= ~(1 << HT_FREQ_VENDOR); /* Ignore Vendor HT frequencies */
@@ -36,7 +42,12 @@
/* AMD 8131 Errata 48 */
if ((dev->vendor == PCI_VENDOR_ID_AMD) &&
(dev->device == PCI_DEVICE_ID_AMD_8131_PCIX)) {
+#if (ALLOW_HT_OVERCLOCKING==1) && (USE_FALLBACK_IMAGE==0)
+ on=0; get_option(&on, "amd8131_800MHz");
+ if(!on) freq_cap &= ~(1 << HT_FREQ_800Mhz);
+#else
freq_cap &= ~(1 << HT_FREQ_800Mhz);
+#endif
}
/* AMD 8151 Errata 23 */
if ((dev->vendor == PCI_VENDOR_ID_AMD) &&
@@ -45,7 +56,12 @@
}
/* AMD K8 Unsupported 1Ghz? */
if ((dev->vendor == PCI_VENDOR_ID_AMD) && (dev->device == 0x1100)) {
+#if (ALLOW_HT_OVERCLOCKING==1) && (USE_FALLBACK_IMAGE==0)
+ on=0; get_option(&on, "amdk8_1GHz");
+ if(!on) freq_cap &= ~(1 << HT_FREQ_1000Mhz);
+#else
freq_cap &= ~(1 << HT_FREQ_1000Mhz);
+#endif
}
return freq_cap;
}
Index: src/northbridge/amd/amdk8/coherent_ht.c
===
RCS file: /cvsroot/freebios/freebios2/src/northbridge/amd/amdk8/coherent_ht.c,v
retrieving revision 1.40
diff -u -r1.40 coherent_ht.c
--- src/northbridge/amd/amdk8/coherent_ht.c 7 Jan 2005 21:12:05 -
1.40
+++ src/northbridge/amd/amdk8/coherent_ht.c 26 Jan 2005 09:50:04 -
@@ -266,7 +266,13 @@
/* AMD 8131 Errata 48 */
if (id == (PCI_VENDOR_ID_AMD | (PCI_DEVICE_ID_AMD_8131_PCIX << 16))) {
- freq_cap &= ~(1 << HT_FREQ_800Mhz);
+#if (ALLOW_HT_OVERCLOCKING==1) && (USE_FALLBACK_IMAGE==0)
+if(!read_option(CMOS_VSTART_amd8131_800MHz,
+CMOS_VLEN_amd8131_800MHz, 0))
+freq_cap &= ~(1 << HT_FREQ_800Mhz);
+#else
+freq_cap &= ~(1 << HT_FREQ_800Mhz);
+#endif
}
/* AMD 8151 Errata 23 */
if (id == (PCI_VENDOR_ID_AMD | (PCI_DEVICE_ID_AMD_8151_SYSCTRL << 16)))
{
@@ -274,7 +280,13 @@
}
/* AMD K8 Unsupported 1Ghz? */
if (id == (PCI_VENDOR_ID_AMD | (0x1100 << 16))) {
- freq_cap &= ~(1 << HT_FREQ_1000Mhz);
+#if (ALLOW_HT_OVERCLOCKING==1) && (USE_FALLBACK_IMAGE==0)
+if(!read_
Re: HT initialization
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [050124 17:38]: > I'm trying to port LinuxBIOS to a Opteron board with a CK804. IIRC Yinghai Lu did some CK804 work as well. http://www.clustermatic.org/pipermail/linuxbios/2004-August/008797.html > In auto.c I notice that most boards call ht_setup_chain() and use the > return code to see if a reset is needed. Since I can't seem to get > soft_reset() to work with the CK804, can some on tell me why HT > initialization needs a reset? Thanks. The hypertransport links only change their speed after an LDTSTOP_L signal or soft reset. Otherwise the values written to the registers are not in charge. Since LDTSTOP is more complicated, though it has less impact on the system, LinuxBIOS uses soft reset all over the place. You need to check where your southbridge is and adapt the soft_reset() function in auto.c (bus,dev,fn number etc) Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: error in k8 ram setup
* Yinghai Lu <[EMAIL PROTECTED]> [050124 04:44]: > what's other SPD about your DIMM? Brand & model > > That bit means x4 DIMM. > > YH I don't have the list at hand, but the only difference in SPD-ROM that is actually read by LinuxBIOS is the "Primary SDRAM Width" byte. As far as I see it, there are 8x and 16x DIMMs as well, and they also need the x4 DIMM bit set in the DRAM controller to work. With that bit set they do work nicely though. Stefan. ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
error in k8 ram setup
Hi,
The following function in freebios2/src/northbridge/amd/amdk8/raminit.c
is obviously wrong.
static int update_dimm_x4(const struct mem_controller *ctrl, const
struct mem_param *param, int i)
{
uint32_t dcl;
int value;
int dimm;
value = spd_read_byte(ctrl->channel0[i], 13);
if (value < 0) {
return -1;
}
dimm = i;
dimm += DCL_x4DIMM_SHIFT;
dcl = pci_read_config32(ctrl->f2, DRAM_CONFIG_LOW);
dcl &= ~(1 << dimm);
if (value == 4) {
dcl |= (1 << dimm);
}
pci_write_config32(ctrl->f2, DRAM_CONFIG_LOW, dcl);
return 1;
}
Especially the part that checks the Primary SDRAM Width for a value
of 4. The SPD roms I am using have the value 8 in there and memory
does not initialize correctly.
Checking (value == 4 || value == 8) or (value >= 0x4) helps, but I
have no idea whether that is correct. It appears that something else
has to be done. I've also seen RAMs with a value of 0x10.
Comments? Otherwise I am going to check (value >= 0x4) in somewhen next
week.
Stefan
___
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: auto.c questions
* Richard Smith <[EMAIL PROTECTED]> [050121 21:34]: > What's the functional purpose of auto.c? Obvously to turn on the ram > but what else? mostly ram init control. It is the main function that has to run before LinuxBIOS can be copied to ram. On AMD K8 this means you have to set up hypertransport and enable i2c to see the spd roms. It grabs the different code fragments and puts them together. It also contains some board specific setups, like the addresses of the spd roms on the i2c bus. > Are the #includes distributed through the file for a romcc reason? Mostly for readability. And some code uses functions defined in auto.c. On K8 this was generate_row for a long while, and activate_spd_rom to set i2c switches on the board dependant on the ram socket you want to access. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
fallback/normal
Hi, What's the most comfortable way to switch between normal and fallback images in LinuxBIOS on AMD64. I was using lxbios from http://www.llnl.gov/linux/lxbios/lxbios.html But when changing the parameters to Normal, the next boot LinuxBIOS still says "Invalid CMOS LB checksum" and it sets "boot_option" back to Fallback. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: [PROPOSAL] enhanced table dumping
* Ronald G. Minnich [050118 20:05]:
> > I'd like to hear more about what Stefan had in mind for the 'small set of C
> > functions'. Maybe the simplest way would be to pass the device tree itself
> > to
> > the payload? I guess it wouldn't solve the binary/ascii problem, but it
> > would
> > sure as hell make the code easy.
>
> no, that will not work, due to the compiler portability issues. The Plan 9
> C compiler won't work against GCC structs in any cases where
> __attribute(xyz) has been used. We have to be careful here -- not all
> payloads are compiled with gcc.
>
> That's why I favor the s-expression approach. Binary trees are not going
> to work.
What I meant is: There should be a library that people can use that
parses s-expressions or whatever is used in the end and work on this
information. So you can do foo=find-lbtable("memorymap");
Any payload will want a set of functions like this that can just be
compiled and linked. It is not about copying binary data from one edge
to another, it is about not having every LinuxBIOS application developer
looking for his favourite s-expression library and starting to look for
tags and formats. Using a very simple parser s-expressions or xml is
perfectly fine for exchanging data. It won't have to do a lot of syntax
or semantics checking either since we can probably rely on the fact that
the table in memory was produced by another piece of code that has no
form errors.
Stefan
___
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: V2 questions
* Richard Smith <[EMAIL PROTECTED]> [050120 17:19]: > > What about fs_stream? > > What's fs_stream? If you set CONFIG_FS_STREAM 1 you can load a payload from an IDE disk with a filesystem on it. It's basically filo directly integrated. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: buildtarget error
* Richard Smith <[EMAIL PROTECTED]> [050120 19:27]: > Does IRQ_SLOT_COUNT have to match how many actual slots are on the MB > or just the number of pci devices in total? Basically one for each device and one for bus1. Otherwise Linux won't see the APIC of the 8111. ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: V2 questions
* Richard Smith <[EMAIL PROTECTED]> [050120 18:05]: > > Currently, it's always enabled, but if you build a fallback-only payload, > > then 'normal' won't get run. This is hokey, I know. > > So if I just remove all the normal stuff? What about all the reset16 > and entry16 stuff? Looks to me like I pretty much have to re-write my > MB config.lb Start with building a rom that only has a fallback image, leaving failover.c intact and strip it down once everything else is working. You'll never have to touch the reset16 and entry16 code. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: V2 questions
* Ronald G. Minnich [050120 16:41]: > > Why are all the payloads out of tree? Be nice if there was a payloads > > directory with some known good payloads. > > well, I am supposed to put my filo in there RSN, should I do that? My > mistake ... What about fs_stream? > I would still prefer to get people to build out of the tree, but ... We could pack a script that downloads a given etherboot version, asks some questions and compiles. But then again, packing a good documentation might help further. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
ACPI and Linux
*Sigh* When Linux has IOAPICs and Local Apics configured via an ACPI MADT it will not read the mptable at all. It will reference mptable information though and not find any bus. Only way out seems to add a DSDT als well. Or whatever table it wants for that. It is really broken. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: linkb_to_host
* YhLu <[EMAIL PROTECTED]> [050119 02:35]:
> i wonder what the different between
> offs = ( pci_read_config16(dev, pos + PCI_CAP_FLAGS) & (1<<10)) ?
> PCI_HT_SLAVE1_OFFS : PCI_HT_SLAVE0_OFFS;
>
> and
>
> offs = ( (pci_read_config16(dev, pos + PCI_CAP_FLAGS) >> 10) & 1) ?
> PCI_HT_SLAVE1_OFFS : PCI_HT_SLAVE0_OFFS;
It won't configure the second 8131 correctly, still.
It boots fine though if I put my swap_links macro back in and call it
for the second 8131
#define swap_links(bus,dev,fn) \
do {\
unsigned reg1,reg2; \
device_t b=PCI_DEV(bus,dev,fn); \
reg1=pci_read_config32(b, 0xCC);\
reg2=pci_read_config32(b, 0xD0);\
pci_write_config32(b, 0xCC, (reg1 & 0x00ff)|(reg2&0xff00)); \
pci_write_config32(b, 0xD0, (reg2 & 0x00ff)|(reg1&0xff00)); \
} while(0)
Stefan
___
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Overlaping IO resource for AMD K8
* Eric W. Biederman [050118 20:29]: > In addition it is quite possible some of those cards still follow the original > option rom specification (pre pci enhancements) which simply requires > the 0x55aa signature the length byte and the jump to the entry point. Also, the 0x55aa sequence has to be at any 4k boundary within the rom. Before that any data may occur. IIRC the standard does not say that the option rom image has to start at the beginning of the physical chip. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Running with VGA
* YhLu <[EMAIL PROTECTED]> [050118 19:34]: > Can I use that to connect Exchange Server in IMAP? Yes, it works fine. ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: v2 testbios compile error
* Richard Smith <[EMAIL PROTECTED]> [050118 17:40]: > > > It is used because it is in FC2. I believe it is in recent SuSe too. > > > I think it is requred for x86_64. > > > > I changed it to be configurable in the Makefile. Just enter your libpci > > version there and it will compile. Unfortunately there is no simple way > > I didn't see that in V2 makefile I was using. All it had was a > hardcoded path /usr/lib/libpci.a Do cvs update. The path is still hardcoded. > Both the #include statements in the .c files and the path to the > library had to be changed. Why did you have to change the #include statements?!? ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Overlaping IO resource for AMD K8
* Li-Ta Lo <[EMAIL PROTECTED]> [050118 17:14]: > Some of them don't have correct 0x55aa signature. All of them have > wrong Class code. > Then it is not a pci option rom as described by the standard. Do they have the other pci option rom structs? ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: [PROPOSAL] enhanced table dumping
* Greg Watson <[EMAIL PROTECTED]> [050118 15:56]: > The only issue really is what format to use for serialization. I'm > leaning towards s-expressions for use with openbios. However, it's > conceivable that different serialzation methods could be provided for > different payloads, though probably not desirable. The easiest solution would be to provide a small set of C functions that can be linked to any payload that allow generic access to the device tree information. This could go as a small static library to utils/ Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
configurable HT speeds.
Hi, as far as I see CPU-CPU HT links are configured with 800MHz at max. C0 and newer K8 CPUs should be able to do 1000. Is there any reason not to enable this in such case? Also, if there happened to be 8131 which do 800MHz on the link, can we make this configurable via cmos or is Config.lb the way to go that early? Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: v2 testbios compile error
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [050118 02:06]: > > What was the a reason you had to move to the alpha version for the > > userspace program in V2? Seems like a lot of trouble for not much > > real gain. > > > > It is used because it is in FC2. I believe it is in recent SuSe too. > I think it is requred for x86_64. I changed it to be configurable in the Makefile. Just enter your libpci version there and it will compile. Unfortunately there is no simple way to find out the version of libpci yet. There was discussion on the linux pci mailinglist so this is likely to change in near future. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: [PROPOSAL] enhanced table dumping
* Eric W. Biederman [050118 12:51]: > I agree that there is an issue particularly with respect to > interrupts. A lot of this has waited until we have the time to > do this properly. I agree. However I also think we are coming close to the point were the existing infrastructure is fine enough to handle distributed table generation sanely. > > Autocreation of those tables should belong to the driver code of each > > supported device. > > No. The devices should have no idea about the format of the data > we present to the user. We should push all of the information into > the device tree so we can derive it from there. This is certainly true. But it will require some extra layer to be introduced that is completely missing at the moment. Representation of IOAPICs in the device tree are completely missing at the moment for example. We will also need quite some extra information from the config files. > No. A write_tables method is bad. We need to enhance the dynamic > device tree with irq information. And possible with something like > pci class so we can recognize devices with well know software programming > interfaces. ACPI has things like IRQ override entries in it's MADT. There are quite some other pretty exceptional situations of working around hardware layout and kernel design allowed by the specification. I am not sure how we want to associate information like this with a certain device. Is it part of the "mainboard" device then? I am scared that we have to invent a proper representation of things like this, just to be able to convert it to acpi later on while in the end ACPI tables are simple to produce and on non-x86 the hardware and linux kernel is less broken. > > This would also allow to extend the generic information provided by the > > bridges, by adding such functionality to the mainboard specific code, so > > we won't end up with something that is worse than now in any case. > > I think allowing additional work to be done at a per port level > is a valid critique. I would prefer we leave it until we find an > actual need however. This might be now, even though I am probably able to work around by factorizing the ACPI code seperating the table creator functions and the main function calling those. This one would go to the motherboard directory, next to mptable.c and irq_table.c. The problem I have is that I designed the ACPI code originally for the AMD Solo motherboard, and someone updated it to be useful on the Epia. But with every new motherboard there need to be different devices filled into the MADT. Say "then drop ACPI", but Linux is not able to boot this machine properly without ACPI. As sad as it is. > > Roughly thinking, table_t could look like: > > That is terrible. :- Which is why I kept myself from implementing it yet. > For a subset of the idea look at how we generate the cpu information and > the memory information directly from the LinuxBIOS table already. Can you give me a quick pointer? I am not sure that i am looking at the right piece of code. > We need an internal format for the information that we can consume and > control, and enhance. The fact that we are passing on that information is > secondary. I agree, though plugging a good concept between 2 broken ones might be hard. > For IRQ routing something very like the work done with open firmware > is needed. Open firmware actually cannot represent x86 irq routing > as there is it cannot handle a the separate descriptions of apic and > non-apic modes. But otherwise it should be able to handle everything. How does it handle APIC modes? If there is an APIC, I don't see any need to go non-APIC except for academical interest. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: [PROPOSAL] enhanced table dumping
* Ronald G. Minnich [050118 03:31]: > no argument that we have to create those tables, I just don't want the > baseline format to be binary, if at all possible. It's very non-portable > to non-x86 systems. The baseline really is our internal device tree representation. Everything else should be generated from it. Non-x86 has been kept rather clean from ACPI, MP, pirq. They did not spend the time to invent the same information passing 3 times ;-) Those platforms rather offer an IEEE 1275-1994 interface (which is binary+callback, all evil combined, but it is well proven) Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: [PROPOSAL] enhanced table dumping
* Stefan Reinauer <[EMAIL PROTECTED]> [050115 22:07]:
> enum {
> MPTABLE_CPUS,
> [..]
> ACPI_COMPLETE_TABLES,
> } table_t;
>
> and dev::write_tables() would look similar to this:
>
> static void amd8111_write_tables(device_t dev, table_t id)
> {
> struct resource *res;
>
> switch (id) {
> case MPTABLE_BUSSES:
> [...]
> break;
> case MPTABLE_APICS:
> [...]
> break;
> case ACPI_COMPLETE_TABLES:
> [...]
> break;
> case ACPI_APICS:
> [...]
> break;
> default: // all unneeded and unknown table types are ignored.
> break;
> }
> }
Thinking about Ron's comments we might want to keep the different table
types more seperated.
Thus instead of having dev::devops::write_tables() would it be
preferable to have several hooks for
1) linuxbios table
2) ACPI tables
3) MP table
4) pirq table
The more complete 1 and 2 become, the less 3 and 4 will be needed.
In a perfect world we could choose to stop calling 2-4 and not compile
them in. This is nicer if the table generation is more seperated.
Regarding non-x86 systems: We don't want 2-4 on those anyways since no
operating system _expects_ they are there. And we definitely don't want
to change that.
Stefan
___
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: [PROPOSAL] enhanced table dumping
* Ronald G. Minnich [050117 21:48]: > It all sounds good except I would really like to try generating > s-expressions as well. I am convinced that the binary table thing is going > to cause us future trouble, and the reason I am so convinced is that every > binary table I've ever seen had troubles not long after it was > disseminated as a standard. You might be right. But it seems that it becomes harder and harder to boot a machine without ACPI and mptables. Until we have Linux and other OSes convinced of something better we might have to grin and bear it. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: superio connected to the PCI bus?
* Andreas Bach Aaen (AH/TED) <[EMAIL PROTECTED]> [050117 16:03]: > Hi, > > can I from the lspci output see where the superio chips is connected? Not really. you got to know that it usually hangs off the LPC bridge. > My lspci -tv says: > lspci -tv > +-1f.0 Intel Corp. 82801DB/DBL (ICH4/ICH4-L) LPC Bridge Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: compilation of tyan2735 linuxbios2
* Andreas Bach Aaen (AH/TED) <[EMAIL PROTECTED]> [050117 15:56]: > Hi, > > I am looking at a board chipsetwise a lot like the Tyan2735. When I compile > tyan2735 I get the following problem from a few days old CVS shapshot: > --- > cp linuxbios_ram.nrv2b linuxbios_ram.rom > echo "INCLUDE ldoptions" > ldscript.ld ; for file > in /home/tedaba/linuxbios/x/freebios2/src/arch/i386/init/ldscript.lb > /home/tedaba/linuxbios/x/freebios2/src//cpu/x86/16bit/entry16.lds > /home/tedaba/linuxbios/x/freebios2/src//cpu/x86/32bit/entry32.lds > /home/tedaba/linuxbios/x/freebios2/src//cpu/x86/32bit/reset32.lds > /home/tedaba/linuxbios/x/freebios2/src//arch/i386/lib/id.lds ; > do echo "INCLUDE $file" >> ldscript.ld ; done > gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld crt0.o > /usr/bin/ld: section .reset [fffdfff0 -> fffd] overlaps > section .rom [fffdc6eb -> fffe3e2f] > /usr/bin/ld: section .id [fffdffd9 -> fffdffef] overlaps > section .rom [fffdc6eb -> fffe3e2f] > collect2: ld returned 1 exit status > make[1]: *** [linuxbios] Error 1 > make[1]: Leaving directory > `/home/tedaba/linuxbios/x/freebios2/targets/tyan/s2735/s2735/normal' > -- > > Can you see what's wrong in this configuration. I have actually ordered a > tyan2735 board for testing, so I would really like to get this up and > running. You need to increase ROM_IMAGE_SIZE in freebios2/targets/tyan/s2735/Config.lb Choose something like 0x18000 Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
[PROPOSAL] enhanced table dumping
Hi,
Porting LinuxBIOS to new motherboards has become easier and easier over
the last period of time. There's almost no need for assembler coding
anymore, Hypertransport featured systems do a completely automatical
setup of their non coherent devices. On K8 systems even the coherent
devices get initialized automatically. But there is still one major
drawback when it comes to boot an operating system: Passing the
information.
No, this is not going to be a discussion about whether this or that
table is preferred. The problem is simply that for each motherboard
these tables have to be redone over and over: The pirq table, the mp
table and the acpi tables.
This leads to hand made tables that often contain errors or have to be
adapted with architectural changes that might have consequences wrt the
bus numbering for instance.
* pirq tables do need knowledge that is not provided in the config files
yet (wiring)
* MP tables contain a static "compatibility part" and have to have
entries for devices on the bus and their interrupts. This is very
similar to the pirq table. But they also need information on available
APICs. These could be provided from the device tree. We know we have
an 8131 in there, so we know 2 IOAPICs belong on the list. We also
know what busses hang off that 8131, so we can generate most of the
interrupt tables.
* ACPI tables need information on the Apics as well. Now the ACPI
implementation I wrote a longer while ago is completely static and
basically only works for systems with a single IOAPIC and not very
well even on those.
Autocreation of those tables should belong to the driver code of each
supported device.
The information about the 8131 should come from the 8131 code, the
information for the 8111 should come from the 8111 code, and so on.
The solution could be to enhance the struct device_operations by an
additional member write_tables(device_t dev, table_t id) which can be
subsequently called by each of the write_*_tables() functions, adding
their part to the table.
This would also allow to extend the generic information provided by the
bridges, by adding such functionality to the mainboard specific code, so
we won't end up with something that is worse than now in any case.
Roughly thinking, table_t could look like:
enum {
MPTABLE_CPUS,
MPTABLE_APICS,
MPTABLE_BUSSES,
MPTABLE_DEVICES,
ACPI_APICS,
ACPI_COMPLETE_TABLES,
} table_t;
and dev::write_tables() would look similar to this:
static void amd8111_write_tables(device_t dev, table_t id)
{
struct resource *res;
switch (id) {
case MPTABLE_BUSSES:
smp_write_bus(mc, dev.link.secondary, "PCI ");
[...]
break;
case MPTABLE_APICS:
res = find_resource(dev, PCI_BASE_ADDRESS_0);
if (!res) break;
smp_write_ioapic(mc, last_ioapic()+1, AMD8131_IOAPIC_VERSION,
res->base);
[...]
break;
case ACPI_COMPLETE_TABLES:
acpi_create_hpet(...);
[...]
break;
case ACPI_APICS:
// We're adding an APIC to an ACPI MADT:
acpi_create_madt_ioapic(...);
[...]
break;
default: // all unneeded and unknown table types are ignored.
break;
}
}
Since everything is a device in LinuxBIOS, we could create these tables
in a nice and ordered manner.
Comments? Flames? Better ideas?
Stefan
___
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Does linux kernel parse linuxbios table?
* Eric W. Biederman [041021 12:52]: > > Hello Eric, > > > >I searched the linux kernel mail archive and found your > > patch for x86 boot linuxbios support, but I didn't find the > > linuxbios table parse code in linux-2.6.8.1, does linux kernel > > still parse the linuxbios table now? > > Not currently. When I originally introduced the table I could not > get my patch in. At the moment mkelfImage just digest the table > and feeds Linux what it is expecting. Any endeavor to walk on the linux+lbtable path? Now that x86emu is working it would be very nice to store things like framebuffer address and resolution/depth in the lbtable as well.. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: speaker beeper
* Adam Talbot <[EMAIL PROTECTED]> [050113 20:39]: > -Stefan > Can i set my baud rate in the config, or do i need to go change it in the > code? You should be able to set it in the config ## Select the serial console baud rate default TTYS0_BAUD=115200 #default TTYS0_BAUD=57600 #default TTYS0_BAUD=38400 #default TTYS0_BAUD=19200 #default TTYS0_BAUD=9600 #default TTYS0_BAUD=4800 #default TTYS0_BAUD=2400 #default TTYS0_BAUD=1200 but I actually meant playing with your terminal program. A very common problem is that some i2c programming is missing and that makes the serial console come out with 57600 instead of the configured 115200 baud.. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: speaker beeper
* Adam Talbot <[EMAIL PROTECTED]> [050113 17:32]: > -Ron > Sorry about that, have not even looked at vga; yes, screen=console. > As far as the output i see in minicom... > ".. ... .. .. TÜ .¿.Ü.ü. . .. . .. ... Tü. .. .. . . ...û. . . .. > .. .. ." > Hope that means something to you. Have you tried setting it to half or double baud rate? Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: speaker beeper
* Bari Ari <[EMAIL PROTECTED]> [050112 19:43]: > Eric W. Biederman wrote: > > > >I think morse code would actually tie in better with the post code > >infrastructure than general console traffic. That would keep > >the volume of data low enough so as to be meaningful. Even > >if you did not know morse code. > > Then maybe you could use one of these instead of a POST card: > http://www.universal-radio.com/catalog/morse/2070.html If you don't want an extra device these might work as well, they capture morse code with a sound card: http://he.fi/archive/linux-hams/200407/0035.html http://bellota.ele.uva.es/~jesus/rtty/ The windows programmers usually take a pretium doloris for their code: http://www.dxsoft.com/en/products/cwget/ http://www.polar-electric.com/Morse/MRP40-EN/index.html Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Directory structure for x86emu
* Li-Ta Lo <[EMAIL PROTECTED]> [050107 16:26]: > For scsi, do we need the 'runtime' part as well as the 'init' part ? > The emulator has support to install an int handler (the real thing > from the BIOS image, not our C code emulation) and call the int > handler. This is exactly what we need. > Since in the LinuxBIOS, the emulator uses virtual==physical > address, we can just keep the scsi bios in the memory and do some int13 > call if we have to. There should be some streaming driver such as ROM_STREAM, IDE_STREAM or FS_STREAM: INT13_STREAM which allows reading a kernel image from disk. I would guess this allows to use a whole couple of other devices that "misuse" int13 to become bootable as well. Stefan. ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Directory structure for x86emu
* Stefan Reinauer <[EMAIL PROTECTED]> [050107 15:40]: > Definitely! Pragmatic decisions are not always those with the nicest > design, but in this case it will no doubt help LinuxBIOS gain a lot of > momentum against the other alternatives (ie. http://www.tianocore.org/) They are _really_ _honestly_ making their EFI stuff _freely_ available: Excerpt of the Usage Agreements for the source code Grant of License to Use [..] You acknowledge and agree that You will not, directly or indirectly: (i) reverse engineer, decompile, disassemble or otherwise attempt to discover the underlying source code or underlying ideas or algorithms of the Software; (ii) modify, translate, or create derivative works based on the Software; (iii) rent, lease, distribute, sell, resell or assign, or otherwise transfer rights to the Software; or (iv) remove any proprietary notices in the Software. [..] IANAL, but do I get it right that before I am allowed to see their sources for _participating_ in their neat little project I have to accept that I am not going to _modify_ them or discover the way they work? The derivative work clause almost seems like nothing compared to this. There are 17 more paragraphs which I did not even dare reading anymore. Poor guys who made the mistake clicking on "I agree".. "All your bases are belong to us". Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Directory structure for x86emu
* Ronald G. Minnich [050107 05:54]: > > On Thu, 6 Jan 2005, Li-Ta Lo wrote: > > > Any comments ? > > > > This is wonderful, as it may solve the SCSI problem too. > > I agree with eric that in general going to expansion roms as an option is > undesirable, but ... sometimes you have no choice. I have friends at one > lab who will be able to use linuxbios on 64 machines if we can init the > SCSI BIOS on their RAIDs. Definitely! Pragmatic decisions are not always those with the nicest design, but in this case it will no doubt help LinuxBIOS gain a lot of momentum against the other alternatives (ie. http://www.tianocore.org/) getting scsi to work will be some more work than vga due to int13 overloading, but given how far things have come in the last couple of days this will happen rather sooner than later. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Attic gone?
* Eric W. Biederman [050106 21:01]: > "Ronald G. Minnich" writes: > > > bitkeeper anyone? I'm using it for a lot of projects and going back to > > sourceforge all the time is getting annoying. > > If we made regular releases bitkeeper might be an option. > As it is I have extreme problems with their free license. I wrote some scripts doing daily snapshots a while ago when OpenBIOS was using bitkeeper. > Stefan how has using arch for openbios been working? I'm happy with it, some points: * It combines the flexibility, distribution and enhanced functionality (like decent merge algorithms) of bitkeeper and the open source development model and licensing. * There are .rpm and .deb packages available for all major distributions, clients for windows are also available. * It works with wide spread communication layers such as ssh, ftp or webdav * Due to it's distributed concept there is no "main" tree except through definition. There's no difference between a local repository and a remote one. * Syncing from/to a CVS tree is easy as long as there's only one sync direction. The available software even intelligently pairs CVS checked in files into changesets. Patrick Mauritz set up a local freebios2 arch tree like this a while ago on openbios.org. It was a matter of less than an hour iirc. * After the arch people were strictly focussed on a clean design they also take usability a lot more into regard these days. * To make life easier for OpenBIOS developers we have a tight howto available at http://www.openbios.org/experience/gnuarch.html All in all it is no harder than cvs or bk if you are new to it. * Repository browsing for the openbios arch repositories is available at http://www.openbios.org/cgi-bin/viewarch.cgi It works a lot like the well known viewcvs. * Unlike bitkeeper I have full control over my source trees sitting on my own machine with a reliable high speed connection. No dependency on bkbits or sourceforge.net resources/bandwidth. If you have concerns that should be met, tell me. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Attic gone?
* Eric W. Biederman [050106 04:10]: > > It seems it's also impossible to check out the old files with > > cvs co -D "2003-07-30 20:00" freebios2 > > Very weird. I would run cvs log to see if you can spot the proper revisions > and see if you can check out the individual files. I know I have > been able to ckeck out older files in the past.. No, it's completely gone. I've been talking about amd8111_ldtstop.c and the according part in northbridge/. Seems Sourceforge cleaned out all the deleted files for the linuxbios tree. Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: mptable.c
* Ronald G. Minnich [050104 14:56]: > > > On Tue, 4 Jan 2005, Stefan Reinauer wrote: > > > Am I supposed to delete it, or am I supposed to look up what it means > > and implement it in mptable.c so LinuxBIOS can use it? > > oh boy. It's been a year at least since I even looked at that thing. > > I will try to see what it's trying to do but I can't really tell why it is > doing this. I can have a look, if you can point me to some documentation. Is the utility supposed to through out a working mptable? The code it creates looks fundamentally different from the opteron boards' mptables.c versions. > That type of thing was supposed to only come out between /* */ It doesn't, instead it comes right after all the smp_write_intsrc() calls: smp_write_intsrc(mc, mp_NMI, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, 0x0, 0x0, MP_APIC_ALL, 0x1); MP Config Extended Table Entries: [..] Especially the bus hierarchy information might be interesting to linux? I'll strip the comments out and see whether things work Stefan ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
