Re: Error in compiling STPC Consumer
Richard Smith <[EMAIL PROTECTED]> writes: > > Second thing I have got the BIOS writer guide for STPC > > So If I think I changes the replaces the code of STPC_ELITE > > for that of STPC_ATLAS then I can make it for STPC_ATLAS > > If you are going to have to do a lot of re-write work I encourage you > to start over with V2. V1 is a dead end product and will be very > difficult for the linuxbios developers to support you as we are all > focusing on V2. V2 is so much nicer to work with compared to V1. In > V2 almost everything is in C rather than assembly, even all your RAM > init code is C due to Eric's marvelous romcc which is a C compiler > designed to use registers rather than RAM. Right. V1 is essentially frozen so nothing that used to work breaks. The very nice thing about V2 that the structure of the code makes it much easier to write reusable code. > The STPC Atlas is basically a fast cryix 486 so I don't know what > impact that has on romcc due to its smaller register set and if its > been tested on that arch much but its shouldn't be too much effort to > make it work. Right Eric? All you have to do is not tell romcc it has mmx or sse registers. For a modern memory controller that gets awfully tight but for a simpler memory controller it should be doable, to make everything fit. I almost had the Opteron memory controller working in just 8 registers. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Anyone tried LinuxBIOS with freeBSD?
Stefan Reinauer <[EMAIL PROTECTED]> writes: > * 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? Definitely. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Anyone tried LinuxBIOS with freeBSD?
yhlu <[EMAIL PROTECTED]> writes: > 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. > > Any suggestion about 1 and 2. We already do. Although getting the irq routing information into the device tree and the linuxbios table is something I have on the todo list. The ADLO loader needs to handle the conversion from the format linuxbios uses and whatever bochs bios uses. Currently the loader is terribly primitive. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Anyone tried LinuxBIOS with freeBSD?
yhlu <[EMAIL PROTECTED]> writes: > LinuxBIOS already got pirq table and mptable and may put vga_bios in 0xc. > > I would help ADLO can get these data automatically. Right if the ADLO loader can be tweaked to copy these from LinuxBIOS we could shortly have a generic ADLO which would be much easier to work with, and should work for nearly any board. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Version Control
Li-Ta Lo <[EMAIL PROTECTED]> writes: > I am reading the manual now. One question regarding development model. > Are we going to have multiple local "archive" for each developer and > sync to some upstream archive ([EMAIL PROTECTED]) from time to > time? The current situation is that there are already at least 2 archives. There is the public LinuxBIOS tree that everyone works against. There is the LNXI internal tree, that we have to have to work on prerelease products. And I there are a few other branches for different companies products. So the reality is that we currently have several archives and we need to sync between them. And since those multiple archives know nothing of each other it can be a lot of work. So what I expect to see is that there will be an upstream archive [EMAIL PROTECTED] ftp://openbios.org/pub/arch/[EMAIL PROTECTED] where we will periodically commit changes two. There is still some discussion going on with how the public/main archive will be managed. The lazy solution is to setup an account and put everyone's public ssh key who has we want to have commit access in there. Stefan may be more creative and figure out how to get the patch queue manager going.. We want to be careful and not get too many branches or there will be a lot of needless merging work. However beyond that I believe the intention is to stay as in-sync as we can. Eric ___ 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]> writes: > > From: Eric W. Biederman > > > > Does vmware > > accurately simulate what is required to bring memory up or do we > > get to short cut that. If the latter the porting could be done > > very quickly. Memory initialization is generally the hard part, > > of a LinuxBIOS port and would likely be trivial under vmware :) > > VMware virtual 440BX doesn't care about setting RAM timings, etc. > but it supports reading DIMM SPD configuration. > > Initially VM's RAM size can be hardcoded in BIOS. So there is a little pain but it should be fairly easy... > North bridge's PAM (Programmable Attribute Map) registers are fully emulated > so BIOS has to do the right thing with them. That bit is easy. > SMM/SMRAM handling has some peculiarities but LinuxBIOS doesn't care about > SMM, does it? Nope. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: we need to sequence this
Li-Ta Lo <[EMAIL PROTECTED]> writes: > ??? I thought vfat support long filenames. I believe it is the length of the pathname rather than individual filenames. Although some filenames may also be affected. I really don't understand it either. This is my dim recollection from watching some of the conversation. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: we need to sequence this
Li-Ta Lo <[EMAIL PROTECTED]> writes: > On Tue, 2005-03-08 at 14:35, Eric W. Biederman wrote: > > The biggest problem with arch is that it does not work well on a > > windows machine. Mostly because of limitations of windows > > filesystems. I believe most of the issues go away if you > > don't have your repository on a windows box. Plus there are > > a number of people working on that part of the problem. > > > > What's the limitation of the filesystem? Can't handle > the strange filenames used by arch? As I recall there are some small issues with a case preserving case insensitive filenames. But I think the big issues is the depth of the directory tree and possibly the length of the filenames. The primary work with windows has been referred to as path compression. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: we need to sequence this
"Ronald G. Minnich" writes: > 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? My final practical test is to merge with Stefan's tree. We don't have any commit access setup so that would slow down a switch over a little. I would hedge our bets by archiving the current cvs tree for a little while. Once the primaries are up and running at a basic level i.e. everyone is comfortable with checkout/commit on the main branch I don't have a problem it. > What stepan could do is an import, and at the same time we shut down > commits to the cvs. > > Sound ok? Roughly. I have asked Stefan to tag cvs at the point he does his import so if there are a few stray pieces flying around we should be ok. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: we need to sequence this
YhLu <[EMAIL PROTECTED]> writes: > why does the Linux kernel use bitkeeper? The linux kernel uses a combination of bitkeeper, quilt, and diff+patch. Using bitkeeper is nowhere mandatory in the process. At the time the call was made by the kernel developers bitkeeper existed and none of the alternatives did. Arch is close to bitkeeper in a lot of ways, and it is free software. The biggest problem with arch is that it does not work well on a windows machine. Mostly because of limitations of windows filesystems. I believe most of the issues go away if you don't have your repository on a windows box. Plus there are a number of people working on that part of the problem. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Version Control
"Ronald G. Minnich" writes: > On Tue, 8 Mar 2005, Eric W. Biederman wrote: > > > 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? > > nope. Have not had time to look as I have been sick. Fooey. > > The only issue I worry about is making sure that vendors have One Place To > Go for as they do know (i.e. sourceforge.net). It seems to me that > openbios.org could be that place. Sound ok? Generally. And certainly it should be the tree we work against. However one of very nice things about arch is that any with a file sever can trivially setup a mirror. But I do agree we do a blessed repository that holds the mainline development. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Version Control
Li-Ta Lo <[EMAIL PROTECTED]> writes: > what is the tla command for > > cvs -d:xxx login > cvs -d:xxx co freebios2 tla register-archive ftp://ftp.openbios.org/pub/arch/[EMAIL PROTECTED] tla get -A [EMAIL PROTECTED] freebios--devel--2.0 For more information look at: http://www.openbios.org/experience/gnuarch.html http://wiki.gnuarch.org/ Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Anyone tried LinuxBIOS with freeBSD?
Richard Smith <[EMAIL PROTECTED]> writes: > On Tue, 8 Mar 2005 09:53:03 -0800, yhlu <[EMAIL PROTECTED]> wrote: > > So need to make shadowing work in V2 before make ADLO working...? > > > > which region? > > > > 0xf - 0xf and 0xc- 0xc. Look at util/ADLO/loader.s > That shows you the ranges. In general simply making 0xc - 0xf memory is a good target and I think v2 does that by default. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Version Control
"Ronald G. Minnich" writes: > 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! I'm in the prep stages of merging my tree with Stefan's. This first merge is going to be as bad anything I have done before but after that things should be much easier. I have managed to check Stefan's pgp signatures on his tree and everything looks good there :) 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? Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: First cluster project
"Justin C. Darby" <[EMAIL PROTECTED]> writes: > * Lustre (If I can get a good dialogue with the ClusterFS folks started.. > still waiting to hear from them. I need to mirror two hard disks over > 1000mbit tcp/ip for redundancy.) For the small scale you are looking at, I recommend you look at nbd and the linux md layer, or possibly drbd. I don't believe Lustre does redundancy in software yet. If you need an active/active configuration things are harder. nfs from the primary to the secondary would be my first guess there. Eric ___ 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]> writes: > > From: Ronald G. Minnich > > On Mon, 7 Mar 2005, Dmitriy Budko wrote: > > > > > Does anybody needs LinuxBIOS for VMware virtual machines? > > > If you want it please describe why do you want it. > > > > it would sure make it easier to do full-up sims of linuxbios-equipped > > systems. > > So, you don't need it for "production" systems, only for development, > do you? > > How difficult is it to port Intel 440BX chipset support from > V1 to V2? Not terribly hard. It is more of a time/desire thing. Does vmware accurately simulate what is required to bring memory up or do we get to short cut that. If the latter the porting could be done very quickly. Memory initialization is generally the hard part, of a LinuxBIOS port and would likely be trivial under vmware :) > It seems to me that supporting a new SIO chips (the emulated > NS PC97338/PC87338) should be easy. Right it should not be a problem there. The case that was discussed recently with vmware was to do things the other way around. The observation was made that for server clusters dedicated to running vmware, running LinuxBIOS underneath could help boot time and cluster management. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Anyone tried LinuxBIOS with freeBSD?
Richard Smith <[EMAIL PROTECTED]> writes: > On Fri, 04 Mar 2005 15:37:31 -0600, Bari Ari <[EMAIL PROTECTED]> wrote: > > > http://wiki.linuxbios.org/ADLO > > > > That info is all from my V1 stuff and ADLO is not in V2 yet. However > its just a elf payload just like anything else so it will load fine. > It won't run until you get the shadowing right. > > I don't remember what the final result of our V2 shadowing discussion > was. I seem to remember that we thought we could do an elf location > trick that might make the mainboard specific shadowing in ADLO > unnecessary. Right. We should simply need to enable the shadow memory in V2. ADLO can take it from there. We can reexamine if we ever find memory that has a problem being read-write. It is weird that ADLO loads in one place and runs in another but that is largely a non-issue. We need the a loader that runs in protected mode. So whatever I was thinking with ELF tricks is something we can ignore. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Version Control
Stefan Reinauer <[EMAIL PROTECTED]> writes: > * 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 Stefan I have not looked at it yet but could you look at signing your tree. That is something we need for a public tree. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Version Control
"Ronald G. Minnich" writes: > On Mon, 28 Feb 2005, Josh England wrote: > > > The offer still stands to host SVN for the freebios trees as well as > > host linuxbios.org, plan9.net, etcI think the server is close to > > being ready. We'll have to figure out how to best transfer the CVS > > history over to SVN -- I've heard the tools for that are not the best. > > good stuff. I think linuxbios.org web pages will be somewhere but SVN > would be nice on the sandia.org host. For the web pages I don't care. But for the sources I SVN does not solve one of our major problems: Multiple repositories. Because of the NDA issues inherent in doing LinuxBIOS support before a chipset is released, and because of forks needed to ensure quality board ports that vendors can support I don't see multiple repositories going away. 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. 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. The big plus of something like this is it will be a lot less work for me to push my changes to the public tree so everyone will get them sooner. The latest version of cscvs is not perfect but it does do an adequate job of converting a cvs repository into an arch repository. You just have to be very patient with it :) It took about 8 hours to convert my internal tree. Ron does this sound like something you would be willing to look at? Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: [Etherboot-developers] freeebios project
Ramesh Chhaba <[EMAIL PROTECTED]> writes: > Hi Eric , > > thanks for ur response > u r right i am having old copy > plz tell me link from where I can get latest copy and procedure to compile it > and make bios for my board. > > I am using ATPC Vega Board. There is a reason a copied the linuxbios list. There are plenty of people who can tell you and a lot you can find out by looking up linuxbios. And yes it is the same project. Asking my privately for common things is not a good use of time and a terrible way to get responses out of me. I don't mind being copied but by asking on the list it is possible someone else will have time and reply to you before I do. I don't have time right now to hold your hand. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: [Etherboot-developers] freeebios project
Ramesh Chhaba <[EMAIL PROTECTED]> writes: > Hi all > > I am trying to learn how to makemy own BIOS > for my embedded PC. I want to make freebios as my root > for the project . > > If there is anybody woh have usedthe project. Several. > when I make it gives error of missing files like > > rom/stpc.h > rom/asm.h > > from where can I get a complete package You have an old old copy. The most recent code is checked into cvs and that is likely the best way to get it. I believe someone was also making recent CVS snapshots. I've copied this on the primary development list. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Linuxbios and co...
Guido Fiala <[EMAIL PROTECTED]> writes: > Hallo Mr. Biederman, > > came to contact you reading your article in the Linuxjournal: > http://www.linuxjournal.com/article/4888 > > You mention that you managed to set up Linuxbios for 3 mainboards, was it a > big job or quite easy to do? The hard part is always the chipset port. In particular the memory controllers can be a pain. > Would really like to try it for to system i have at hands here: a Via-based > system and a Pentium-M based one (MB890 mainboard). > > Can you recommend some step-by-step procedure how to get it working? > Unfortunately the documentation at the linux/free/open-bios sites is not very > useful compared to a "classical" Howto ;-) Love to but I've been too busy porting to different systems. > I can not even decide which one is the way to go - linux-bios, free-bios or > open-bios! There is mailing-list-traffic in all these, but in none a > site-search even got me results on "MB890" or "855GME" chipsets etc. linuxbios is a subset of freebios that seems to equal the entire set. openbios for the most part runs on top of Linuxbios. > Maybe you can give me some hint if you are still involved? I am. If you need more of a hint hopefully someone else can do a better job of answering the questions. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: totalimpact briq?
Stefan Reinauer <[EMAIL PROTECTED]> writes: > 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? 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? I guess that is a question for Greg. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: VGABIOS
Li-Ta Lo <[EMAIL PROTECTED]> writes: > On Mon, 2005-02-07 at 10:16, Richard Smith wrote: > > > The emulator is slightly larger than 32KB. For the Tyan S2885 > > > mainboard, the difference of the final romimage is 41376 bytes. > > > > > > Actuall, it is for uncompress romimage. For compressed image, > > > it is about 16KB. > > > > > > > Wow. I didn't realize that the Linuxbios verison would compile down > > and compress so small. If you apply Paulos work to all that it might > > get a lot smaller. I remember Paulo saying that there was lots of > > code duplication in the x86 instruction emulation that could be > > consolidated. > > It is Paulo's work. A small addendum to this thread. ACPI 3.0 specifies a _ROM method to read the video ROM from onboard video devices that store the _ROM in a proprietary format and cannot be read from the PCI ROM bar. Which seems to answer the question how does windows read that :) Eric ___ 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]> writes: > > Yes you can do that with ELF. > > > > The big gotcha is going to be that there are pirq tables current > > stored at 0xf that you are not going to want to stomp. > > Actually thats not that much of an issue. It currently stomps it already > > ADLO has that table broken out into a single binary file. All I do is > copy the table binary table generated with linubios into the adlo > build file and it gets stuck in the adlo image. Loader.s copies it > to a specific location. > So really if you loaded loader and ADLO code after the linuxbios PIRQ > table location and then tweaked loader to not make a PIRQ it should be > fine. > > Not haveing to do the PIRQ table copy would be nice but its pretty > trival. A script to do it automatically would be easy. The fact that ADLO has to manually customized per board is what keeps it from being a lot more generally usable. > > The fun question. Can I make the bochs bios useable on a system > > after the linux kernel has run. Load it with kexec and then boot windows? > > > > If LinuxBIOS is the native bios this should be no extra challenge. If the > > native BIOS is something else life gets a little more interesting. > > That _is_ a fun quesition.. I don't think you would have too many > problems though. The ADLO bios is used to running on systems that > already have everything setup. It does minimal hardware setup. If > you put everything in the right spot and modified the loader so that > it didn't copy anything I think it will work. > > kexec loads an elf right? So this would be pretty easy to test. Yes /sbin/kkexec loads an elf among other things. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: [BULK] RFC: Generic shadow mechanism useable from a payload
Adam Sulmicki <[EMAIL PROTECTED]> writes: > On Wed, 26 Jan 2005, Richard Smith wrote: > > I wonder if we could not just set things up where the ELF loader just > > loas it into the right spot in the first place. Perhaps that > > overwrites where the ELF code lives? > > if the ram/shadowing was setup correctly _before_ payload is started, then > perhaps. Which it should be fairly universally doable with freebios2. > but you still need to execute the switch to real mode code. > > perhaps you could do that by the means of more elaborate elf header which > tells > > * load loader.s here > * load pc bios here > * load video bios here > * jump to loader.s > > as far as I belive elf should spport loading multiple segments into arbirary > places in ram. Yes you can do that with ELF. The big gotcha is going to be that there are pirq tables current stored at 0xf that you are not going to want to stomp. The fun question. Can I make the bochs bios useable on a system after the linux kernel has run. Load it with kexec and then boot windows? If LinuxBIOS is the native bios this should be no extra challenge. If the native BIOS is something else life gets a little more interesting. Eric ___ 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]> writes: > Thinking about ADLO and the shadow enable/disable got some wheels turning. > > I've been spending lots of time in V2 and I was wondering if the same > type of methodology can't work for ADLO. > > In V2 there are specifc .c files that do thing in a chipset specific > way and the auto.c includes them as necesary. Those get compiled and > then stuck in the startup assembly. > > 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. That is a fairly sane way to get code sharing, if we need it. The code is small enough and simple enough cut-and-paste code sharing is probably just as good. All you need to do is look at which chipset you are running on. We only need to drop out support if it becomes too much code having support for all of the chipsets and cpus. But I actually think that is overkill. v2 by default and design enables all of the shadow ranges as memory. So we just need to use those ranges. That should be much easier having to patch ADLO each time. It is fairly unlikely a writable ROM segment is going to break anything. Once we find the application a writable rom segment breaks I will be happy to reconsider, solutions. > I suppose that that FILO and the emulator render most of ADLO > un-needed but if you are going to try and use FreeDOS or Windoze as an > OS then you will need ADLO. ADLO has a use case and for those Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: fallback reset_vector offset
YhLu <[EMAIL PROTECTED]> writes: > The problem solved. > > I switch the auto.c... before reset.inc in MB Config.lb > > Also add two inc in it > > mainboardinit arch/i386/lib/jmp_auto_out.inc > after auto.c segment > > mainboardinit arch/i386/lib/jmp_auto.inc > in old auto.c position > > please advise where to put these two inc. > > jmp_auto_out.inc > /* -*- asm -*- */ > > /* clear boot_complete flag */ > xorl%ebp, %ebp > jmp __main > > jmp_auto.inc > > /* -*- asm -*- */ > jmp __fpu_start Progress however unless I am mistaken this will fail miserably on an 8111 that only enables 64KiB of ROM by default. I think all of failover.c needs to be put in the magic position, if we are going to allow arbitrary memory size code. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: fallback reset_vector offset
YhLu <[EMAIL PROTECTED]> writes: > in reset16.lds > > _ROMTOP = (_start >= 0x) ? 0xfff0 : 0x8; > > > 0x8 ? And from the line above. /* Trigger an error if I have an unuseable start address */ That is exactly what happens correct? 0xfff8 does not work does it? Show me a less confusing way and I will use it. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: fallback reset_vector offset
YhLu <[EMAIL PROTECTED]> writes: > sometime the linuxbios.strip for fallback reset_vector will have 15 more > offset. > > here I set ROM_IMAGE_SIZE 0x19200, and the linuxbios.strip will be 15 bytes > longer. weird? > > 00191f0: e900 > 0019200: eeca fffe e900 ef18 fffe You are probably exceeding the 64K jump limit, to the start of the romcc code. I trigger a very weird ld case when that happens so the code will not compile. It was the best I could do. If you want to look at what it would take to arbitrarily relax that limit be my guest. If I could get a linker section to allocate space backwards this would be trivial to fix, as it is... Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Another V2 question
Richard Smith <[EMAIL PROTECTED]> writes: > > And since I don't have prototypes (which makes inlining easier) those > > functions must be defined before they are used. > > > > Just curious now, how does the lack of prototypes make inlining easier? The primary benefit comes from compiling everything in one pass. The lack of prototypes means you can inline something as soon as you see a call to it because you have it's definition. At one point that was a pretty big help. I believe I have a second pass in there for other reasons so adding prototype support would probably not be a big deal at this point. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Another V2 question
Richard Smith <[EMAIL PROTECTED]> writes: > > To start I added all of this framework in freebios v1.x and it > > caused not problems there. We just default to using it all in v2. > > There should be no reason to require it. Especially if you are doing > > your own motherboard. > > I would like what I'm making to be as usefult to the next 440bx user > as possible and so I wan't to keep all the fallback framework stuff in > unless I just have a real remove it. Just don't implement a failover.c for your mainboard. That is the only real practical difference. > > Beyond that on the boards that use it I usually write a failover.c > > which comes before auto.c that sets things up. > > Man the waters just get deeper. I though auto.c was first. I just > looked at failover.c and the fallback does a 'retun bist' so who > called failover.c? > > Can you list out the boot sequence for me step by step? Who calls what? It is the order they are listed in Config.lb. Or more simply the order the included files are included into crt0.S just like in freebios v1. There is just an extra step to build the assembly code now. > > As for the magic include order in auto.c that is because currently > > romcc does not do prototypes. > > Why does that require them to be after the big block of includes? > You can't just stick them all up at the beginning of the .c file? Things get interesting when you are including .c files. As has been previously mentioned auto.c defines board specific helper functions for the memory initialization code. And since I don't have prototypes (which makes inlining easier) those functions must be defined before they are used. So the file that uses them is included after the functions are defined. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Another V2 question
Richard Smith <[EMAIL PROTECTED]> writes: > > > > It should be straight forward to remove all of the tests etc for > > > > switching > > > > > from a fallback to a normal image. > > > > > > Do I really have to remove them? Ron seemed to suggest that if I just > > > turn off the fallback suff then I will end up with only a singel > > > fallback image. > > > > I was thinking of the per board test that make the policy decision > > which image you should be in. > > > > Ok so now I'm confused again. Perhaps we should just go through the > gory details and I'll be sure to write it up in something for the next > person. > > When HAVE_FALLBACK_BOOT=1 things do the normal fallback, check and > jump to normal. This won't ever work fully on our board since the > CMOS is not powered. > > When I set that to 0 whats going to happen in the resulting build and > image runtime? > > I would prefer to stay as close to the framework you have already and > just running fallback seems fine to me if thats all I need to do. To start I added all of this framework in freebios v1.x and it caused not problems there. We just default to using it all in v2. There should be no reason to require it. Especially if you are doing your own motherboard. Beyond that on the boards that use it I usually write a failover.c which comes before auto.c that sets things up. As for the magic include order in auto.c that is because currently romcc does not do prototypes. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Another V2 question
"Ronald G. Minnich" writes: > On Thu, 20 Jan 2005, Eric W. Biederman wrote: > > > > Yeah I would say so... Since you guys have the power to render 1000 > > > paperweights with a single command. > > > > Ron came insanely close to doing just that a while ago. > > ?? when was that? I gotta hear this story! I remember a support call with Pink. You had built the fallback image with the a loglevel of spew and for some reason that caused the nodes not to boot. You managed to fix it yourself so I don't know just what the fix was but I believe it involved opening cases and swapping rom chips. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Another V2 question
Richard Smith <[EMAIL PROTECTED]> writes: > > Ok so by design you really only want a single firmware image. > > > > Right.. I think Ron has me fixed up. I was unaware that there was an > overall flag that enabled/disabled the fallback system. In the generic code yes. > > It should be straight forward to remove all of the tests etc for switching > > from a fallback to a normal image. > > Do I really have to remove them? Ron seemed to suggest that if I just > turn off the fallback suff then I will end up with only a singel > fallback image. I was thinking of the per board test that make the policy decision which image you should be in. > > For those of us who have field upgradable systems it makes a bigger > difference. > > Yeah I would say so... Since you guys have the power to render 1000 > paperweights with a single command. Ron came insanely close to doing just that a while ago. > Our product is going to go into Gasoline pumps. You would not believe > the lengths that some store operators go to so they can cheat the > consumer slightly per fillup. So our customer requires a flash update > to be physical mod. Now that is a sane reason not to have field upgradable parts. :) Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Another V2 question
Richard Smith <[EMAIL PROTECTED]> writes: > > :) > > Do you have any other non-volatile storage? > > Nope. > > > A serial eeprom might be another good choice, of a location for variables. > > Anyway I understand the reasons for it and will happily work on > > brainstorming > > By design if you want to change the boot firmware of our device (in > production) you will have to de-solder the flash. Ok so by design you really only want a single firmware image. It should be straight forward to remove all of the tests etc for switching from a fallback to a normal image. For those of us who have field upgradable systems it makes a bigger difference. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: [PROPOSAL] enhanced table dumping
Stefan Reinauer <[EMAIL PROTECTED]> writes:
> * 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.
A reference implementation sounds sane. We can't assume that everyone
will be using the same code or the latest code but having something
to compare with sounds good. Except that a library has not been
factored out that is roughly what is in freebios/util/lb-dump directory
is.
Eric
___
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Another V2 question
Richard Smith <[EMAIL PROTECTED]> writes: > > probably because the cmos checksum is wrong. You need to use cmos_util > > (from LNXI ftp site) to set up the cmos with good params and checksum. > > >the docs I could find. My cmos is now fixed up, and I'm getting in to > >my normal image. > > H... Our board dosent have CMOS. Well dosen't have any retainable > cmos that is. There isn't a battery hooked up to the southbridge. > > Guess this means that I'll never come out of fallback? Of course I'm > stll a long ways off from that now :) Do you have any other non-volatile storage? For all of the settings except fallback/normal storing them in the flash chip won't be a problem (it just needs a little work). A serial eeprom might be another good choice, of a location for variables. Anyway I understand the reasons for it and will happily work on brainstorming a solution. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: memory reported to OS
"Gin" <[EMAIL PROTECTED]> writes: > Is it mandatory to report Reserved Memory region to the OS? For example, > the IOAPICs memory-mapped addresses? Reserving the address of any IO devices is a BUG BUG BUG. Your kernel will not boot if it doing things properly. > Would that be a problem if Linux > kernel didn't see it be claimed as RESERVED? More likely the reverse. > It seems Linuxbios doesn't claim any memory regions as RESERVED. We reserve out tables. Reserving memory is to tell the OS to never ever touch it (at least that is the linux interpretation). So if there is some magic hardware that the OS never sees we may want to reserve that. But mostly it is about reserving memory that is used for another purpose. And we just have a couple of tables which are pretty small. We really should communicate the address of non probable devices but that work is in process. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: what cpu models are tested?
Richard Smith <[EMAIL PROTECTED]> writes: > cpu model_6xx will not build. > > microcode_MU16930c.h: No such file or directory. A typo in the header file include name. It should be microcode_MU16830c.h I just committed the fix. The code was mostly written by converting old freebios1 code, and reading the appropriate docs. > I'll play with some others. As to how these things are named I have simply been using the hex value of %eax that comes back from cpuid. Which is roughly cpufamily, cpumodel, stepping as reported by /proc/cpuinfo. With various bits ignored as seems appropriate. With respect to discriminating which code needs to runs on which cpu this seems to be a fairly good arrangement. > Also if you forget to provide enough arguments to romcc you get an > 'Invalid tolken' error. A nice enhancement would be to count > arguments and if they don't match then give a incorrect number of > arguments error. Patches to romcc are welcome. My hunch in this case is that you had an undefined macro but without the error message I can't guess. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: [PROPOSAL] enhanced table dumping
Greg Watson <[EMAIL PROTECTED]> writes: > An arbitrary graph seems to be adding additional complexity that we don't > really > need. Do you have an example of where a tree won't actually suffice? The way interrupts are hooked up on most every board, I have seen including dec alphas. When you add to that the problems of designing something that is multiplatform and must continue to use whatever format we settle upon potentially forever we need to be careful. I admit that to work with an arbitrary graph between devices is a little harder to work with. Largely however this is 5 lines of code little. The big advantage a tree has is for internal processing because you get a well defined order for operating on it. A graph does not have this property but as most of the structure will be a tree extracting the appropriate trees should not be difficult for a client. > The nice thing about s-expressions is that it deals with both the structure > and > representation. None of this prevents use from using s-expressions, it simply means we can't use the most obvious application of s-expressions. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Intel 7520 support
YhLu <[EMAIL PROTECTED]> writes: > Eric, > > When can you put the E7520 support on the CVS server? > > I have worked out all amd64 dual core support even on 8 way system and want > to play something else. :) Currently this is Eric limited :) I need to send off the latest version of my kexec work to Andrew Morton, and I have some support issues but I should be checking the code in any time now. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: SMP linux
YhLu <[EMAIL PROTECTED]> writes: > You are kidding. I put junk in the CVS server? No. I just could not remember if it was a recent or an ancient board. If it was an ancient board in the v2 tree I could see problems. > I guess he still need some time to figure out how to modify his mptable.c. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Small and fast systerm.
[EMAIL PROTECTED] writes: > Hi Bari, > > I have the plain old VIA EPIA (800/5000) working a good 80 % of the time. > > Not sure if my problems are buggy northbridge setup or buggy motherboard - it > generates some spurious serial at power on, and sometimes hangs reading the > smbus to size the ram. The spurious serial at power on. (Assuming it is just a character) sounds like normal line noise. As for smbus they seem to be the most common board problem I have seen. Last time I trace one down it really was a board design defect, and made using lmsensors on that board impossible. In any event it is not terribly hard to put in timeouts and board resets to get past smbus problems. Although if you are having problems 20% of the time that is much more often then I have seen problems on other boards. Usually I see problems closer to the 1% mark. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: [PROPOSAL] enhanced table dumping
Greg Watson <[EMAIL PROTECTED]> writes: > On Jan 18, 2005, at 4:51 AM, Eric W. Biederman wrote: > > 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. Please note this problem has to pieces. Which information should we represent and how should we represent it. Devices on a motherboard are not necessarily connect as a tree. I have never seen a tree structured schematic :) So the actual layout of the data is to some extent secondary to the data structures we will use to represent that data. So we need to drill down on that part as to how we represent logical devices and how we represent the logical connections between them. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: [PROPOSAL] enhanced table dumping
Stefan Reinauer <[EMAIL PROTECTED]> writes: > * 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. Agreed. > > > 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. A small amount or we just get the devices to populate the IOAPICs. When the IOAPICs happen to be a pci device we already represent them. When the path to an IOAPIC is something else we don't. Devices with well known programming interfaces need a little extra care so we can report their well known resources properly. > > 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. Maybe. Let's handle the sane cases and see where that puts us. With respect to irq handling we need enough information to route the interrupts before Linux loads. With the pirq and other interrupt routing tables simply standing in the background. > > > 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. Hmm. I had not seen that problem. But the SOLO was always a weird board. Is this because linux has/had a bug in it's pirq table parser and did not recognize the 8111? Is the problem that we did not get the fix pushed upstream? > > > 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. Sorry I don't have a good example handy. I just know that for some parts of the process we already do use the existing tables. It is not very sophisticated. A good starting exercise would be to get the apics and ioapics into the device tree (which requires not extensions) and simply hard code the interrupt source information. That should generate about half of the interrupt routing table. > > 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
Re: [PROPOSAL] enhanced table dumping
"Ronald G. Minnich" writes: > On Tue, 18 Jan 2005, Greg Watson wrote: > > > 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. Taking this one step farther I am not at all convinced that we want to even export a tree. The simplest representation is actually a graph of the connections between hardware devices. This requires one list of hardware devices and a second list of connections. If we don't export what is physically possible some creative hardware designer will gang up on us in the future. And I'm not certain we don't need that to properly represent irqs in any event. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: configurable HT speeds.
Stefan Reinauer <[EMAIL PROTECTED]> writes: > 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? This one is subtle. AMD does not really talk about cpu to cpu link speed. But there is no support of 1000Mhz being supported until we get to the newest generation of chips coming out. In addition I measured it on a dual cpu system and I could not detect a performance difference based on the link speed so I decided to play that one safe. > 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? The 8131 very clearly has an errata that as I recall was labeled wont fix that limits the link speed to 600Mhz. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: SMP linux
"Gin" <[EMAIL PROTECTED]> writes: > I've been stuck at this problem for a while. My linuxbios boots a > NON-SMP kernel ok but not the SMP one. > The SMP kernel gets loaded and run. When it tries to access an IDE > drive, an IDE command timed out before anything returns(kernel > messages). My I/O APIC settings correspond to the MP table. > > All ISA devices are mapped to the I/O IOAPIC at 0xFEC0. But where do > we set this I/O APIC up? How does it know to route the IRQs to the local > APIC? Linux looks at the mptable. > Another question is, does linuxbios setup the local APIC as Virtual Wire > mode that via I/O APIC? Usually we simply setup the local apic in virtual wire mode. > My board is similar to Tyan/s2735, does anyone get this booted with a > SMP linux before?? Good question. Eric ___ 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]> writes: > On Tue, 2005-01-18 at 04:54, Eric W. Biederman wrote: > > In what sense do they have a bad ROM header? I can easily see > > them not supporting new pci features. Unless we can show that > > something is broken beyond repair we should not give up on supporting > > it. We don't know what brain damage will show up next. > > > > Some of them don't have correct 0x55aa signature. All of them have > wrong Class code. I can possibly see the class code being wrong. That is fairly minor, and you already have that on the physical hardware. For pci option roms you still have the vendor and device ids that tend to be the important part. 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. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Running with VGA
YhLu could you please, please, please fix your mailer so it sets In-Reply-To: and References: correctly or could you switch to a mailer that does. Catching up on a conversation like this when all of the threads are chopped in to little pieces is a major pain. It does not help that you are also top posting which is a terrible way to quote text. Putting the text you are replying to above what you are quote is usually much more readable. YhLu <[EMAIL PROTECTED]> writes: > Li-Ta Lo <[EMAIL PROTECTED]> writes: > > > On Fri, 2005-01-14 at 12:45, YhLu wrote: > > > I check the amd_early_mtrr.c with old amd earymtrr.inc. It seems the only > > > difference is not enable SYSCFG_MSR_MtrrFixDramModEn before clear MTRR > > > fixed. Did I miss that. It should be a simple fix? > > Probably I didn't commit all the old code I used to have. > > Anyway, the things we have to do in early_mtrr.c are: > > > > 1. enable SYSCFG_MSR_MtrrFixDramModEn > > 2. set fixed mtrrs for 0-0x9 and 0xC-0xF > > as WB and READ_MEM and WRITE_MEM > > 3. set fixed mtrrs for 0xA-0xBFFF to UC The attributes should come naturally from the systems memory map. > > 4. disable SYSCFG_MSR_MtrrFixDramModEn > > 5. enable SYSCFG_MSR_MtrrFixDramEn I think substantially we did all of that prior to this conversation. > > > I enable that, but the result shows no change > I add the code to amd_earlymtrr.c but found two problem > 1. in the cpu init, the second cpu cache can not be enabled. (still using > value set by amd_earlymtrr.c). ( before the amd_mtrr.c called by init). YhLu you have a bug in your cpu initialization code. It sounds like something has broken in the dual core cpu setup. > 2. some slow in auto.c stage. Maybe because of before enable cache for > LinuxBIOS rom flash, there is more instruction to enable fixed mtrrs. > > So I prefer to two phase dev_init loop. Ok we have a dependency order in the running of the init routines. Ouch. How about something very simple. We can put the bus for the cpus before any of the inboard devices. The cpus are the special case here not the pci video card. It is the cpus that should get the special handling. We may need to move the cpu initialization up into the enable_resources phase of everything if simply reordering the buses in Config.lb is not enough. Eric ___ 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]> writes: > On Tue, 2005-01-11 at 16:52, Ronald G. Minnich wrote: > > Ollie, you did it! > > > > We should thank SciTech for their wonderful emulator. Yes. > > Ollie just took a big stack of video cards, some AGP and some PCI, and > > booted linuxbios one at a time and showed how each video card came up. > > > > It's fantastic. > > > > I think the current code should support most VGA cards available in the > market. I have tried VGA cards from Nvidia, ATI, Matrox and Cirrus. > > I found that the VBIOS on S3 cards don't have correct ROM header. The > company is dead anyway. In what sense do they have a bad ROM header? I can easily see them not supporting new pci features. Unless we can show that something is broken beyond repair we should not give up on supporting it. We don't know what brain damage will show up next. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: [PROPOSAL] enhanced table dumping
Stefan Reinauer <[EMAIL PROTECTED]> writes: > 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. 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. > 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. Yes. > * 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. 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. > 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. Agreed. The information should be associated with the device in the device tree. > 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. 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. > 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. > Roughly thinking, table_t could look like: That is terrible. > Since everything is a device in LinuxBIOS, we could create these tables > in a nice and ordered manner. > > Comments? Flames? Better ideas? For a subset of the idea look at how we generate the cpu information and the memory information directly from the LinuxBIOS table already. 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. 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. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: speaker beeper
"Adam Talbot" <[EMAIL PROTECTED]> writes:
> A morse code decoder for decoding "Audio console". Wow, our geek is
> hanging out! :-) if some one have that much spair time... But for now, one
> or two simple beeps would make me VERY happy.
> As far a POST card, I do not have one... Yet. What POST card have your guys
> had good luck with (PCI)?
I keep having problems with not having a 5V 32bit PCI slot or an ISA slot...
But in any case the llshell.inc should do the trick just include it and
call it very early on. And the first thing it does when called is beep.
>From romcc the calling convention would look something like:
asm("movl $1f, %esp\n\t"
"jmp low_level_shell\n\t"
"1:\n\t"
);
Of course you won't come back unless you have your serial console working...
Eric
___
Linuxbios mailing list
Linuxbios@clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Moving 440bx to V2
Richard Smith <[EMAIL PROTECTED]> writes: > I don't understand the cpu naming scheme in the > cpu/intel dirctory. > > Our board uses a PIII Celeron in a PGA socket 370 @ > 400 Mhz > > should I just call the directory socket_PGA370 or do I > need to add speed info? What about the Celeron, > non-celeron difference? The idea is to filter the processors by which processors will fit into a socket. With recent Xeons Intel has reused the same socket with a different pin-out. The only name associated with the pin out change is the processor front side bus frequency. You can look up the appropriate Intel data sheets to figure out what is socket compatible with what else. If we fully supported it we would have a lot of potential cpus and non-intel cpus that could plug into it. So we would need to include a bunch of directories. Socket 370 is the first socket that Intel denied the clone manufacturers from using I believe. So the choice in cpus should be fairly small. After that I break the functionality by the information returned by cpuid. If the processors are significantly different I have different directories for initializing them. If the processors are similar I have the same directory and look at the values cpuid returns for the changes. The idea is to differentiate things how it makes sense from a code perspective, rather than how it makes sense from a vendor marketing perspective. As I recall the only real difference with Celerons is their reduction in cache so we may get a fair amount of code sharing with other processors. I don't think the clock cycle changes at that point caused a different socket pin out to be used. And of course a lot of functionality is buried in cpu/x86/ for code that is independent of a given processor model. It is not a huge leap forward from where we used to be but it is better, and the code has the very nice property that when we encounter a new model of cpu (which for Intel almost always requires a different microcode update) we have to explicitly allow it to boot. So the developers get a chance to verify the code is going to work with the new cpu model. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: speaker beeper
"Ronald G. Minnich" writes: > On Wed, 12 Jan 2005, Eric W. Biederman wrote: > > > Unfortunately I don't believe we have an pc-speaker output coded for the > > LinuxBIOS case. I keep play with the idea of morse code console, using > > the pc-speaker :) You would not want full debugging on but it might be > > useful for your kind of scenario. > > now that's a cool idea, Eric, I didn't know you knew morse code! Not very well. The idea originally came from Alan Cox with respect to the kernel. I have simply been mulling it over for a while. With the realization a couple of days ago that the PIT is easily accessible makes it that much more attractive. 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. > How about for the failure case: > ... --- ... :) Except that usually the failure case does not print a message. But a boot sequence that when like - . ..--- ...-- - . -. --... ---.. But never got to . Could be pretty telling. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: speaker beeper
"Adam Talbot" <[EMAIL PROTECTED]> writes: > Need some way to test if linuxbios is booting correctly. I am debugging and > I have reason to believe that my problem is the super io... Does any one > know how to get the pc speaker to beep in X second intervals, or some thing > that simple, power LED blink... I would like to set up a "speaker beeper" as > my payload. > > I would also like to try to get the new VGA bios running... The graphics > card is built on to the board, just to make life more of a pain. If any one > is willing to give me a "How To" that would be of great help. I would aim at the PC speaker if I could. Usually the PIT (programmable interval timer) which drives that speaker is on the south-bridge, so it should make a very good target for getting output if you are not certain about the super-IO. The keyboard LED is a lot more work, so I would not worry about that. And I would suggest that a payload is much later than you want that debugging to happen. Unfortunately I don't believe we have an pc-speaker output coded for the LinuxBIOS case. I keep play with the idea of morse code console, using the pc-speaker :) You would not want full debugging on but it might be useful for your kind of scenario. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Moving 440bx to V2
Richard Smith <[EMAIL PROTECTED]> writes: > I need to start looking at moving the 440bx stuff to > V2. The part I'm most concerned about is re-writing > the ram init code. > > Is it possible to use the V2 structure but graft in > the assembly output from V1? Then as time permits I > can go back and re-write those routines. Yes. You will need to copy a few of the assembly helper routines as well, since I think we finally removed those from V2. > Tell me again which is the reference board for V2 for > a simple embedded case. Something like the via epia, q-emu should be ok. I don't really know as I have not looked at the simple embedded case lately. In the last round of cleanups I'm pretty certain we managed to purge the worst of the bad examples from the tree in the last round of cleanups. Eric ___ 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]> writes: > On Tue, 2005-01-11 at 12:39, YhLu wrote: > > >As the Nvidia card it does > > >not have PCI IO resource so we got the 2 to 1 thing. > > > > It mean it doesn't allocate resource to it. Limit > > > But why it set the resource to the HW registers? Doesn't it cause > some ill side effect? Setting limit < start is as close as you have to a disable. Nothing falls in that range so nothing is decoded. Eric ___ 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]> writes: > Eric, > > Why I got the overlaping IO resources in the 18:0 ? > > PCI: 00:18.0 1ba <- [0x00f400 - 0x00f5ff] prefmem > PCI: 00:18.0 1c2 <- [0x001000 - 0x001fff] io > PCI: 00:18.0 1d8 <- [0x002000 - 0x001fff] io > PCI: 00:18.0 1b0 <- [0x00e000 - 0x00efff] prefmem > PCI: 00:18.0 1a8 <- [0x00f630 - 0x00f63f] mem > PCI: 00:18.0 1a2 <- [0x00f600 - 0x00f62f] mem > > Shouldn't the 1d8 be 0x2000 to 0x2? I'm not quite certain but it appears to be my code for disabling bridge resources when there is nothing behind it. start > end creates a resource that doesn't decode anything. Do you have any I/O resources on that link? Does the resource allocator see those resources? Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Directory structure for x86emu
Li-Ta Lo <[EMAIL PROTECTED]> writes: > Hello, > > It turns out that the VGABIOS support can be made pretty generic > for all kinds of PCI expansion ROM. So I have the emulator the > .init method of default_pci_ops_dev. I am going to add the following > directories, if there is no objection, I will commit it next week. Except for plug in video cards I don't think this is a direction we want to go in. So at least for now pleas don't make the emulator the default .init method. > src/include/x86emu -- public header file of x86emu > src/devices/pci_rom.c -- expansion ROM loading and execution > src/devices/emulator -- the emulator and supporting functions > src/devices/emulator/x86emu -- the emulator itself > src/devices/emulator/pcbios -- legacy PC BIOS handler for the emulator > src/devices/emulator/biosemu.c -- glue between pci_rom.c and the > > emulator > > Any comments ? Your structure looks fairly sane. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Attic gone?
"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. Stefan how has using arch for openbios been working? Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Attic gone?
Stefan Reinauer <[EMAIL PROTECTED]> writes: > * Stefan Reinauer <[EMAIL PROTECTED]> [050104 00:29]: > > Hi, > > > > I want to look at some old files I checked into LinuxBIOS CVS a looong > > time ago, implementing LDTSTOP_L. But SF's ViewCVS does not show the > > Attic anymore.. is there a trick to get them? > > 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.. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: VGABIOS is working under LinuxBIOS
Li-Ta Lo <[EMAIL PROTECTED]> writes: > Ron, > > I just got the vgabios emulation working in the LinuxBIOS. The VGA card > is complete inited before the kernel is loaded. Now I have vga console > just like normal bios system. > > I will try the reduced x86emu and see if it works too. How large was your resulting linuxbios image. I am trying to see if it looks possible to put LinuxBIOS with VGABIOS support and a linux kernel all in a 1M rom chip. Eric ___ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: warning about pci_driver
YhLu <[EMAIL PROTECTED]> writes: > /tmp/ccX7Rb2q.s:9: Warning: setting incorrect section attributes for > .rodata.pci_driver > > Why? Good question. We set section attributes that say the section will be present. Beyond that I don't know why binutils (I think it's as in this case) is complaining. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: RFC: linuxbios table fix
Greg Watson <[EMAIL PROTECTED]> writes: > On Dec 9, 2004, at 10:49 PM, Eric W. Biederman wrote: > > > "Ronald G. Minnich" <[EMAIL PROTECTED]> writes: > > > >> On Thu, 9 Dec 2004, Eric W. Biederman wrote: > >> > >>> I am still worried about ppc, and big endian architectures in general. > >>> But I don't think we currently have any users there. > >> > >> we do. I think I'd like to hear Greg Watson's take on this as he is > >> working with the PPC 970 guys and this will impact him. > > > > Ron we have users of the LinxuBIOS table on PPC? It was my impression that > > we > > did not. > > > > I would be happy to hear what Greg has to say. If nothing uses this entry > > I will be happy to change this.Otherwise we need to know what the test > > program below reports on ppc. > > Nothing uses this currently, but I will be providing support to pass the > entire > device tree to a payload in the near future. Whether this will be using > linuxbios tables, s-expressions or XML depends on the results of the current > discussion. > > On ppc32, gcc-3.2.2 I get a size of 24. I'll try ppc64 later today. Thanks. Then I am going to ``fix'' the table definition so it returns a size of 20 even on ppc. What we do later is still in the air. But at least the current situation can be corrected without a flag day. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: need a linux floppy
"Adam Talbot" <[EMAIL PROTECTED]> writes:
> Hummm. Got both tomsrtbt and coyote Linux running. coyote Linux is very
> nice and I have other apps for it. But none of those had minicom on them.
> Any other ideas?
cat /dev/ttyS0
cat > /dev/ttyS0
Should just about do it.
Or for something a little more complete.
Eric
/* To compile run: gcc -g -O -Wall serial_echo.c -o serial_echo */
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define BUFFER_SIZE (1024)
#define BUFFER_RESERVE 8
speed_t get_baud(int wanted)
{
speed_t result = B0;
switch(wanted) {
case 50: result = B50; break;
case 75: result = B75; break;
case 110: result = B110; break;
case 134: result = B134; break;
case 150: result = B150; break;
case 200: result = B200; break;
case 300: result = B300; break;
case 600: result = B600; break;
case 1200: result = B1200; break;
case 1800: result = B1800; break;
case 2400: result = B2400; break;
case 4800: result = B4800; break;
case 9600: result = B9600; break;
case 19200: result = B19200; break;
case 38400: result = B38400; break;
case 57600: result = B57600; break;
case 115200: result = B115200; break;
case 230400: result = B230400; break;
case 460800: result = B460800; break;
case 50: result = B50; break;
case 576000: result = B576000; break;
case 921600: result = B921600; break;
case 100: result = B100; break;
case 1152000: result = B1152000; break;
case 150: result = B150; break;
case 200: result = B200; break;
case 250: result = B250; break;
case 300: result = B300; break;
case 350: result = B350; break;
case 400: result = B400; break;
}
return result;
}
#define ESC_CHAR '\x1e'
int do_inbuf_actions(char *in_buff, int len, int fd_serial,
char *input_file, int *fd_input_file)
{
static int in_esc = 0;
int i;
for(i = 0; i < len ;) {
if (!in_esc) {
if (in_buff[i] == ESC_CHAR) {
in_esc = 1;
memmove(in_buff, in_buff +1, len - i -1);
len--;
continue;
}
}
if (in_esc) {
if (in_buff[i] == ESC_CHAR) {
in_esc = 0;
i++;
continue;
}
else if (in_buff[i] == '\x3') {
exit(0);
}
else if (in_buff[i] == 'b') {
tcsendbreak(fd_serial, 0);
}
else if (in_buff[i] == 'f') {
int fd;
fd = open(input_file, O_RDONLY | O_NONBLOCK);
if (fd < 0) {
*fd_input_file = -1;
fprintf(stderr, "Cannot open %s %s\n",
input_file, strerror(errno));
}
else {
*fd_input_file = fd;
}
#if 0
do_transmit_file(fd_serial, input_file);
#endif
}
memmove(in_buff, in_buff +1, len -i -1);
len--;
in_esc = 0;
continue;
}
i++;
}
return len;
}
static struct termios initial_term_options;
void do_terminal_cleanup(void)
{
int result;
result = tcsetattr(STDOUT_FILENO, TCSANOW, &initial_term_options);
fprintf(stderr, "Exiting due to error %d -> %s\n",
errno, strerror(errno));
}
void usage(int argc, char **argv)
{
fprintf(stderr, "Usage: %s [device] speed] none|hard|soft]
ro|rw]\n",
argv[0]);
exit(1);
}
int main(int argc, char *argv[])
{
int fd_serial;
char serial_port[] = "/dev/ttyS0";
char *port;
speed_t speed;
struct pollfd fds_wait[3], fds_data_wait[3], *fds;
int result;
char out_buff[BUFFER_SIZE], in_buff[BUFFER_SIZE];
int out_buff_fill, in_buff_fill;
struct termios serial_options, term_options;
char *input_file;
int fd_input_file;
int hard_flow_control;
int soft_flow_control;
int read_only;
port = serial_port;
speed = B115200;
input_file
Re: RFC: linuxbios table fix
"Ronald G. Minnich" <[EMAIL PROTECTED]> writes:
> On Thu, 9 Dec 2004, Eric W. Biederman wrote:
>
> > I am still worried about ppc, and big endian architectures in general.
> > But I don't think we currently have any users there.
>
> we do. I think I'd like to hear Greg Watson's take on this as he is
> working with the PPC 970 guys and this will impact him.
Ron we have users of the LinxuBIOS table on PPC? It was my impression that we
did not.
I would be happy to hear what Greg has to say. If nothing uses this entry
I will be happy to change this.Otherwise we need to know what the test
program below reports on ppc.
If I can modify the definition to an equivalent one without breaking anything
that is my intention. We have just enough users on x86 that anything else
involves pain.
cat > test.c << EOF
#include
#include
struct lb_memory_range {
uint64_t start;
uint64_t size;
uint32_t type;
};
int main(int argc, char **argv)
{
printf("sizeof(lb_memory_range): %d\n", sizeof(struct lb_memory_range));
return 0;
}
EOF
gcc -o ./test ./test.c
./test
Eric
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
RFC: linuxbios table fix
Stefan I believe I have a better fix for the LinuxBIOS table
bug then __attribute__((packed)).
How does this look?
I am still worried about ppc, and big endian architectures in general.
But I don't think we currently have any users there.
I don't know what is the best long term strategy for handling 64bit
numbers but for this instance where we need a better definition for
the current structure simply using a structure with 2 32bit ints
looks like a sane way to go.
Eric
--- checkin/freebios2/src/include/boot/linuxbios_tables.h Tue Apr 22
13:01:45 2003
+++ linuxbios/freebios2/src/include/boot/linuxbios_tables.h Thu Dec 9
16:55:18 2004
@@ -57,14 +57,17 @@
#define LB_TAG_MEMORY 0x0001
+struct lb_uint64 {
+ uint32_t lo;
+ uint32_t hi;
+};
struct lb_memory_range {
- uint64_t start;
- uint64_t size;
+ struct lb_uint64 start;
+ struct lb_uint64 size;
uint32_t type;
#define LB_MEM_RAM 1 /* Memory anyone can use */
#define LB_MEM_RESERVED 2 /* Don't use this memory region */
#define LB_MEM_TABLE 16/* Ram configuration tables are kept in */
-
};
struct lb_memory {
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: K8 D0 support
"Yinghai Lu" <[EMAIL PROTECTED]> writes: > The D0 is released last week. And Normal BIOS support it already. > > Thanks for your great job in raminit.c of K8 and others, and I add several > lines to reflect the new mapping of memory bank. Cool. I am confused about what the current situation is. All I know for certain is that AMD has not updated their public documentation yet. So it does not appear as if these processors have been released to the public. Long term I wish we had a better way to handle development before the official product launch. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: K8 D0 support
YhLu <[EMAIL PROTECTED]> writes: > Opteron Rev D0 support done. > > So I need to wait for AMD put the updated Bios porting guide including > Opteron Rev D0 info. Only after that, I can commit the patch? > Or ask the AMD to review the code? Essentially. It all depends on your relationship. But as a general rule if you have knowledge under an NDA that is not public knowledge it is impolite to publish it with out the vendors approval. This is courtesy, and in the case of AMD not a large imposition, as we know the information will be publicly available in time. Having the work done sooner and published would not hurt my feelings though. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: K8 D0 support
YhLu <[EMAIL PROTECTED]> writes: > Eric, > > Are you working on Opteron D0 support? There are some memory initialization > changes to support D0... It is on the near term TODO list, as are way to many other things. I need to make certain I have some so I can test with them. My impression the biggest change was the E0 stepping processors. In any event until the information goes into the public datasheet I can't publish anything. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: k8 cpu rev
YhLu <[EMAIL PROTECTED]> writes:
> northbridge/amd/amdk8/cpu_rev.c
>
> static int is_cpu_pre_c0(void)
> {
> return (cpuid_eax(1) & 0xffef) < 0x0f48;
> }
>
> Why need to and 0xffef?
Look at the various cpuid values that happen to be c0 stepping
processors.
Eric
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Allocating Resource for Legacy VGA Buffer
Li-Ta Lo <[EMAIL PROTECTED]> writes:
> Eric,
>
> I tried to allocate a MEM resource for legacy VGA framebuffer (0xA -
> 0xB) on AMDK8 NB Fun 1. I find a new mem_pair and assigned base
> and size of the resource as the code show in the bottom. But at the run
> time the resrouce allocation code still try to allocate that resource
> to 0xA to 0x002ff. Why it does not care about the
> resource->size field nor the FIXED flag ?
The resource allocator should and it does in other cases.
Hmm. You don't even allocate this resource in read_resources
so the resource allocator might should not even see it.
The IORESOURCE_PREFETCH is not correct for that area though.
Setting up write-combining MSRs would be a very bad thing
to have happen. Which is what IORESOURCE_PREFETCH implies is
legal.
Eric
> static void amdk8_create_vga_resource(device_t dev, unsigned nodeid)
> {
> struct resource *resource;
> unsigned link;
> for (link = 0; link < dev->links; link++) {
> if (dev->link[link].bridge_ctrl & PCI_BRIDGE_CTL_VGA) {
> printk_info("%s: bridge on link %d has VGA device\n",
> dev_path(dev), link);
> printk_info("creating MEM pair for VGA memory\n");
> /* Initialize the io space constraints on the current
> bus */
>
> resource = amdk8_find_mempair(dev, nodeid, link);
> printk_info("MEM pair register %x\n", resource->index -
> 0x100);
>
> resource->base = 0xa;
> resource->size = 0x2;
> resource->gran = 16;
> resource->align = 16;
> resource->flags = IORESOURCE_PREFETCH | IORESOURCE_MEM |
>
> IORESOURCE_FIXED | IORESOURCE_ASSIGNED;
> }
> }
> }
> static void amdk8_set_resources(device_t dev)
> {
> unsigned nodeid, link;
> int i;
>
> /* Find the nodeid */
> nodeid = amdk8_nodeid(dev);
>
> amdk8_create_vga_resource(dev, nodeid);
>
> /* Set each resource we have found */
> for (i = 0; i < dev->resources; i++) {
> amdk8_set_resource(dev, &dev->resource[i], nodeid);
> }
>
> for(link = 0; link < dev->links; link++) {
> struct bus *bus;
> bus = &dev->link[link];
> if (bus->children) {
> assign_resources(bus);
> }
> }
> }
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Substractive Resource
Li-Ta Lo <[EMAIL PROTECTED]> writes: > Eric, > > You explained substractive decoding to me long time ago but I really > forgot what it is. Could you tell me again ? Hoe do you determine if > some resource of some device is substractive ? Form the data sheet ? A subtractive bridge resource is a bridge resource that picks up the unclaimed transactions and forwards them on. In networking the equivalent concept the default route. A subtractive resource is what picks up all of the traffic on a bus that does not have a specific route to somewhere else. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: print_smbus_regs_all
YhLu <[EMAIL PROTECTED]> writes: > I add some code to debug_device to dump smbus for S4882. > > Please let me know if you need me to commit it. I don't know about need but I think it could be handy to have. Especially as we don't have many users of i2c code in the tree at the present time. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: error disclosure
Stefan Reinauer <[EMAIL PROTECTED]> writes: > Hi there, > > the error disclosure of the config tool is a little bit mystic. > Building the sandpoint configuration says the following: > This looks like an error in the config tool, while it is a mistake in the > config file. Is there any easy way to point the user/developer to the > place in the config file that is wrong (rather than printing a python > traceback)? This could make it a lot easier for newbies to create fresh > linuxbios ports to motherboards whose hardware is basically already > supported and it could safe the regulars quite some time comparing > config files between the ports... Last I looked a lot of the problem is design issues with the python parser generator the code is using. It does not do a very good job at remember making it possible to print good error messages. The case you mention does not look like the typical failure there so it may allow for a simple fix. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: strange prink_debug output with dev_path
YhLu <[EMAIL PROTECTED]> writes:
> What is the difference between
> printk_debug("smbus: %s[%d]->", dev_path(dev->bus->dev),
> dev->bus->link );
> printk_debug("%s", dev_path(dev));
>
> and
>
> printk_debug("smbus: %s[%d]->%s", dev_path(dev->bus->dev),
> dev->bus->link , dev_path(dev));
>
> the first print
> smbus: PCI: 01:01.1[0]->I2C: 50
>
> the second one print
> smbus: PCI: 01:01.1[0]-> PCI: 01:01.1
dev_path returns the address of a statically allocated buffer
that it puts the path in. That address is always the same.
So multiple calls to dev_path before printing the path are a
problem.
I had a hard time balancing convenience and safety when
implementing this.
If we need to fix this likely there are 2 possibilities.
1) Pass dev_path the address of a buffer, to write into.
2) Update printk to have a special format flag that
performs the actions of dev_path.
Except for being a gotcha to watch out for I think we are ok.
Eric
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: get_pbus
YhLu <[EMAIL PROTECTED]> writes: > You mean to access extra reg space (4096 bytes) for PCI-E device? > > We don't need to touch that extra space in LinuxBIOS. So far. The question is how long will that last. What firmware has to do especially with onboard hardware never follows the rules for ordinary hardware. Especially when bug workarounds are involved. > Under LinuxBIOS + kernel + IB driver, the IB adapter works well with S289x. > need to create one entry in mptable for the device. Otherwise it can not get > INT. > > Currently I can not make MSI workKernel 2.6. I have not had a chance to play with that. I saw something on the openib list a while ago about MSI with a mellanox IB card not having a complete firmware implementation or something like that. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: get_pbus
YhLu <[EMAIL PROTECTED]> writes: > Every pci_read_config and pci_write_config need to findout top parenent bus > to get bus ops. (get_pbus). > > It looks weird Yes, it does look weird. But it comes very close to modeling reality. You have to find the top of the pci bus to perform reads and writes. The apparent inefficiency does not thrill me but the tree is not usually very deep so in practice get_pbus only needs to execute one or two look iterations. It allows any bus that has specific methods for pci read/write to implement them, and any bus that does not need not care. If I read the documentation correctly one of the powerpc northbridges the cpc710 I think actually has 2 separate pci domains with a different base register to access each of the different pci domains. So having pci access methods that vary by pci domain is a case that needs to be handled, and this code allows it. In addition we need something similar to handle the extended pci accesses which PCI express allows. I still need to find out how the hypertransport to PCI-Express bridges handle that case. Do the decode the reserved HT memory region that is just below 1TB or do they do something else? Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Stuck. Compile error with a clean tree.
"Ronald G. Minnich" <[EMAIL PROTECTED]> writes: > Adam, I just committed my changes and the adl855pc builds with same error. > > The problem is simple: the debug levels are so high that our code is > getting too big. > > I will try to fix this monday. Looks like recent changes made linuxbios > grow a bit. Can you bump up ROM_IMAGE_SIZE by a small amount to avoid this? I wish I knew a way to implement a grow down segment in LD. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Alignment of LinuxBIOS table structures
"Ronald G. Minnich" <[EMAIL PROTECTED]> writes: > On Fri, 26 Nov 2004, Stefan Reinauer wrote: > I think the big problem is the use of binary data structures. It shows how > smart the Open Boot guys were to use strings, and they figured this out 16 > years ago! open boot provides a single function you can call. And as I recall everything is done in terms of forth words. 32 bit or 64bit. My memory may be faulty but that does not sound like a string based interface. > I think we should look at having linuxbios create strings of data for > tables, not binary tables. Long term, the binary tables are going to cause > us trouble, as they have already: having to use non-portable compiler > options/attributes is a recipe for disaster. You only parse them once to > turn them into internal binary data structures in the OS; performance is > not an issue here. Performance is not an issue code size can be. Check out ACPI for the nasty version of needing too much parsing to get the data you need. > In Plan 9, the parameters are passed in as keyword-value pairs, viz: > totalmem=0x10 Which is not bad. But the implementation is totally naive. > This is easy to generate, and both Linux and Plan 9 and other OSes have > more than enough functions in the kernel already to parse these. This > removes special needs for alignment, packing, and so on. What of etherboot, what of mkelfImage, and other simple utilities. > If you want you can generate Forth tables, which are also simple, but in > the end, I think we need to avoid the problems of binary tables. > My real preference is for S-expressions, as they are totally > character-oriented tables that can still provide structure such as trees > and tables, but I am not sure people will like S-expressions. If we really want to avoid problems what we need is a table definition checker that looks at the definitions of table entries and checks to see if they are portable and safe. I don't care if they are binary or string based, you can get into problems either way. If someone wants to do a proof of concept of a string based implementation I am willing to consider ideas. Be warned though that strings scare me because everyone thinks they are safe, and easy. When in fact they have the same essential complexity as binary data structures with simply a different set of limitations, and fewer tools provided in the compiler to make certain you don't mess up. In addition there are cases that string based tables handle very poorly such as passing fonts. With the current structure is there is information that is best passed in a string form we can define one or more table entries that allows us to implement that. The next big step is to export the device tree via the linuxbios table to the outside world. In most cases the this decomposes nicely into a hierarchical set of devices. But with interrupts and a few of their kin it starts getting hard to describe hardware as a tree, making a graph necessary to handle the general case. Fundamentally changing things is just something to think about for now. The current problem while very bad is still mild enough the current table definitions can be patched. It is unfortunate that this happened with the most widely used table entry. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Alignment of LinuxBIOS table structures
Stefan Reinauer <[EMAIL PROTECTED]> writes:
> Hi,
>
> I got an interesting report today from a customer having problems
> with building LinuxBIOS and the payload with different compilers
>
> The problem is that different compilers handle structure alignment
> differently, ie 2.95.x and 3.x have fundamental differences here:
I agree that there is a problem with the definition of this structure.
Everything in the table remains 32bit aligned so we are clear there.
For 64bit data types the alignment is much less clear, and struct
lb_memory_range is a bit of a problem in that it does not have a 32bit
type as padding.
To see what the problem actually amounts to I walked through my
compiler collection with a simple test to see what sizeof reported
for lb_memory_range, (without adding the packed attribute).
> #include
> #include "linuxbios_tables.h"
>
>
> int main(int argc, char **argv)
> {
> printf("sizeof(lb_memory_range): %d\n", sizeof(struct lb_memory_range));
> return 0;
> }
On 32bit x86 I tested with:
gcc-2.7.2
gcc-2.95
gcc-3.0
gcc-3.2
gcc-3.3
gcc-3.4
And in each instance the result was 20.
On 64bit x86 I with I tested with
gcc-3.2
gcc-3.3
gcc-3.4
And the result was 24.
I also managed to test with gcc-3.3 with -m32 and the size was still
20.
So from what I can see with 32bit x86 code we are consistent, and we
do not have compiler version dependencies. So the bad definition
is consistent.
Moving forward we need to remove this table entry and
replace it with a table entry that is properly defined.
Utilities like mkelfImage can continue to support the old definition,
but it should be deprecated there.
> Since this is a table that is passed in memory, we do want it to be
> exactly as it is defined, with no extra padding of any kind to make it
> reliable information. So I consider adding __attribute__ ((packed))
> a good solution for the problem.
It is a good pragmatic solution, but actually needing __attribute__ ((packed))
is an issue. As Ron has pointed out, not all compilers support it.
And having a definition that varies between 32bit and 64bit is a
problem anyway.
> If I get no good reasons against adding this, I will check it in
> later
What I want to do is add a replacement for struct lb_memory_range that
looks like:
struct lb_memory_range2 {
uint64_t start;
uint64_t size;
uint32_t type;
#define LB_MEM_RAM 1 /* Memory anyone can use */
#define LB_MEM_RESERVED 2 /* Don't use this memory region */
#define LB_MEM_TABLE 16 /* Ram configuration tables are kept in */
uint32_t reserved;
};
At the same time I need to define an LB_TAB_ALIGN that I can insert
when data is only 32bit aligned and I need 64bit or better alignment
in the table. 64bit alignment is unlikely to cost much at this
point but better safe than sorry :) And it preserves the property
that the data in the table can just be used.
Eric
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Link and Links again
Li-Ta Lo <[EMAIL PROTECTED]> writes: > Eric, > > >From my understanding, the device.link for bridge device does not > include the up stream bus. Correct it only includes the device itself. device.link.dev == device > The up stream bus is the device.bus field. Correct. > So for 'normal' PCI bridges, with one up stream and one down stream > buses, its device.links = 1. Am I correct ? Yes. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Invalidating TLB, cache
Li-Ta Lo <[EMAIL PROTECTED]> writes: > Eric, > > What was the conclusion of invalidating the cache and TLB ? > If found that > > xorl%eax, %eax > movl%eax, %cr3/* Invalidate TLB*/ > > still exists in the current CVS. Cache invalidates are actively harmful, as they can loose data that has not been written from the cache and they take seconds on an Opteron to execute. Currently TLB invalidates don't have any negative side effects and seem harmless. Since TLB do not cache writes I can't think of a case where they would cause incorrect behavior.If they start running slow on some we can revisit the issue. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Apologies for ignored email...
I just discovered that the my local system administrators had applied a spam filter to my incoming mail that seems to have has a 2:1 false positive rate when identifying spam. Especially picking on email that was short to the point, and important or interesting. I think I have things under control, but I will have to wait until next week when everyone gets back work to tell for certain. So my apologies for not catching this sooner. It resulted in me ignore several messages I should have because I never received them. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: [Etherboot-users] Direct message to com2
YhLu <[EMAIL PROTECTED]> writes: > It seems that mkelfImage should get the com address from commandline. > > For example: > mkelfImage --command-line="ramdisk_size=65536 root=/dev/ram0 rw console=tty0 > console=ttyS1,115200n8" --kernel=linuxkernel/bzImage_2. > 6.9_k8.2 --ramdisk=rootfs/mydisk8_com2.gz > --output=elf/ram0_2.5_2.6.9_k8.2_mydisk8_com2.elf > > Then makeelfImage should use 0x2f8 instead of 0x3f8 in convert_params.c > according to ttyS1. Patches are welcome. What probably makes the most sense long term is to export the console device in the LinuxBIOS table so software running under LinuxBIOS can just lookup what the console device is supposed to be. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Compile error
"Adam Talbot" <[EMAIL PROTECTED]> writes: > Any ideas on this error? What is causing theis? > > /root/freebios2/src/mainboard/commell/lv-671/auto.c -o auto.inc > raminit.c:1369.39: > member channel1 not present It looks like you are trying to compile code that references a structure member you don't have. Typically I boards are setup with a struct memory controller that has channel0 and channel1 members. But that configuration is board specific. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Resource base 0x1xy for AMD K8 northbridge.
Li-Ta Lo <[EMAIL PROTECTED]> writes: > Eric, > > Why you add 0x100 to the resource base register for AMDK8 Function 1, in > find_mem|io_pair()? As a general convention I name the resources as the address in the configuration space. The k8 distributes functionality across it's pci configuration space, which makes it atypical in a number of respects. In this case the bridges are all in function 0, but the bars for those bridges are actually in function 1. Since I am reporting those resources on function 0 I add 0x100 to indicate that those resources are really in function 1.Which is simple and keeps me safe from most conflicts. It looks like I am also playing with the low address bits to distinguish which link I am actually dealing with. Does that make sense? The resource->index is arbitrary but I try to keep to a convention where looking at it you can tell which configuration register you are dealing with. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: 4G 4 Rank memory module
YhLu <[EMAIL PROTECTED]> writes:
> It can treat 4G as 2G modules, if I comment out physical bank check. (!=2
> get out).
Ah so it is the explicit check for <= 2 Ranks that is the immediate problem :)
This case is peculiar enough I did not add support because I could not test it.
Does your board have 4 chip selects running to the dimm socket?
If not you cannot support 4 rank dimms.
What does your struct mem_controller look like?
One partial solution would be to simply repeat the spd address
twice in the channel structure, and comment out the maximum bank check.
Of course that would fail for non quad rank dimms.
So I am not quite certain what the complete solution is. YhLu once you describe
how your dimm sockets are wired we can figure something out.
static const struct mem_controller cpu[] = {
{
.node_id = 0,
.f0 = PCI_DEV(0, 0x18, 0),
.f1 = PCI_DEV(0, 0x18, 1),
.f2 = PCI_DEV(0, 0x18, 2),
.f3 = PCI_DEV(0, 0x18, 3),
.channel0 = { (0xa<<3)|0, (0xa<<3)|2, 0, 0 },
.channel1 = { (0xa<<3)|1, (0xa<<3)|3, 0, 0 },
},
Eric
___
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: ppc targets
Just a progress update before I go to bed. I have the totalimpact/briq building now. There are a couple of things that are not quite right but nothing architectural. Looking at where the code is I should be able to get the sandpointx3+pmc/altimus/mpc7410 building. Since there is only one pmc supported things look much simpler :) Beyond that a lot of my confusion has been looking at code and expecting it to work, or to handle the general case when in fact it doesn't. As I settle for merely fixing the code so it continues to do what it did before, I can successfully make a lot of progress. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Root_complex in northbridge.c
Li-Ta Lo <[EMAIL PROTECTED]> writes: > Eric, > > Is there any reason that you put the root_complex driver in > amdk8/northbridge.c instead of amdk8/root_complex/root_complex.c? Because the code is very strongly intertwined. Logical things the pieces are separate but in practice they are not. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: Root_complex in northbridge.c
Li-Ta Lo <[EMAIL PROTECTED]> writes: > Eric, > > Is there any reason that you put the root_complex driver in > amdk8/northbridge.c instead of amdk8/root_complex/root_complex.c? Because the is very strongly intertwined. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: ppc targets
Ok I am starting to dig into these and figure out what needs to happen to get the ppc targets working again. The hardest case currently appears to be the sandpointx3 with pmc processor modules, so I will get to it last. The whole northboard/southboard thing is interesting. But something we need to handle. I think I have heard of the same thing with a few hypertransport based systems as well.Which board is the bootrom that the systems starts executing with on. The few schematics I have looked up so far have a bootrom on the sandpoint and the MPCxxx pmc module. The other datapoint I need to track down is are there other boards the processor pmc modules can plug into. Or there tighter coupling than that. I have not been able to track down documentation on cpu the embeddedplanet epc405 is using. In fact I'm not even certain which cpu it is using which is part of the problem. Does that board use a northbridge at all or is the memory controller and pci bus built into the cpu? But it looks like I have tracked down enough information on the totalipact/briq, to understand what is going on. Or at least well enough that I can get something that will build and will be close to working built. So I am starting there despite the fact it does not look like that port was ever quite finished, or at least it was never built to handle the general case as it has a hardcoded memory size. One of the cases the northboard/southboard thing brings up is that we don't have good infrastructure for handling plugin boards with lots of chips that need special handling. If we can identify them we can do something, the code is just not very general yet. It is likely we want to be able to build a static device tree that describes a pluging board that we can just graft to the main tree when we detect that board. It is something to think about anyway. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: pci_operations for amd8111_ac97.c
Li-Ta Lo <[EMAIL PROTECTED]> writes: > Eric, > > The lpci_set_subsystem() in amd8111_ac97.c is exactly the same as the > default pci_dev_set_subsystem(), why do you define it instead of using > the default one? Probably because I didn't realize it. It seems like every device has a different function. It may also have been I was wondering if it was worth exporting the default method. The default is simply a good guess, that can't hurt if it's wrong. > BTW, why can't the set_subsystem() method be set at runtime ? All of the methods are set at runtime. I just have the pci specific methods is a sub-table. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: pnp_enable_devices
YhLu <[EMAIL PROTECTED]> writes: > pnp_enable_devices(dev, &pnp_ops,) > > I think the second parameter is not necessary and can be removed. Sounds right. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: recent changes
Greg Watson <[EMAIL PROTECTED]> writes: > We now seem to have a chip keyword, in addition to config, device, driver and > object keywords. We have a device_operations structure, a cpu_device_id > structure and a cpu_driver structure as well as a pci_driver structure. The > cpu > tree has been reorganized to include vendor directories as well as > architecture > directories. We now seem to have a drivers directory tree. All of the northbridge/southbridge/superio keywords were condensed into a single keyword chip. A simplification. device specifies a logical subdevice of a chip. chip specifies where the code lives, generally this is a subdirectory with code for a specific ASIC. device describes a logical device within chip, and an entry in the device tree. And of course the device tree shows up in static.c like it has done for a long while. As for the cpus on x86 they were reorganized so that as much as possible they work like any other device. Since in a lot of cases it is possible to plug in multiple cpus into the same motherboard. The design is for per architecture code to figure out which cpu it is running on and then setup the methods appropriately. driver and object are essentially the same keyword. The difference is that if you are marked object you are only linked in if there is an external reference to you from elsewhere, this is good for library functions. Something marked driver is always linked in. > Can someone please provide the following information: > > 1. What does each keyword actually do now? > > 2. How do the keywords relate to the data structures? > > 3. What files are now auto generated, and how is everything linked together? > > 4. What keywords/data structures are actually needed, and by which devices? > > 5. How/where are the data structures used? > > 6. What is the rationale behind the reorganization of the cpu tree, and how is > it supposed to work? > > 7. What is the purpose of the drivers tree, how do drivers differ from > devices, > and why is the console not included? There is no drivers tree, just the device tree. The code does like it has done for a long time in v2. Some motherboard specific code runs, and then we enter hardwaremain. In hardwaremain we look at the specified set of devices, and we look at the code for those devices and we see if we can find some more. And then we setup the devices. There has been an effort to remove special cases. We are currently left with the timer subsystem, the console, and hard_reset. All of which are optional. I don't see a way for those things to be both useful and not be a special case. > The configuration process now seems so complicated that I can't see how we > could expect someone to port to a new board without some basic description of > how everything is supposed to work. Which is reasonable. Working examples may help as well. > I have a major vendor interested in doing > this, but at the moment I can't offer them any help. The big change from v1 to v2 is that in v1 everything was handled top down, while the code is structured in v2 to encourage building the code bottom up which tends to be more reusable. So in v2 the basic model is: We detect that a piece of hardware exists. We find an ID for that hardware. With that ID we find a driver for that hardware. With that driver we configure the resources for that device. After the resources are configured we enabled them. With everything setup we make a last pass and do device specific initialization. If a device cannot be discovered by the generic code it needs to be present in the static device tree. And if a device is always present on the motherboard it is recommend that it be present in the static tree. The last big round of changes was largely simplifications to expose the primary model on how things work. We generate a device tree directly from Config.lb without an intermediate chip tree. cpus were pushed into the device tree. All of this was done with an eye towards the fact that things were getting too complex. Once the dust clears the infrastructure should be fairly stable from here on out. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: coherent_ht.c,1.29,1.30
Stefan Reinauer <[EMAIL PROTECTED]> writes: > * Eric W. Biederman <[EMAIL PROTECTED]> [041115 17:42]: > > However there are 2 significant checks we can perform. > > - Did the original version compile? > > - Does this work on the tyan/s2850 > > does the s2850 use an athlon64? Iirc the problem was that the athlon64 > has less ht links.. > > > So unless YhLu has problems on the s2850 or we can dig something up in > > the mailing list archives I am fairly certain that this change is ok. > > The best way to test this is testing on a solo system.. If somebody has > one... Which I dont. Otherwise I suggest we mark the solo build broken > until someone can verify this.. On that same note we are getting close to the point where making a stable 2.0 and freezing the API (or at least making no changes that are not backwards compatible) is getting close. We still have irqs and the ppc to sort out before then. With that in mind we probably want to introduce a category of TESTED motherboards. The solo is certainly is not worth dropping out of regression tests because it still cleanly. But since no one has tested it in a long time marking not marking it TESTED is likely a good thing. Anyway something to think about. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: ram_check
"Ronald G. Minnich" <[EMAIL PROTECTED]> writes: > On Mon, 15 Nov 2004, Gin wrote: > > > I have a question with the ram. Don't know if anyone has heard the same > > problem before. I ran the ram_check procedure and it reports that there > > are always 4 bytes out of every 64 bytes that reads zero. I think that's > > why I can run the code in the ram but it gets reset in the in different > > places. > > it just means your ram is still programmed incorrectly. It sounds like there was a conversion bug when converting the memory initialization from assembly to C. The v1 memory initialization for the e7501 should be solid. The v2 port was done primarily as a proof of concept so it would not surprise me if a couple of small bugs were introduced. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
Re: coherent_ht.c,1.29,1.30
Stefan Reinauer <[EMAIL PROTECTED]> writes: > * Eric W. Biederman <[EMAIL PROTECTED]> [041115 17:42]: > > However there are 2 significant checks we can perform. > > - Did the original version compile? > > - Does this work on the tyan/s2850 > > does the s2850 use an athlon64? Iirc the problem was that the athlon64 > has less ht links.. I am pretty certain that case was limited to the code that was living in misc_control.c. For which this problem has been resolved. > > So unless YhLu has problems on the s2850 or we can dig something up in > > the mailing list archives I am fairly certain that this change is ok. > > The best way to test this is testing on a solo system.. If somebody has > one... Which I dont. Otherwise I suggest we mark the solo build broken > until someone can verify this.. Actually looking at this the code is exactly what we have in misc_control.c Which has been tested on an Athlon64 so I'm not concerned. Eric ___ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
