From calvinkendall at shaw.ca Wed Jun 1 07:12:30 2005 From: calvinkendall at shaw.ca (Calvin Kendall) Date: Wed, 01 Jun 2005 00:12:30 -0500 Subject: [LinuxBIOS] Might a Thunder K8WE Support LinuxBios too? Message-ID: <000001c56669$03491e90$6600a8c0@calvinhyb5598z> Being a very interested but very raw newbie to the whole "world of" LinuxBIOS, please excuse me. The Tyan Thunder K8W (S2885) is listed at linuxbios.org as a supported motherboard. Although not listed itself, would the new ("New" as per the Tyan website.) K8WE (S2895) also be a supported motherboard? The reason I venture to speculate is that the S2895 appears to be an "updated" version of the similar S2885. Thank you for your precious time and valuable undivided attention. Later, Calvin E. Kendall, S.F.O. -------------- next part -------------- An HTML attachment was scrubbed... URL: From YhLu at tyan.com Wed Jun 1 18:39:00 2005 From: YhLu at tyan.com (YhLu) Date: Wed, 1 Jun 2005 09:39:00 -0700 Subject: [LinuxBIOS] RE: Might a Thunder K8WE Support LinuxBios too? Message-ID: <3174569B9743D511922F00A0C94314230A40382D@TYANWEB> It's already supported, and the code is in the public tree two weeks ago. YH _____ From: Calvin Kendall [mailto:calvinkendall at shaw.ca] Sent: Tuesday, May 31, 2005 10:13 PM To: YhLu Cc: linuxbios at openbios.org Subject: Might a Thunder K8WE Support LinuxBios too? Being a very interested but very raw newbie to the whole "world of" LinuxBIOS, please excuse me. The Tyan Thunder K8W (S2885) is listed at linuxbios.org as a supported motherboard. Although not listed itself, would the new ("New" as per the Tyan website.) K8WE (S2895) also be a supported motherboard? The reason I venture to speculate is that the S2895 appears to be an "updated" version of the similar S2885. Thank you for your precious time and valuable undivided attention. Later, Calvin E. Kendall, S.F.O. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hugo.mercier at laposte.net Wed Jun 1 19:33:55 2005 From: hugo.mercier at laposte.net (Hugo MERCIER) Date: Wed, 01 Jun 2005 19:33:55 +0200 Subject: [LinuxBIOS] Pm49FL002 Flash Message-ID: <1117647235.2424.14.camel@localhost> Hi, I'm new to this list and to the project. I'd like to add support for the Asus A7V600 motherboard (VT8237 and KT600 based). I don't have many time, I'am not very familiar with chipset low level programming, but ... I found LinuxBios is an interesting project ;) Until now, I spend my time gathering informations (manuals and datasheet - with a request to VIA) and looking to the linuxbios code. I just wanted to add flash support to the flash_rom util to start something. My motherboard is using the Pm49FL002 flash memory. It's the same as the Pm49FL004 with 2Mb instead of 4Mb. With respect to the Pm49FL002 datasheet, it seems to act as Jedec. So, I added this to flash_rom.c: {"Pm49FL002", PMC_ID, PMC_49FL002, NULL, 256, 16 * 1024, probe_jedec, erase_chip_jedec, NULL,NULL}, and to flash_rom.h: #define PMC_49FL002 0x6D /* PMC 49FL002 device code */ I just wanted to test the probing (No erasing or programming yet). And ... it fails. flash_rom doesn't find anything : the reported IDs bytes are the same as those reported without the probing memory cycles (0x555,0xAAA, ...) So ... what am I doing wrong ? Do I have to set some bit in the Northbridge registers ? From hansolofalcon at worldnet.att.net Thu Jun 2 01:54:41 2005 From: hansolofalcon at worldnet.att.net (Gregg C Levine) Date: Wed, 1 Jun 2005 19:54:41 -0400 Subject: [LinuxBIOS] Questions regarding the TV IN functions for one of the boards that were used Message-ID: <000001c56705$4ae8df00$6401a8c0@who7> Hello from Gregg C Levine I've got a new project being created. It concerns a system that uses a rather specialized, and unfortunately not open sourced protocol for talking to external hardware. However the software that does speak to the device is. It's the One-Wire protocol, and the OWFS software, http://owfs.sf.net Basically the hardware would be communicating with other items that would eventually create a video signal. For development purposes I've chosen to, ah, do things here, and I'd be using a specific tuner card, name on request. But I'd eventually like to move to a Linux BIOS solution. Here's an e-mail message that Google found for me that concerns itself with one of the EPIA family boards: ----- Embedded Linux Forum ---------------------------------------------------------------------- ---------- Original Topic: ---------------------------------------------------------------------- ---------- Mini-PCI TV Tuners with hardware encoding Posted by tekmage (andrew at plumb.org) on 12-22-2004 09:29:33 What mini-pci TV Tuners have people had success using in Linux based systems? Follow-up questions would be what chipsets do they use (i.e. which device drivers are they compatible with) and from whom can I buy small quantities? I have plans for a Kontron X-board based system, and VIA's upcoming EPIA N board will also have a mini-pci slot, opening up options for a lot of people. Thanks! Andrew. ---- It came from a forum which lives somewhere on the Linux Devices site, or did, I do not know if the forum is still active. I do remember that one of the EPIA boards did support composite video out, but I do not recall which one, nor do I have access to my local archives. And Ron, if this is really not on topic for anything currently being discussed, even though I do plan on my board design becoming a Linux BIOS platform, I shall discontinue discussing it, with this message. ----- Gregg C Levine hansolofalcon at worldnet.att.net --- "Remember, the Force will be with you... Always." Obi-Wan Kenobi From YhLu at tyan.com Thu Jun 2 20:13:33 2005 From: YhLu at tyan.com (YhLu) Date: Thu, 2 Jun 2005 11:13:33 -0700 Subject: [LinuxBIOS] AMD dual core support and four rank dimm support Message-ID: <3174569B9743D511922F00A0C94314230A403956@TYANWEB> Just commited. Hope it is not broken. AMD D0/E0 Opteron new mem mapping support AMD E Opteron dual core support AMD E Opteron mem hole support AMD K8 Four Ranks DIMM support YH From YhLu at tyan.com Thu Jun 2 20:22:34 2005 From: YhLu at tyan.com (YhLu) Date: Thu, 2 Jun 2005 11:22:34 -0700 Subject: [LinuxBIOS] RE: AMD dual core support and four rank dimm support Message-ID: <3174569B9743D511922F00A0C94314230A403958@TYANWEB> Note: Some MB doesn't support dual core, So if you enable it, you could blow off your VRM or MB... So you need to check with your HW vendor to see if HW is dual core ready. It seems that list linuxbios at openbios.org is broken, Stefan, can you check it? YH > -----Original Message----- > From: YhLu > Sent: Thursday, June 02, 2005 11:12 AM > To: 'Ronald G. Minnich'; 'ebiederman at lnxi.com'; 'Stefan > Reinauer'; 'Li-Ta Lo' > Cc: 'linuxbios at openbios.org' > Subject: AMD dual core support and four rank dimm support > > Just commited. > > Hope it is not broken. > > AMD D0/E0 Opteron new mem mapping support AMD E Opteron dual > core support AMD E Opteron mem hole support AMD K8 Four Ranks > DIMM support > > > YH > From hansolofalcon at worldnet.att.net Fri Jun 3 02:28:46 2005 From: hansolofalcon at worldnet.att.net (Gregg C Levine) Date: Thu, 2 Jun 2005 20:28:46 -0400 Subject: [LinuxBIOS] Questions regarding the TV IN functions for one of the boards that were used Message-ID: <001a01c567d3$34d40e00$6401a8c0@who7> (Resending message. I think the original got lost someplace. Apologies to all if it did get there.) Hello from Gregg C Levine I've got a new project being created. It concerns a system that uses a rather specialized, and unfortunately not open sourced protocol for talking to external hardware. However the software that does speak to the device is. It's the One-Wire protocol, and the OWFS software, http://owfs.sf.net Basically the hardware would be communicating with other items that would eventually create a video signal. For development purposes I've chosen to, ah, do things here, and I'd be using a specific tuner card, name on request. But I'd eventually like to move to a Linux BIOS solution. Here's an e-mail message that Google found for me that concerns itself with one of the EPIA family boards: ----- Embedded Linux Forum ---------------------------------------------------------------------- ---------- Original Topic: ---------------------------------------------------------------------- ---------- Mini-PCI TV Tuners with hardware encoding Posted by tekmage (andrew at plumb.org) on 12-22-2004 09:29:33 What mini-pci TV Tuners have people had success using in Linux based systems? Follow-up questions would be what chipsets do they use (i.e. which device drivers are they compatible with) and from whom can I buy small quantities? I have plans for a Kontron X-board based system, and VIA's upcoming EPIA N board will also have a mini-pci slot, opening up options for a lot of people. Thanks! Andrew. ---- It came from a forum which lives somewhere on the Linux Devices site, or did, I do not know if the forum is still active. I do remember that one of the EPIA boards did support composite video out, but I do not recall which one, nor do I have access to my local archives. And Ron, if this is really not on topic for anything currently being discussed, even though I do plan on my board design becoming a Linux BIOS platform, I shall discontinue discussing it, with this message. ----- Gregg C Levine hansolofalcon at worldnet.att.net --- "Remember, the Force will be with you... Always." Obi-Wan Kenobi From rminnich at lanl.gov Fri Jun 3 06:21:55 2005 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Thu, 2 Jun 2005 22:21:55 -0600 (MDT) Subject: [LinuxBIOS] RE: AMD dual core support and four rank dimm support In-Reply-To: <3174569B9743D511922F00A0C94314230A403958@TYANWEB> References: <3174569B9743D511922F00A0C94314230A403958@TYANWEB> Message-ID: On Thu, 2 Jun 2005, YhLu wrote: > It seems that list linuxbios at openbios.org is broken, Stefan, can you check > it? I am hearing similar complaints. Anything busted? ron From rminnich at lanl.gov Fri Jun 3 06:47:20 2005 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Thu, 2 Jun 2005 22:47:20 -0600 (MDT) Subject: [LinuxBIOS] testing Message-ID: ron From ebiederman at lnxi.com Fri Jun 3 07:18:03 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: 02 Jun 2005 23:18:03 -0600 Subject: [BULK] [LinuxBIOS] How is 'arch' working for you? In-Reply-To: References: Message-ID: "Ronald G. Minnich" writes: > Are folks getting along with 'arch' ok? So far so good. I should be finish the merge I started long ago in the next week or which will make a very good test... After that it should be much easier to keep in sync. > Are you able to download as needed? No problem yet... > How does it compare to CVS? It is distributed and has real branches how can that be bad :) > Is there a different SCM you would like to see used? We should probably keep an eye on git as whatever is the long term winner with revision control is likely to come out that camp. If nothing else we should begin to see interoperability between version control systems. But that is after the dust has settled. Eric From ebiederman at lnxi.com Fri Jun 3 07:19:44 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: 02 Jun 2005 23:19:44 -0600 Subject: [LinuxBIOS] FYI: AMD support for cache as ram. Message-ID: Check out the new BIOS and Kernel Developers Guide. Eric From stepan at openbios.org Fri Jun 3 10:40:47 2005 From: stepan at openbios.org (Stefan Reinauer) Date: Fri, 3 Jun 2005 10:40:47 +0200 Subject: [LinuxBIOS] test Message-ID: <20050603084047.GA8284@openbios.org> just a test. From rminnich at lanl.gov Fri Jun 3 16:49:54 2005 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Fri, 3 Jun 2005 08:49:54 -0600 (MDT) Subject: [LinuxBIOS] Pm49FL002 Flash In-Reply-To: <1117647235.2424.14.camel@localhost> References: <1117647235.2424.14.camel@localhost> Message-ID: On Wed, 1 Jun 2005, Hugo MERCIER wrote: > I just wanted to test the probing (No erasing or programming yet). > And ... it fails. flash_rom doesn't find anything : the reported IDs > bytes are the same as those reported without the probing memory cycles > (0x555,0xAAA, ...) asus loves to put GPIO enables ont their boards to control flash writes. My guess is you are getting no write cycles to the flash part. This is pretty easy to probe for, find the GPIO registers and starting changing them one at a time, and see if at some point you have flash writes working. Some of them, when changed, may reset the board ... so be prepared for that. ron From bari at onelabs.com Fri Jun 3 17:26:47 2005 From: bari at onelabs.com (Bari Ari) Date: Fri, 03 Jun 2005 10:26:47 -0500 Subject: [LinuxBIOS] Pm49FL002 Flash In-Reply-To: <1117647235.2424.14.camel@localhost> References: <1117647235.2424.14.camel@localhost> Message-ID: <42A076B7.7000606@onelabs.com> Hugo MERCIER wrote: > Hi, > > I'm new to this list and to the project. I'd like to add support for > the Asus A7V600 motherboard (VT8237 and KT600 based). I don't have many > time, I'am not very familiar with chipset low level programming, but ... > I found LinuxBios is an interesting project ;) I've been working on VIA VT8237 support. Should be up soon. Lots of boards using the vt8237 now. -Bari From ollie at lanl.gov Fri Jun 3 17:33:17 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Fri, 03 Jun 2005 09:33:17 -0600 Subject: [LinuxBIOS] Pm49FL002 Flash In-Reply-To: References: <1117647235.2424.14.camel@localhost> Message-ID: <1117812797.19005.54.camel@exponential.lanl.gov> On Fri, 2005-06-03 at 08:49 -0600, Ronald G. Minnich wrote: > > On Wed, 1 Jun 2005, Hugo MERCIER wrote: > > > I just wanted to test the probing (No erasing or programming yet). > > And ... it fails. flash_rom doesn't find anything : the reported IDs > > bytes are the same as those reported without the probing memory cycles > > (0x555,0xAAA, ...) > > asus loves to put GPIO enables ont their boards to control flash writes. > My guess is you are getting no write cycles to the flash part. > > This is pretty easy to probe for, find the GPIO registers and starting > changing them one at a time, and see if at some point you have flash > writes working. Some of them, when changed, may reset the board ... so be > prepared for that. > I don't think we have flash_enable for the chipset. So writing command to the flash part has no effect. -- Li-Ta Lo Los Alamos National Lab From bari at onelabs.com Fri Jun 3 18:13:46 2005 From: bari at onelabs.com (Bari Ari) Date: Fri, 03 Jun 2005 11:13:46 -0500 Subject: [LinuxBIOS] Pm49FL002 Flash In-Reply-To: <1117812797.19005.54.camel@exponential.lanl.gov> References: <1117647235.2424.14.camel@localhost> <1117812797.19005.54.camel@exponential.lanl.gov> Message-ID: <42A081BA.8040202@onelabs.com> Li-Ta Lo wrote: > I don't think we have flash_enable for the chipset. So writing command > to the flash part has no effect. > I'm working on flash_enable for VT8237 as well as support for new the 16Mb LPC Flash. There are some issues with getting the vt8237 to unlock the block locking registers in FWH mode. -Bari From yinghailu at gmail.com Fri Jun 3 18:21:21 2005 From: yinghailu at gmail.com (yhlu) Date: Fri, 3 Jun 2005 09:21:21 -0700 Subject: [BULK] [LinuxBIOS] How is 'arch' working for you? In-Reply-To: References: Message-ID: <2ea3fae1050603092122827a8f@mail.gmail.com> On 02 Jun 2005 23:18:03 -0600, Eric W. Biederman wrote: > I should be finish the merge I started long ago in the next week > or which will make a very good test... > After that it should be much easier to keep in sync. Intel E7520 support code? YH From YhLu at tyan.com Fri Jun 3 18:30:39 2005 From: YhLu at tyan.com (YhLu) Date: Fri, 3 Jun 2005 09:30:39 -0700 Subject: [LinuxBIOS] Pm49FL002 Flash Message-ID: <3174569B9743D511922F00A0C94314230A403A40@TYANWEB> K8T890 with PCI-E should be more interesting... YH > -----Original Message----- > From: Hugo MERCIER [mailto:hugo.mercier at laposte.net] > Sent: Wednesday, June 01, 2005 10:34 AM > To: linuxbios at openbios.org > Subject: [LinuxBIOS] Pm49FL002 Flash > > Hi, > > I'm new to this list and to the project. I'd like to add > support for the Asus A7V600 motherboard (VT8237 and KT600 > based). I don't have many time, I'am not very familiar with > chipset low level programming, but ... > I found LinuxBios is an interesting project ;) > > Until now, I spend my time gathering informations (manuals > and datasheet - with a request to VIA) and looking to the > linuxbios code. > > I just wanted to add flash support to the flash_rom util to > start something. My motherboard is using the Pm49FL002 flash > memory. It's the same as the Pm49FL004 with 2Mb instead of 4Mb. > > With respect to the Pm49FL002 datasheet, it seems to act as > Jedec. So, I added this to flash_rom.c: > {"Pm49FL002", PMC_ID, PMC_49FL002, NULL, > 256, 16 * > 1024, > probe_jedec, erase_chip_jedec, NULL,NULL}, > and to flash_rom.h: > #define PMC_49FL002 0x6D /* PMC 49FL002 device code */ > > I just wanted to test the probing (No erasing or programming yet). > And ... it fails. flash_rom doesn't find anything : the > reported IDs bytes are the same as those reported without the > probing memory cycles (0x555,0xAAA, ...) > > So ... what am I doing wrong ? Do I have to set some bit in > the Northbridge registers ? > > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From bari at onelabs.com Fri Jun 3 18:45:12 2005 From: bari at onelabs.com (Bari Ari) Date: Fri, 03 Jun 2005 11:45:12 -0500 Subject: [LinuxBIOS] Intel E7501 Northbridge head-scratching In-Reply-To: References: <006a01c562e0$a3d9e650$6ffea8c0@banana> Message-ID: <42A08918.7080107@onelabs.com> Ronald G. Minnich wrote: > On another note, we just found and killed an extremely nasty bug in the > EPIA port, early in ram init. Once we can get 'arch' working for josiah he > can commit the latest epia patches. I think that we can say 'epia is good' > very soon. > > Next will be epia-m. Was the bug in the PLE133 (Epia) and CLE266 (Epia-M) support? -Bari From rminnich at lanl.gov Fri Jun 3 18:47:50 2005 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Fri, 3 Jun 2005 10:47:50 -0600 (MDT) Subject: [LinuxBIOS] Intel E7501 Northbridge head-scratching In-Reply-To: <42A08918.7080107@onelabs.com> References: <006a01c562e0$a3d9e650$6ffea8c0@banana> <42A08918.7080107@onelabs.com> Message-ID: On Fri, 3 Jun 2005, Bari Ari wrote: > Was the bug in the PLE133 (Epia) and CLE266 (Epia-M) support? somebody who upgraded the ram support for ple133 left out an else. Long story, you can see it in the diffs (it was not me, thank goodness :-0) ron From ollie at lanl.gov Fri Jun 3 18:59:27 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Fri, 03 Jun 2005 10:59:27 -0600 Subject: [LinuxBIOS] Intel E7501 Northbridge head-scratching In-Reply-To: <42A08918.7080107@onelabs.com> References: <006a01c562e0$a3d9e650$6ffea8c0@banana> <42A08918.7080107@onelabs.com> Message-ID: <1117817967.3410.3.camel@exponential.lanl.gov> On Fri, 2005-06-03 at 11:45 -0500, Bari Ari wrote: > Ronald G. Minnich wrote: > > > On another note, we just found and killed an extremely nasty bug in the > > EPIA port, early in ram init. Once we can get 'arch' working for josiah he > > can commit the latest epia patches. I think that we can say 'epia is good' > > very soon. > > > > Next will be epia-m. > > Was the bug in the PLE133 (Epia) and CLE266 (Epia-M) support? > Probably not. It is a very trivial programmer error (if else if). -- Li-Ta Lo Los Alamos National Lab From YhLu at tyan.com Fri Jun 3 19:04:24 2005 From: YhLu at tyan.com (YhLu) Date: Fri, 3 Jun 2005 10:04:24 -0700 Subject: [LinuxBIOS] FYI: AMD support for cache as ram. Message-ID: <3174569B9743D511922F00A0C94314230A403A53@TYANWEB> So you make the romcc to support the real function instead of all inline...? YH > -----Original Message----- > From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] > Sent: Thursday, June 02, 2005 10:20 PM > To: LinuxBIOS > Subject: [LinuxBIOS] FYI: AMD support for cache as ram. > > > Check out the new BIOS and Kernel Developers Guide. > > Eric > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From ollie at lanl.gov Fri Jun 3 19:05:14 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Fri, 03 Jun 2005 11:05:14 -0600 Subject: [LinuxBIOS] FYI: AMD support for cache as ram. In-Reply-To: <3174569B9743D511922F00A0C94314230A403A53@TYANWEB> References: <3174569B9743D511922F00A0C94314230A403A53@TYANWEB> Message-ID: <1117818314.3410.5.camel@exponential.lanl.gov> On Fri, 2005-06-03 at 10:04 -0700, YhLu wrote: > So you make the romcc to support the real function instead of all inline...? > With cache as ram, we don't need romcc, everything can be compiled by GCC. > YH > > > -----Original Message----- > > From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] > > Sent: Thursday, June 02, 2005 10:20 PM > > To: LinuxBIOS > > Subject: [LinuxBIOS] FYI: AMD support for cache as ram. > > > > > > Check out the new BIOS and Kernel Developers Guide. > > > > Eric > > > > _______________________________________________ > > LinuxBIOS mailing list > > LinuxBIOS at openbios.org > > http://www.openbios.org/mailman/listinfo/linuxbios > > > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios -- Li-Ta Lo Los Alamos National Lab From YhLu at tyan.com Fri Jun 3 19:17:08 2005 From: YhLu at tyan.com (YhLu) Date: Fri, 3 Jun 2005 10:17:08 -0700 Subject: [LinuxBIOS] FYI: AMD support for cache as ram. Message-ID: <3174569B9743D511922F00A0C94314230A403A58@TYANWEB> So you will use asm to enable cache as ram. ----cache_as_ram.inc and execute the code in ROM ( compiled by gcc) to initialize the RAM. ----auto.c but the cache only 64k, is it enough? the cache will be used as stack for function. How about the decompress for auto.o... ..... cool YH > -----Original Message----- > From: Li-Ta Lo [mailto:ollie at lanl.gov] > Sent: Friday, June 03, 2005 10:05 AM > To: YhLu > Cc: ebiederman at lnxi.com; LinuxBIOS > Subject: RE: [LinuxBIOS] FYI: AMD support for cache as ram. > > On Fri, 2005-06-03 at 10:04 -0700, YhLu wrote: > > So you make the romcc to support the real function instead > of all inline...? > > > > With cache as ram, we don't need romcc, everything can be > compiled by GCC. > > > YH > > > > > -----Original Message----- > > > From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] > > > Sent: Thursday, June 02, 2005 10:20 PM > > > To: LinuxBIOS > > > Subject: [LinuxBIOS] FYI: AMD support for cache as ram. > > > > > > > > > Check out the new BIOS and Kernel Developers Guide. > > > > > > Eric > > > > > > _______________________________________________ > > > LinuxBIOS mailing list > > > LinuxBIOS at openbios.org > > > http://www.openbios.org/mailman/listinfo/linuxbios > > > > > > > _______________________________________________ > > LinuxBIOS mailing list > > LinuxBIOS at openbios.org > > http://www.openbios.org/mailman/listinfo/linuxbios > -- > Li-Ta Lo > Los Alamos National Lab > From ollie at lanl.gov Fri Jun 3 19:22:59 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Fri, 03 Jun 2005 11:22:59 -0600 Subject: [LinuxBIOS] FYI: AMD support for cache as ram. In-Reply-To: <3174569B9743D511922F00A0C94314230A403A58@TYANWEB> References: <3174569B9743D511922F00A0C94314230A403A58@TYANWEB> Message-ID: <1117819379.3410.12.camel@exponential.lanl.gov> On Fri, 2005-06-03 at 10:17 -0700, YhLu wrote: > So you will use asm to enable cache as ram. ----cache_as_ram.inc > and execute the code in ROM ( compiled by gcc) to initialize the RAM. > ----auto.c > but the cache only 64k, is it enough? > the cache will be used as stack for function. How about the decompress for > auto.o... > ..... > cool > 64KB is actually to much for the stack. I had a (semi)working version long time ago. It only provided 448 Bytes of space. It worked well for UP case (actually, I think the problem was HT reset rather than stack overflow in MP cases). -- Li-Ta Lo Los Alamos National Lab From YhLu at tyan.com Fri Jun 3 19:26:47 2005 From: YhLu at tyan.com (YhLu) Date: Fri, 3 Jun 2005 10:26:47 -0700 Subject: [LinuxBIOS] FYI: AMD support for cache as ram. Message-ID: <3174569B9743D511922F00A0C94314230A403A5D@TYANWEB> makerule ./auto.E depends "$(MAINBOARD)/auto.c option_table.h ./romcc" action "./romcc -E -mcpu=k8 -O2 -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/auto.c -o $@" end makerule ./auto.inc depends "$(MAINBOARD)/auto.c option_table.h ./romcc" action "./romcc -mcpu=k8 -O2 -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/auto.c -o $@" end How to use gcc to produce auto.inc? YH > -----Original Message----- > From: Li-Ta Lo [mailto:ollie at lanl.gov] > Sent: Friday, June 03, 2005 10:05 AM > To: YhLu > Cc: ebiederman at lnxi.com; LinuxBIOS > Subject: RE: [LinuxBIOS] FYI: AMD support for cache as ram. > > On Fri, 2005-06-03 at 10:04 -0700, YhLu wrote: > > So you make the romcc to support the real function instead > of all inline...? > > > > With cache as ram, we don't need romcc, everything can be > compiled by GCC. > > > YH > > > > > -----Original Message----- > > > From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] > > > Sent: Thursday, June 02, 2005 10:20 PM > > > To: LinuxBIOS > > > Subject: [LinuxBIOS] FYI: AMD support for cache as ram. > > > > > > > > > Check out the new BIOS and Kernel Developers Guide. > > > > > > Eric > > > > > > _______________________________________________ > > > LinuxBIOS mailing list > > > LinuxBIOS at openbios.org > > > http://www.openbios.org/mailman/listinfo/linuxbios > > > > > > > _______________________________________________ > > LinuxBIOS mailing list > > LinuxBIOS at openbios.org > > http://www.openbios.org/mailman/listinfo/linuxbios > -- > Li-Ta Lo > Los Alamos National Lab > From ollie at lanl.gov Fri Jun 3 19:30:11 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Fri, 03 Jun 2005 11:30:11 -0600 Subject: [LinuxBIOS] FYI: AMD support for cache as ram. In-Reply-To: <3174569B9743D511922F00A0C94314230A403A5D@TYANWEB> References: <3174569B9743D511922F00A0C94314230A403A5D@TYANWEB> Message-ID: <1117819811.3410.14.camel@exponential.lanl.gov> On Fri, 2005-06-03 at 10:26 -0700, YhLu wrote: > makerule ./auto.E > depends "$(MAINBOARD)/auto.c option_table.h ./romcc" > action "./romcc -E -mcpu=k8 -O2 -I$(TOP)/src -I. $(CPPFLAGS) > $(MAINBOARD)/auto.c -o $@" > end > makerule ./auto.inc > depends "$(MAINBOARD)/auto.c option_table.h ./romcc" > action "./romcc -mcpu=k8 -O2 -I$(TOP)/src -I. $(CPPFLAGS) > $(MAINBOARD)/auto.c -o $@" > end > > How to use gcc to produce auto.inc? > It is much more that that. I will send you the .tgz in another mail. -- Li-Ta Lo Los Alamos National Lab From YhLu at tyan.com Fri Jun 3 19:33:10 2005 From: YhLu at tyan.com (YhLu) Date: Fri, 3 Jun 2005 10:33:10 -0700 Subject: [LinuxBIOS] FYI: AMD support for cache as ram. Message-ID: <3174569B9743D511922F00A0C94314230A403A61@TYANWEB> Great. YH > -----Original Message----- > From: Li-Ta Lo [mailto:ollie at lanl.gov] > Sent: Friday, June 03, 2005 10:30 AM > To: YhLu > Cc: ebiederman at lnxi.com; LinuxBIOS > Subject: RE: [LinuxBIOS] FYI: AMD support for cache as ram. > > On Fri, 2005-06-03 at 10:26 -0700, YhLu wrote: > > makerule ./auto.E > > depends "$(MAINBOARD)/auto.c option_table.h ./romcc" > > action "./romcc -E -mcpu=k8 -O2 -I$(TOP)/src -I. > $(CPPFLAGS) > > $(MAINBOARD)/auto.c -o $@" > > end > > makerule ./auto.inc > > depends "$(MAINBOARD)/auto.c option_table.h ./romcc" > > action "./romcc -mcpu=k8 -O2 -I$(TOP)/src -I. > $(CPPFLAGS) > > $(MAINBOARD)/auto.c -o $@" > > end > > > > How to use gcc to produce auto.inc? > > > > It is much more that that. I will send you the .tgz in another mail. > > -- > Li-Ta Lo > Los Alamos National Lab > From gwatson at lanl.gov Fri Jun 3 19:53:10 2005 From: gwatson at lanl.gov (Greg Watson) Date: Fri, 3 Jun 2005 11:53:10 -0600 Subject: [LinuxBIOS] FYI: AMD support for cache as ram. In-Reply-To: <3174569B9743D511922F00A0C94314230A403A58@TYANWEB> References: <3174569B9743D511922F00A0C94314230A403A58@TYANWEB> Message-ID: <00E849D4-1294-417C-9B95-8A8AB446BBBB@lanl.gov> Cache on the PPC is only 8K. It seems to work fine. Greg On Jun 3, 2005, at 11:17 AM, YhLu wrote: > So you will use asm to enable cache as ram. ----cache_as_ram.inc > and execute the code in ROM ( compiled by gcc) to initialize the RAM. > ----auto.c > but the cache only 64k, is it enough? > the cache will be used as stack for function. How about the > decompress for > auto.o... > ..... > cool > > YH > > >> -----Original Message----- >> From: Li-Ta Lo [mailto:ollie at lanl.gov] >> Sent: Friday, June 03, 2005 10:05 AM >> To: YhLu >> Cc: ebiederman at lnxi.com; LinuxBIOS >> Subject: RE: [LinuxBIOS] FYI: AMD support for cache as ram. >> >> On Fri, 2005-06-03 at 10:04 -0700, YhLu wrote: >> >>> So you make the romcc to support the real function instead >>> >> of all inline...? >> >>> >>> >> >> With cache as ram, we don't need romcc, everything can be >> compiled by GCC. >> >> >>> YH >>> >>> >>>> -----Original Message----- >>>> From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] >>>> Sent: Thursday, June 02, 2005 10:20 PM >>>> To: LinuxBIOS >>>> Subject: [LinuxBIOS] FYI: AMD support for cache as ram. >>>> >>>> >>>> Check out the new BIOS and Kernel Developers Guide. >>>> >>>> Eric >>>> >>>> _______________________________________________ >>>> LinuxBIOS mailing list >>>> LinuxBIOS at openbios.org >>>> http://www.openbios.org/mailman/listinfo/linuxbios >>>> >>>> >>> >>> _______________________________________________ >>> LinuxBIOS mailing list >>> LinuxBIOS at openbios.org >>> http://www.openbios.org/mailman/listinfo/linuxbios >>> >> -- >> Li-Ta Lo >> Los Alamos National Lab >> >> > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From ebiederman at lnxi.com Fri Jun 3 20:40:55 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: 03 Jun 2005 12:40:55 -0600 Subject: [BULK] RE: [LinuxBIOS] Intel E7501 Northbridge head-scratching In-Reply-To: References: <006a01c562e0$a3d9e650$6ffea8c0@banana> Message-ID: "Ronald G. Minnich" writes: > On Fri, 27 May 2005, Steven J. Magnani wrote: > > The architecture is fixed. I either have to find a way to make LinuxBIOS > > we are also working here on V2 and 7501 for other reasons. > > I think the code can be made to work. > > On another note, we just found and killed an extremely nasty bug in the > EPIA port, early in ram init. Once we can get 'arch' working for josiah he > can commit the latest epia patches. I think that we can say 'epia is good' > very soon. Have we played with pulling changes from any one yet? In general pulling should be better than pushing... Eric From rminnich at lanl.gov Fri Jun 3 20:51:36 2005 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Fri, 3 Jun 2005 12:51:36 -0600 (MDT) Subject: [LinuxBIOS] FYI: AMD support for cache as ram. In-Reply-To: <3174569B9743D511922F00A0C94314230A403A58@TYANWEB> References: <3174569B9743D511922F00A0C94314230A403A58@TYANWEB> Message-ID: On Fri, 3 Jun 2005, YhLu wrote: > but the cache only 64k, is it enough? I think it is. ron From kevin at koconnor.net Fri Jun 3 22:18:20 2005 From: kevin at koconnor.net (Kevin O'Connor) Date: Fri, 3 Jun 2005 16:18:20 -0400 Subject: [LinuxBIOS] FYI: AMD support for cache as ram. In-Reply-To: <1117818314.3410.5.camel@exponential.lanl.gov> References: <3174569B9743D511922F00A0C94314230A403A53@TYANWEB> <1117818314.3410.5.camel@exponential.lanl.gov> Message-ID: <20050603201820.GA4836@double.lan> On Fri, Jun 03, 2005 at 11:05:14AM -0600, Li-Ta Lo wrote: > On Fri, 2005-06-03 at 10:04 -0700, YhLu wrote: > > So you make the romcc to support the real function instead of all inline...? > > > > With cache as ram, we don't need romcc, everything can be compiled > by GCC. The AMD docs don't mention a chip revision - does this mean the trick will work for all Athlon64 and Opterons? -Kevin From ebiederman at lnxi.com Sat Jun 4 03:04:35 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: 03 Jun 2005 19:04:35 -0600 Subject: [BULK] RE: [LinuxBIOS] FYI: AMD support for cache as ram. In-Reply-To: References: <3174569B9743D511922F00A0C94314230A403A58@TYANWEB> Message-ID: "Ronald G. Minnich" writes: > On Fri, 3 Jun 2005, YhLu wrote: > > > but the cache only 64k, is it enough? > > I think it is. Currently we use 96 bytes I think we can fit it all in 64K. We might be able to run the normal C portion of LinuxBIOS if we decompressed it... Heck you can even run a small Unix in 64K..... Eric From YhLu at tyan.com Sat Jun 4 03:18:16 2005 From: YhLu at tyan.com (YhLu) Date: Fri, 3 Jun 2005 18:18:16 -0700 Subject: [BULK] RE: [LinuxBIOS] FYI: AMD support for cache as ram. Message-ID: <3174569B9743D511922F00A0C94314230A403ADF@TYANWEB> For s2895, with CAS, -rw-r--r-- 1 root root 49930 Jun 3 17:51 linuxbios_ram.nrv2b -rw-r--r-- 1 root root 5688 Jun 3 17:51 crt0.o -rw-r--r-- 1 root root 30276 Jun 3 17:51 init.o (include auto.o and failover.o and memcpy.o) -rw-r--r-- 1 root root 16006 Jun 3 17:51 init.o.gz if the init.o can be compressed too, you can spare 14k. YH > -----Original Message----- > From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] > Sent: Friday, June 03, 2005 6:05 PM > To: Ronald G. Minnich > Cc: YhLu; LinuxBIOS > Subject: Re: [BULK] RE: [LinuxBIOS] FYI: AMD support for cache as ram. > > "Ronald G. Minnich" writes: > > > On Fri, 3 Jun 2005, YhLu wrote: > > > > > but the cache only 64k, is it enough? > > > > I think it is. > > Currently we use 96 bytes I think we can fit it all in 64K. > We might be able to run the normal C portion of LinuxBIOS if > we decompressed it... > > Heck you can even run a small Unix in 64K..... > > Eric > From ebiederman at lnxi.com Sat Jun 4 04:14:03 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: 03 Jun 2005 20:14:03 -0600 Subject: [BULK] RE: [LinuxBIOS] FYI: AMD support for cache as ram. In-Reply-To: <3174569B9743D511922F00A0C94314230A403ADF@TYANWEB> References: <3174569B9743D511922F00A0C94314230A403ADF@TYANWEB> Message-ID: YhLu writes: > For s2895, with CAS, > -rw-r--r-- 1 root root 49930 Jun 3 17:51 linuxbios_ram.nrv2b > -rw-r--r-- 1 root root 5688 Jun 3 17:51 crt0.o > -rw-r--r-- 1 root root 30276 Jun 3 17:51 init.o (include > auto.o and failover.o and memcpy.o) > -rw-r--r-- 1 root root 16006 Jun 3 17:51 init.o.gz > if the init.o can be compressed too, you can spare 14k. certainly some significant parts of init.o cannot be compressed. You need to get at least far enough to do the cache as ram thing. Currently the cpu designers Intel and AMD do not support running out of the cache so that is an issue. However the size of a .o rarely has a strong correspondence to actual code size. Use size to find out the size of the .text and .data segments. Eric From noodles at earth.li Sat Jun 4 12:45:20 2005 From: noodles at earth.li (Jonathan McDowell) Date: Sat, 4 Jun 2005 11:45:20 +0100 Subject: [LinuxBIOS] EPIA-M status In-Reply-To: <001d01c5657f$bc7ce1c0$c501a8c0@newflame> References: <3174569B9743D511922F00A0C943142309F81813@TYANWEB> <001d01c5657f$bc7ce1c0$c501a8c0@newflame> Message-ID: <20050604104519.GX10176@earth.li> On Tue, May 31, 2005 at 02:26:09AM +0000, Adam Talbot wrote: > Any one had any time to look at the EPIA-M code? Or is it still > broken? I'm interested in this too; I've hacked up a checkout from arch so it actually compiles for epia-m now, but I'm waiting for my BIOS Saviour to arrive before I can test it. It sounds like there are private trees floating around that have at least some extra work done on them though? J. -- Revd. Jonathan McDowell, ULC | Even the Evening Herald slags me off. From erlend at slettevoll.no Sat Jun 4 14:59:28 2005 From: erlend at slettevoll.no (Erlend Slettevoll) Date: Sat, 4 Jun 2005 14:59:28 +0200 Subject: [LinuxBIOS] NBD? Message-ID: <20050604125928.GA23000@stud.ntnu.no> I just recently started to look at the Linux BIOS-project. Is it possible to use Linux BIOS to boot other OSes disklessly using Network Block Devices? (NBD) --Erlend From smithbone at gmail.com Sat Jun 4 16:07:52 2005 From: smithbone at gmail.com (Richard Smith) Date: Sat, 4 Jun 2005 09:07:52 -0500 Subject: [LinuxBIOS] NBD? In-Reply-To: <20050604125928.GA23000@stud.ntnu.no> References: <20050604125928.GA23000@stud.ntnu.no> Message-ID: <8a0c36780506040707779f9370@mail.gmail.com> On 6/4/05, Erlend Slettevoll wrote: > I just recently started to look at the Linux BIOS-project. Is it > possible to use Linux BIOS to boot other OSes disklessly using Network > Block Devices? (NBD) Depends on how big your flash, what additional boot devices are available, or how much you are willing to code. LinuxBIOS itself only directly supports the init of the hardware. After the hardware is up LinuxBIOS loads a elf payload. This payload then can do whatever it wants. A payload for etherboot exists so you could hack up that. If your flash is large enough then you can load an actual linux kernel+initrd as a payload and then do anything linux can do. Or if you can boot off of a compact flash then you can FILO ( a disk loader payload) a kernel+initrd image. Or if you have USB available you can pull a kernel off of a USB stick. So yes, but not directly. -- Richard A. Smith From cpasqualini at ciudad.com.ar Sat Jun 4 16:52:42 2005 From: cpasqualini at ciudad.com.ar (Carlos Pasqualini) Date: Sat, 4 Jun 2005 11:52:42 -0300 Subject: [LinuxBIOS] LinuxBIOS Message-ID: <200506041152.42248.cpasqualini@ciudad.com.ar> Hello List! I'm Carlos Pasqualini from Argentina. Sorry about my english (i do not speak english) so try to understandme i have a motherboard in wich i wan't to boot Linux, but diskless... can i put a linuxbios on it and boot Linux from the net? May be using linuxbios + etherboot or some thing like that. thanks charly From smithbone at gmail.com Sat Jun 4 17:16:29 2005 From: smithbone at gmail.com (Richard Smith) Date: Sat, 4 Jun 2005 10:16:29 -0500 Subject: [LinuxBIOS] LinuxBIOS In-Reply-To: <200506041152.42248.cpasqualini@ciudad.com.ar> References: <200506041152.42248.cpasqualini@ciudad.com.ar> Message-ID: <8a0c36780506040816620ad549@mail.gmail.com> > > can i put a linuxbios on it and boot Linux from the net? > May be using linuxbios + etherboot or some thing like that. If your hardware is supported by LinuxBIOS then yes. Boot linux on it and do an 'lspci' and check http://linuxbios.org/index.php/Supported_Motherboards If you don't see your board listed then send the lspci output to the list. It may still be supported or perhaps in the works. -- Richard A. Smith From smithbone at gmail.com Sat Jun 4 17:48:34 2005 From: smithbone at gmail.com (Richard Smith) Date: Sat, 4 Jun 2005 10:48:34 -0500 Subject: [LinuxBIOS] LinuxBIOS In-Reply-To: <200506041225.22403.cpasqualini@ciudad.com.ar> References: <200506041152.42248.cpasqualini@ciudad.com.ar> <8a0c36780506040816620ad549@mail.gmail.com> <200506041225.22403.cpasqualini@ciudad.com.ar> Message-ID: <8a0c367805060408482b4e0957@mail.gmail.com> > the board it's a PCCHIPS with a VIA C3 processor > CLE266 North / 8235 South > via rhine II ethernet... > use a VGA integrated onto the CLE266 chipset and have sound on board too... > > it seems to be the same chips than a EPIA motherboard, but it's a FlexATX and > it's builded by pcchips... The VIA EPIA platform is supported. Currently the code is broken but several people are working on it. Latest word is that is mostly fixed and the various developent trees ned to be merged back upstream. I'll let the actual people who are working on the code give you the specific details. -- Richard A. Smith From talbotx at comcast.net Sat Jun 4 18:57:53 2005 From: talbotx at comcast.net (Adam Talbot) Date: Sat, 4 Jun 2005 09:57:53 -0700 Subject: [LinuxBIOS] EPIA-M status References: <3174569B9743D511922F00A0C943142309F81813@TYANWEB><001d01c5657f$bc7ce1c0$c501a8c0@newflame> <20050604104519.GX10176@earth.li> Message-ID: <00b701c56926$8ce6b210$c501a8c0@newflame> Jonathan I have a prom flasher and am more then willing to test the code. If you would tar/gzip your tree and send it to me I will compile it for my EPIA-MII and test it for you. The worst that could happen is the system does not boot at all, that why I bought the prom flasher in the first place. :-) Adam ----- Original Message ----- From: "Jonathan McDowell" To: Sent: Saturday, June 04, 2005 3:45 AM Subject: Re: [LinuxBIOS] EPIA-M status > On Tue, May 31, 2005 at 02:26:09AM +0000, Adam Talbot wrote: > >> Any one had any time to look at the EPIA-M code? Or is it still >> broken? > > I'm interested in this too; I've hacked up a checkout from arch so it > actually compiles for epia-m now, but I'm waiting for my BIOS Saviour to > arrive before I can test it. It sounds like there are private trees > floating around that have at least some extra work done on them though? > > J. > > -- > Revd. Jonathan McDowell, ULC | Even the Evening Herald slags me off. > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From rminnich at lanl.gov Sun Jun 5 08:49:14 2005 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Sun, 5 Jun 2005 00:49:14 -0600 (MDT) Subject: [LinuxBIOS] EPIA-M status In-Reply-To: <20050604104519.GX10176@earth.li> References: <3174569B9743D511922F00A0C943142309F81813@TYANWEB> <001d01c5657f$bc7ce1c0$c501a8c0@newflame> <20050604104519.GX10176@earth.li> Message-ID: we have fixes to epia. The commit via arch has failed. Once it is fixed, epia support is in. ron From rminnich at lanl.gov Sun Jun 5 08:50:23 2005 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Sun, 5 Jun 2005 00:50:23 -0600 (MDT) Subject: [LinuxBIOS] NBD? In-Reply-To: <20050604125928.GA23000@stud.ntnu.no> References: <20050604125928.GA23000@stud.ntnu.no> Message-ID: On Sat, 4 Jun 2005, Erlend Slettevoll wrote: > I just recently started to look at the Linux BIOS-project. Is it > possible to use Linux BIOS to boot other OSes disklessly using Network > Block Devices? (NBD) it is easiest to do this by booting linux from flash and using linux to boot linux. But yet, it is possible. ron From noodles at earth.li Sun Jun 5 12:34:55 2005 From: noodles at earth.li (Jonathan McDowell) Date: Sun, 5 Jun 2005 11:34:55 +0100 Subject: [LinuxBIOS] EPIA-M status In-Reply-To: <00b701c56926$8ce6b210$c501a8c0@newflame> References: <20050604104519.GX10176@earth.li> <00b701c56926$8ce6b210$c501a8c0@newflame> Message-ID: <20050605103455.GY10176@earth.li> On Sat, Jun 04, 2005 at 09:57:53AM -0700, Adam Talbot wrote: > I have a prom flasher and am more then willing to test the code. If > you would tar/gzip your tree and send it to me I will compile it for > my EPIA-MII and test it for you. The worst that could happen is the > system does not boot at all, that why I bought the prom flasher in the > first place. :-) Heh. Well, I make absolutely no guarantees about this code other than "it compiles for me". It won't do VGA stuff and having had a further prod around there's a lot of cleanup that needs done around the vt1211 code. I've no way of running it or testing it until my kit arrives and I'm loathe to start making more changes until I've tested at least this lot to see if anything happens. :) However, I've put what I've got up in an Arch repository. tla register-archive noodles at earth.li--pie \ http://www.earth.li/~noodles/arch/noodles at earth.li--pie tla get noodles at earth.li--pie/freebios--epia-m--2.0 freebios2-epiam cd freebios2-epiam/targets ./buildtarget via/epia-m/Config.filo.lb cd via/epia-m/epia-m/ make (You'll need a copy of filo.elf in the same directory as the freebios2-epiam subdirectory for the make to complete) J. -- 101 things you can't have too much of : 50 - Escalators. From yinghailu at gmail.com Sun Jun 5 20:03:21 2005 From: yinghailu at gmail.com (yhlu) Date: Sun, 5 Jun 2005 11:03:21 -0700 Subject: [LinuxBIOS] NBD? In-Reply-To: References: <20050604125928.GA23000@stud.ntnu.no> Message-ID: <2ea3fae1050605110322abe270@mail.gmail.com> You need setup extra (dhcp server+tftp server). LinuxBIOS(in ROM)--> Etherboot(in ROM)-->ELF (Kernel...)(Download from boot server). Make sure NBD is enabled in Kernel. Also when using makelfimage to make elf you can pass some command line to it. YH On 6/4/05, Ronald G. Minnich wrote: > > > On Sat, 4 Jun 2005, Erlend Slettevoll wrote: > > > I just recently started to look at the Linux BIOS-project. Is it > > possible to use Linux BIOS to boot other OSes disklessly using Network > > Block Devices? (NBD) > > it is easiest to do this by booting linux from flash and using linux to > boot linux. But yet, it is possible. > > ron > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From talbotx at comcast.net Mon Jun 6 07:42:02 2005 From: talbotx at comcast.net (Adam Talbot) Date: Sun, 5 Jun 2005 22:42:02 -0700 Subject: [LinuxBIOS] EPIA-M Almost there References: <20050604104519.GX10176@earth.li><00b701c56926$8ce6b210$c501a8c0@newflame> <20050605103455.GY10176@earth.li> Message-ID: <002301c56a5a$781fd480$c501a8c0@newflame> Humm, so I am working on the EPIA-MII. Jonathan was kind enough to provide me with a compiling version of the source code. OK, I am stuck at this point. The code is compiled and flashed. Here is my console output. On the first reboot. 0 LinuxBIOS-1.1.8.0Fallback Sun Jun 5 22:31:42 PDT 2005 starting... vt8623 init starting vt8623 done After the first reboot I have to set my connection speed to 57600 instead of 115200, and I get. ...`(...H....`(...H. LinuxBIOS-1.1.8.0Normal Sun Jun 5 22:31:09 PDT 2005 starting... Where do I turn up the debug so I can get a bit more info and perhaps track the problem?? -Adam ----- Original Message ----- From: "Jonathan McDowell" To: Sent: Sunday, June 05, 2005 3:34 AM Subject: Re: [LinuxBIOS] EPIA-M status > On Sat, Jun 04, 2005 at 09:57:53AM -0700, Adam Talbot wrote: >> I have a prom flasher and am more then willing to test the code. If >> you would tar/gzip your tree and send it to me I will compile it for >> my EPIA-MII and test it for you. The worst that could happen is the >> system does not boot at all, that why I bought the prom flasher in the >> first place. :-) > > Heh. Well, I make absolutely no guarantees about this code other than > "it compiles for me". It won't do VGA stuff and having had a further > prod around there's a lot of cleanup that needs done around the vt1211 > code. I've no way of running it or testing it until my kit arrives and > I'm loathe to start making more changes until I've tested at least this > lot to see if anything happens. :) > > However, I've put what I've got up in an Arch repository. > > tla register-archive noodles at earth.li--pie \ > http://www.earth.li/~noodles/arch/noodles at earth.li--pie > tla get noodles at earth.li--pie/freebios--epia-m--2.0 freebios2-epiam > cd freebios2-epiam/targets > ./buildtarget via/epia-m/Config.filo.lb > cd via/epia-m/epia-m/ > make > > (You'll need a copy of filo.elf in the same directory as the > freebios2-epiam subdirectory for the make to complete) > > J. > > -- > 101 things you can't have too much of : 50 - Escalators. > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From noodles at earth.li Mon Jun 6 11:17:19 2005 From: noodles at earth.li (Jonathan McDowell) Date: Mon, 6 Jun 2005 10:17:19 +0100 Subject: [LinuxBIOS] EPIA-M Almost there In-Reply-To: <002301c56a5a$781fd480$c501a8c0@newflame> References: <20050605103455.GY10176@earth.li> <002301c56a5a$781fd480$c501a8c0@newflame> Message-ID: <20050606091719.GI10176@earth.li> On Sun, Jun 05, 2005 at 10:42:02PM -0700, Adam Talbot wrote: > Humm, so I am working on the EPIA-MII. Jonathan was kind enough to provide > me with a compiling version of the source code. OK, I am stuck at this > point. The code is compiled and flashed. Here is my console output. On > the first reboot. > > 0 > > LinuxBIOS-1.1.8.0Fallback Sun Jun 5 22:31:42 PDT 2005 starting... > vt8623 init starting > vt8623 done > > After the first reboot I have to set my connection speed to 57600 instead > of 115200, and I get. > > ...`(...H....`(...H. > > LinuxBIOS-1.1.8.0Normal Sun Jun 5 22:31:09 PDT 2005 starting... Oh cool. I was worried there wouldn't be any output at all which would be harder to diagnose. :) > Where do I turn up the debug so I can get a bit more info and perhaps > track the problem?? Try adding: uses DEFAULT_CONSOLE_LOGLEVEL uses MAXIMUM_CONSOLE_LOGLEVEL to src/mainboard/via/epia-m/Options.lb just under "uses OBJCOPY" and then: option DEFAULT_CONSOLE_LOGLEVEL=9 option MAXIMUM_CONSOLE_LOGLEVEL=9 to targets/via/epia-m/Config.filo.lb just under "option HAVE_FALLBACK_BOOT=1" You'll need to do the ./buildtarget again afterwards obviously. J. -- OK, if we can't have a tour, can | .''`. Debian GNU/Linux Developer we at least have a look around? | : :' : Happy to accept PGP signed | `. `' or encrypted mail - RSA + | `- DSA keys on the keyservers. From noodles at earth.li Mon Jun 6 14:39:09 2005 From: noodles at earth.li (Jonathan McDowell) Date: Mon, 6 Jun 2005 13:39:09 +0100 Subject: [LinuxBIOS] EPIA-M Almost there In-Reply-To: <20050606091719.GI10176@earth.li> References: <20050605103455.GY10176@earth.li> <002301c56a5a$781fd480$c501a8c0@newflame> <20050606091719.GI10176@earth.li> Message-ID: <20050606123909.GV10176@earth.li> On Mon, Jun 06, 2005 at 10:17:19AM +0100, Jonathan McDowell wrote: > On Sun, Jun 05, 2005 at 10:42:02PM -0700, Adam Talbot wrote: > > Where do I turn up the debug so I can get a bit more info and perhaps > > track the problem?? > > Try adding: > > uses DEFAULT_CONSOLE_LOGLEVEL > uses MAXIMUM_CONSOLE_LOGLEVEL > > to src/mainboard/via/epia-m/Options.lb just under "uses OBJCOPY" > > and then: > > option DEFAULT_CONSOLE_LOGLEVEL=9 > option MAXIMUM_CONSOLE_LOGLEVEL=9 > > to targets/via/epia-m/Config.filo.lb just under > "option HAVE_FALLBACK_BOOT=1" > > You'll need to do the ./buildtarget again afterwards obviously. Also, I've just fixed up the config a bit more (and checked it into my arch tree) so the southbridge init stuff should actually get called - I don't think it was doing so before. Still looking at the right way to handle the vt1211 stuff. J. -- Time is an illusion. Lunchtime doubly so. From talbotx at comcast.net Mon Jun 6 17:31:34 2005 From: talbotx at comcast.net (Adam Talbot) Date: Mon, 6 Jun 2005 08:31:34 -0700 Subject: [LinuxBIOS] EPIA-M Almost there References: <20050605103455.GY10176@earth.li><002301c56a5a$781fd480$c501a8c0@newflame> <20050606091719.GI10176@earth.li> Message-ID: <000801c56aac$d588f910$c501a8c0@newflame> -Jonathan I grabbed the new tree. Here is the new output. (on the first boot) And that just keeps going, never stops. After the first reboot, I need to set my com settings to 57600 and just get "LinuxBIOS-1.1.8.0Normal Mon Jun 6 08:25:38 PDT 2005 starting..." and nothing else. Hope this helps in the debug process. -Adam LinuxBIOS-1.1.8.0Normal Mon Jun 6 08:08:08 PDT 2005 starting... vt8623 init starting 00000000 is the north 1106 3123 e4 is the computed timing vt8623 done 00:06 11 23 31 06 00 30 22 00 00 00 06 00 08 00 00 10:08 00 00 d0 00 00 00 00 00 00 00 00 00 00 00 00 20:00 00 00 00 00 00 00 00 00 00 00 00 06 11 01 aa 30:00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 40:00 18 88 80 82 44 00 00 18 99 88 80 82 44 00 00 50:c8 de cf 88 e0 07 00 00 e0 00 10 10 10 10 00 00 60:02 ff 00 30 e6 32 01 2e 59 2d 43 58 00 44 00 00 70:82 48 00 01 01 08 50 00 01 00 00 00 00 00 00 00 80:0f 65 00 00 f0 00 00 00 03 80 34 01 00 00 00 00 90:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0:02 c0 20 00 07 02 00 1f 04 00 00 00 2f 02 04 00 b0:00 00 00 00 80 00 00 00 68 00 00 00 00 00 00 00 c0:01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 d0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0:80 df 42 00 00 00 01 00 40 00 00 00 00 00 00 00 f0:00 00 00 00 00 00 11 13 00 00 00 00 00 00 00 00 Copying LinuxBIOS to ram. Jumping to LinuxBIOS. 0 LinuxBIOS-1.1.8.0Fallback Mon Jun 6 08:08:40 PDT 2005 starting... 0 LinuxBIOS-1.1.8.0Normal Mon Jun 6 08:08:08 PDT 2005 starting... vt8623 init starting 00000000 is the north 1106 3123 e4 is the computed timing vt8623 done 00:06 11 23 31 06 00 30 22 00 00 00 06 00 08 00 00 10:08 00 00 d0 00 00 00 00 00 00 00 00 00 00 00 00 20:00 00 00 00 00 00 00 00 00 00 00 00 06 11 01 aa 30:00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 40:00 18 88 80 82 44 00 00 18 99 88 80 82 44 00 00 50:c8 de cf 88 e0 07 00 00 e0 00 10 10 10 10 00 00 60:02 ff 00 30 e6 32 01 2e 59 2d 43 58 00 44 00 00 70:82 48 00 01 01 08 50 00 01 00 00 00 00 00 00 00 80:0f 65 00 00 f0 00 00 00 03 80 34 01 00 00 00 00 90:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0:02 c0 20 00 07 02 00 1f 04 00 00 00 2f 02 04 00 b0:00 00 00 00 80 00 00 00 68 00 00 00 00 00 00 00 c0:01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 d0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0:80 df 42 00 00 00 01 00 40 00 00 00 00 00 00 00 f0:00 00 00 00 00 00 11 13 00 00 00 00 00 00 00 00 Copying LinuxBIOS to ram. Jumping to LinuxBIOS. ----- Original Message ----- From: "Jonathan McDowell" To: Sent: Monday, June 06, 2005 2:17 AM Subject: Re: [LinuxBIOS] EPIA-M Almost there > On Sun, Jun 05, 2005 at 10:42:02PM -0700, Adam Talbot wrote: >> Humm, so I am working on the EPIA-MII. Jonathan was kind enough to >> provide >> me with a compiling version of the source code. OK, I am stuck at this >> point. The code is compiled and flashed. Here is my console output. On >> the first reboot. >> >> 0 >> >> LinuxBIOS-1.1.8.0Fallback Sun Jun 5 22:31:42 PDT 2005 starting... >> vt8623 init starting >> vt8623 done >> >> After the first reboot I have to set my connection speed to 57600 instead >> of 115200, and I get. >> >> ...`(...H....`(...H. >> >> LinuxBIOS-1.1.8.0Normal Sun Jun 5 22:31:09 PDT 2005 starting... > > Oh cool. I was worried there wouldn't be any output at all which would > be harder to diagnose. :) > >> Where do I turn up the debug so I can get a bit more info and perhaps >> track the problem?? > > Try adding: > > uses DEFAULT_CONSOLE_LOGLEVEL > uses MAXIMUM_CONSOLE_LOGLEVEL > > to src/mainboard/via/epia-m/Options.lb just under "uses OBJCOPY" > > and then: > > option DEFAULT_CONSOLE_LOGLEVEL=9 > option MAXIMUM_CONSOLE_LOGLEVEL=9 > > to targets/via/epia-m/Config.filo.lb just under > "option HAVE_FALLBACK_BOOT=1" > > You'll need to do the ./buildtarget again afterwards obviously. > > J. > > -- > OK, if we can't have a tour, can | .''`. Debian GNU/Linux Developer > we at least have a look around? | : :' : Happy to accept PGP signed > | `. `' or encrypted mail - RSA + > | `- DSA keys on the keyservers. > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From noodles at earth.li Mon Jun 6 17:54:19 2005 From: noodles at earth.li (Jonathan McDowell) Date: Mon, 6 Jun 2005 16:54:19 +0100 Subject: [LinuxBIOS] EPIA-M Almost there In-Reply-To: <000801c56aac$d588f910$c501a8c0@newflame> References: <20050606091719.GI10176@earth.li> <000801c56aac$d588f910$c501a8c0@newflame> Message-ID: <20050606155419.GD10176@earth.li> On Mon, Jun 06, 2005 at 08:31:34AM -0700, Adam Talbot wrote: > -Jonathan > I grabbed the new tree. > Here is the new output. (on the first boot) And that just keeps going, > never stops. After the first reboot, I need to set my com settings to > 57600 and just get "LinuxBIOS-1.1.8.0Normal Mon Jun 6 08:25:38 PDT 2005 > starting..." and nothing else. Hmmm. I wonder if it's the fact the CONFIG_CONSOLE_SERIAL8250 option doesn't appear to get set; in fact I don't see any console option set by default. Try adding "uses CONFIG_CONSOLE_SERIAL8250" to src/mainboard/via/epia-m/Options.lb under the LOGLEVEL bits you added, and then "option CONFIG_CONSOLE_SERIAL8250=1" to targets/via/epia-m/Config.filo.lb and see if that gives you some more output? J. - Wishing his BIOS Saviour would arrive soon so he can play himself. -- I don't know. I'm a dog. From talbotx at comcast.net Mon Jun 6 21:43:43 2005 From: talbotx at comcast.net (Adam Talbot) Date: Mon, 6 Jun 2005 12:43:43 -0700 Subject: [LinuxBIOS] EPIA-M Almost there References: <20050606091719.GI10176@earth.li><000801c56aac$d588f910$c501a8c0@newflame> <20050606155419.GD10176@earth.li> Message-ID: <001101c56ad0$0c07b260$c501a8c0@newflame> Jonathan Well, that was cool... I have recompiled with the new options in place. Here is all my out put that I got, I just let minicom capture it. It was stuck in a dead loop, so I kill power after a bit. Still have the first boot at 115200 and all others need to be at 57600 issue. Hopes this helps in the debug. -Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: minicom.cap.gz Type: application/x-gzip Size: 1799 bytes Desc: not available URL: From YhLu at tyan.com Mon Jun 6 22:21:02 2005 From: YhLu at tyan.com (YhLu) Date: Mon, 6 Jun 2005 13:21:02 -0700 Subject: [BULK] RE: [LinuxBIOS] FYI: AMD support for cache as ram. Message-ID: <3174569B9743D511922F00A0C94314230A403B62@TYANWEB> I'm trying to enable the CAR for opteron. 1. create failover.inc and auto.inc with gcc -S 2. change the label in failover.inc from .L --> .fL 3. change section name in failover.inc and auto.c .text --> .rom.text .rodata--> .rom.data .rodata.str...-> .rom.data.str... 4. using following cache_as_ram.inc, and it will be executed after entry.inc at last it will call amd64 in failover.inc or auto.inc 5. current it will die after post code 0x22 I wonder how to make the cpu using the stack in cache.... movl $(CacheBase>>4), %eax movl %eax, %ss is enough? Also how to using gcc parammetor to do 2, and 3.... YH /* cache_as_ram.c */ #define CacheBase 0x60000 #include #include /* Save the BIST result */ movl %eax, %ebp CacheAsRam: xorl %eax, %eax # clear %eax and %edx xorl %edx, %edx # movl $fixed_mtrr_msr, %esi enable_fixed_mtrr_dram_modify: movl $SYSCFG_MSR, %ecx rdmsr orl $SYSCFG_MSR_MtrrFixDramModEn, %eax wrmsr /*Clear all MTRRs */ clear_fixed_var_mtrr: lodsl (%esi), %eax testl %eax, %eax jz clear_fixed_var_mtrr_out movl %eax, %ecx xorl %eax, %eax wrmsr jmp clear_fixed_var_mtrr clear_fixed_var_mtrr_out: /* enable mtrr dram enable */ enable_fixed_var_mtrr_dram: movl $SYSCFG_MSR, %ecx rdmsr orl $(7<<18), %eax wrmsr /* enable caching for 64K using variable mtrr */ movl $0x200, %ecx xorl %edx, %edx movl $(CacheBase | MTRR_TYPE_WRBACK), %eax wrmsr movl $0x201, %ecx movl $0x000000ff, %edx # AMD 40 bit movl $((~((CacheBase + 0x10000) - 1)) | 0x800), %eax wrmsr /* make it to be IO by clearing RD Dram and WR Dram */ movl $IORR0_BASE, %ecx xorl %edx, %edx movl $CacheBase, %eax # bit 3, and bit = 0 mean clear RD ram and ER ram wrmsr movl $IORR0_MASK, %ecx movl $0x000000ff, %edx movl $(~((CacheBase + 0x10000) - 1) | 0x800), %eax wrmsr /* enable cache */ movl %cr0, %eax andl $0x9fffffff,%eax movl %eax, %cr0 intel_chip_post_macro(0x21) /* post 21 */ #if 1 /* we zerod it above */ /* consistency: clear stack */ movl $(CacheBase+0x5000), %edi movl $0x100, %ecx xorl %eax, %eax rep stosl #endif intel_chip_post_macro(0x22) /* post 22 */ // movl $(CacheBase+0x10000-4), %esp movl $(CacheBase>>4), %eax movl %eax, %ss /* Load a different set of data segments */ #if 0 movw $CACHE_RAM_DATA_SEG, %ax movw %ax, %ds movw %ax, %es movw %ax, %ss #endif lout: /* Restore the BIST result */ movl %ebp, %eax jmp _start_init fixed_mtrr_msr: .long 0x250, 0x258, 0x259 .long 0x268, 0x269, 0x26A .long 0x26B, 0x26C, 0x26D .long 0x26E, 0x26F var_mtrr_msr: .long 0x200, 0x201, 0x202, 0x203 .long 0x204, 0x205, 0x206, 0x207 .long 0x208, 0x209, 0x20A, 0x20B .long 0x20C, 0x20D, 0x20E, 0x20F var_iorr_msr: .long 0xC0010016, 0xC0010017, 0xC0010018, 0xC0010019 mem_top: .long 0xC001001A, 0xC001001D .long 0x000 /* NULL, end of table */ _start_init: cli intel_chip_post_macro(0x23) /* post 23 */ call amd64_main intel_chip_post_macro(0x24) /* post 24 */ From noodles at earth.li Tue Jun 7 00:23:55 2005 From: noodles at earth.li (Jonathan McDowell) Date: Mon, 6 Jun 2005 23:23:55 +0100 Subject: [LinuxBIOS] EPIA-M Almost there In-Reply-To: <001101c56ad0$0c07b260$c501a8c0@newflame> References: <20050606155419.GD10176@earth.li> <001101c56ad0$0c07b260$c501a8c0@newflame> Message-ID: <20050606222355.GK10176@earth.li> On Mon, Jun 06, 2005 at 12:43:43PM -0700, Adam Talbot wrote: > Well, that was cool... I have recompiled with the new options in place. > Here is all my out put that I got, I just let minicom capture it. It was > stuck in a dead loop, so I kill power after a bit. Still have the first > boot at 115200 and all others need to be at 57600 issue. > Hopes this helps in the debug. Slowly we seem to be making progress. :) I /think/ the southbridge code needs some cleanup. It'll be a day or two before I have time to look properly, but if you shove printk_debug("In VT8235 southbridge_enable\n"); in the southbridge_enable function in /src/southbridge/via/vt8235/vt8235.c that'll at least show if it ever gets that far. Don't worry if you don't have time though, as that whole area definitely looks like it needs work anyway. The half baud rate problem is something I've seen mentioned before; something to do with the southbridge and various clocks settling down? I'll worry about it once other matters are sorted. ;) J. -- jid: noodles at jabber.earth.li noodles is the place to From noodles at earth.li Tue Jun 7 00:25:06 2005 From: noodles at earth.li (Jonathan McDowell) Date: Mon, 6 Jun 2005 23:25:06 +0100 Subject: [LinuxBIOS] EPIA-M status In-Reply-To: References: <3174569B9743D511922F00A0C943142309F81813@TYANWEB> <001d01c5657f$bc7ce1c0$c501a8c0@newflame> <20050604104519.GX10176@earth.li> Message-ID: <20050606222506.GL10176@earth.li> On Sun, Jun 05, 2005 at 12:49:14AM -0600, Ronald G. Minnich wrote: > we have fixes to epia. The commit via arch has failed. Once it is fixed, > epia support is in. This is plain EPIA support, isn't it (ie vt8601/vt8231)? Any closer to commit? Or is there even anywhere I can have a look at the diffs involved? J. -- jid: noodles at jabber.earth.li "Making the impossible very difficult" -- The OpenGALEN website. From bari at onelabs.com Tue Jun 7 01:57:53 2005 From: bari at onelabs.com (Bari Ari) Date: Mon, 06 Jun 2005 18:57:53 -0500 Subject: [LinuxBIOS] Pm49FL002 Flash In-Reply-To: <1117647235.2424.14.camel@localhost> References: <1117647235.2424.14.camel@localhost> Message-ID: <42A4E301.7020505@onelabs.com> Hugo MERCIER wrote: > Hi, > > I'm new to this list and to the project. I'd like to add support for > the Asus A7V600 motherboard (VT8237 and KT600 based). I don't have many > time, I'am not very familiar with chipset low level programming, but ... > I found LinuxBios is an interesting project ;) > > Until now, I spend my time gathering informations (manuals and > datasheet - with a request to VIA) and looking to the linuxbios code. > > I just wanted to add flash support to the flash_rom util to start > something. My motherboard is using the Pm49FL002 flash memory. It's the > same as the Pm49FL004 with 2Mb instead of 4Mb. > > With respect to the Pm49FL002 datasheet, it seems to act as Jedec. So, > I added this to flash_rom.c: > {"Pm49FL002", PMC_ID, PMC_49FL002, NULL, 256, 16 * > 1024, > probe_jedec, erase_chip_jedec, NULL,NULL}, > and to flash_rom.h: > #define PMC_49FL002 0x6D /* PMC 49FL002 device code */ > > I just wanted to test the probing (No erasing or programming yet). > And ... it fails. flash_rom doesn't find anything : the reported IDs > bytes are the same as those reported without the probing memory cycles > (0x555,0xAAA, ...) > > So ... what am I doing wrong ? Do I have to set some bit in the > Northbridge registers ? Here's a copy of flash_enable.c with vt8237 support. -Bari -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: flash_enable.c URL: From talbotx at comcast.net Tue Jun 7 04:47:56 2005 From: talbotx at comcast.net (Adam Talbot) Date: Mon, 6 Jun 2005 19:47:56 -0700 Subject: [LinuxBIOS] EPIA-M Almost there References: <20050606155419.GD10176@earth.li><001101c56ad0$0c07b260$c501a8c0@newflame> <20050606222355.GK10176@earth.li> Message-ID: <004701c56b0b$4f203410$c501a8c0@newflame> Jonathan New line of code in. Linuxbios bios recompiled... And yes, we are making it into the south bridge. Here is the new output. Adam ----- Original Message ----- From: "Jonathan McDowell" To: Sent: Monday, June 06, 2005 3:23 PM Subject: Re: [LinuxBIOS] EPIA-M Almost there > On Mon, Jun 06, 2005 at 12:43:43PM -0700, Adam Talbot wrote: >> Well, that was cool... I have recompiled with the new options in place. >> Here is all my out put that I got, I just let minicom capture it. It was >> stuck in a dead loop, so I kill power after a bit. Still have the first >> boot at 115200 and all others need to be at 57600 issue. >> Hopes this helps in the debug. > > Slowly we seem to be making progress. :) > > I /think/ the southbridge code needs some cleanup. It'll be a day or two > before I have time to look properly, but if you shove > > printk_debug("In VT8235 southbridge_enable\n"); > > in the southbridge_enable function in > /src/southbridge/via/vt8235/vt8235.c that'll at least show if it ever > gets that far. Don't worry if you don't have time though, as that whole > area definitely looks like it needs work anyway. > > The half baud rate problem is something I've seen mentioned before; > something to do with the southbridge and various clocks settling down? > I'll worry about it once other matters are sorted. ;) > > J. > > -- > jid: noodles at jabber.earth.li > noodles is the place to > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > -------------- next part -------------- A non-text attachment was scrubbed... Name: minicom2.cap.gz Type: application/x-gzip Size: 1758 bytes Desc: not available URL: From rminnich at lanl.gov Tue Jun 7 05:33:13 2005 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Mon, 6 Jun 2005 21:33:13 -0600 (MDT) Subject: [LinuxBIOS] EPIA-M status In-Reply-To: <20050606222506.GL10176@earth.li> References: <3174569B9743D511922F00A0C943142309F81813@TYANWEB> <001d01c5657f$bc7ce1c0$c501a8c0@newflame> <20050604104519.GX10176@earth.li> <20050606222506.GL10176@earth.li> Message-ID: <9670.128.165.0.81.1118115193.squirrel@webmail.lanl.gov> > On Sun, Jun 05, 2005 at 12:49:14AM -0600, Ronald G. Minnich wrote: >> we have fixes to epia. The commit via arch has failed. Once it is fixed, >> epia support is in. > > This is plain EPIA support, isn't it (ie vt8601/vt8231)? Any closer to > commit? Or is there even anywhere I can have a look at the diffs > involved? Ollie or Josiah, please send jonathan a copy of your working tree until we can get arch fixed. ron From yinghailu at gmail.com Tue Jun 7 06:02:24 2005 From: yinghailu at gmail.com (yhlu) Date: Mon, 6 Jun 2005 21:02:24 -0700 Subject: [BULK] RE: [LinuxBIOS] FYI: AMD support for cache as ram. In-Reply-To: <3174569B9743D511922F00A0C94314230A403B62@TYANWEB> References: <3174569B9743D511922F00A0C94314230A403B62@TYANWEB> Message-ID: <2ea3fae105060621025cc22e98@mail.gmail.com> I just figure out, the ss don't need to be changed. and only need to set the esp. It can get into amd64_main in failover. the it seems even the 64 range in cache can be read and write, but the result is not right. It means when clear all of range, the readout will still be 0xff.... #if 1 movl $CacheBase, %edi cld movl $04000, %ecx xorl %eax, %eax rep stosl #endif movl $CacheBase, %esi movl (%esi), %eax .testx: outb %al, $0x80 jmp .testx intel_chip_post_macro(0x22) /* post 22 */ Ollie, are you sure that your code can use 300 bytes in cache? YH From stepan at openbios.org Tue Jun 7 11:07:06 2005 From: stepan at openbios.org (Stefan Reinauer) Date: Tue, 7 Jun 2005 11:07:06 +0200 Subject: [LinuxBIOS] EPIA-M status In-Reply-To: <9670.128.165.0.81.1118115193.squirrel@webmail.lanl.gov> References: <3174569B9743D511922F00A0C943142309F81813@TYANWEB> <001d01c5657f$bc7ce1c0$c501a8c0@newflame> <20050604104519.GX10176@earth.li> <20050606222506.GL10176@earth.li> <9670.128.165.0.81.1118115193.squirrel@webmail.lanl.gov> Message-ID: <20050607090706.GA10679@openbios.org> * Ronald G. Minnich [050607 05:33]: > > This is plain EPIA support, isn't it (ie vt8601/vt8231)? Any closer to > > commit? Or is there even anywhere I can have a look at the diffs > > involved? > > Ollie or Josiah, please send jonathan a copy of your working tree until we > can get arch fixed. Arch is perfectly operational. Maybe this should wait for SVN? Stefan. From josiah at lanl.gov Tue Jun 7 17:08:22 2005 From: josiah at lanl.gov (Josiah England) Date: Tue, 07 Jun 2005 09:08:22 -0600 Subject: [LinuxBIOS] EPIA-M status In-Reply-To: <20050606222506.GL10176@earth.li> References: <3174569B9743D511922F00A0C943142309F81813@TYANWEB> <001d01c5657f$bc7ce1c0$c501a8c0@newflame> <20050604104519.GX10176@earth.li> <20050606222506.GL10176@earth.li> Message-ID: <1118156903.4940.6.camel@plipper.ccstar> On Mon, 2005-06-06 at 23:25 +0100, Jonathan McDowell wrote: > On Sun, Jun 05, 2005 at 12:49:14AM -0600, Ronald G. Minnich wrote: > > we have fixes to epia. The commit via arch has failed. Once it is fixed, > > epia support is in. > > This is plain EPIA support, isn't it (ie vt8601/vt8231)? Any closer to > commit? Or is there even anywhere I can have a look at the diffs > involved? > > J. Attached is the diffs file generated by 'tla changes --diffs'. For your convenience, I've also put a gzipped tarball at http://klassified.info/freebios2--tla33-epia.tar.gz but the host apparently takes forever to sync disks so it may not show up there just yet. -------------- next part -------------- * looking for linuxbios at linuxbios.org--devel/freebios--devel--2.0--patch-33 to compare with * comparing to linuxbios at linuxbios.org--devel/freebios--devel--2.0--patch-33 A src/southbridge/via/vt8231/.arch-ids/vt8231_acpi.c.id A src/southbridge/via/vt8231/.arch-ids/vt8231_ide.c.id A src/southbridge/via/vt8231/.arch-ids/vt8231_lpc.c.id A src/southbridge/via/vt8231/.arch-ids/vt8231_nic.c.id A src/southbridge/via/vt8231/.arch-ids/vt8231_usb.c.id A src/southbridge/via/vt8231/vt8231_acpi.c A src/southbridge/via/vt8231/vt8231_ide.c A src/southbridge/via/vt8231/vt8231_lpc.c A src/southbridge/via/vt8231/vt8231_nic.c A src/southbridge/via/vt8231/vt8231_usb.c -- {arch}/freebios/freebios--devel/freebios--devel--2.0/linuxbios at linuxbios.org--devel/patch-log/patch-13 -- {arch}/freebios/freebios--devel/freebios--devel--2.0/linuxbios at linuxbios.org--devel/patch-log/patch-14 M src/mainboard/via/epia/Options.lb M src/northbridge/via/vt8601/northbridge.c M src/northbridge/via/vt8601/raminit.c M src/southbridge/via/vt8231/Config.lb M src/southbridge/via/vt8231/chip.h M src/southbridge/via/vt8231/vt8231.c M src/mainboard/via/epia/Config.lb M src/mainboard/via/epia/auto.c M src/southbridge/via/vt8231/vt8231_early_smbus.c M targets/via/epia/Config.lb * file metadata changed ./{arch}/freebios/freebios--devel/freebios--devel--2.0/linuxbios at linuxbios.org--devel/patch-log/patch-13 --permissions 664 => --permissions 644 ./{arch}/freebios/freebios--devel/freebios--devel--2.0/linuxbios at linuxbios.org--devel/patch-log/patch-14 --permissions 664 => --permissions 644 * modified files --- orig/src/mainboard/via/epia/Config.lb +++ mod/src/mainboard/via/epia/Config.lb @@ -125,61 +125,70 @@ config chip.h chip northbridge/via/vt8601 - device pci_domain 0 on - device pci 0.0 on - chip southbridge/via/vt8231 - register "enable_usb" = "0" - register "enable_native_ide" = "0" - register "enable_com_ports" = "1" - register "enable_keyboard" = "0" - register "enable_nvram" = "1" - device pci 11.0 on # Southbridge - device pci 11.1 on end # Ide - device pci 11.2 off end # Usb - device pci 11.3 off end # Usb - device pci 11.4 off end # ACPI - device pci 11.5 off end # Audio - device pci 11.6 on # Com - chip superio/winbond/w83627hf - device pnp 2e.0 on # Floppy - io 0x60 = 0x3f0 - irq 0x70 = 6 - drq 0x74 = 2 - end - device pnp 2e.1 off # Parallel Port - io 0x60 = 0x378 - irq 0x70 = 7 - end - device pnp 2e.2 on # Com1 - io 0x60 = 0x3f8 - irq 0x70 = 4 - end - device pnp 2e.3 off # Com2 - io 0x60 = 0x2f8 - irq 0x70 = 3 - end - device pnp 2e.5 on # Keyboard - io 0x60 = 0x60 - io 0x62 = 0x64 - irq 0x70 = 1 - irq 0x72 = 12 - end - device pnp 2e.6 off end # CIR - device pnp 2e.7 off end # GAME_MIDI_GIPO1 - device pnp 2e.8 off end # GPIO2 - device pnp 2e.9 off end # GPIO3 - device pnp 2e.a off end # ACPI - device pnp 2e.b on # HW Monitor - io 0x60 = 0x290 - end - register "com1" = "{1}" - end - end - device pci 12.0 on end # Ethernet - end - end - end - end - chip cpu/via/model_centaur - end + device pci_domain 0 on + device pci 0.0 on end # Northbridge + device pci 0.1 on # AGP bridge + # chip drivers/pci/onboard # Integrated VGA + # device pci 0.0 on end + # register "rom_adress" = "0xfff80000" + # end + end + chip southbridge/via/vt8231 + register "enable_native_ide" = "0" + register "enable_com_ports" = "1" + register "enable_keyboard" = "0" + device pci 11.0 on # Southbrdge + chip superio/winbond/w83627hf + device pnp 2e.0 on # Floppy + io 0x60 = 0x3f0 + irq 0x70 = 6 + drq 0x74 = 2 + end + device pnp 2e.1 off # Parallel Port + io 0x60 = 0x378 + irq 0x70 = 7 + end + device pnp 2e.2 on # Com1 + io 0x60 = 0x3f8 + irq 0x70 = 4 + end + device pnp 2e.3 off # Com2 + io 0x60 = 0x2f8 + irq 0x70 = 3 + end + device pnp 2e.5 on # Keyboard + io 0x60 = 0x60 + io 0x62 = 0x64 + irq 0x70 = 1 + irq 0x72 = 12 + end + register "com1" = "{1}" + end + device pnp 2e.6 off end # CIR + device pnp 2e.7 off end # GAME_MIDI_GIPO1 + device pnp 2e.8 off end # GPIO2 + device pnp 2e.9 off end # GPIO3 + device pnp 2e.a off end # ACPI + device pnp 2e.b on # HW Monitor + io 0x60 = 0x290 + end + + end + device pci 11.1 on end # Ide + device pci 11.2 on end # Usb port 0-1 + device pci 11.3 on end # Usb port 2-3 + device pci 11.4 on end # ACPI + device pci 11.5 on end # AC97 Audio + device pci 11.6 on end # AC97 Modem + device pci 12.0 on end # Ethernet + end + end + + chip drivers/generic/debug + device pnp 0.0 off end + device pnp 0.1 off end + end + + chip cpu/via/model_centaur + end end --- orig/src/mainboard/via/epia/Options.lb +++ mod/src/mainboard/via/epia/Options.lb @@ -1,3 +1,10 @@ +uses MAXIMUM_CONSOLE_LOGLEVEL +uses DEFAULT_CONSOLE_LOGLEVEL +uses CONFIG_CONSOLE_SERIAL8250 +uses TTYS0_BAUD +uses TTYS0_BASE +uses TTYS0_LCS +uses CONFIG_CHIP_NAME uses HAVE_MP_TABLE uses HAVE_PIRQ_TABLE uses USE_FALLBACK_IMAGE @@ -40,6 +47,18 @@ uses DEFAULT_CONSOLE_LOGLEVEL uses MAXIMUM_CONSOLE_LOGLEVEL +default CONFIG_CONSOLE_SERIAL8250=1 +## Select the serial console baud rate +default TTYS0_BAUD=19200 + +# Select the serial console base port +default TTYS0_BASE=0x3f8 + +# Select the serial protocol +# This defaults to 8 data bits, 1 stop bit, and no parity +default TTYS0_LCS=0x3 + +default CONFIG_CHIP_NAME=1 ## ROM_SIZE is the size of boot ROM that this board will use. default ROM_SIZE = 256*1024 --- orig/src/mainboard/via/epia/auto.c +++ mod/src/mainboard/via/epia/auto.c @@ -2,9 +2,6 @@ #include #include -#if 0 -#include -#endif #include #include #include @@ -21,7 +18,7 @@ void udelay(int usecs) { int i; - for(i = 0; i < usecs; i++) + for (i = 0; i < usecs; i++) outb(i&0xff, 0x80); } @@ -30,18 +27,8 @@ #include "debug.c" #include "southbridge/via/vt8231/vt8231_early_smbus.c" - - #include "southbridge/via/vt8231/vt8231_early_serial.c" -static void memreset_setup(void) -{ -} -/* - static void memreset(int controllers, const struct mem_controller *ctrl) - { - } -*/ static inline int spd_read_byte(unsigned device, unsigned address) { unsigned char c; @@ -49,8 +36,6 @@ return c; } - - #include "northbridge/via/vt8601/raminit.c" /* #include "sdram/generic_sdram.c" @@ -66,6 +51,7 @@ if (dev == PCI_DEV_INVALID) { die("Southbridge not found!!!\n"); } + pci_write_config8(dev, 0x50, 7); pci_write_config8(dev, 0x51, 0xff); #if 0 @@ -87,9 +73,9 @@ static void enable_shadow_ram(void) { - device_t dev = 0; /* no need to look up 0:0.0 */ + device_t dev = 0; unsigned char shadowreg; - /* dev 0 for southbridge */ + shadowreg = pci_read_config8(dev, 0x63); /* 0xf0000-0xfffff */ shadowreg |= 0x30; @@ -113,8 +99,8 @@ enable_mainboard_devices(); enable_smbus(); enable_shadow_ram(); + /* - memreset_setup(); this is way more generic than we need. sdram_initialize(sizeof(cpu)/sizeof(cpu[0]), cpu); */ --- orig/src/northbridge/via/vt8601/northbridge.c +++ mod/src/northbridge/via/vt8601/northbridge.c @@ -29,8 +29,6 @@ pci_write_config8(dev, 0x76, 0x52); } - - static struct device_operations northbridge_operations = { .read_resources = pci_dev_read_resources, .set_resources = pci_dev_set_resources, @@ -46,8 +44,6 @@ .device = 0x0601, /* 0x8601 is the AGP bridge? */ }; - - #define BRIDGE_IO_MASK (IORESOURCE_IO | IORESOURCE_MEM) static void pci_domain_read_resources(device_t dev) --- orig/src/northbridge/via/vt8601/raminit.c +++ mod/src/northbridge/via/vt8601/raminit.c @@ -39,7 +39,7 @@ * might need to change some of register values. */ #ifndef DIMM_PC133 -#define DIMM_PC133 0 +#define DIMM_PC133 1 #endif // Set to 1 if your DIMMs are CL=2 @@ -47,32 +47,30 @@ #define DIMM_CL2 0 #endif -void dimms_read(unsigned long x) +void dimms_read(unsigned long x) { uint8_t c; - unsigned long eax; + unsigned long eax; volatile unsigned long y; - eax = x; - for(c = 0; c < 6; c++) { - y = * (volatile unsigned long *) eax; + eax = x; + for (c = 0; c < 6; c++) { + y = *(volatile unsigned long *) eax; eax += 0x10000000; } } -void dimms_write(int x) +void dimms_write(int x) { uint8_t c; unsigned long eax = x; - for(c = 0; c < 6; c++) { + for (c = 0; c < 6; c++) { *(volatile unsigned long *) eax = 0; eax += 0x10000000; } } - - #ifdef DEBUG_SETNORTHB -void setnorthb(device_t north, uint8_t reg, uint8_t val) +void setnorthb(device_t north, uint8_t reg, uint8_t val) { print_debug("setnorth: reg "); print_debug_hex8(reg); @@ -85,108 +83,108 @@ #define setnorthb pci_write_config8 #endif -void -dumpnorth(device_t north) +void dumpnorth(device_t north) { unsigned int r, c; - for(r = 0; ; r += 16) { + for (r = 0;; r += 16) { print_debug_hex8(r); print_debug(":"); - for(c = 0; c < 16; c++) { - print_debug_hex8(pci_read_config8(north, r+c)); + for (c = 0; c < 16; c++) { + print_debug_hex8(pci_read_config8(north, r + c)); print_debug(" "); } print_debug("\r\n"); if (r >= 240) break; - } + } } -static void sdram_set_registers(const struct mem_controller *ctrl) +static void sdram_set_registers(const struct mem_controller *ctrl) { - device_t north = (device_t) 0; + device_t north = (device_t) PCI_DEV(0, 0, 0); uint8_t c, r; print_err("vt8601 init starting\r\n"); - north = pci_locate_device(PCI_ID(0x1106, 0x8601), 0); - north = 0; print_debug_hex32(north); print_debug(" is the north\n"); print_debug_hex16(pci_read_config16(north, 0)); print_debug(" "); print_debug_hex16(pci_read_config16(north, 2)); print_debug("\r\n"); - + /* All we are doing now is setting initial known-good values that will * be revised later as we read SPD - */ + */ + // memory clk enable. We are not using ECC - pci_write_config8(north,0x78, 0x01); + pci_write_config8(north, 0x78, 0x01); print_debug_hex8(pci_read_config8(north, 0x78)); + // dram control, see the book. #if DIMM_PC133 - pci_write_config8(north,0x68, 0x52); + pci_write_config8(north, 0x68, 0x52); #else - pci_write_config8(north,0x68, 0x42); + pci_write_config8(north, 0x68, 0x42); #endif + // dram control, see the book. - pci_write_config8(north,0x6B, 0x0c); + pci_write_config8(north, 0x6B, 0x0c); + // Initial setting, 256MB in each bank, will be rewritten later. - pci_write_config8(north,0x5A, 0x20); + pci_write_config8(north, 0x5A, 0x20); print_debug_hex8(pci_read_config8(north, 0x5a)); - pci_write_config8(north,0x5B, 0x40); - pci_write_config8(north,0x5C, 0x60); - pci_write_config8(north,0x5D, 0x80); - pci_write_config8(north,0x5E, 0xA0); - pci_write_config8(north,0x5F, 0xC0); + pci_write_config8(north, 0x5B, 0x40); + pci_write_config8(north, 0x5C, 0x60); + pci_write_config8(north, 0x5D, 0x80); + pci_write_config8(north, 0x5E, 0xA0); + pci_write_config8(north, 0x5F, 0xC0); // It seems we have to take care of these 2 registers as if // they are bank 6 and 7. - pci_write_config8(north,0x56, 0xC0); - pci_write_config8(north,0x57, 0xC0); - + pci_write_config8(north, 0x56, 0xC0); + pci_write_config8(north, 0x57, 0xC0); + // SDRAM in all banks - pci_write_config8(north,0x60, 0x3F); + pci_write_config8(north, 0x60, 0x3F); + // DRAM timing. I'm suspicious of this // This is for all banks, 64 is 0,1. 65 is 2,3. 66 is 4,5. // ras precharge 4T, RAS pulse 5T // cas2 is 0xd6, cas3 is 0xe6 // we're also backing off write pulse width to 2T, so result is 0xee #if DIMM_CL2 - pci_write_config8(north,0x64, 0xd4); - pci_write_config8(north,0x65, 0xd4); - pci_write_config8(north,0x66, 0xd4); -#else // CL=3 - pci_write_config8(north,0x64, 0xe4); - pci_write_config8(north,0x65, 0xe4); - pci_write_config8(north,0x66, 0xe4); + pci_write_config8(north, 0x64, 0xd4); + pci_write_config8(north, 0x65, 0xd4); + pci_write_config8(north, 0x66, 0xd4); +#else // CL=3 + pci_write_config8(north, 0x64, 0xe4); + pci_write_config8(north, 0x65, 0xe4); + pci_write_config8(north, 0x66, 0xe4); #endif // dram frequency select. // enable 4K pages for 64M dram. #if DIMM_PC133 - pci_write_config8(north,0x69, 0x3c); + pci_write_config8(north, 0x69, 0x3c); #else - pci_write_config8(north,0x69, 0xac); + pci_write_config8(north, 0x69, 0xac); #endif /* IMPORTANT -- disable refresh counter */ // refresh counter, disabled. - pci_write_config8(north,0x6A, 0x00); - + pci_write_config8(north, 0x6A, 0x00); // clkenable configuration. kevinh FIXME - add precharge - pci_write_config8(north,0x6C, 0x00); + pci_write_config8(north, 0x6C, 0x00); // dram read latch delay of 1 ns, MD drive 8 mA, - // high drive strength on MA[2: 13], we#, cas#, ras# + // high drive strength on MA[2: 13], we#, cas#, ras# // As per Cindy Lee, set to 0x37, not 0x57 - pci_write_config8(north,0x6D, 0x7f); + pci_write_config8(north, 0x6D, 0x7f); } /* slot is the dram slot. Return size of side0 in lower 16-bit, * side1 in upper 16-bit, in units of 8MB */ -static unsigned long -spd_module_size(unsigned char slot) -{ +static unsigned long spd_module_size(unsigned char slot) +{ /* for all the DRAMS, see if they are there and get the size of each * module. This is just a very early first cut at sizing. */ @@ -195,21 +193,31 @@ unsigned int value = 0; /* unsigned int module = ((0x50 + slot) << 1) + 1; */ unsigned int module = 0x50 + slot; + /* is the module there? if byte 2 is not 4, then we'll assume it * is useless. */ - print_info("Slot "); - print_info_hex8(slot); + print_info("Slot "); + print_info_hex8(slot); if (smbus_read_byte(module, 2) != 4) { print_info(" is empty\r\n"); return 0; } print_info(" is SDRAM "); - + banks = smbus_read_byte(module, 17); + /* we're going to assume symmetric banks. Sorry. */ - cols = smbus_read_byte(module, 4) & 0xf; - rows = smbus_read_byte(module, 3) & 0xf; + cols = smbus_read_byte(module, 4) & 0xf; + rows = smbus_read_byte(module, 3) & 0xf; + +// print_info("banks"); +// print_info_hex8(banks); +// print_info("cols"); +// print_info_hex8(cols); +// print_info("banks"); +// print_info_hex8(rows); + /* grand total. You have rows+cols addressing, * times of banks, times * width of data in bytes */ /* Width is assumed to be 64 bits == 8 bytes */ @@ -229,10 +237,8 @@ } -static int -spd_num_chips(unsigned char slot) -{ -/* unsigned int module = ((0x50 + slot) << 1) + 1; */ +static int spd_num_chips(unsigned char slot) +{ unsigned int module = 0x50 + slot; unsigned int width; @@ -249,20 +255,21 @@ unsigned char timing = 0xe4; /* read Trp */ val = smbus_read_byte(0x50, 27); - if (val < 2*T133) + if (val < 2 * T133) Trp = 1; val = smbus_read_byte(0x50, 30); - if (val < 5*T133) + if (val < 5 * T133) Tras = 0; val = smbus_read_byte(0x50, 18); if (val < 8) casl = 1; if (val < 4) casl = 0; - + val = (Trp << 7) | (Tras << 6) | (casl << 4) | 4; - - print_debug_hex8(val); print_debug(" is the computed timing\n"); + + print_debug_hex8(val); + print_debug(" is the computed timing\n"); /* don't set it. Experience shows that this screwy chipset should just * be run with the most conservative timing. * pci_write_config8(0, 0x64, val); @@ -271,23 +278,23 @@ static void set_ma_mapping(device_t north, int slot, int type) { - unsigned char reg, val; - int shift; + unsigned char reg, val; + int shift; - reg = 0x58 + slot/2; - if (slot%2 >= 1) - shift = 0; - else - shift = 4; - - val = pci_read_config8(north, reg); - val &= ~(0xf << shift); - val |= type << shift; - pci_write_config8(north, reg, val); + reg = 0x58 + slot / 2; + if (slot % 2 >= 1) + shift = 0; + else + shift = 4; + + val = pci_read_config8(north, reg); + val &= ~(0xf << shift); + val |= type << shift; + pci_write_config8(north, reg, val); } -static void sdram_enable(int controllers, const struct mem_controller *ctrl) +static void sdram_enable(int controllers, const struct mem_controller *ctrl) { unsigned char i; static const uint8_t ramregs[] = { @@ -295,29 +302,30 @@ }; device_t north = 0; uint32_t size, base, slot, ma; - /* begin to initialize*/ + /* begin to initialize */ + // I forget why we need this, but we do dimms_write(0xa55a5aa5); - - /* set NOP*/ - pci_write_config8(north,0x6C, 0x01); + + /* set NOP */ + pci_write_config8(north, 0x6C, 0x01); print_debug("NOP\r\n"); - /* wait 200us*/ + /* wait 200us */ // You need to do the memory reference. That causes the nop cycle. dimms_read(0); udelay(400); print_debug("PRECHARGE\r\n"); /* set precharge */ - pci_write_config8(north,0x6C, 0x02); + pci_write_config8(north, 0x6C, 0x02); print_debug("DUMMY READS\r\n"); - /* dummy reads*/ + /* dummy reads */ dimms_read(0); udelay(200); print_debug("CBR\r\n"); - /* set CBR*/ - pci_write_config8(north,0x6C, 0x04); - - /* do 8 reads and wait >100us between each - from via*/ + /* set CBR */ + pci_write_config8(north, 0x6C, 0x04); + + /* do 8 reads and wait >100us between each - from via */ dimms_read(0); udelay(200); dimms_read(0); @@ -335,43 +343,43 @@ dimms_read(0); udelay(200); print_debug("MRS\r\n"); - /* set MRS*/ - pci_write_config8(north,0x6c, 0x03); + /* set MRS */ + pci_write_config8(north, 0x6c, 0x03); #if DIMM_CL2 dimms_read(0x150); -#else // CL=3 +#else // CL=3 dimms_read(0x1d0); #endif udelay(200); print_debug("NORMAL\r\n"); /* set to normal mode */ - pci_write_config8(north,0x6C, 0x08); - + pci_write_config8(north, 0x6C, 0x08); + dimms_write(0x55aa55aa); dimms_read(0); udelay(200); print_debug("set ref. rate\r\n"); // Set the refresh rate. #if DIMM_PC133 - pci_write_config8(north,0x6A, 0x86); + pci_write_config8(north, 0x6A, 0x86); #else - pci_write_config8(north,0x6A, 0x65); + pci_write_config8(north, 0x6A, 0x65); #endif print_debug("enable multi-page open\r\n"); // enable multi-page open - pci_write_config8(north,0x6B, 0x0d); - + pci_write_config8(north, 0x6B, 0x0d); + base = 0; - for(slot = 0; slot < 4; slot++) { + for (slot = 0; slot < 4; slot++) { size = spd_module_size(slot); /* side 0 */ base += size & 0xffff; - pci_write_config8(north, ramregs[2*slot], base); + pci_write_config8(north, ramregs[2 * slot], base); /* side 1 */ base += size >> 16; if (base > 0xff) base = 0xff; - pci_write_config8(north, ramregs[2*slot + 1], base); + pci_write_config8(north, ramregs[2 * slot + 1], base); if (!size) continue; @@ -379,13 +387,13 @@ /* Calculate the value of MA mapping type register, * based on size of SDRAM chips. */ size = (size & 0xffff) << (3 + 3); - /* convert module size to be in Mbits */ + /* convert module size to be in Mbits */ size /= spd_num_chips(slot); print_debug_hex16(size); print_debug(" is the chip size\r\n"); if (size < 64) ma = 0; - if (size < 256) + else if (size < 256) ma = 8; else ma = 0xe; --- orig/src/southbridge/via/vt8231/Config.lb +++ mod/src/southbridge/via/vt8231/Config.lb @@ -1,2 +1,8 @@ config chip.h -object vt8231.o +driver vt8231.o +driver vt8231_lpc.o +driver vt8231_acpi.o +driver vt8231_ide.o +driver vt8231_nic.o +#driver vt8231_usb.o + --- orig/src/southbridge/via/vt8231/chip.h +++ mod/src/southbridge/via/vt8231/chip.h @@ -4,18 +4,10 @@ extern struct chip_operations southbridge_via_vt8231_ops; struct southbridge_via_vt8231_config { - /* PCI function enables */ - /* i.e. so that pci scan bus will find them. */ - /* I am putting in IDE as an example but obviously this needs - * to be more complete! - */ - int enable_ide; - /* enables of functions of devices */ - int enable_usb; + /* enables of Non-PCI devices */ int enable_native_ide; int enable_com_ports; int enable_keyboard; - int enable_nvram; }; #endif /* _SOUTHBRIDGE_VIA_VT8231 */ --- orig/src/southbridge/via/vt8231/vt8231.c +++ mod/src/southbridge/via/vt8231/vt8231.c @@ -1,441 +1,73 @@ - -#include +#include #include #include #include #include -#include + +#include +#include + #include "vt8231.h" #include "chip.h" -void pc_keyboard_init(void); +/* Base 8231 controller */ +static device_t lpc_dev; -void hard_reset(void) +void hard_reset(void) { - printk_err("NO HARD RESET ON VT8231! FIX ME!\n"); -} - -static void usb_on(int enable) -{ - unsigned char regval; - - /* Base 8231 controller */ - device_t dev0 = dev_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8231, 0); - /* USB controller 1 */ - device_t dev2 = dev_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2, 0); - /* USB controller 2 */ - device_t dev3 = dev_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2, dev2); - - /* enable USB1 */ - if(dev2) { - if (enable) { - pci_write_config8(dev2, 0x3c, 0x05); - pci_write_config8(dev2, 0x04, 0x07); - } else { - pci_write_config8(dev2, 0x3c, 0x00); - pci_write_config8(dev2, 0x04, 0x00); - } - } - - if(dev0) { - regval = pci_read_config8(dev0, 0x50); - if (enable) - regval &= ~(0x10); - else - regval |= 0x10; - pci_write_config8(dev0, 0x50, regval); - } - - /* enable USB2 */ - if(dev3) { - if (enable) { - pci_write_config8(dev3, 0x3c, 0x05); - pci_write_config8(dev3, 0x04, 0x07); - } else { - pci_write_config8(dev3, 0x3c, 0x00); - pci_write_config8(dev3, 0x04, 0x00); - } - } - - if(dev0) { - regval = pci_read_config8(dev0, 0x50); - if (enable) - regval &= ~(0x20); - else - regval |= 0x20; - pci_write_config8(dev0, 0x50, regval); - } + printk_err("NO HARD RESET ON VT8231! FIX ME!\n"); } static void keyboard_on(void) { unsigned char regval; - - /* Base 8231 controller */ - device_t dev0 = dev_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8231, 0); - - /* kevinh/Ispiri - update entire function to use - new pci_write_config8 */ - if (dev0) { - regval = pci_read_config8(dev0, 0x51); + if (lpc_dev) { + regval = pci_read_config8(lpc_dev, 0x51); regval |= 0x0f; - pci_write_config8(dev0, 0x51, regval); + pci_write_config8(lpc_dev, 0x51, regval); } init_pc_keyboard(0x60, 0x64, 0); } -static void nvram_on(void) +static void com_port_on(void) { - /* - * the VIA 8231 South has a very different nvram setup than the - * piix4e ... - * turn on ProMedia nvram. - * TO DO: use the PciWriteByte function here. - */ +#if 0 + // enable com1 and com2. + enables = pci_read_config8(dev, 0x6e); - /* - * kevinh/Ispiri - I don't think this is the correct address/value - * intel_conf_writeb(0x80008841, 0xFF); + /* 0x80 is enable com port b, 0x10 is to make it com2, 0x8 + * is enable com port a as com1 kevinh/Ispiri - Old code + * thought 0x01 would make it com1, that was wrong enables = + * 0x80 | 0x10 | 0x8 ; pci_write_config8(dev, 0x6e, + * enables); // note: this is also a redo of some port of + * assembly, but we want everything up. */ -} - -/* - * Enable the ethernet device and turn off stepping (because it is integrated - * inside the southbridge) - */ -static void ethernet_fixup() -{ - device_t edev; - uint8_t byte; - - printk_info("Ethernet fixup\n"); - - edev = dev_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8233_7, 0); - if (edev) { - printk_debug("Configuring VIA LAN\n"); - - /* We don't need stepping - though the device supports it */ - byte = pci_read_config8(edev, PCI_COMMAND); - byte &= ~PCI_COMMAND_WAIT; - pci_write_config8(edev, PCI_COMMAND, byte); - } else { - printk_debug("VIA LAN not found\n"); - } -} - - -/* we need to do things in this function so that PCI scan will find - * them. One problem here is that we can't use ANY of the new device - * stuff. This work here precedes all that. - * Fundamental problem with linuxbios V2 architecture. - * You can't do pci control in the C code without having done a PCI scan. - * But in some cases you need to to pci control in the c code before doing - * a PCI scan. But you can't use arch/romcc_io.h (the code you need) because - * that has functions with the same name but different type signatures - * (e.g. device_t). This needs to get fixed. We need low-level pci scans - * in the C code. - */ -static void vt8231_pci_enable(struct southbridge_via_vt8231_config *conf) -{ - /* - unsigned long busdevfn = 0x8000; - if (conf->enable_ide) { - printk_debug("%s: enabling IDE function\n", __FUNCTION__); - } - */ -} - -/* PIRQ init - */ -void pci_assign_irqs(unsigned bus, unsigned slot, const unsigned char pIntAtoD[4]); - - -static const unsigned char southbridgeIrqs[4] = { 11, 5, 10, 12 }; -static const unsigned char enetIrqs[4] = { 11, 5, 10, 12 }; -static const unsigned char slotIrqs[4] = { 5, 10, 12, 11 }; - -/* - Our IDSEL mappings are as follows - PCI slot is AD31 (device 15) (00:14.0) - Southbridge is AD28 (device 12) (00:11.0) -*/ -static void pci_routing_fixup(struct device *dev) -{ - - printk_info("%s: dev is %p\n", __FUNCTION__, dev); - if (dev) { - /* initialize PCI interupts - these assignments depend - on the PCB routing of PINTA-D - - PINTA = IRQ11 - PINTB = IRQ5 - PINTC = IRQ10 - PINTD = IRQ12 - */ - pci_write_config8(dev, 0x55, 0xb0); - pci_write_config8(dev, 0x56, 0xa5); - pci_write_config8(dev, 0x57, 0xc0); - } - - // Standard southbridge components - printk_info("setting southbridge\n"); - pci_assign_irqs(0, 0x11, southbridgeIrqs); - - // Ethernet built into southbridge - printk_info("setting ethernet\n"); - pci_assign_irqs(0, 0x12, enetIrqs); - - // PCI slot - printk_info("setting pci slot\n"); - pci_assign_irqs(0, 0x14, slotIrqs); - printk_info("%s: DONE\n", __FUNCTION__); -} - - -void -dump_south(void) -{ - device_t dev0; - dev0 = dev_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8231, 0); - int i,j; - - for(i = 0; i < 256; i += 16) { - printk_debug("0x%x: ", i); - for(j = 0; j < 16; j++) { - printk_debug("%02x ", pci_read_config8(dev0, i+j)); - } - printk_debug("\n"); - } + /* set com1 to 115 kbaud not clear how to do this yet. + * forget it; done in assembly. + */ +#endif } -static void vt8231_init(struct southbridge_via_vt8231_config *conf) +/* FixME: to be removed ? */ +static void vt8231_enable(struct device *dev) { - unsigned char enables; - device_t dev0; - device_t dev1; - device_t devpwr; - - // to do: use the pcibios_find function here, instead of - // hard coding the devfn. - // done - kevinh/Ispiri - printk_debug("vt8231 init\n"); - /* Base 8231 controller */ - dev0 = dev_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8231, 0); - /* IDE controller */ - dev1 = dev_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1, 0); - /* Power management controller */ - devpwr = dev_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8231_4, 0); - - // enable the internal I/O decode - enables = pci_read_config8(dev0, 0x6C); - enables |= 0x80; - pci_write_config8(dev0, 0x6C, enables); - - // Map 4MB of FLASH into the address space - pci_write_config8(dev0, 0x41, 0x7f); - - // Set bit 6 of 0x40, because Award does it (IO recovery time) - // IMPORTANT FIX - EISA 0x4d0 decoding must be on so that PCI - // interrupts can be properly marked as level triggered. - enables = pci_read_config8(dev0, 0x40); - pci_write_config8(dev0, 0x40, enables); - - // Set 0x42 to 0xf0 to match Award bios - enables = pci_read_config8(dev0, 0x42); - enables |= 0xf0; - pci_write_config8(dev0, 0x42, enables); - - // Set bit 3 of 0x4a, to match award (dummy pci request) - enables = pci_read_config8(dev0, 0x4a); - enables |= 0x08; - pci_write_config8(dev0, 0x4a, enables); - - // Set bit 3 of 0x4f to match award (use INIT# as cpu reset) - enables = pci_read_config8(dev0, 0x4f); - enables |= 0x08; - pci_write_config8(dev0, 0x4f, enables); - - // Set 0x58 to 0x03 to match Award - pci_write_config8(dev0, 0x58, 0x03); - - // enable the ethernet/RTC - if(dev0) { - enables = pci_read_config8(dev0, 0x51); - enables |= 0x18; - pci_write_config8(dev0, 0x51, enables); - } - - - // enable com1 and com2. - if (conf->enable_com_ports) { - enables = pci_read_config8(dev0, 0x6e); - - /* 0x80 is enable com port b, 0x10 is to make it com2, 0x8 - * is enable com port a as com1 kevinh/Ispiri - Old code - * thought 0x01 would make it com1, that was wrong enables = - * 0x80 | 0x10 | 0x8 ; pci_write_config8(dev0, 0x6e, - * enables); // note: this is also a redo of some port of - * assembly, but we want everything up. - */ - - /* set com1 to 115 kbaud not clear how to do this yet. - * forget it; done in assembly. - */ + struct southbridge_via_vt8231_config *conf = dev->chip_info; + if (!lpc_dev) { + /* the first time called, enable devices not on PCI bus + * FIXME: is that device struct there yet? */ + lpc_dev = dev_find_device(PCI_VENDOR_ID_VIA, + PCI_DEVICE_ID_VIA_8231, 0); + if (conf->enable_keyboard) + keyboard_on(); + if (conf->enable_com_ports) + com_port_on(); } - // enable IDE, since Linux won't do it. - // First do some more things to devfn (17,0) - // note: this should already be cleared, according to the book. - enables = pci_read_config8(dev0, 0x50); - printk_debug("IDE enable in reg. 50 is 0x%x\n", enables); - enables &= ~8; // need manifest constant here! - printk_debug("set IDE reg. 50 to 0x%x\n", enables); - pci_write_config8(dev0, 0x50, enables); - - // set default interrupt values (IDE) - enables = pci_read_config8(dev0, 0x4c); - printk_debug("IRQs in reg. 4c are 0x%x\n", enables & 0xf); - // clear out whatever was there. - enables &= ~0xf; - enables |= 4; - printk_debug("setting reg. 4c to 0x%x\n", enables); - pci_write_config8(dev0, 0x4c, enables); - - // set up the serial port interrupts. - // com2 to 3, com1 to 4 - pci_write_config8(dev0, 0x46, 0x04); - pci_write_config8(dev0, 0x47, 0x03); - pci_write_config8(dev0, 0x6e, 0x98); - // - // Power management setup - // - // Set ACPI base address to IO 0x4000 - pci_write_config32(devpwr, 0x48, 0x4001); - - // Enable ACPI access (and setup like award) - pci_write_config8(devpwr, 0x41, 0x84); - - // Set hardware monitor base address to IO 0x6000 - pci_write_config32(devpwr, 0x70, 0x6001); - - // Enable hardware monitor (and setup like award) - pci_write_config8(devpwr, 0x74, 0x01); - - // set IO base address to 0x5000 - pci_write_config32(devpwr, 0x90, 0x5001); - - // Enable SMBus - pci_write_config8(devpwr, 0xd2, 0x01); - - // - // IDE setup - // - if (! conf->enable_native_ide) { - // Run the IDE controller in 'compatiblity mode - i.e. don't use PCI - // interrupts. Using PCI ints confuses linux for some reason. - - printk_info("%s: enabling compatibility IDE addresses\n", __FUNCTION__); - enables = pci_read_config8(dev1, 0x42); - printk_debug("enables in reg 0x42 0x%x\n", enables); - enables &= ~0xc0; // compatability mode - pci_write_config8(dev1, 0x42, enables); - enables = pci_read_config8(dev1, 0x42); - printk_debug("enables in reg 0x42 read back as 0x%x\n", enables); - } - - enables = pci_read_config8(dev1, 0x40); - printk_debug("enables in reg 0x40 0x%x\n", enables); - enables |= 3; - pci_write_config8(dev1, 0x40, enables); - enables = pci_read_config8(dev1, 0x40); - printk_debug("enables in reg 0x40 read back as 0x%x\n", enables); - - // Enable prefetch buffers - enables = pci_read_config8(dev1, 0x41); - enables |= 0xf0; - pci_write_config8(dev1, 0x41, enables); - - // Lower thresholds (cause award does it) - enables = pci_read_config8(dev1, 0x43); - enables &= ~0x0f; - enables |= 0x05; - pci_write_config8(dev1, 0x43, enables); - - // PIO read prefetch counter (cause award does it) - pci_write_config8(dev1, 0x44, 0x18); - - // Use memory read multiple - pci_write_config8(dev1, 0x45, 0x1c); - - // address decoding. - // we want "flexible", i.e. 1f0-1f7 etc. or native PCI - // kevinh at ispiri.com - the standard linux drivers seem ass slow when - // used in native mode - I've changed back to classic - enables = pci_read_config8(dev1, 0x9); - printk_debug("enables in reg 0x9 0x%x\n", enables); - // by the book, set the low-order nibble to 0xa. - if (conf->enable_native_ide) { - enables &= ~0xf; - // cf/cg silicon needs an 'f' here. - enables |= 0xf; - } else { - enables &= ~0x5; - } - - pci_write_config8(dev1, 0x9, enables); - enables = pci_read_config8(dev1, 0x9); - printk_debug("enables in reg 0x9 read back as 0x%x\n", enables); - - // standard bios sets master bit. - enables = pci_read_config8(dev1, 0x4); - printk_debug("command in reg 0x4 0x%x\n", enables); - enables |= 7; - - // No need for stepping - kevinh at ispiri.com - enables &= ~0x80; - - pci_write_config8(dev1, 0x4, enables); - enables = pci_read_config8(dev1, 0x4); - printk_debug("command in reg 0x4 reads back as 0x%x\n", enables); - - if (! conf->enable_native_ide) { - // Use compatability mode - per award bios - pci_write_config32(dev1, 0x10, 0x0); - pci_write_config32(dev1, 0x14, 0x0); - pci_write_config32(dev1, 0x18, 0x0); - pci_write_config32(dev1, 0x1c, 0x0); - - // Force interrupts to use compat mode - just like Award bios - pci_write_config8(dev1, 0x3d, 00); - pci_write_config8(dev1, 0x3c, 0xff); - } - - - /* set up isa bus -- i/o recovery time, rom write enable, extend-ale */ - pci_write_config8(dev0, 0x40, 0x54); - ethernet_fixup(); - - // Start the rtc - rtc_init(0); -} - -static void southbridge_init(struct device *dev) { - vt8231_init(dev->chip_info); - pci_routing_fixup(dev); -} - -struct device_operations vt8231_dev_ops = { - .init = &southbridge_init, -}; - -static void southbridge_enable(struct device *dev) -{ - dev->ops = &vt8231_dev_ops; } struct chip_operations southbridge_via_vt8231_ops = { CHIP_NAME("VIA vt8231") - .enable_dev = southbridge_enable, + .enable_dev = vt8231_enable, }; --- orig/src/southbridge/via/vt8231/vt8231_early_smbus.c +++ mod/src/southbridge/via/vt8231/vt8231_early_smbus.c @@ -12,12 +12,12 @@ #define SMBTRNSADD 0x9 #define SMBSLVDATA 0xa #define SMLINK_PIN_CTL 0xe -#define SMBUS_PIN_CTL 0xf +#define SMBUS_PIN_CTL 0xf /* Define register settings */ #define HOST_RESET 0xff -#define DIMM_BASE 0xa0 // 1010000 is base for DIMM in SMBus -#define READ_CMD 0x01 // 1 in the 0 bit of SMBHSTADD states to READ +#define DIMM_BASE 0xa0 // 1010000 is base for DIMM in SMBus +#define READ_CMD 0x01 // 1 in the 0 bit of SMBHSTADD states to READ #define SMBUS_TIMEOUT (100*1000*10) @@ -27,29 +27,28 @@ device_t dev; unsigned char c; /* Power management controller */ - dev = pci_locate_device(PCI_ID(0x1106,0x8235), 0); - + dev = pci_locate_device(PCI_ID(0x1106, 0x8235), 0); + if (dev == PCI_DEV_INVALID) { die("SMBUS controller not found\r\n"); } - // set IO base address to SMBUS_IO_BASE - pci_write_config32(dev, 0x90, SMBUS_IO_BASE|1); - + pci_write_config32(dev, 0x90, SMBUS_IO_BASE | 1); + // Enable SMBus c = pci_read_config8(dev, 0xd2); c |= 5; pci_write_config8(dev, 0xd2, c); - + /* make it work for I/O ... */ - dev = pci_locate_device(PCI_ID(0x1106,0x8231), 0); + dev = pci_locate_device(PCI_ID(0x1106, 0x8231), 0); c = pci_read_config8(dev, 4); c |= 1; pci_write_config8(dev, 4, c); print_debug_hex8(c); print_debug(" is the comm register\r\n"); - + print_debug("SMBus controller enabled\r\n"); } @@ -61,52 +60,51 @@ static int smbus_wait_until_active(void) { - unsigned long loops; - loops = SMBUS_TIMEOUT; - do { - unsigned char val; - smbus_delay(); - val = inb(SMBUS_IO_BASE + SMBHSTSTAT); - if ((val & 1)) { - break; - } - } while(--loops); - return loops?0:-4; + unsigned long loops; + loops = SMBUS_TIMEOUT; + do { + unsigned char val; + smbus_delay(); + val = inb(SMBUS_IO_BASE + SMBHSTSTAT); + if ((val & 1)) { + break; + } + } while (--loops); + return loops ? 0 : -4; } static int smbus_wait_until_ready(void) { - unsigned long loops; - loops = SMBUS_TIMEOUT; - do { - unsigned char val; - smbus_delay(); - val = inb(SMBUS_IO_BASE + SMBHSTSTAT); - if ((val & 1) == 0) { - break; - } - if(loops == (SMBUS_TIMEOUT / 2)) { - outb(inb(SMBUS_IO_BASE + SMBHSTSTAT), - SMBUS_IO_BASE + SMBHSTSTAT); - } - } while(--loops); - return loops?0:-2; + unsigned long loops; + loops = SMBUS_TIMEOUT; + do { + unsigned char val; + smbus_delay(); + val = inb(SMBUS_IO_BASE + SMBHSTSTAT); + if ((val & 1) == 0) { + break; + } + if (loops == (SMBUS_TIMEOUT / 2)) { + outb(inb(SMBUS_IO_BASE + SMBHSTSTAT), SMBUS_IO_BASE + SMBHSTSTAT); + } + } while (--loops); + return loops ? 0 : -2; } static int smbus_wait_until_done(void) { - unsigned long loops; - loops = SMBUS_TIMEOUT; - do { - unsigned char val; - smbus_delay(); - - val = inb(SMBUS_IO_BASE + SMBHSTSTAT); - if ( (val & 1) == 0) { - break; - } - } while(--loops); - return loops?0:-3; + unsigned long loops; + loops = SMBUS_TIMEOUT; + do { + unsigned char val; + smbus_delay(); + + val = inb(SMBUS_IO_BASE + SMBHSTSTAT); + if ((val & 1) == 0) { + break; + } + } while (--loops); + return loops ? 0 : -3; } void smbus_reset(void) @@ -115,13 +113,13 @@ outb(HOST_RESET, SMBUS_IO_BASE + SMBHSTSTAT); outb(HOST_RESET, SMBUS_IO_BASE + SMBHSTSTAT); outb(HOST_RESET, SMBUS_IO_BASE + SMBHSTSTAT); - + smbus_wait_until_ready(); print_debug("After reset status "); - print_debug_hex8( inb(SMBUS_IO_BASE + SMBHSTSTAT)); + print_debug_hex8(inb(SMBUS_IO_BASE + SMBHSTSTAT)); print_debug("\r\n"); } - + static void smbus_print_error(unsigned char host_status_register) { @@ -152,96 +150,95 @@ */ static int smbus_read_byte(unsigned device, unsigned address) { - unsigned char global_control_register; - unsigned char global_status_register; - unsigned char byte; - - if (smbus_wait_until_ready() < 0) { - outb(inb(SMBUS_IO_BASE + SMBHSTSTAT), SMBUS_IO_BASE + SMBHSTSTAT); - if ( smbus_wait_until_ready() < 0 ) { - return -2; - } - } - - /* setup transaction */ - /* disable interrupts */ - outb(inb(SMBUS_IO_BASE + SMBHSTCTL) & 0xfe, SMBUS_IO_BASE + SMBHSTCTL); - /* set the device I'm talking too */ - outb(((device & 0x7f) << 1) | 1, SMBUS_IO_BASE + SMBXMITADD); - /* set the command/address... */ - outb(address & 0xFF, SMBUS_IO_BASE + SMBHSTCMD); - /* set up for a byte data read */ - outb((inb(SMBUS_IO_BASE + SMBHSTCTL) & 0xe3) | (0x2<<2), SMBUS_IO_BASE + SMBHSTCTL); - - /* clear any lingering errors, so the transaction will run */ - outb(inb(SMBUS_IO_BASE + SMBHSTSTAT), SMBUS_IO_BASE + SMBHSTSTAT); - - /* clear the data byte...*/ - outb(0, SMBUS_IO_BASE + SMBHSTDAT0); - - /* start a byte read, with interrupts disabled */ - outb((inb(SMBUS_IO_BASE + SMBHSTCTL) | 0x40), SMBUS_IO_BASE + SMBHSTCTL); - /* poll for it to start */ - if (smbus_wait_until_active() < 0) { - return -4; - } - - /* poll for transaction completion */ - if (smbus_wait_until_done() < 0) { - return -3; - } + unsigned char global_control_register; + unsigned char global_status_register; + unsigned char byte; + + if (smbus_wait_until_ready() < 0) { + outb(inb(SMBUS_IO_BASE + SMBHSTSTAT), SMBUS_IO_BASE + SMBHSTSTAT); + if (smbus_wait_until_ready() < 0) { + return -2; + } + } + + /* setup transaction */ + /* disable interrupts */ + outb(inb(SMBUS_IO_BASE + SMBHSTCTL) & 0xfe, SMBUS_IO_BASE + SMBHSTCTL); + /* set the device I'm talking too */ + outb(((device & 0x7f) << 1) | 1, SMBUS_IO_BASE + SMBXMITADD); + /* set the command/address... */ + outb(address & 0xFF, SMBUS_IO_BASE + SMBHSTCMD); + /* set up for a byte data read */ + outb((inb(SMBUS_IO_BASE + SMBHSTCTL) & 0xe3) | (0x2 << 2), SMBUS_IO_BASE + SMBHSTCTL); + + /* clear any lingering errors, so the transaction will run */ + outb(inb(SMBUS_IO_BASE + SMBHSTSTAT), SMBUS_IO_BASE + SMBHSTSTAT); + + /* clear the data byte... */ + outb(0, SMBUS_IO_BASE + SMBHSTDAT0); + + /* start a byte read, with interrupts disabled */ + outb((inb(SMBUS_IO_BASE + SMBHSTCTL) | 0x40), SMBUS_IO_BASE + SMBHSTCTL); + /* poll for it to start */ + if (smbus_wait_until_active() < 0) { + return -4; + } + + /* poll for transaction completion */ + if (smbus_wait_until_done() < 0) { + return -3; + } /* Ignore the Host Busy & Command Complete ? */ - global_status_register = inb(SMBUS_IO_BASE + SMBHSTSTAT) & ~((1<<1)|(1<<0)); + global_status_register = inb(SMBUS_IO_BASE + SMBHSTSTAT) & ~((1 << 1) | (1 << 0)); - /* read results of transaction */ - byte = inb(SMBUS_IO_BASE + SMBHSTDAT0); + /* read results of transaction */ + byte = inb(SMBUS_IO_BASE + SMBHSTDAT0); - if (global_status_register != 0) { - return -1; - } - return byte; + if (global_status_register != 0) { + return -1; + } + return byte; } #if 0 /* SMBus routines borrowed from VIA's Trident Driver */ /* this works, so I am not going to touch it for now -- rgm */ -static unsigned char smbus_read_byte(unsigned char devAdr, - unsigned char bIndex) +static unsigned char smbus_read_byte(unsigned char devAdr, unsigned char bIndex) { unsigned int i; - unsigned char bData; - unsigned char sts = 0; - + unsigned char bData; + unsigned char sts = 0; + /* clear host status */ outb(0xff, SMBUS_IO_BASE); - + /* check SMBUS ready */ - for ( i = 0; i < SMBUS_TIMEOUT; i++ ) - if ( (inb(SMBUS_IO_BASE) & 0x01) == 0 ) + for (i = 0; i < SMBUS_TIMEOUT; i++) + if ((inb(SMBUS_IO_BASE) & 0x01) == 0) break; /* set host command */ - outb(bIndex, SMBUS_IO_BASE+3); - + outb(bIndex, SMBUS_IO_BASE + 3); + /* set slave address */ - outb(devAdr | 0x01, SMBUS_IO_BASE+4); - + outb(devAdr | 0x01, SMBUS_IO_BASE + 4); + /* start */ - outb(0x48, SMBUS_IO_BASE+2); - + outb(0x48, SMBUS_IO_BASE + 2); + /* SMBUS Wait Ready */ - for ( i = 0; i < SMBUS_TIMEOUT; i++ ) - if ( ((sts = inb(SMBUS_IO_BASE)) & 0x01) == 0 ) + for (i = 0; i < SMBUS_TIMEOUT; i++) + if (((sts = inb(SMBUS_IO_BASE)) & 0x01) == 0) break; if ((sts & ~3) != 0) { smbus_print_error(sts); return 0; } - bData=inb(SMBUS_IO_BASE+5); - + bData = inb(SMBUS_IO_BASE + 5); + return bData; - + } #endif /* for reference, here is the fancier version which we will use at some @@ -252,11 +249,11 @@ { unsigned char host_status_register; unsigned char byte; - + reset(); - + smbus_wait_until_ready(); - + /* setup transaction */ /* disable interrupts */ outb(inb(SMBUS_IO_BASE + SMBHSTCTL) & (~1), SMBUS_IO_BASE + SMBHSTCTL); @@ -265,35 +262,32 @@ /* set the command/address... */ outb(address & 0xFF, SMBUS_IO_BASE + SMBHSTCMD); /* set up for a byte data read */ - outb((inb(SMBUS_IO_BASE + SMBHSTCTL) & 0xE3) | (0x2 << 2), - SMBUS_IO_BASE + SMBHSTCTL); - + outb((inb(SMBUS_IO_BASE + SMBHSTCTL) & 0xE3) | (0x2 << 2), SMBUS_IO_BASE + SMBHSTCTL); + /* clear any lingering errors, so the transaction will run */ outb(inb(SMBUS_IO_BASE + SMBHSTSTAT), SMBUS_IO_BASE + SMBHSTSTAT); - - /* clear the data byte...*/ + + /* clear the data byte... */ outb(0, SMBUS_IO_BASE + SMBHSTDAT0); - + /* start the command */ - outb((inb(SMBUS_IO_BASE + SMBHSTCTL) | 0x40), - SMBUS_IO_BASE + SMBHSTCTL); - + outb((inb(SMBUS_IO_BASE + SMBHSTCTL) | 0x40), SMBUS_IO_BASE + SMBHSTCTL); + /* poll for transaction completion */ smbus_wait_until_done(); - + host_status_register = inb(SMBUS_IO_BASE + SMBHSTSTAT); - + /* Ignore the In Use Status... */ host_status_register &= ~(1 << 6); - + /* read results of transaction */ byte = inb(SMBUS_IO_BASE + SMBHSTDAT0); smbus_print_error(byte); - + *result = byte; return host_status_register != 0x02; } #endif - --- orig/targets/via/epia/Config.lb +++ mod/targets/via/epia/Config.lb @@ -1,9 +1,10 @@ # Sample config file for EPIA # This will make a target directory of ./epia - target epia mainboard via/epia -# +option TTYS0_BAUD=19200 +option DEFAULT_CONSOLE_LOGLEVEL=9 +option MAXIMUM_CONSOLE_LOGLEVEL=9 # Via Epia romimage "normal" option USE_FALLBACK_IMAGE=0 @@ -11,7 +12,8 @@ option LINUXBIOS_EXTRA_VERSION=".0Normal" # payload /usr/share/etherboot/5.1.9pre2-lnxi-lb/tg3--ide_disk.zelf # payload ../../../../tg3--ide_disk.zelf - payload ../../../../../lnxieepro100.ebi +# payload ../../../../../lnxieepro100.ebi + payload /usr/local/src/filo-0.4.2/filo.elf end romimage "fallback" @@ -20,7 +22,8 @@ option LINUXBIOS_EXTRA_VERSION=".0Fallback" # payload /usr/share/etherboot/5.1.9pre2-lnxi-lb/tg3--ide_disk.zelf # payload ../../../../tg3--ide_disk.zelf - payload ../../../../../lnxieepro100.ebi +# payload ../../../../../lnxieepro100.ebi + payload /usr/local/src/filo-0.4.2/filo.elf end buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback" * added files --- /dev/null +++ /usr/local/src/freebios2-updated/,,what-changed.freebios--devel--2.0--patch-33--linuxbios at linuxbios.org--devel/new-files-archive/./src/southbridge/via/vt8231/.arch-ids/vt8231_acpi.c.id @@ -0,0 +1 @@ +Josiah England Thu May 26 15:21:29 2005 27981.0 --- /dev/null +++ /usr/local/src/freebios2-updated/,,what-changed.freebios--devel--2.0--patch-33--linuxbios at linuxbios.org--devel/new-files-archive/./src/southbridge/via/vt8231/.arch-ids/vt8231_ide.c.id @@ -0,0 +1 @@ +Josiah England Thu May 26 15:21:58 2005 27983.0 --- /dev/null +++ /usr/local/src/freebios2-updated/,,what-changed.freebios--devel--2.0--patch-33--linuxbios at linuxbios.org--devel/new-files-archive/./src/southbridge/via/vt8231/.arch-ids/vt8231_lpc.c.id @@ -0,0 +1 @@ +Josiah England Thu May 26 15:22:10 2005 27984.0 --- /dev/null +++ /usr/local/src/freebios2-updated/,,what-changed.freebios--devel--2.0--patch-33--linuxbios at linuxbios.org--devel/new-files-archive/./src/southbridge/via/vt8231/.arch-ids/vt8231_nic.c.id @@ -0,0 +1 @@ +Josiah England Thu May 26 15:22:19 2005 27985.0 --- /dev/null +++ /usr/local/src/freebios2-updated/,,what-changed.freebios--devel--2.0--patch-33--linuxbios at linuxbios.org--devel/new-files-archive/./src/southbridge/via/vt8231/.arch-ids/vt8231_usb.c.id @@ -0,0 +1 @@ +Josiah England Thu May 26 15:22:33 2005 27986.0 --- /dev/null +++ /usr/local/src/freebios2-updated/,,what-changed.freebios--devel--2.0--patch-33--linuxbios at linuxbios.org--devel/new-files-archive/./src/southbridge/via/vt8231/vt8231_acpi.c @@ -0,0 +1,44 @@ +#include +#include +#include +#include +#include +#include "vt8231.h" + +static void acpi_init(struct device *dev) +{ + printk_debug("Configuring VIA ACPI\n"); + + // Set ACPI base address to IO 0x4000 + pci_write_config32(dev, 0x48, 0x4001); + + // Enable ACPI access (and setup like award) + pci_write_config8(dev, 0x41, 0x84); + + // Set hardware monitor base address to IO 0x6000 + pci_write_config32(dev, 0x70, 0x6001); + + // Enable hardware monitor (and setup like award) + pci_write_config8(dev, 0x74, 0x01); + + // set IO base address to 0x5000 + pci_write_config32(dev, 0x90, 0x5001); + + // Enable SMBus + pci_write_config8(dev, 0xd2, 0x01); +} + +static struct device_operations acpi_ops = { + .read_resources = pci_dev_read_resources, + .set_resources = pci_dev_set_resources, + .enable_resources = pci_dev_enable_resources, + .init = acpi_init, + .enable = 0, + .ops_pci = 0, +}; + +static struct pci_driver northbridge_driver __pci_driver = { + .ops = &acpi_ops, + .vendor = PCI_VENDOR_ID_VIA, + .device = PCI_DEVICE_ID_VIA_8231_4, +}; --- /dev/null +++ /usr/local/src/freebios2-updated/,,what-changed.freebios--devel--2.0--patch-33--linuxbios at linuxbios.org--devel/new-files-archive/./src/southbridge/via/vt8231/vt8231_ide.c @@ -0,0 +1,108 @@ +#include +#include +#include +#include +#include +#include "vt8231.h" +#include "chip.h" + +static void ide_init(struct device *dev) +{ + struct southbridge_via_vt8231_config *conf; + unsigned char enables; + + if (!conf->enable_native_ide) { + // Run the IDE controller in 'compatiblity mode - i.e. don't use PCI + // interrupts. Using PCI ints confuses linux for some reason. + + printk_info("%s: enabling compatibility IDE addresses\n", __FUNCTION__); + enables = pci_read_config8(dev, 0x42); + printk_debug("enables in reg 0x42 0x%x\n", enables); + enables &= ~0xc0; // compatability mode + pci_write_config8(dev, 0x42, enables); + enables = pci_read_config8(dev, 0x42); + printk_debug("enables in reg 0x42 read back as 0x%x\n", enables); + } + + enables = pci_read_config8(dev, 0x40); + printk_debug("enables in reg 0x40 0x%x\n", enables); + enables |= 3; + pci_write_config8(dev, 0x40, enables); + enables = pci_read_config8(dev, 0x40); + printk_debug("enables in reg 0x40 read back as 0x%x\n", enables); + + // Enable prefetch buffers + enables = pci_read_config8(dev, 0x41); + enables |= 0xf0; + pci_write_config8(dev, 0x41, enables); + + // Lower thresholds (cause award does it) + enables = pci_read_config8(dev, 0x43); + enables &= ~0x0f; + enables |= 0x05; + pci_write_config8(dev, 0x43, enables); + + // PIO read prefetch counter (cause award does it) + pci_write_config8(dev, 0x44, 0x18); + + // Use memory read multiple + pci_write_config8(dev, 0x45, 0x1c); + + // address decoding. + // we want "flexible", i.e. 1f0-1f7 etc. or native PCI + // kevinh at ispiri.com - the standard linux drivers seem ass slow when + // used in native mode - I've changed back to classic + enables = pci_read_config8(dev, 0x9); + printk_debug("enables in reg 0x9 0x%x\n", enables); + // by the book, set the low-order nibble to 0xa. + if (conf->enable_native_ide) { + enables &= ~0xf; + // cf/cg silicon needs an 'f' here. + enables |= 0xf; + } else { + enables &= ~0x5; + } + + pci_write_config8(dev, 0x9, enables); + enables = pci_read_config8(dev, 0x9); + printk_debug("enables in reg 0x9 read back as 0x%x\n", enables); + + // standard bios sets master bit. + enables = pci_read_config8(dev, 0x4); + printk_debug("command in reg 0x4 0x%x\n", enables); + enables |= 7; + + // No need for stepping - kevinh at ispiri.com + enables &= ~0x80; + + pci_write_config8(dev, 0x4, enables); + enables = pci_read_config8(dev, 0x4); + printk_debug("command in reg 0x4 reads back as 0x%x\n", enables); + + if (!conf->enable_native_ide) { + // Use compatability mode - per award bios + pci_write_config32(dev, 0x10, 0x0); + pci_write_config32(dev, 0x14, 0x0); + pci_write_config32(dev, 0x18, 0x0); + pci_write_config32(dev, 0x1c, 0x0); + + // Force interrupts to use compat mode - just like Award bios + pci_write_config8(dev, 0x3d, 00); + pci_write_config8(dev, 0x3c, 0xff); + } +} + +static struct device_operations ide_ops = { + .read_resources = pci_dev_read_resources, + .set_resources = pci_dev_set_resources, + .enable_resources = pci_dev_enable_resources, + .init = ide_init, + .enable = 0, + .ops_pci = 0, +}; + +static struct pci_driver northbridge_driver __pci_driver = { + .ops = &ide_ops, + .vendor = PCI_VENDOR_ID_VIA, + .device = PCI_DEVICE_ID_VIA_82C586_1, +}; --- /dev/null +++ /usr/local/src/freebios2-updated/,,what-changed.freebios--devel--2.0--patch-33--linuxbios at linuxbios.org--devel/new-files-archive/./src/southbridge/via/vt8231/vt8231_lpc.c @@ -0,0 +1,154 @@ +#include +#include +#include +#include +#include + +#include + +#include "vt8231.h" +#include "chip.h" + +/* PIRQ init + */ +void pci_assign_irqs(unsigned bus, unsigned slot, const unsigned char pIntAtoD[4]); +static const unsigned char southbridgeIrqs[4] = { 11, 5, 10, 12 }; +static const unsigned char enetIrqs[4] = { 11, 5, 10, 12 }; +static const unsigned char slotIrqs[4] = { 5, 10, 12, 11 }; + +/* + Our IDSEL mappings are as follows + PCI slot is AD31 (device 15) (00:14.0) + Southbridge is AD28 (device 12) (00:11.0) +*/ +static void pci_routing_fixup(struct device *dev) +{ + + printk_info("%s: dev is %p\n", __FUNCTION__, dev); + if (dev) { + /* initialize PCI interupts - these assignments depend + on the PCB routing of PINTA-D + + PINTA = IRQ11 + PINTB = IRQ5 + PINTC = IRQ10 + PINTD = IRQ12 + */ + pci_write_config8(dev, 0x55, 0xb0); + pci_write_config8(dev, 0x56, 0xa5); + pci_write_config8(dev, 0x57, 0xc0); + } + + // Standard southbridge components + printk_info("setting southbridge\n"); + pci_assign_irqs(0, 0x11, southbridgeIrqs); + + // Ethernet built into southbridge + printk_info("setting ethernet\n"); + pci_assign_irqs(0, 0x12, enetIrqs); + + // PCI slot + printk_info("setting pci slot\n"); + pci_assign_irqs(0, 0x14, slotIrqs); + printk_info("%s: DONE\n", __FUNCTION__); +} + +static void vt8231_init(struct device *dev) +{ + unsigned char enables; + struct southbridge_via_vt8231_config *conf = dev->chip_info; + + printk_debug("vt8231 init\n"); + + // enable the internal I/O decode + enables = pci_read_config8(dev, 0x6C); + enables |= 0x80; + pci_write_config8(dev, 0x6C, enables); + + // Map 4MB of FLASH into the address space + pci_write_config8(dev, 0x41, 0x7f); + + // Set bit 6 of 0x40, because Award does it (IO recovery time) + // IMPORTANT FIX - EISA 0x4d0 decoding must be on so that PCI + // interrupts can be properly marked as level triggered. + enables = pci_read_config8(dev, 0x40); + pci_write_config8(dev, 0x40, enables); + + // Set 0x42 to 0xf0 to match Award bios + enables = pci_read_config8(dev, 0x42); + enables |= 0xf0; + pci_write_config8(dev, 0x42, enables); + + // Set bit 3 of 0x4a, to match award (dummy pci request) + enables = pci_read_config8(dev, 0x4a); + enables |= 0x08; + pci_write_config8(dev, 0x4a, enables); + + // Set bit 3 of 0x4f to match award (use INIT# as cpu reset) + enables = pci_read_config8(dev, 0x4f); + enables |= 0x08; + pci_write_config8(dev, 0x4f, enables); + + // Set 0x58 to 0x03 to match Award + pci_write_config8(dev, 0x58, 0x03); + + // enable the ethernet/RTC + if (dev) { + enables = pci_read_config8(dev, 0x51); + enables |= 0x18; + pci_write_config8(dev, 0x51, enables); + } + + // enable IDE, since Linux won't do it. + // First do some more things to devfn (17,0) + // note: this should already be cleared, according to the book. + enables = pci_read_config8(dev, 0x50); + printk_debug("IDE enable in reg. 50 is 0x%x\n", enables); + enables &= ~8; // need manifest constant here! + printk_debug("set IDE reg. 50 to 0x%x\n", enables); + pci_write_config8(dev, 0x50, enables); + + // set default interrupt values (IDE) + enables = pci_read_config8(dev, 0x4c); + printk_debug("IRQs in reg. 4c are 0x%x\n", enables & 0xf); + // clear out whatever was there. + enables &= ~0xf; + enables |= 4; + printk_debug("setting reg. 4c to 0x%x\n", enables); + pci_write_config8(dev, 0x4c, enables); + + // set up the serial port interrupts. + // com2 to 3, com1 to 4 + pci_write_config8(dev, 0x46, 0x04); + pci_write_config8(dev, 0x47, 0x03); + pci_write_config8(dev, 0x6e, 0x98); + + /* set up isa bus -- i/o recovery time, rom write enable, extend-ale */ + pci_write_config8(dev, 0x40, 0x54); + //ethernet_fixup(); + + // Start the rtc + rtc_init(0); +} + +static void southbridge_init(struct device *dev) +{ + vt8231_init(dev); + pci_routing_fixup(dev); +} + +static struct device_operations vt8231_lpc_ops = { + .read_resources = pci_dev_read_resources, + .set_resources = pci_dev_set_resources, + .enable_resources = pci_dev_enable_resources, + .init = &southbridge_init, + .scan_bus = scan_static_bus, + .enable = 0, + .ops_pci = 0, +}; + +static struct pci_driver lpc_driver __pci_driver = { + .ops = &vt8231_lpc_ops, + .vendor = PCI_VENDOR_ID_VIA, + .device = PCI_DEVICE_ID_VIA_8231, +}; --- /dev/null +++ /usr/local/src/freebios2-updated/,,what-changed.freebios--devel--2.0--patch-33--linuxbios at linuxbios.org--devel/new-files-archive/./src/southbridge/via/vt8231/vt8231_nic.c @@ -0,0 +1,37 @@ +#include +#include +#include +#include +#include +#include "vt8231.h" + +/* + * Enable the ethernet device and turn off stepping (because it is integrated + * inside the southbridge) + */ +static void nic_init(struct device *dev) +{ + uint8_t byte; + + printk_debug("Configuring VIA LAN\n"); + + /* We don't need stepping - though the device supports it */ + byte = pci_read_config8(dev, PCI_COMMAND); + byte &= ~PCI_COMMAND_WAIT; + pci_write_config8(dev, PCI_COMMAND, byte); +} + +static struct device_operations nic_ops = { + .read_resources = pci_dev_read_resources, + .set_resources = pci_dev_set_resources, + .enable_resources = pci_dev_enable_resources, + .init = nic_init, + .enable = 0, + .ops_pci = 0, +}; + +static struct pci_driver northbridge_driver __pci_driver = { + .ops = &nic_ops, + .vendor = PCI_VENDOR_ID_VIA, + .device = PCI_DEVICE_ID_VIA_8233_7, +}; --- /dev/null +++ /usr/local/src/freebios2-updated/,,what-changed.freebios--devel--2.0--patch-33--linuxbios at linuxbios.org--devel/new-files-archive/./src/southbridge/via/vt8231/vt8231_usb.c @@ -0,0 +1,52 @@ + +static void usb_on(int enable) +{ + unsigned char regval; + + /* Base 8231 controller */ + device_t dev0 = dev_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8231, 0); + /* USB controller 1 */ + device_t dev2 = dev_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2, 0); + /* USB controller 2 */ + device_t dev3 = dev_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2, dev2); + + /* enable USB1 */ + if(dev2) { + if (enable) { + pci_write_config8(dev2, 0x3c, 0x05); + pci_write_config8(dev2, 0x04, 0x07); + } else { + pci_write_config8(dev2, 0x3c, 0x00); + pci_write_config8(dev2, 0x04, 0x00); + } + } + + if(dev0) { + regval = pci_read_config8(dev0, 0x50); + if (enable) + regval &= ~(0x10); + else + regval |= 0x10; + pci_write_config8(dev0, 0x50, regval); + } + + /* enable USB2 */ + if(dev3) { + if (enable) { + pci_write_config8(dev3, 0x3c, 0x05); + pci_write_config8(dev3, 0x04, 0x07); + } else { + pci_write_config8(dev3, 0x3c, 0x00); + pci_write_config8(dev3, 0x04, 0x00); + } + } + + if(dev0) { + regval = pci_read_config8(dev0, 0x50); + if (enable) + regval &= ~(0x20); + else + regval |= 0x20; + pci_write_config8(dev0, 0x50, regval); + } +} From ollie at lanl.gov Tue Jun 7 18:09:51 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Tue, 07 Jun 2005 10:09:51 -0600 Subject: [BULK] RE: [LinuxBIOS] FYI: AMD support for cache as ram. In-Reply-To: <2ea3fae105060621025cc22e98@mail.gmail.com> References: <3174569B9743D511922F00A0C94314230A403B62@TYANWEB> <2ea3fae105060621025cc22e98@mail.gmail.com> Message-ID: <1118160591.5629.6.camel@logarithm.lanl.gov> On Mon, 2005-06-06 at 21:02 -0700, yhlu wrote: > I just figure out, the ss don't need to be changed. and only need to > set the esp. > > It can get into amd64_main in failover. > > the it seems even the 64 range in cache can be read and write, but the > result is not right. It means when clear all of range, the readout > will still be 0xff.... > > #if 1 > movl $CacheBase, %edi > cld > movl $04000, %ecx > xorl %eax, %eax > rep stosl > #endif > movl $CacheBase, %esi > movl (%esi), %eax > .testx: outb %al, $0x80 > jmp .testx > > intel_chip_post_macro(0x22) /* post 22 */ > The AMD doc says you have to use REP MOVS to read from IO space. It looks like you are using REP STOS. > Ollie, > are you sure that your code can use 300 bytes in cache? > Yea, I am sure it uses less than 448 bytes. You didn't reuse the ldscript and .inc files in the .tgz I sent, right? > YH -- Li-Ta Lo Los Alamos National Lab From yinghailu at gmail.com Tue Jun 7 18:28:27 2005 From: yinghailu at gmail.com (yhlu) Date: Tue, 7 Jun 2005 09:28:27 -0700 Subject: [BULK] RE: [LinuxBIOS] FYI: AMD support for cache as ram. In-Reply-To: <1118160591.5629.6.camel@logarithm.lanl.gov> References: <3174569B9743D511922F00A0C94314230A403B62@TYANWEB> <2ea3fae105060621025cc22e98@mail.gmail.com> <1118160591.5629.6.camel@logarithm.lanl.gov> Message-ID: <2ea3fae10506070928700156d9@mail.gmail.com> 448 bytes should be enough, the first 448 or last 448 in 64k range. I tried your code it doesn't work too. The reason for using auto.inc and failover.inc, i don't want to set cs, ds, es....second time. Also I wonder it will need go back to crt0.s to start from __main ... YH From Dirk.Ullrich.Berlin at web.de Wed Jun 8 11:51:48 2005 From: Dirk.Ullrich.Berlin at web.de (Dirk Ullrich) Date: Wed, 08 Jun 2005 11:51:48 +0200 Subject: [LinuxBIOS] Athlon XP Boards supported linuxbios? Message-ID: <984225296@web.de> Hi all, I'm new to the linuxbios list, but I have successfully running linuxbios (v.1) on a older PII board (Gigabyte's GA-6BXC). A first search in the archive of this list suggests that nforce2-based boards like my Asus A7N8X are not supported. Are there any modern boards for Athlon XP supported by linuxbios? Dirk ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193 From noodles at earth.li Wed Jun 8 13:47:38 2005 From: noodles at earth.li (Jonathan McDowell) Date: Wed, 8 Jun 2005 12:47:38 +0100 Subject: [LinuxBIOS] EPIA-M status In-Reply-To: <1118156903.4940.6.camel@plipper.ccstar> References: <3174569B9743D511922F00A0C943142309F81813@TYANWEB> <001d01c5657f$bc7ce1c0$c501a8c0@newflame> <20050604104519.GX10176@earth.li> <20050606222506.GL10176@earth.li> <1118156903.4940.6.camel@plipper.ccstar> Message-ID: <20050608114738.GV10176@earth.li> On Tue, Jun 07, 2005 at 09:08:22AM -0600, Josiah England wrote: > Attached is the diffs file generated by 'tla changes --diffs'. Great, thanks. Minor issue I found while using it as a basis for the EPIA-M stuff: > +static void ide_init(struct device *dev) > +{ > + struct southbridge_via_vt8231_config *conf; > + unsigned char enables; > + > + if (!conf->enable_native_ide) { I think you want: struct southbridge_via_vt8231_config *conf = dev->chip_info; otherwise you're dereferencing an uninitialised pointer? J. -- 101 things you can't have too much of : 3 - Sleep. Ask me about server co-location - info at blackcatnetworks.co.uk From noodles at earth.li Wed Jun 8 13:48:33 2005 From: noodles at earth.li (Jonathan McDowell) Date: Wed, 8 Jun 2005 12:48:33 +0100 Subject: [LinuxBIOS] EPIA-M Almost there In-Reply-To: <004701c56b0b$4f203410$c501a8c0@newflame> References: <20050606222355.GK10176@earth.li> <004701c56b0b$4f203410$c501a8c0@newflame> Message-ID: <20050608114833.GW10176@earth.li> On Mon, Jun 06, 2005 at 07:47:56PM -0700, Adam Talbot wrote: > New line of code in. Linuxbios bios recompiled... > And yes, we are making it into the south bridge. Ok, I've updated the vt8235 stuff based on Josiah's EPIA work and checked it into my arch tree. As per usual, all it's passed is a compile test. J. -- 101 things you can't have too much of : 34 - Beaches. From josiah at lanl.gov Wed Jun 8 18:34:07 2005 From: josiah at lanl.gov (Josiah England) Date: Wed, 08 Jun 2005 10:34:07 -0600 Subject: [LinuxBIOS] Epia Commit Message-ID: <1118248447.22376.86.camel@plipper.ccstar> I have committed Ollie's Epia code to the new subversion tree: svn co svn://openbios.org/LinuxBIOSv2 It's getting farther than it was before, detecting IDE drives in native pci mode, and we've even seen a bproc node come up once using it. For all I know, it might work fine (albeit pretty slow at points), but I can't do further testing of it until some flash parts come in the mail because the ones I've been testing it with have been flashed a few too many times. Josiah From jonsmirl at gmail.com Wed Jun 8 21:28:06 2005 From: jonsmirl at gmail.com (Jon Smirl) Date: Wed, 8 Jun 2005 15:28:06 -0400 Subject: [LinuxBIOS] HPET and ACPI Message-ID: <9e47339105060812285127e246@mail.gmail.com> I have a bunch of Dell servers around here that have chipsets supporting HPET (like ICH5) but they don't have the HPET ACPI entry. I have talked to Dell technical support and this is because no Microsoft OS uses HPET. At boot Linux looks for the HPET ACPI entry to know if there is HPET support. Of course on my Dell machines it says there isn't any. What is involved in the HPET ACPI entry? Would it be easy to modify the kernel to look for this device without the entry? -- Jon Smirl jonsmirl at gmail.com From huangjen.wang at gmail.com Thu Jun 9 05:31:37 2005 From: huangjen.wang at gmail.com (Huang-Jen Wang) Date: Thu, 9 Jun 2005 11:31:37 +0800 Subject: [LinuxBIOS] A question of Mptable Message-ID: <4325815c05060820319a7440f@mail.gmail.com> Dear all, I got a new mainboard, and I want to get its own Mptable.c is there a easy way to achieve it ? Thanks From stepan at openbios.org Thu Jun 9 12:22:32 2005 From: stepan at openbios.org (Stefan Reinauer) Date: Thu, 9 Jun 2005 12:22:32 +0200 Subject: [LinuxBIOS] HPET and ACPI In-Reply-To: <9e47339105060812285127e246@mail.gmail.com> References: <9e47339105060812285127e246@mail.gmail.com> Message-ID: <20050609102232.GA26719@openbios.org> * Jon Smirl [050608 21:28]: > At boot Linux looks for the HPET ACPI entry to know if there is HPET > support. Of course on my Dell machines it says there isn't any. > > What is involved in the HPET ACPI entry? Would it be easy to modify > the kernel to look for this device without the entry? Yes, indeed. The only useful information passed in the HPET table is the start address of the timer. you could add a kernel parameter "hpet_addr" that passes the address instead, or something similar. Stefan From kfuchs at winternet.com Thu Jun 9 16:55:08 2005 From: kfuchs at winternet.com (Ken Fuchs) Date: Thu, 9 Jun 2005 09:55:08 -0500 (CDT) Subject: [LinuxBIOS] A question of Mptable Message-ID: <200506091455.j59Et8hW029562@tundra.winternet.com> Huang-Jen Wang wrote: > I got a new mainboard, and I want to get its own Mptable.c > is there a easy way to achieve it ? Yes: 1) Execute make in util/mptable 2) Run the mptable executable create in step 1 on the mainboard with the mainboard's original "COTS" BIOS installed. 3) The output of the mptable executable is an mptable.c that should saved as src/mainboard///mptable.c. Some hand editing of the result of step 3 may be required. Last time I used it, I had to delete some non-C code at the end. It was a rather edit. However, the resulting mptable will be a clone of the original at best. Any bugs in the original will be in the clone, but with LinuxBIOS you have the option to fix those bugs. Fixing an mptable bug may not necessarily be easy though. Good luck! Sincerely, Ken Fuchs From Stephen.Kimball at bench.com Thu Jun 9 18:08:17 2005 From: Stephen.Kimball at bench.com (Stephen.Kimball at bench.com) Date: Thu, 9 Jun 2005 12:08:17 -0400 Subject: [LinuxBIOS] A question of Mptable Message-ID: <9B124F08B3EFDA4F8813B05102DC719503A40C6B@nh-ex01.bench.com> I'd suggest you read about the IRQ and MP tables, then look at several examples in the LinuxBIOS source tree, then find someone who knows. Running the mptable util doesn't give you much. Steve -----Original Message----- From: linuxbios-bounces at openbios.org [mailto:linuxbios-bounces at openbios.org] On Behalf Of Ken Fuchs Sent: Thursday, June 09, 2005 10:55 AM To: linuxbios at openbios.org Subject: Re: [LinuxBIOS] A question of Mptable Huang-Jen Wang wrote: > I got a new mainboard, and I want to get its own Mptable.c > is there a easy way to achieve it ? Yes: 1) Execute make in util/mptable 2) Run the mptable executable create in step 1 on the mainboard with the mainboard's original "COTS" BIOS installed. 3) The output of the mptable executable is an mptable.c that should saved as src/mainboard///mptable.c. Some hand editing of the result of step 3 may be required. Last time I used it, I had to delete some non-C code at the end. It was a rather edit. However, the resulting mptable will be a clone of the original at best. Any bugs in the original will be in the clone, but with LinuxBIOS you have the option to fix those bugs. Fixing an mptable bug may not necessarily be easy though. Good luck! Sincerely, Ken Fuchs _______________________________________________ LinuxBIOS mailing list LinuxBIOS at openbios.org http://www.openbios.org/mailman/listinfo/linuxbios From Stephen.Kimball at bench.com Thu Jun 9 18:15:57 2005 From: Stephen.Kimball at bench.com (Stephen.Kimball at bench.com) Date: Thu, 9 Jun 2005 12:15:57 -0400 Subject: [LinuxBIOS] Tyan S2895 Mptable Message-ID: <9B124F08B3EFDA4F8813B05102DC719503A40C6C@nh-ex01.bench.com> The Tyan/s2895 mptable.c is missing two entries for SATA. If the Config.lb file turns the SATA devices on the second CK804, this could be a problem. Ethernet is the only device in the mptable for the second CK804. Steve From kfuchs at winternet.com Thu Jun 9 18:23:15 2005 From: kfuchs at winternet.com (Ken Fuchs) Date: Thu, 9 Jun 2005 11:23:15 -0500 (CDT) Subject: [LinuxBIOS] Athlon XP Boards supported linuxbios? Message-ID: <200506091623.j59GNFKR029914@tundra.winternet.com> Dirk Ullrich wrote: > Are there any modern boards for Athlon XP supported by linuxbios? No, although it is possible that there might be some in development. However, there is LinuxBIOS support for the Opteron & AMD64 via the AMD-8000 and nForce4 chipsets: The AMD-8000 chipset has excellent support. Many AMD-8000 chipset Tyan boards are very well supported. The nForce4 chipset source code was recently released by Yh Lu from Tyan. This code appears to be stable for nForce4 based Tyan boards. ------ Dirk also asked about nforce2 chipset & Asus A7N8X support: Would it make sense to port the nForce4 code to nForce2/nForce3 and Opteron/AMD64 code to Athlon 32? It seems like a viable option for someone with the time, experience and motivation. Comments? Sincerely, Ken Fuchs From yinghailu at gmail.com Thu Jun 9 19:43:48 2005 From: yinghailu at gmail.com (yhlu) Date: Thu, 9 Jun 2005 10:43:48 -0700 Subject: [LinuxBIOS] Tyan S2895 Mptable In-Reply-To: <9B124F08B3EFDA4F8813B05102DC719503A40C6C@nh-ex01.bench.com> References: <9B124F08B3EFDA4F8813B05102DC719503A40C6C@nh-ex01.bench.com> Message-ID: <2ea3fae1050609104358999afd@mail.gmail.com> the sata in second CK804 is disabled in MB Config.lb, So don't need that. YH On 6/9/05, Stephen.Kimball at bench.com wrote: > The Tyan/s2895 mptable.c is missing two entries for SATA. If the Config.lb file turns the SATA devices on the second CK804, this could be a problem. > Ethernet is the only device in the mptable for the second CK804. > > Steve > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From kfuchs at winternet.com Thu Jun 9 20:30:54 2005 From: kfuchs at winternet.com (Ken Fuchs) Date: Thu, 9 Jun 2005 13:30:54 -0500 (CDT) Subject: [LinuxBIOS] Tyan S2895 Mptable Message-ID: <200506091830.j59IUsaL000493@tundra.winternet.com> > On 6/9/05, Stephen.Kimball at bench.com wrote: > > The Tyan/s2895 mptable.c is missing two entries for SATA. If the > > Config.lb file turns the SATA devices on the second CK804, this > > could be a problem. Ethernet is the only device in the mptable > > for the second CK804. Yh Lu wrote: > the sata in second CK804 is disabled in MB Config.lb, So don't need > that. I think that Stephen has already clearly indicated that there is no problem when SATA for the second CK8-04 is disabled. Does the Tyan S2885 hardware (with COTS BIOS) support SATA on the second CK8-04? If so, the mptable should have the entries required to support SATA on the second CK8-04. Sincerely, Ken Fuchs From yinghailu at gmail.com Thu Jun 9 20:33:33 2005 From: yinghailu at gmail.com (yhlu) Date: Thu, 9 Jun 2005 11:33:33 -0700 Subject: [LinuxBIOS] Tyan S2895 Mptable In-Reply-To: <200506091830.j59IUsaL000493@tundra.winternet.com> References: <200506091830.j59IUsaL000493@tundra.winternet.com> Message-ID: <2ea3fae105060911337a02f609@mail.gmail.com> No connector for that. YH On 6/9/05, Ken Fuchs wrote: > > On 6/9/05, Stephen.Kimball at bench.com wrote: > > > The Tyan/s2895 mptable.c is missing two entries for SATA. If the > > > Config.lb file turns the SATA devices on the second CK804, this > > > could be a problem. Ethernet is the only device in the mptable > > > for the second CK804. > > Yh Lu wrote: > > > the sata in second CK804 is disabled in MB Config.lb, So don't need > > that. > > I think that Stephen has already clearly indicated that there is no > problem when SATA for the second CK8-04 is disabled. > > Does the Tyan S2885 hardware (with COTS BIOS) support SATA on the > second CK8-04? If so, the mptable should have the entries required to > support SATA on the second CK8-04. > > Sincerely, > > Ken Fuchs > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From Stephen.Kimball at bench.com Thu Jun 9 20:34:15 2005 From: Stephen.Kimball at bench.com (Stephen.Kimball at bench.com) Date: Thu, 9 Jun 2005 14:34:15 -0400 Subject: [LinuxBIOS] Tyan S2895 Mptable Message-ID: <9B124F08B3EFDA4F8813B05102DC719503A40C6E@nh-ex01.bench.com> That's what I said ... it's disabled in the MB Config.lb, but the hardware is still there. It's only two lines in the mptable.c. Do you expect s2895 users to not need the extra 4 SATA ports? Why not fix it? I'm sure you know how to fix it. If I see something that could be improved in the CK804 code, what should I do? So far all my suggestions have been dismissed. Steve -----Original Message----- From: yhlu [mailto:yinghailu at gmail.com] Sent: Thursday, June 09, 2005 1:44 PM To: Kimball, Stephen Cc: linuxbios at openbios.org Subject: Re: [LinuxBIOS] Tyan S2895 Mptable the sata in second CK804 is disabled in MB Config.lb, So don't need that. YH On 6/9/05, Stephen.Kimball at bench.com wrote: > The Tyan/s2895 mptable.c is missing two entries for SATA. If the Config.lb file turns the SATA devices on the second CK804, this could be a problem. > Ethernet is the only device in the mptable for the second CK804. > > Steve > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From yinghailu at gmail.com Thu Jun 9 21:42:02 2005 From: yinghailu at gmail.com (yhlu) Date: Thu, 9 Jun 2005 12:42:02 -0700 Subject: [LinuxBIOS] Tyan S2895 Mptable In-Reply-To: <9B124F08B3EFDA4F8813B05102DC719503A40C6E@nh-ex01.bench.com> References: <9B124F08B3EFDA4F8813B05102DC719503A40C6E@nh-ex01.bench.com> Message-ID: <2ea3fae105060912421cf1d2dc@mail.gmail.com> but the problem is that S2895 only used SATA on first CK804. And the mptable.c in Mb dir is sth related with MB Configuration. So if you have another MB that enable sata on second ck804, you should create that two entries for sata of it's mptable.c There is no extra space for another four sata connector, also there is some power consumption conern... YH On 6/9/05, Stephen.Kimball at bench.com wrote: > That's what I said ... it's disabled in the MB Config.lb, but the hardware is still there. It's only two lines in the mptable.c. Do you expect s2895 users to not need the extra 4 SATA ports? Why not fix it? I'm sure you know how to fix it. > > If I see something that could be improved in the CK804 code, what should I do? So far all my suggestions have been dismissed. > > Steve > > -----Original Message----- > From: yhlu [mailto:yinghailu at gmail.com] > Sent: Thursday, June 09, 2005 1:44 PM > To: Kimball, Stephen > Cc: linuxbios at openbios.org > Subject: Re: [LinuxBIOS] Tyan S2895 Mptable > > the sata in second CK804 is disabled in MB Config.lb, So don't need that. > > YH > > On 6/9/05, Stephen.Kimball at bench.com wrote: > > The Tyan/s2895 mptable.c is missing two entries for SATA. If the Config.lb file turns the SATA devices on the second CK804, this could be a problem. > > Ethernet is the only device in the mptable for the second CK804. > > > > Steve > > > > _______________________________________________ > > LinuxBIOS mailing list > > LinuxBIOS at openbios.org > > http://www.openbios.org/mailman/listinfo/linuxbios > > > From Stephen.Kimball at bench.com Thu Jun 9 22:39:04 2005 From: Stephen.Kimball at bench.com (Stephen.Kimball at bench.com) Date: Thu, 9 Jun 2005 16:39:04 -0400 Subject: [LinuxBIOS] Tyan S2895 Mptable Message-ID: <9B124F08B3EFDA4F8813B05102DC719503A40C70@nh-ex01.bench.com> Then maybe the S2895 MB Config.lb shouldn't make it look like the second CK804's SATA devices could be turned on. A comment noting the connector is missing would clear it up. Steve -----Original Message----- but the problem is that S2895 only used SATA on first CK804. And the mptable.c in Mb dir is sth related with MB Configuration. So if you have another MB that enable sata on second ck804, you should create that two entries for sata of it's mptable.c There is no extra space for another four sata connector, also there is some power consumption conern... YH From ollie at lanl.gov Thu Jun 9 23:04:01 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Thu, 09 Jun 2005 15:04:01 -0600 Subject: [LinuxBIOS] TLA Sucks Message-ID: <1118351041.19063.10.camel@logarithm.lanl.gov> Ouch, I have messed up the TLA tree many times by trying to commit only the emulator changes. I guess patch-36 to patch-38 are mistakes. I hope I didn't mess the tree too much. BTW, how exactly should I roll back a patch level ? Is the "tla replay --revers" plus "tla sync-tree" the right way to do? Does it undo "tla add"? -- Li-Ta Lo Los Alamos National Lab From ollie at lanl.gov Thu Jun 9 23:20:57 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Thu, 09 Jun 2005 15:20:57 -0600 Subject: [LinuxBIOS] TLA Sucks In-Reply-To: <1118351041.19063.10.camel@logarithm.lanl.gov> References: <1118351041.19063.10.camel@logarithm.lanl.gov> Message-ID: <1118352057.19063.12.camel@logarithm.lanl.gov> On Thu, 2005-06-09 at 15:04 -0600, Li-Ta Lo wrote: > Ouch, > > I have messed up the TLA tree many times by trying to commit only the > emulator changes. I guess patch-36 to patch-38 are mistakes. I hope > I didn't mess the tree too much. > > BTW, how exactly should I roll back a patch level ? Is the "tla replay > --revers" plus "tla sync-tree" the right way to do? Does it undo > "tla add"? > What is the equivalent of "cvs diff -rX.Y -rX.Z"? -- Li-Ta Lo Los Alamos National Lab From ollie at lanl.gov Thu Jun 9 23:35:03 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Thu, 09 Jun 2005 15:35:03 -0600 Subject: [LinuxBIOS] TLA Sucks In-Reply-To: <1118351041.19063.10.camel@logarithm.lanl.gov> References: <1118351041.19063.10.camel@logarithm.lanl.gov> Message-ID: <1118352904.19063.15.camel@logarithm.lanl.gov> On Thu, 2005-06-09 at 15:04 -0600, Li-Ta Lo wrote: > Ouch, > > I have messed up the TLA tree many times by trying to commit only the > emulator changes. I guess patch-36 to patch-38 are mistakes. I hope > I didn't mess the tree too much. > > BTW, how exactly should I roll back a patch level ? Is the "tla replay > --revers" plus "tla sync-tree" the right way to do? Does it undo > "tla add"? > Holy shit, why can't I see any file on the TLA web interface for patch-36 and later? -- Li-Ta Lo Los Alamos National Lab From noodles at earth.li Fri Jun 10 01:19:27 2005 From: noodles at earth.li (Jonathan McDowell) Date: Fri, 10 Jun 2005 00:19:27 +0100 Subject: [LinuxBIOS] TLA Sucks In-Reply-To: <1118352057.19063.12.camel@logarithm.lanl.gov> References: <1118351041.19063.10.camel@logarithm.lanl.gov> <1118352057.19063.12.camel@logarithm.lanl.gov> Message-ID: <20050609231927.GL10176@earth.li> On Thu, Jun 09, 2005 at 03:20:57PM -0600, Li-Ta Lo wrote: > On Thu, 2005-06-09 at 15:04 -0600, Li-Ta Lo wrote: > > I have messed up the TLA tree many times by trying to commit only the > > emulator changes. I guess patch-36 to patch-38 are mistakes. I hope > > I didn't mess the tree too much. > > > > BTW, how exactly should I roll back a patch level ? Is the "tla replay > > --revers" plus "tla sync-tree" the right way to do? Does it undo > > "tla add"? > What is the equivalent of "cvs diff -rX.Y -rX.Z"? Have you seen: http://wiki.gnuarch.org/Learning_20Arch_20commands_20for_20CVS_20users ? It suggests: cvs diff -r 1.2 -r 1.5 == tla delta --diffs patch-2 patch-5 For the backing out a changeset I found: http://wiki.gnuarch.org/Arch_20Recipes#head-13d35cf3d0899c602e4e054cd7e962e62685edb7 J. -- I'm from the government. I'm here to help you. From ollie at lanl.gov Fri Jun 10 02:30:07 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Thu, 9 Jun 2005 18:30:07 -0600 (MDT) Subject: [LinuxBIOS] TLA Sucks In-Reply-To: <20050609231927.GL10176@earth.li> References: <1118351041.19063.10.camel@logarithm.lanl.gov> <1118352057.19063.12.camel@logarithm.lanl.gov> <20050609231927.GL10176@earth.li> Message-ID: <9621.128.165.0.81.1118363407.squirrel@webmail.lanl.gov> > On Thu, Jun 09, 2005 at 03:20:57PM -0600, Li-Ta Lo wrote: >> > BTW, how exactly should I roll back a patch level ? Is the "tla replay >> > --revers" plus "tla sync-tree" the right way to do? Does it undo >> > "tla add"? > For the backing out a changeset I found: > > >http://wiki.gnuarch.org/Arch_20Recipes#head-13d35cf3d0899c602e4e054cd7e962e62685edb7 > Does this roll back "tla add", "tla rm" and "tla mv" ? What do these commands do to the repository? Are they just local until a "tla commit" like their cvs counterparts? One reason we tried to switch to some VCS with "automatic" operation is to be easy to roll back these commands. Ollie From yinghailu at gmail.com Fri Jun 10 02:31:17 2005 From: yinghailu at gmail.com (yhlu) Date: Thu, 9 Jun 2005 17:31:17 -0700 Subject: [BULK] RE: [LinuxBIOS] FYI: AMD support for cache as ram. In-Reply-To: <2ea3fae10506070928700156d9@mail.gmail.com> References: <3174569B9743D511922F00A0C94314230A403B62@TYANWEB> <2ea3fae105060621025cc22e98@mail.gmail.com> <1118160591.5629.6.camel@logarithm.lanl.gov> <2ea3fae10506070928700156d9@mail.gmail.com> Message-ID: <2ea3fae105060917314acfcd1@mail.gmail.com> Some good news, it die at "Clearing initial memory region: ", I guess some code that enable mtrr or cache in raminit.c need to move out .c and put into crt0.S directly. Another question: Now the auto.inc is generated with gcc, the problem there should some way to modify section name. i mean .text ---> .section .rom.text .section .rodat ---> .section .rom.data If the gcc can not do that, any one can tell me how to do that via perl or python.... YH LinuxBIOS-1.1.8_s2891_Fallback Thu Jun 9 18:03:24 PDT 2005 starting... 02 nodes initialized. ht reset - LinuxBIOS-1.1.8_s2891_Fallback Thu Jun 9 18:03:24 PDT 2005 starting... 02 nodes initialized. SMBus controller enabled Ram1.00 Ram1.01 Ram2.00 Ram2.01 Ram3 Initializing memory: done Initializing memory: done Clearing initial memory region: From ollie at lanl.gov Fri Jun 10 02:49:52 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Thu, 9 Jun 2005 18:49:52 -0600 (MDT) Subject: [BULK] RE: [LinuxBIOS] FYI: AMD support for cache as ram. In-Reply-To: <2ea3fae105060917314acfcd1@mail.gmail.com> References: <3174569B9743D511922F00A0C94314230A403B62@TYANWEB> <2ea3fae105060621025cc22e98@mail.gmail.com> <1118160591.5629.6.camel@logarithm.lanl.gov> <2ea3fae10506070928700156d9@mail.gmail.com> <2ea3fae105060917314acfcd1@mail.gmail.com> Message-ID: <13802.128.165.0.81.1118364592.squirrel@webmail.lanl.gov> > Some good news, > > it die at "Clearing initial memory region: ", > I guess some code that enable mtrr or cache in raminit.c need to move > out .c and put into crt0.S directly. > > Another question: > Now the auto.inc is generated with gcc, the problem there should some > way to modify section name. > i mean .text ---> .section .rom.text > .section .rodat ---> .section .rom.data > > If the gcc can not do that, any one can tell me how to do that via > perl or python.... > Are you using inline asm in gcc code? What is your asm in C looks like? You can still use .section directive in the inline asm AFIAK. Ollie From rminnich at lanl.gov Fri Jun 10 04:52:55 2005 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Thu, 9 Jun 2005 20:52:55 -0600 (MDT) Subject: [LinuxBIOS] Tyan S2895 Mptable In-Reply-To: <9B124F08B3EFDA4F8813B05102DC719503A40C6E@nh-ex01.bench.com> References: <9B124F08B3EFDA4F8813B05102DC719503A40C6E@nh-ex01.bench.com> Message-ID: On Thu, 9 Jun 2005 Stephen.Kimball at bench.com wrote: > That's what I said ... it's disabled in the MB Config.lb, but the > hardware is still there. It's only two lines in the mptable.c. Do you > expect s2895 users to not need the extra 4 SATA ports? Why not fix it? > I'm sure you know how to fix it. I'm a little mixed up here, are the connectors and everything there? > If I see something that could be improved in the CK804 code, what should > I do? So far all my suggestions have been dismissed. Just hang in there, sorry this is frustrating for you, I don't have this mobo so can only go on what people say. Yh Lu, why is second one disabled? ron From YhLu at tyan.com Fri Jun 10 04:58:23 2005 From: YhLu at tyan.com (YhLu) Date: Thu, 9 Jun 2005 19:58:23 -0700 Subject: [LinuxBIOS] Tyan S2895 Mptable Message-ID: <3174569B9743D511922F00A0C94314230A403F18@TYANWEB> There is no space in MB, the HW engineer didn't connect the second sata out. YH > -----Original Message----- > From: Ronald G. Minnich [mailto:rminnich at lanl.gov] > Sent: Thursday, June 09, 2005 7:53 PM > To: Stephen.Kimball at bench.com > Cc: linuxbios at openbios.org > Subject: RE: [LinuxBIOS] Tyan S2895 Mptable > > > > On Thu, 9 Jun 2005 Stephen.Kimball at bench.com wrote: > > > That's what I said ... it's disabled in the MB Config.lb, but the > > hardware is still there. It's only two lines in the mptable.c. Do > > you expect s2895 users to not need the extra 4 SATA ports? > Why not fix it? > > I'm sure you know how to fix it. > > I'm a little mixed up here, are the connectors and everything there? > > > If I see something that could be improved in the CK804 code, what > > should I do? So far all my suggestions have been dismissed. > > Just hang in there, sorry this is frustrating for you, I > don't have this mobo so can only go on what people say. > > Yh Lu, why is second one disabled? > > ron > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From rminnich at lanl.gov Fri Jun 10 05:04:25 2005 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Thu, 9 Jun 2005 21:04:25 -0600 (MDT) Subject: [LinuxBIOS] Tyan S2895 Mptable In-Reply-To: <3174569B9743D511922F00A0C94314230A403F18@TYANWEB> References: <3174569B9743D511922F00A0C94314230A403F18@TYANWEB> Message-ID: On Thu, 9 Jun 2005, YhLu wrote: > There is no space in MB, the HW engineer didn't connect the second sata out. > ok, then, I guess Stephen's request for a comment in the config file would be helpful for other users too, Yh Lu, can you add a comment about that? ron From YhLu at tyan.com Fri Jun 10 05:34:02 2005 From: YhLu at tyan.com (YhLu) Date: Thu, 9 Jun 2005 20:34:02 -0700 Subject: [LinuxBIOS] Tyan S2895 Mptable Message-ID: <3174569B9743D511922F00A0C94314230A403F19@TYANWEB> After i get cache as ram done. YH > -----Original Message----- > From: Ronald G. Minnich [mailto:rminnich at lanl.gov] > Sent: Thursday, June 09, 2005 8:04 PM > To: YhLu > Cc: Stephen.Kimball at bench.com; linuxbios at openbios.org > Subject: RE: [LinuxBIOS] Tyan S2895 Mptable > > > > On Thu, 9 Jun 2005, YhLu wrote: > > > There is no space in MB, the HW engineer didn't connect the > second sata out. > > > > ok, then, I guess Stephen's request for a comment in the > config file would be helpful for other users too, Yh Lu, can > you add a comment about that? > > ron > From ebiederman at lnxi.com Fri Jun 10 07:27:26 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: 09 Jun 2005 23:27:26 -0600 Subject: [BULK] RE: [LinuxBIOS] FYI: AMD support for cache as ram. In-Reply-To: <2ea3fae105060917314acfcd1@mail.gmail.com> References: <3174569B9743D511922F00A0C94314230A403B62@TYANWEB> <2ea3fae105060621025cc22e98@mail.gmail.com> <1118160591.5629.6.camel@logarithm.lanl.gov> <2ea3fae10506070928700156d9@mail.gmail.com> <2ea3fae105060917314acfcd1@mail.gmail.com> Message-ID: yhlu writes: > Some good news, > > it die at "Clearing initial memory region: ", > I guess some code that enable mtrr or cache in raminit.c need to move > out .c and put into crt0.S directly. Potentially. It might simply be that we are reprogramming top_mem or the iorrs to define what memory is and messing up the early definition. > Another question: > Now the auto.inc is generated with gcc, the problem there should some > way to modify section name. > i mean .text ---> .section .rom.text > .section .rodat ---> .section .rom.data > > If the gcc can not do that, any one can tell me how to do that via > perl or python.... The trivial way is to include an asm directive at the beginning. I had actually expected to use something like the init directive that is used on the PPC, and let gcc generate the .o files. At that point a trivial linker script could place everything in .rom.text and .rom.data if needed. Eric p.s. Anyone know why I did not receive a copy of this message on the mailing list? p.p.s. YH I just got a look at your auto routing hypertransport code and while it looks to be a good step in the right direction I had always imagined topology discovery in there. More tommorrow after I have slept. Eric From ebiederman at lnxi.com Fri Jun 10 07:28:49 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: 09 Jun 2005 23:28:49 -0600 Subject: [BULK] RE: [LinuxBIOS] FYI: AMD support for cache as ram. In-Reply-To: <13802.128.165.0.81.1118364592.squirrel@webmail.lanl.gov> References: <3174569B9743D511922F00A0C94314230A403B62@TYANWEB> <2ea3fae105060621025cc22e98@mail.gmail.com> <1118160591.5629.6.camel@logarithm.lanl.gov> <2ea3fae10506070928700156d9@mail.gmail.com> <2ea3fae105060917314acfcd1@mail.gmail.com> <13802.128.165.0.81.1118364592.squirrel@webmail.lanl.gov> Message-ID: "Li-Ta Lo" writes: > Are you using inline asm in gcc code? What is your asm in C looks like? > You can still use .section directive in the inline asm AFIAK. You can and you can even explicitly tell gcc the section. The problem is that you have to tell gcc everywhere... Eric From noodles at earth.li Fri Jun 10 12:14:40 2005 From: noodles at earth.li (Jonathan McDowell) Date: Fri, 10 Jun 2005 11:14:40 +0100 Subject: [LinuxBIOS] TLA Sucks In-Reply-To: <9621.128.165.0.81.1118363407.squirrel@webmail.lanl.gov> References: <1118351041.19063.10.camel@logarithm.lanl.gov> <1118352057.19063.12.camel@logarithm.lanl.gov> <20050609231927.GL10176@earth.li> <9621.128.165.0.81.1118363407.squirrel@webmail.lanl.gov> Message-ID: <20050610101440.GD10176@earth.li> On Thu, Jun 09, 2005 at 06:30:07PM -0600, Li-Ta Lo wrote: > > On Thu, Jun 09, 2005 at 03:20:57PM -0600, Li-Ta Lo wrote: > >> > BTW, how exactly should I roll back a patch level ? Is the "tla replay > >> > --revers" plus "tla sync-tree" the right way to do? Does it undo > >> > "tla add"? > > For the backing out a changeset I found: > > > > >http://wiki.gnuarch.org/Arch_20Recipes#head-13d35cf3d0899c602e4e054cd7e962e62685edb7 > > > Does this roll back "tla add", "tla rm" and "tla mv" ? > What do these commands do to the repository? Are they > just local until a "tla commit" like their cvs counterparts? Yes, add, rm & mv all just affect your local tree checkout until you commit them. Try looking at the rest of the http://wiki.gnuarch.org/Arch_20Recipes page. "Fixing your own mistakes" seems to be the section you want. > One reason we tried to switch to some VCS with "automatic" operation > is to be easy to roll back these commands. I've not had to do it myself (yet), but it looks like arch can handle this without a problem. J. -- ] http://www.earth.li/~noodles/ [] noodles is made from buckwheat [ ] PGP/GPG Key @ the.earth.li [] flour [ ] via keyserver, web or email. [] [ ] RSA: 4DC4E7FD / DSA: 5B430367 [] [ From yinghailu at gmail.com Fri Jun 10 18:26:27 2005 From: yinghailu at gmail.com (yhlu) Date: Fri, 10 Jun 2005 09:26:27 -0700 Subject: [BULK] RE: [LinuxBIOS] FYI: AMD support for cache as ram. In-Reply-To: References: <3174569B9743D511922F00A0C94314230A403B62@TYANWEB> <2ea3fae105060621025cc22e98@mail.gmail.com> <1118160591.5629.6.camel@logarithm.lanl.gov> <2ea3fae10506070928700156d9@mail.gmail.com> <2ea3fae105060917314acfcd1@mail.gmail.com> Message-ID: <2ea3fae105061009265a9bac6@mail.gmail.com> On 09 Jun 2005 23:27:26 -0600, Eric W. Biederman > Potentially. It might simply be that we are reprogramming > top_mem or the iorrs to define what memory is and messing up the > early definition. It seems top_mem....I will double check that. > > The trivial way is to include an asm directive at the beginning. > I had actually expected to use something like the init directive > that is used on the PPC, and let gcc generate the .o files. At > that point a trivial linker script could place everything in .rom.text > and .rom.data if needed. That could be next step, in asm make it more easier to debug. Current I could not get out of auto.c, I guess i will 1. change cache_lbmem in raminit.c to 512k only 2. covert copy or decode in crt0.S to c and call directly after ram is initialized. 3. use init.o like Ollie wanted....and change to use new print_debug to printk_debug.... > > p.s. > > Anyone know why I did not receive a copy of this message on the > mailing list? Stefan must leave your out of linuxbios list in openbios... YH From stuge-linuxbios at cdy.org Fri Jun 10 20:16:12 2005 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Fri, 10 Jun 2005 20:16:12 +0200 Subject: [BULK] RE: [LinuxBIOS] FYI: AMD support for cache as ram. In-Reply-To: <2ea3fae105061009265a9bac6@mail.gmail.com> References: <3174569B9743D511922F00A0C94314230A403B62@TYANWEB> <2ea3fae105060621025cc22e98@mail.gmail.com> <1118160591.5629.6.camel@logarithm.lanl.gov> <2ea3fae10506070928700156d9@mail.gmail.com> <2ea3fae105060917314acfcd1@mail.gmail.com> <2ea3fae105061009265a9bac6@mail.gmail.com> Message-ID: <20050610181612.GA16500@foo.birdnet.se> On Fri, Jun 10, 2005 at 09:26:27AM -0700, yhlu wrote: > On 09 Jun 2005 23:27:26 -0600, Eric W. Biederman > > p.s. > > > > Anyone know why I did not receive a copy of this message on the > > mailing list? > Stefan must leave your out of linuxbios list in openbios... This is an option in Mailman, the same thing happened to me and I also want the message from the list. Enter subscribed email address and password on http://www.openbios.org/mailman/options/linuxbios/ and down at the bottom of the page select No for the "Avoid duplicate copies of messages?" option. I also like to disable the password reminder a few options up. //Peter From stuge-linuxbios at cdy.org Fri Jun 10 20:23:53 2005 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Fri, 10 Jun 2005 20:23:53 +0200 Subject: [BULK] RE: [LinuxBIOS] FYI: AMD support for cache as ram. In-Reply-To: <20050610181612.GA16500@foo.birdnet.se> References: <3174569B9743D511922F00A0C94314230A403B62@TYANWEB> <2ea3fae105060621025cc22e98@mail.gmail.com> <1118160591.5629.6.camel@logarithm.lanl.gov> <2ea3fae10506070928700156d9@mail.gmail.com> <2ea3fae105060917314acfcd1@mail.gmail.com> <2ea3fae105061009265a9bac6@mail.gmail.com> <20050610181612.GA16500@foo.birdnet.se> Message-ID: <20050610182353.GB16500@foo.birdnet.se> On Fri, Jun 10, 2005 at 08:16:12PM +0200, Peter Stuge wrote: > also want the message from the list. Enter subscribed email address > and password on http://www.openbios.org/mailman/options/linuxbios/ > and down at the bottom of the page select No for the "Avoid duplicate ^ - next Must log in first to show the options page, sorry, could have been clearer. //Peter From ollie at lanl.gov Sat Jun 11 07:58:25 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Fri, 10 Jun 2005 23:58:25 -0600 Subject: [BULK] RE: [LinuxBIOS] FYI: AMD support for cache as ram. In-Reply-To: <2ea3fae105061009265a9bac6@mail.gmail.com> References: <3174569B9743D511922F00A0C94314230A403B62@TYANWEB> <2ea3fae105060621025cc22e98@mail.gmail.com> <1118160591.5629.6.camel@logarithm.lanl.gov> <2ea3fae10506070928700156d9@mail.gmail.com> <2ea3fae105060917314acfcd1@mail.gmail.com> <2ea3fae105061009265a9bac6@mail.gmail.com> Message-ID: <1118469505.9395.3.camel@logarithm.lanl.gov> On Fri, 2005-06-10 at 09:26 -0700, yhlu wrote: > On 09 Jun 2005 23:27:26 -0600, Eric W. Biederman > > Potentially. It might simply be that we are reprogramming > > top_mem or the iorrs to define what memory is and messing up the > > early definition. > It seems top_mem....I will double check that. > > > > The trivial way is to include an asm directive at the beginning. > > I had actually expected to use something like the init directive > > that is used on the PPC, and let gcc generate the .o files. At > > that point a trivial linker script could place everything in .rom.text > > and .rom.data if needed. > That could be next step, in asm make it more easier to debug. > Current I could not get out of auto.c, I guess i will > 1. change cache_lbmem in raminit.c to 512k only > 2. covert copy or decode in crt0.S to c and call directly after ram is > initialized. > 3. use init.o like Ollie wanted....and change to use new print_debug > to printk_debug.... > > > > p.s. > > > > Anyone know why I did not receive a copy of this message on the > > mailing list? > Stefan must leave your out of linuxbios list in openbios... > Did you do HT reset after CAR but before DRAM? In my old implementation, HT reset will mess up CAR. -- Li-Ta Lo Los Alamos National Lab From YhLu at tyan.com Sat Jun 11 08:02:25 2005 From: YhLu at tyan.com (YhLu) Date: Fri, 10 Jun 2005 23:02:25 -0700 Subject: [BULK] RE: [LinuxBIOS] FYI: AMD support for cache as ram. Message-ID: <3174569B9743D511922F00A0C94314230A403FEE@TYANWEB> YES LinuxBIOS-1.1.8_s2891_Fallback Fri Jun 10 22:56:51 PDT 2005 starting... (0,1) link=01 (1,0) link=00 02 nodes initialized. SBLink=00 NC node|link=00 NC node|link=02 busn=06 ht reset - LinuxBIOS-1.1.8_s2891_Fallback Fri Jun 10 22:56:51 PDT 2005 starting... (0,1) link=01 (1,0) link=00 02 nodes initialized. SBLink=00 NC node|link=00 NC node|link=02 busn=06 SMBus controller enabled Ram1.00 Ram1.01 Ram2.00 Ram2.01 Ram3 Initializing memory: done Initializing memory: done Ram4 Clearing initial memory region: No cache as ram now - Use Ram as Stack now - > -----Original Message----- > From: Li-Ta Lo [mailto:ollie at lanl.gov] > Sent: Friday, June 10, 2005 10:58 PM > To: yhlu > Cc: Eric W. Biederman; YhLu; Ronald G. Minnich; Stefan > Reinauer; LinuxBIOS > Subject: Re: [BULK] RE: [LinuxBIOS] FYI: AMD support for cache as ram. > > On Fri, 2005-06-10 at 09:26 -0700, yhlu wrote: > > On 09 Jun 2005 23:27:26 -0600, Eric W. Biederman > > > > Potentially. It might simply be that we are > reprogramming top_mem > > > or the iorrs to define what memory is and messing up the early > > > definition. > > It seems top_mem....I will double check that. > > > > > > The trivial way is to include an asm directive at the beginning. > > > I had actually expected to use something like the init directive > > > that is used on the PPC, and let gcc generate the .o > files. At that > > > point a trivial linker script could place everything in .rom.text > > > and .rom.data if needed. > > That could be next step, in asm make it more easier to debug. > > Current I could not get out of auto.c, I guess i will 1. change > > cache_lbmem in raminit.c to 512k only 2. covert copy or decode in > > crt0.S to c and call directly after ram is initialized. > > 3. use init.o like Ollie wanted....and change to use new > print_debug > > to printk_debug.... > > > > > > p.s. > > > > > > Anyone know why I did not receive a copy of this message on the > > > mailing list? > > Stefan must leave your out of linuxbios list in openbios... > > > > Did you do HT reset after CAR but before DRAM? In my old > implementation, HT reset will mess up CAR. > > -- > Li-Ta Lo > Los Alamos National Lab > From talbotx at comcast.net Sun Jun 12 00:04:47 2005 From: talbotx at comcast.net (Adam Talbot) Date: Sat, 11 Jun 2005 15:04:47 -0700 Subject: [LinuxBIOS] Filo References: <3174569B9743D511922F00A0C94314230A403F18@TYANWEB> Message-ID: <007d01c56ed1$950d1550$c501a8c0@newflame> So we have been playing with the EPIA-M/MII code. Getting very close. Joathan has been able to get us to filo, but at this point I am lost. Filo is called, but it does not look like my kernel is getting called. Here is what I see. Any ideas? Adam Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.3 23:stream_init() - rom_stream: 0xfffe0000 - 0xfffeffff Found ELF candiate at offset 0 header_offset is 0 Try to load at offset 0x0 malloc Enter, size 32, free_mem_ptr 000164f0 malloc 0x000164f0 New segment addr 0x100000 size 0x210a0 offset 0xe0 filesize 0x70c8 (cleaned up) New segment addr 0x100000 size 0x210a0 offset 0xe0 filesize 0x70c8 lb: [0x0000000000004000, 0x000000000001a000) malloc Enter, size 32, free_mem_ptr 00016510 malloc 0x00016510 New segment addr 0x1210a0 size 0x48 offset 0x71c0 filesize 0x48 (cleaned up) New segment addr 0x1210a0 size 0x48 offset 0x71c0 filesize 0x48 lb: [0x0000000000004000, 0x000000000001a000) Dropping non PT_LOAD segment Dropping non PT_LOAD segment Dropping non PT_LOAD segment Loading Segment: addr: 0x0000000000100000 memsz: 0x00000000000210a0 filesz: 0x00000000000070c8 [ 0x0000000000100000, 00000000001070c8, 0x00000000001210a0) <- 00000000000000e0 Clearing Segment: addr: 0x00000000001070c8 memsz: 0x0000000000019fd8 Loading Segment: addr: 0x00000000001210a0 memsz: 0x0000000000000048 filesz: 0x0000000000000048 [ 0x00000000001210a0, 00000000001210e8, 0x00000000001210e8) <- 00000000000071c0 Loaded segments verified segments closed down stream Jumping to boot code at 0x104ec8 entry = 0x00104ec8 lb_start = 0x00004000 lb_size = 0x00016000 adjust = 0xfcfe6000 buffer = 0xfcfd4000 elf_boot_notes = 0x000112e0 adjusted_boot_notes = 0xfcff72e0 From YhLu at tyan.com Mon Jun 13 23:08:48 2005 From: YhLu at tyan.com (YhLu) Date: Mon, 13 Jun 2005 14:08:48 -0700 Subject: [BULK] RE: [LinuxBIOS] FYI: AMD support for cache as ram. Message-ID: <3174569B9743D511922F00A0C94314230A404078@TYANWEB> I got the stack in ram works. it when execute the dump_mem(dst, dst+0x100); print_debug("Jumping to LinuxBIOS.\r\n"); __asm__ volatile ( "cli\n\t" "leal _iseg, %edi\n\t" "jmp %edi\n\t" ); in copy_and_run.c, the jmp will cause cpu_reset.... It's strang.... I want to check in the cache_as_ram code, and it can coexist with old romcc code, ( by USE_DCACHE_RAM to switch..) Please let me know if you want to check that code in...... YH LinuxBIOS-1.1.8_s2891_Fallback Mon Jun 13 14:33:38 PDT 2005 starting... (0,1) link=01 (1,0) link=00 02 nodes initialized. SBLink=00 NC node|link=00 NC node|link=02 busn=06 ht reset - LinuxBIOS-1.1.8_s2891_Fallback Mon Jun 13 14:33:38 PDT 2005 starting... (0,1) link=01 (1,0) link=00 02 nodes initialized. SBLink=00 NC node|link=00 NC node|link=02 busn=06 SMBus controller enabled Ram1.00 Ram1.01 Ram2.00 Ram2.01 Ram3 Initializing memory: done Initializing memory: done Ram4 v_esp=000cfe84 Clearing initial memory region: No cache as ram now - Use Ram as Stack now - done Copying LinuxBIOS to ram. src=fffe9c84 dst=00004000 0x00004000: fa 2e 0f 01 15 31 41 00 00 ea 10 40 00 00 10 00 0x00004010: b8 18 00 00 00 8e d8 8e c0 8e d0 8e e0 8e e8 b0 0x00004020: 13 e6 80 8d 3d 00 e0 03 00 b9 00 60 04 00 29 f9 0x00004030: 31 c0 f3 aa 8d 3d 70 54 02 00 b9 e8 dd 03 00 29 0x00004040: f9 74 04 31 c0 f3 aa bc 00 60 04 00 6a 00 6a 00 0x00004050: 55 89 e5 8d 3d 10 ad 01 00 8d 1d 9a 40 00 00 b8 0x00004060: 00 00 10 00 66 89 d8 89 da 66 ba 00 8e 89 47 00 0x00004070: 89 57 04 83 c3 06 83 c7 08 81 ff b0 ad 01 00 75 0x00004080: e3 0f 01 1d 08 ad 01 00 b0 fe e6 80 89 ec e8 a5 0x00004090: 42 00 00 b0 ee e6 80 f4 eb f9 6a 00 6a 00 eb 72 0x000040a0: 6a 00 6a 01 eb 6c 6a 00 6a 02 eb 66 6a 00 6a 03 0x000040b0: eb 60 6a 00 6a 04 eb 5a 6a 00 6a 05 eb 54 6a 00 0x000040c0: 6a 06 eb 4e 6a 00 6a 07 eb 48 6a 08 eb 44 90 90 0x000040d0: 6a 00 6a 09 eb 3c 6a 0a eb 38 90 90 6a 0b eb 32 0x000040e0: 90 90 6a 0c eb 2c 90 90 6a 0d eb 26 90 90 6a 0e 0x000040f0: eb 20 90 90 6a 00 6a 0f eb 18 6a 00 6a 10 eb 12 Jumping to LinuxBIOS. Clearing initial memory region: No cache as ram now - Use Ram as Stack now - done Copying LinuxBIOS to ram. src=fffe9c84 dst=00004000 0x00004000: fa 2e 0f 01 15 31 41 00 00 ea 10 40 00 00 10 00 0x00004010: b8 18 00 00 00 8e d8 8e c0 8e d0 8e e0 8e e8 b0 0x00004020: 13 e6 80 8d 3d 00 e0 03 00 b9 00 60 04 00 29 f9 0x00004030: 31 c0 f3 aa 8d 3d 70 54 02 00 b9 e8 dd 03 00 29 0x00004040: f9 74 04 31 c0 f3 aa bc 00 60 04 00 6a 00 6a 00 0x00004050: 55 89 e5 8d 3d 10 ad 01 00 8d 1d 9a 40 00 00 b8 0x00004060: 00 00 10 00 66 89 d8 89 da 66 ba 00 8e 89 47 00 0x00004070: 89 57 04 83 c3 06 83 c7 08 81 ff b0 ad 01 00 75 0x00004080: e3 0f 01 1d 08 ad 01 00 b0 fe e6 80 89 ec e8 a5 0x00004090: 42 00 00 b0 ee e6 80 f4 eb f9 6a 00 6a 00 eb 72 0x000040a0: 6a 00 6a 01 eb 6c 6a 00 6a 02 eb 66 6a 00 6a 03 0x000040b0: eb 60 6a 00 6a 04 eb 5a 6a 00 6a 05 eb 54 6a 00 0x000040c0: 6a 06 eb 4e 6a 00 6a 07 eb 48 6a 08 eb 44 90 90 0x000040d0: 6a 00 6a 09 eb 3c 6a 0a eb 38 90 90 6a 0b eb 32 0x000040e0: 90 90 6a 0c eb 2c 90 90 6a 0d eb 26 90 90 6a 0e 0x000040f0: eb 20 90 90 6a 00 6a 0f eb 18 6a 00 6a 10 eb 12 Jumping to LinuxBIOS. Clearing initial memory region: No cache as ram now - Use Ram as Stack now - done Copying LinuxBIOS to ram. src=fffe9c84 dst=00004000 From YhLu at tyan.com Tue Jun 14 07:01:14 2005 From: YhLu at tyan.com (YhLu) Date: Mon, 13 Jun 2005 22:01:14 -0700 Subject: [BULK] RE: [LinuxBIOS] FYI: AMD support for cache as ram. Message-ID: <3174569B9743D511922F00A0C94314230A4040D3@TYANWEB> Get into hardwaremain now, and boot_complete is right, but the console_init cause cpu_reset...... YH void hardwaremain(int boot_complete) { struct lb_memory *lb_mem; post_code(0x80); /* displayinit MUST PRECEDE ALL PRINTK! */ console_init(); From steve at digidescorp.com Tue Jun 14 16:54:58 2005 From: steve at digidescorp.com (Steven J. Magnani) Date: Tue, 14 Jun 2005 09:54:58 -0500 Subject: [LinuxBIOS] E7501 SDRAM command bug? Message-ID: <000c01c570f1$0be2cf50$6ffea8c0@banana> I'm still working on getting the DRAM running on our E7501-based board. I've run across something in the E7501 raminit code that doesn't look right. The E7501 datasheet isn't clear about how RAM commands get sent to the DIMMs. All it says is (for example): "NOP Command Enable - All processor cycles to DRAM result in a NOP command on the DRAM interface". It isn't clear whether a single access to DRAM causes the command to go to all DIMMs, or only to the one addressed by the access. I ran some experiments and it appears that only the addressed DIMM gets the command. So, the raminit.c code that sends commands to RAM (below) needs to loop over all the possible DIMMs, accessing a memory address that lies within each. static inline void do_ram_command (const struct mem_controller *ctrl, uint32_t value) { uint32_t dword; uint8_t byte; int i; uint32_t result; /* Compute the offset */ dword = value >> 16; for(i=0;i<8;i++) { /* Set the ram command */ byte = pci_read_config8(ctrl->d0, 0x7c); byte &= 0x8f; byte |= (uint8_t)(value & 0xff); pci_write_config8(ctrl->d0, 0x7c, byte); /* Assert the command to the memory */ result = read32(dword); /* Go to the next base address */ dword += 0x04000000; } /* The command has been sent to all dimms so get out */ } The problem is that the code assumes that the address "distance" from one DIMM to the next is always 0x04000000. Depending on the DIMM geometry, that may not be the case. Instead, shouldn't the code be using the previously-initialized DRAM boundary registers to construct addresses for each DIMM? And for systems with more than 4 GB, shouldn't it have the ability to access 36-bit addresses? Steve Magnani www.digidescorp.com From rminnich at lanl.gov Tue Jun 14 17:24:45 2005 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Tue, 14 Jun 2005 09:24:45 -0600 (MDT) Subject: [LinuxBIOS] E7501 SDRAM command bug? In-Reply-To: <000c01c570f1$0be2cf50$6ffea8c0@banana> References: <000c01c570f1$0be2cf50$6ffea8c0@banana> Message-ID: I would need to look at that code more, but what is typically done is the boundary registers are programmed so that the ram "size" is 0x4000000 and all the commands for setup are sent to the ram. Once all the ram init is done, then the actual row boundaries are set. We do it this way because it saves a lot of computation that is not really needed. ron From steve at digidescorp.com Tue Jun 14 17:34:48 2005 From: steve at digidescorp.com (Steven J. Magnani) Date: Tue, 14 Jun 2005 10:34:48 -0500 Subject: [LinuxBIOS] E7501 SDRAM command bug? In-Reply-To: Message-ID: <000d01c570f6$9c1c6720$6ffea8c0@banana> The boundaries are configured during the "sdram_set_registers" phase of setup, but (for E7501) the "sdram_set_spd_registers" phase overrides those values before the RAM commands are sent in the "sdram_enable" phase. There is evidence in the code that this was not always the case. Steve -----Original Message----- From: Ronald G. Minnich [mailto:rminnich at lanl.gov] Sent: Tuesday, June 14, 2005 9:25 AM To: Steven J. Magnani Cc: linuxbios at openbios.org Subject: Re: [LinuxBIOS] E7501 SDRAM command bug? I would need to look at that code more, but what is typically done is the boundary registers are programmed so that the ram "size" is 0x4000000 and all the commands for setup are sent to the ram. Once all the ram init is done, then the actual row boundaries are set. We do it this way because it saves a lot of computation that is not really needed. ron From rminnich at lanl.gov Tue Jun 14 18:38:24 2005 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Tue, 14 Jun 2005 10:38:24 -0600 (MDT) Subject: [LinuxBIOS] E7501 SDRAM command bug? In-Reply-To: <000d01c570f6$9c1c6720$6ffea8c0@banana> References: <000d01c570f6$9c1c6720$6ffea8c0@banana> Message-ID: On Tue, 14 Jun 2005, Steven J. Magnani wrote: > The boundaries are configured during the "sdram_set_registers" phase of > setup, but (for E7501) the "sdram_set_spd_registers" phase overrides > those values before the RAM commands are sent in the "sdram_enable" > phase. There is evidence in the code that this was not always the case. yes, that is a wrong sequence. boundaries should always be set LAST. do you want to take a stab at fixing this? ron From steve at digidescorp.com Tue Jun 14 18:55:39 2005 From: steve at digidescorp.com (Steven J. Magnani) Date: Tue, 14 Jun 2005 11:55:39 -0500 Subject: [LinuxBIOS] E7501 SDRAM command bug? In-Reply-To: Message-ID: <000e01c57101$e8173c30$6ffea8c0@banana> I am working on a substantial rewrite of E7501's raminit.c to get it into a form that is easier to understand. I'll fix it there. But the changes may be too radical for the LB community-at-large, and probably won't be available for a few weeks. Steve -----Original Message----- From: Ronald G. Minnich [mailto:rminnich at lanl.gov] Sent: Tuesday, June 14, 2005 10:38 AM To: Steven J. Magnani Cc: linuxbios at openbios.org Subject: RE: [LinuxBIOS] E7501 SDRAM command bug? On Tue, 14 Jun 2005, Steven J. Magnani wrote: > The boundaries are configured during the "sdram_set_registers" phase > of setup, but (for E7501) the "sdram_set_spd_registers" phase > overrides those values before the RAM commands are sent in the > "sdram_enable" phase. There is evidence in the code that this was not > always the case. yes, that is a wrong sequence. boundaries should always be set LAST. do you want to take a stab at fixing this? ron From steve at digidescorp.com Tue Jun 14 19:32:45 2005 From: steve at digidescorp.com (Steven J. Magnani) Date: Tue, 14 Jun 2005 12:32:45 -0500 Subject: [LinuxBIOS] E7501 SDRAM timing bug? In-Reply-To: Message-ID: <000f01c57107$16631870$6ffea8c0@banana> Another suspicious looking bit of E7501 RAM initialization code...in spd_set_dram_controller_mode() there is code that reads the SPD address/command hold time and configures the E7501 for "1n rule" or "2n rule" operation: value = spd_read_byte(ctrl->channel0[i], 33); /* Address and command hold time after clock */ if(value < 0) continue; if(value >= 0xa0) { /* At 133Mhz this constant should be 0x75 */ dword &= ~(1<<16); /* Use two clock cyles instead of one */ } The issues here are frequency and scale. The rest of the E7501 code assumes 133 MHz operation. So it looks from the comments like the comparison to 0xa0 should really be to 0x75. But the SPD value is in _tenths_ of nanoseconds. So the above code translates to, "if the address/hold time is more than 1 ns, use 2 clock cycles per command". But the clock period is 10 ns for 100 MHz or 7.5 ns for 133 MHz, which is an order of magnitude larger than the SPD values. I didn't see code for any other chipset that did something like this, except the Intel 855pm - where it's #ifdef'd out. I'm thinking this code should be removed. Steve www.digidescorp.com From YhLu at tyan.com Tue Jun 14 19:40:57 2005 From: YhLu at tyan.com (YhLu) Date: Tue, 14 Jun 2005 10:40:57 -0700 Subject: [LinuxBIOS] E7501 SDRAM timing bug? Message-ID: <3174569B9743D511922F00A0C94314230A404104@TYANWEB> Good, Can you compare the raminit.inc in V1, and raminit.c in V2? So make sure if my translation cause problm. Thanks YH > -----Original Message----- > From: Steven J. Magnani [mailto:steve at digidescorp.com] > Sent: Tuesday, June 14, 2005 10:33 AM > To: 'Ronald G. Minnich' > Cc: linuxbios at openbios.org > Subject: [LinuxBIOS] E7501 SDRAM timing bug? > > Another suspicious looking bit of E7501 RAM initialization code...in > spd_set_dram_controller_mode() there is code that reads the > SPD address/command hold time and configures the E7501 for > "1n rule" or "2n rule" operation: > > value = spd_read_byte(ctrl->channel0[i], 33); > /* Address and command hold time after clock */ > if(value < 0) continue; > if(value >= 0xa0) { /* At 133Mhz this > constant should be 0x75 */ > dword &= ~(1<<16); /* Use two clock cyles > instead of one */ > } > > The issues here are frequency and scale. > > The rest of the E7501 code assumes 133 MHz operation. So it > looks from the comments like the comparison to 0xa0 should > really be to 0x75. > > But the SPD value is in _tenths_ of nanoseconds. So the above > code translates to, "if the address/hold time is more than 1 > ns, use 2 clock cycles per command". But the clock period is > 10 ns for 100 MHz or 7.5 ns for 133 MHz, which is an order of > magnitude larger than the SPD values. > > I didn't see code for any other chipset that did something > like this, except the Intel 855pm - where it's #ifdef'd out. > I'm thinking this code should be removed. > > Steve > www.digidescorp.com > > > > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From steve at digidescorp.com Tue Jun 14 19:52:37 2005 From: steve at digidescorp.com (Steven J. Magnani) Date: Tue, 14 Jun 2005 12:52:37 -0500 Subject: [LinuxBIOS] E7501 SDRAM timing bug? In-Reply-To: <3174569B9743D511922F00A0C94314230A404104@TYANWEB> Message-ID: <001001c57109$dd5bea40$6ffea8c0@banana> The translation is fine, the issue was present in the V1 code. Probably it's one of those things where the DRAM would work fine (if slower than necessary) regardless of the SPD value. Steve -----Original Message----- From: YhLu [mailto:YhLu at tyan.com] Sent: Tuesday, June 14, 2005 11:41 AM To: Steven J. Magnani; 'Ronald G. Minnich' Cc: linuxbios at openbios.org Subject: RE: [LinuxBIOS] E7501 SDRAM timing bug? Good, Can you compare the raminit.inc in V1, and raminit.c in V2? So make sure if my translation cause problm. Thanks YH > -----Original Message----- > From: Steven J. Magnani [mailto:steve at digidescorp.com] > Sent: Tuesday, June 14, 2005 10:33 AM > To: 'Ronald G. Minnich' > Cc: linuxbios at openbios.org > Subject: [LinuxBIOS] E7501 SDRAM timing bug? > > Another suspicious looking bit of E7501 RAM initialization code...in > spd_set_dram_controller_mode() there is code that reads the > SPD address/command hold time and configures the E7501 for > "1n rule" or "2n rule" operation: > > value = spd_read_byte(ctrl->channel0[i], 33); > /* Address and command hold time after clock */ > if(value < 0) continue; > if(value >= 0xa0) { /* At 133Mhz this > constant should be 0x75 */ > dword &= ~(1<<16); /* Use two clock cyles > instead of one */ > } > > The issues here are frequency and scale. > > The rest of the E7501 code assumes 133 MHz operation. So it > looks from the comments like the comparison to 0xa0 should > really be to 0x75. > > But the SPD value is in _tenths_ of nanoseconds. So the above > code translates to, "if the address/hold time is more than 1 > ns, use 2 clock cycles per command". But the clock period is > 10 ns for 100 MHz or 7.5 ns for 133 MHz, which is an order of > magnitude larger than the SPD values. > > I didn't see code for any other chipset that did something > like this, except the Intel 855pm - where it's #ifdef'd out. > I'm thinking this code should be removed. > > Steve > www.digidescorp.com > > > > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From rminnich at lanl.gov Tue Jun 14 20:51:04 2005 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Tue, 14 Jun 2005 12:51:04 -0600 (MDT) Subject: [LinuxBIOS] Re: E7501 SDRAM timing bug? In-Reply-To: <000f01c57107$16631870$6ffea8c0@banana> References: <000f01c57107$16631870$6ffea8c0@banana> Message-ID: can you comment that code, out, and add your comment to it. Sometimes a history is very helpful for people who come later and say "Why didn't they do this?" ron From YhLu at tyan.com Wed Jun 15 01:58:21 2005 From: YhLu at tyan.com (YhLu) Date: Tue, 14 Jun 2005 16:58:21 -0700 Subject: [BULK] RE: [LinuxBIOS] FYI: AMD support for cache as ram. Message-ID: <3174569B9743D511922F00A0C94314230A404188@TYANWEB> AMD cache_as_ram first stage done. current status 1. use gcc to produce auto.inc or init.o 2. it can reboot in fallback 3. it can reboot from fallback to normal 4. it can reboot in normal.... I'm using auto.c for romcc version cache_as_ram_auto.c for gcc and via auto.inc version cache_as_ram_auto.c for gcc and via init.o version next stage: 1. convert cache_as_ram_init.c version. 2. it will use the printk_debug to substitue print_debug 3. create compressed init.o version???? could spare 10k bytes.... YH From linuxbios at xdr.com Wed Jun 15 15:19:04 2005 From: linuxbios at xdr.com (Dave Ashley) Date: Wed, 15 Jun 2005 06:19:04 -0700 Subject: [LinuxBIOS] CN400 support Message-ID: <200506151319.j5FDJ4sI014852@xdr.com> VIA's released the EPIA-SP and they're in production, they've got the CN400 northbridge, VT8237 southbridge. Has anyone tried linuxbios on one of these? -Dave From bari at onelabs.com Wed Jun 15 18:28:05 2005 From: bari at onelabs.com (Bari Ari) Date: Wed, 15 Jun 2005 11:28:05 -0500 Subject: [LinuxBIOS] CN400 support In-Reply-To: <200506151319.j5FDJ4sI014852@xdr.com> References: <200506151319.j5FDJ4sI014852@xdr.com> Message-ID: <42B05715.6000200@onelabs.com> Dave Ashley wrote: > VIA's released the EPIA-SP and they're in production, they've got the > CN400 northbridge, VT8237 southbridge. Has anyone tried linuxbios on > one of these? CN400 & VT8237 support is in the works. FYI: http://www.epios.net/ A Linux disti. tweaked for the Epia's. They are also trying to have full driver support for all Epia features. -Bari From justin at street-vision.com Wed Jun 15 20:12:36 2005 From: justin at street-vision.com (Justin Cormack) Date: 15 Jun 2005 18:12:36 +0000 Subject: [LinuxBIOS] Solaris Message-ID: <1118859181.17017.12.camel@scrod> Has anyone looked at what it would take to get Solaris booting under Linuxbios on Opteron? If not I might dig around (there is a modified grub - I think that does some of the init work; one suspects that because of its heritage it is quite BIOS-unencumbered). justin From yinghailu at gmail.com Wed Jun 15 19:47:32 2005 From: yinghailu at gmail.com (yhlu) Date: Wed, 15 Jun 2005 10:47:32 -0700 Subject: [LinuxBIOS] Solaris In-Reply-To: <1118859181.17017.12.camel@scrod> References: <1118859181.17017.12.camel@scrod> Message-ID: <2ea3fae10506151047338d409b@mail.gmail.com> I guess LinuxBIOS+OpenBIOS could help. which solaris version? Is there special solaris version support Opteron in 64bit? YH On 15 Jun 2005 18:12:36 +0000, Justin Cormack wrote: > > > Has anyone looked at what it would take to get Solaris booting under > Linuxbios on Opteron? > > If not I might dig around (there is a modified grub - I think that does > some of the init work; one suspects that because of its heritage it is > quite BIOS-unencumbered). > > justin > > > > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From hansolofalcon at worldnet.att.net Wed Jun 15 20:15:32 2005 From: hansolofalcon at worldnet.att.net (Gregg C Levine) Date: Wed, 15 Jun 2005 14:15:32 -0400 Subject: [LinuxBIOS] Solaris In-Reply-To: <2ea3fae10506151047338d409b@mail.gmail.com> Message-ID: <000f01c571d6$3958fb40$6401a8c0@who7> Hello from Gregg C Levine Funny you should be asking that question. At an event the company called "Boot Camp", they displayed laptops running Opterons, and Solaris, via the AMD64 code. I have here several copies of X86, and SPARC Solaris products. Currently there is default support for AMD64 based systems including their own boxes. This is all via Solaris 10. ---- Gregg C Levine hansolofalcon at worldnet.att.net --- "The Force will be with you... Always." Obi-Wan Kenobi > -----Original Message----- > From: linuxbios-bounces at openbios.org [mailto:linuxbios-bounces at openbios.org] > On Behalf Of yhlu > Sent: Wednesday, June 15, 2005 1:48 PM > To: Justin Cormack > Cc: linuxbios at openbios.org > Subject: Re: [LinuxBIOS] Solaris > > I guess LinuxBIOS+OpenBIOS could help. > > which solaris version? > > Is there special solaris version support Opteron in 64bit? > > YH > > On 15 Jun 2005 18:12:36 +0000, Justin Cormack wrote: > > > > > > Has anyone looked at what it would take to get Solaris booting under > > Linuxbios on Opteron? > > > > If not I might dig around (there is a modified grub - I think that does > > some of the init work; one suspects that because of its heritage it is > > quite BIOS-unencumbered). > > > > justin > > > > > > > > > > _______________________________________________ > > LinuxBIOS mailing list > > LinuxBIOS at openbios.org > > http://www.openbios.org/mailman/listinfo/linuxbios > > > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios From hansolofalcon at worldnet.att.net Wed Jun 15 20:20:35 2005 From: hansolofalcon at worldnet.att.net (Gregg C Levine) Date: Wed, 15 Jun 2005 14:20:35 -0400 Subject: [LinuxBIOS] Errror messages for sending e-mail Message-ID: <001001c571d6$ecc990e0$6401a8c0@who7> Hello from Gregg C. Levine Justin regarding that posting you made earlier. I just tried sending you my response, regarding Solaris, and our work. Both were sent via the private e-mail method, and the list. The list worked. The private method failed, with a complaint. The complaint was: 'Justin Cormack' on 6/15/05 2:17 PM 450 [TEMPFAIL] destination not valid within DNS I suspect this is a temporary issue, but please e-mail me directly to confirm otherwise. ---- Gregg C Levine hansolofalcon at worldnet.att.net --- "The Force will be with you... Always." Obi-Wan Kenobi From YhLu at tyan.com Wed Jun 15 20:23:28 2005 From: YhLu at tyan.com (YhLu) Date: Wed, 15 Jun 2005 11:23:28 -0700 Subject: [LinuxBIOS] Solaris Message-ID: <3174569B9743D511922F00A0C94314230A40420B@TYANWEB> SUN visit us some time, but i'm not interested in that, so i didn't attend that meeting..... YH > -----Original Message----- > From: Gregg C Levine [mailto:hansolofalcon at worldnet.att.net] > Sent: Wednesday, June 15, 2005 11:16 AM > To: 'yhlu'; 'Justin Cormack' > Cc: linuxbios at openbios.org > Subject: RE: [LinuxBIOS] Solaris > > Hello from Gregg C Levine > Funny you should be asking that question. > At an event the company called "Boot Camp", they displayed > laptops running Opterons, and Solaris, via the AMD64 code. I > have here several copies of X86, and SPARC Solaris products. > Currently there is default support for AMD64 based systems > including their own boxes. This is all via Solaris 10. > ---- > Gregg C Levine hansolofalcon at worldnet.att.net > --- > "The Force will be with you... Always." Obi-Wan Kenobi > > > -----Original Message----- > > From: linuxbios-bounces at openbios.org > [mailto:linuxbios-bounces at openbios.org] > > On Behalf Of yhlu > > Sent: Wednesday, June 15, 2005 1:48 PM > > To: Justin Cormack > > Cc: linuxbios at openbios.org > > Subject: Re: [LinuxBIOS] Solaris > > > > I guess LinuxBIOS+OpenBIOS could help. > > > > which solaris version? > > > > Is there special solaris version support Opteron in 64bit? > > > > YH > > > > On 15 Jun 2005 18:12:36 +0000, Justin Cormack > wrote: > > > > > > > > > Has anyone looked at what it would take to get Solaris booting > under > > > Linuxbios on Opteron? > > > > > > If not I might dig around (there is a modified grub - I think that > does > > > some of the init work; one suspects that because of its heritage > it is > > > quite BIOS-unencumbered). > > > > > > justin > > > > > > > > > > > > > > > _______________________________________________ > > > LinuxBIOS mailing list > > > LinuxBIOS at openbios.org > > > http://www.openbios.org/mailman/listinfo/linuxbios > > > > > > > _______________________________________________ > > LinuxBIOS mailing list > > LinuxBIOS at openbios.org > > http://www.openbios.org/mailman/listinfo/linuxbios > > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From justin at street-vision.com Wed Jun 15 21:42:49 2005 From: justin at street-vision.com (Justin Cormack) Date: 15 Jun 2005 19:42:49 +0000 Subject: [LinuxBIOS] Solaris In-Reply-To: <2ea3fae10506151047338d409b@mail.gmail.com> References: <1118859181.17017.12.camel@scrod> <2ea3fae10506151047338d409b@mail.gmail.com> Message-ID: <1118864690.17017.25.camel@scrod> On Wed, 2005-06-15 at 17:47, yhlu wrote: > I guess LinuxBIOS+OpenBIOS could help. > > which solaris version? > > Is there special solaris version support Opteron in 64bit? www.opensolaris.com Its approximately the 10.1 release, with source code, full Opteron support in 64 bit... Looked at grub, the patches are only for ufs file system; havent looked much at the kernel init yet. Justin > YH > > On 15 Jun 2005 18:12:36 +0000, Justin Cormack wrote: > > > > > > Has anyone looked at what it would take to get Solaris booting under > > Linuxbios on Opteron? > > > > If not I might dig around (there is a modified grub - I think that does > > some of the init work; one suspects that because of its heritage it is > > quite BIOS-unencumbered). > > > > justin > > > > > > > > > > _______________________________________________ > > LinuxBIOS mailing list > > LinuxBIOS at openbios.org > > http://www.openbios.org/mailman/listinfo/linuxbios > > From gwatson at lanl.gov Wed Jun 15 20:43:04 2005 From: gwatson at lanl.gov (Greg Watson) Date: Wed, 15 Jun 2005 12:43:04 -0600 Subject: [LinuxBIOS] Solaris In-Reply-To: <000f01c571d6$3958fb40$6401a8c0@who7> References: <000f01c571d6$3958fb40$6401a8c0@who7> Message-ID: <2B98853E-1E93-412A-8BC4-DB9EBBE4969C@lanl.gov> FYI, Sun approached me a couple of years ago at USENIX about LinuxBIOS/OpenBIOS. I tried following up with them, but to no avail. Maybe now is the time... Greg On Jun 15, 2005, at 12:15 PM, Gregg C Levine wrote: > Hello from Gregg C Levine > Funny you should be asking that question. > At an event the company called "Boot Camp", they displayed laptops > running Opterons, and Solaris, via the AMD64 code. I have here several > copies of X86, and SPARC Solaris products. Currently there is default > support for AMD64 based systems including their own boxes. This is all > via Solaris 10. > ---- > Gregg C Levine hansolofalcon at worldnet.att.net > --- > "The Force will be with you... Always." Obi-Wan Kenobi > > >> -----Original Message----- >> From: linuxbios-bounces at openbios.org >> > [mailto:linuxbios-bounces at openbios.org] > >> On Behalf Of yhlu >> Sent: Wednesday, June 15, 2005 1:48 PM >> To: Justin Cormack >> Cc: linuxbios at openbios.org >> Subject: Re: [LinuxBIOS] Solaris >> >> I guess LinuxBIOS+OpenBIOS could help. >> >> which solaris version? >> >> Is there special solaris version support Opteron in 64bit? >> >> YH >> >> On 15 Jun 2005 18:12:36 +0000, Justin Cormack >> > wrote: > >>> >>> >>> Has anyone looked at what it would take to get Solaris booting >>> > under > >>> Linuxbios on Opteron? >>> >>> If not I might dig around (there is a modified grub - I think that >>> > does > >>> some of the init work; one suspects that because of its heritage >>> > it is > >>> quite BIOS-unencumbered). >>> >>> justin >>> >>> >>> >>> >>> _______________________________________________ >>> LinuxBIOS mailing list >>> LinuxBIOS at openbios.org >>> http://www.openbios.org/mailman/listinfo/linuxbios >>> >>> >> >> _______________________________________________ >> LinuxBIOS mailing list >> LinuxBIOS at openbios.org >> http://www.openbios.org/mailman/listinfo/linuxbios >> > > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From YhLu at tyan.com Thu Jun 16 00:20:23 2005 From: YhLu at tyan.com (YhLu) Date: Wed, 15 Jun 2005 15:20:23 -0700 Subject: [BULK] RE: [LinuxBIOS] FYI: AMD support for cache as ram. Message-ID: <3174569B9743D511922F00A0C94314230A404282@TYANWEB> make the cache_as_ram_auto for init.o to use printk now, #if CONFIG_USE_INIT printk_debug("linxbios_ram.bin length = %08x\r\n", olen); #else print_debug("linxbios_ram.bin length = "); print_debug_hex32(olen); print_debug("\r\n"); #endif there is some space for optimize code for the raminit and ht init in auto ...... The 8 way system get most benefit from the cache-as-ram solution. 1. with romcc, the compile time may need 5 minutes and can not enable vga support 2. win cache as ram and gcc, compile only need 23 seconds. ( the same as four way and two way), and vga support is already enabled. the system with multi CK804 as slaves can get some benefits too. YH > -----Original Message----- > From: YhLu > Sent: Tuesday, June 14, 2005 4:58 PM > To: Ronald G. Minnich; Eric W. Biederman; 'Stefan Reinauer'; Li-Ta Lo > Cc: LinuxBIOS > Subject: RE: [BULK] RE: [LinuxBIOS] FYI: AMD support for cache as ram. > > AMD cache_as_ram first stage done. > > current status > 1. use gcc to produce auto.inc or init.o 2. it can reboot in > fallback 3. it can reboot from fallback to normal 4. it can > reboot in normal.... > > I'm using auto.c for romcc version > cache_as_ram_auto.c for gcc and via auto.inc version > cache_as_ram_auto.c for gcc and via init.o version > > next stage: > 1. convert cache_as_ram_init.c version. > 2. it will use the printk_debug to substitue print_debug 3. > create compressed init.o version???? could spare 10k bytes.... > > YH > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From rminnich at lanl.gov Thu Jun 16 04:43:46 2005 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Wed, 15 Jun 2005 20:43:46 -0600 (MDT) Subject: [LinuxBIOS] Solaris In-Reply-To: <1118859181.17017.12.camel@scrod> References: <1118859181.17017.12.camel@scrod> Message-ID: On Wed, 15 Jun 2005, Justin Cormack wrote: > Has anyone looked at what it would take to get Solaris booting under > Linuxbios on Opteron? can you find out if they do BIOS calls? What kind of tables do they need from BIOS for memory and so on? ron From stepan at openbios.org Thu Jun 16 09:29:28 2005 From: stepan at openbios.org (Stefan Reinauer) Date: Thu, 16 Jun 2005 09:29:28 +0200 Subject: [LinuxBIOS] Solaris In-Reply-To: <1118859181.17017.12.camel@scrod> References: <1118859181.17017.12.camel@scrod> Message-ID: <20050616072928.GA12358@openbios.org> * Justin Cormack [050615 20:12]: > > > Has anyone looked at what it would take to get Solaris booting under > Linuxbios on Opteron? > > If not I might dig around (there is a modified grub - I think that does > some of the init work; one suspects that because of its heritage it is > quite BIOS-unencumbered). Solaris on x86/amd64 does not contain any open firmware support. So while using OpenBIOS to boot Solaris might be possible (if they don't do legacy bios calls), it won't benefit from OpenBIOS' IEEE1275 compliance. This might change with OpenSolaris though-- Stefan From justin at street-vision.com Thu Jun 16 13:25:36 2005 From: justin at street-vision.com (Justin Cormack) Date: Thu, 16 Jun 2005 12:25:36 +0100 Subject: [LinuxBIOS] Solaris In-Reply-To: <20050616072928.GA12358@openbios.org> References: <1118859181.17017.12.camel@scrod> <20050616072928.GA12358@openbios.org> Message-ID: <42B161B0.5070606@street-vision.com> Stefan Reinauer wrote: >* Justin Cormack [050615 20:12]: > > >>Has anyone looked at what it would take to get Solaris booting under >>Linuxbios on Opteron? >> >>If not I might dig around (there is a modified grub - I think that does >>some of the init work; one suspects that because of its heritage it is >>quite BIOS-unencumbered). >> >> > >Solaris on x86/amd64 does not contain any open firmware support. So >while using OpenBIOS to boot Solaris might be possible (if they don't >do legacy bios calls), it won't benefit from OpenBIOS' IEEE1275 >compliance. This might change with OpenSolaris though-- > > Stefan > > There are some odd BIOS based interfaces in the x86 code (though at some point it just builds a structure that looks like what comes out of the Sun PROMS). Probably easiest to just port the Open Firmware support from the Sparc part of the tree as its all there though. justin From YhLu at tyan.com Fri Jun 17 03:45:48 2005 From: YhLu at tyan.com (YhLu) Date: Thu, 16 Jun 2005 18:45:48 -0700 Subject: [LinuxBIOS] S2735 tree is totall broken Message-ID: <3174569B9743D511922F00A0C94314230A4043C6@TYANWEB> with romcc, also there is a werid reset, in raminit stage LinuxBIOS-1.1.8_s2735_Fallback Thu Jun 16 19:15:24 PDT 2005 starting... SMBus controller enabled Ram1.00 Ram2.00 Ram3 LinuxBIOS-1.1.8_s2735_Fallback Thu Jun 16 19:15:24 PDT 2005 starting... SMBus controller enabled Ram1.00 Ram2.00 Ram3 Ram4 PCI: 00:00.00 00: 86 80 4c 25 06 00 90 00 01 00 00 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 40: 09 00 05 11 00 00 00 00 00 00 00 00 00 00 00 00 50: 04 60 0d 00 00 00 00 00 00 30 33 33 33 33 33 33 60: 10 20 30 40 50 60 60 60 00 00 00 00 00 00 00 00 70: 44 44 44 00 00 00 00 00 1f 02 01 39 79 02 67 20 80: b1 0b 71 00 00 00 00 00 00 98 10 d2 88 00 00 00 90: 00 00 00 00 00 00 00 00 55 05 55 05 01 02 38 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 44 c0 50 11 00 c0 60 00 70 00 00 00 00 00 00 00 d0: 02 28 00 0e 03 00 00 33 80 09 31 b5 00 00 00 00 e0: 1c 1d 00 00 00 00 00 00 58 44 00 00 00 00 00 00 f0: 00 00 00 00 76 00 30 40 40 0f 00 00 00 00 00 00 Done. Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.1.8_s2735_Fallback Thu Jun 16 19:15:24 PDT 2005 booting... clocks_per_usec: 4538 Enumerating buses... PCI_DOMAIN: 0000 enabled APIC_CLUSTER: 0 enabled done Allocating resources... Reading resources... PCI_DOMAIN: 0000 missing read_resources APIC_CLUSTER: 0 missing read_resources PCI_DOMAIN: 0000 missing read_resources APIC_CLUSTER: 0 missing read_resources Done reading resources. Setting resources... PCI_DOMAIN: 0000 missing read_resources APIC_CLUSTER: 0 missing read_resources PCI_DOMAIN: 0000 missing read_resources APIC_CLUSTER: 0 missing read_resources Done setting resources. Done allocating resources. Enabling resourcess... PCI_DOMAIN: 0000 missing enable_resources APIC_CLUSTER: 0 missing enable_resources done. Initializing devices... Root Device init Devices initialized Copying IRQ routing tables to 0xf0000...done. Verifing copy of IRQ routing tables at 0xf0000...done Checking IRQ routing table consistency... Inconsistent IRQ routing table size (0xd0/0x110) check_pirq_routing_table() - irq_routing_table located at: 0x000f0000 /home/yhlu/xx/xx/freebios2/src/arch/i386/boot/pirq_routing.c: 36:check_pirq_routing_table() - checksum is: 0x91 but should be: 0a done. Wrote the mp table end at: 00000020 - 000001e4 Wrote linuxbios table at: 00000500 - 00000b9c checksum 56e5 Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.3 From hansolofalcon at worldnet.att.net Fri Jun 17 05:29:32 2005 From: hansolofalcon at worldnet.att.net (Gregg C Levine) Date: Thu, 16 Jun 2005 23:29:32 -0400 Subject: [LinuxBIOS] The actual location for Open Solaris has been announced Message-ID: <000001c572ec$c7c5bb40$6401a8c0@who7> Hello from Gregg C Levine I have news regarding Open Solaris. It now lives at http://opensolaris.org The one posted earlier is now probably closed. The announcement was dated the 14th. It came to my other e-mail ID, today. --- Gregg C Levine hansolofalcon at worldnet.att.net --- "The Force will be with you... Always." Obi-Wan Kenobi From YhLu at tyan.com Fri Jun 17 05:55:49 2005 From: YhLu at tyan.com (YhLu) Date: Thu, 16 Jun 2005 20:55:49 -0700 Subject: [LinuxBIOS] S2735 tree is totall broken Message-ID: <3174569B9743D511922F00A0C94314230A4043D1@TYANWEB> Eric, It hang somewhere before ending "reading resources", what could cause that? YH LinuxBIOS-1.1.8_s2735_Fallback Thu Jun 16 21:26:53 PDT 2005 starting... SMBus controller enabled Ram1.00 Ram2.00 Ram3 LinuxBIOS-1.1.8_s2735_Fallback Thu Jun 16 21:26:53 PDT 2005 starting... SMBus controller enabled Ram1.00 Ram2.00 Ram3 Ram4 PCI: 00:00.00 00: 86 80 4c 25 06 00 90 00 01 00 00 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 40: 09 00 05 11 00 00 00 00 00 00 00 00 00 00 00 00 50: 04 60 0d 00 00 00 00 00 00 30 33 33 33 33 33 33 60: 10 20 30 40 50 60 60 60 00 00 00 00 00 00 00 00 70: 44 44 44 00 00 00 00 00 1f 02 01 39 79 02 67 20 80: b1 0b 71 00 00 00 00 00 00 98 10 d2 88 00 00 00 90: 00 00 00 00 00 00 00 00 55 05 55 05 01 02 38 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 44 c0 50 11 00 c0 60 00 70 00 00 00 00 00 00 00 d0: 02 28 00 0e 03 00 00 33 80 09 31 b5 00 00 00 00 e0: 1c 1d 00 00 00 00 00 00 56 48 00 00 00 00 00 00 f0: 00 00 00 00 76 00 30 40 40 0f 00 00 00 00 00 00 Copying LinuxBIOS to ram. Jumping to LinuxBIOS. LinuxBIOS-1.1.8_s2735_Fallback Thu Jun 16 21:26:53 PDT 2005 booting... clocks_per_usec: 4538 Enumerating buses... PCI_DOMAIN: 0000 enabled APIC_CLUSTER: 0 enabled PCI: pci_scan_bus for bus 0 PCI: 00:00.0 [8086/254c] enabled PCI: 00:00.1 [8086/2541] enabled PCI: 00:02.0 [8086/2543] enabled PCI: 00:06.0 [8086/2549] enabled PCI: 00:1d.0 [8086/24d2] ops PCI: 00:1d.0 [8086/24d2] enabled PCI: 00:1d.1 [8086/24d4] ops PCI: 00:1d.1 [8086/24d4] enabled PCI: 00:1d.2 [8086/24d7] ops PCI: 00:1d.2 [8086/24d7] enabled PCI: 00:1d.3 [8086/24de] ops PCI: 00:1d.3 [8086/24de] enabled PCI: 00:1d.7 [8086/24dd] ops PCI: 00:1d.7 [8086/24dd] enabled PCI: 00:1e.0 [8086/244e] bus ops PCI: 00:1e.0 [8086/244e] enabled PCI: 00:1f.0 [8086/24d0] bus ops PCI: 00:1f.0 [8086/24d0] enabled PCI: 00:1f.2 [8086/24df] ops PCI: 00:1f.2 [8086/24df] enabled PCI: 00:1f.3 [8086/24d3] enabled PCI: pci_scan_bus for bus 1 PCI: 01:1c.0 [8086/1461] ops PCI: 01:1c.0 [8086/1461] enabled PCI: 01:1d.0 [8086/1460] bus ops PCI: 01:1d.0 [8086/1460] enabled PCI: 01:1e.0 [8086/1461] ops PCI: 01:1e.0 [8086/1461] enabled PCI: 01:1f.0 [8086/1460] bus ops PCI: 01:1f.0 [8086/1460] enabled PCI: pci_scan_bus for bus 2 PCI: 02:01.0 [8086/1010] enabled PCI: 02:01.1 [8086/1010] enabled PCI: pci_scan_bus returning with max=02 PCI: pci_scan_bus for bus 3 PCI: pci_scan_bus returning with max=03 PCI: pci_scan_bus returning with max=03 PCI: pci_scan_bus for bus 4 PCI: 04:01.0 [8086/1229] enabled PCI: 04:02.0 [1002/4752] enabled PCI: pci_scan_bus returning with max=04 PNP: 002e.0 enabled PNP: 002e.1 disabled PNP: 002e.2 enabled PNP: 002e.3 enabled PNP: 002e.5 enabled PNP: 002e.6 disabled PNP: 002e.7 disabled PNP: 002e.8 disabled PNP: 002e.9 disabled PNP: 002e.a disabled PNP: 002e.b enabled PCI: pci_scan_bus returning with max=04 done Allocating resources... Reading resources... PCI: 01:1d.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 2 prefmem PCI: 01:1f.0 1c <- [0x000000f000 - 0x000000efff] bus 3 io PCI: 01:1f.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 3 prefmem PCI: 01:1f.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 3 mem PCI: 00:02.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 1 prefmem PCI: 00:1e.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 4 prefmem From yinghailu at gmail.com Fri Jun 17 06:49:39 2005 From: yinghailu at gmail.com (yhlu) Date: Thu, 16 Jun 2005 21:49:39 -0700 Subject: [LinuxBIOS] cache as ram for x86 In-Reply-To: <3174569B9743D511922F00A0C94314230A404282@TYANWEB> References: <3174569B9743D511922F00A0C94314230A404282@TYANWEB> Message-ID: <2ea3fae10506162149283a49db@mail.gmail.com> Ron, It turns out that Cache as Ram can work in intel xeon too. The only difference is AMD need to set some bits in SYSCFG_MSR. So final cache as ram support for x86 will be cpu/x86/car/cache_as_ram.inc cpu/x86/car/cache_as_ram_post.c cpu/x86/car/copy_and_run.c there is special version for AMD cpu/amd/car/cache_as_ram.inc cpu/amd/car/cache_as_ram_post.c in MB dir cache_as_ram_auto.c it will include old failover.c and auto.c and corresponding cache_as_ram_post.c and copy_and_run.c the cache_as_ram_post.c will stop the cache as ram and switch to ram stack. copy_and_run will decode linuxbios_ram to memory, and jmp to it. USE_DCACHE_RAM ---> use romcc or gcc for auto.c... CONFIG_USE_INIT ----> use init or not. the code can coexist with romcc ..... If it is ok, I will check in cache as ram support for s2735 and s2885/s2891/s2895 tomorrow. Also I would help to verify that on other x86 platform. YH From huangjen.wang at gmail.com Fri Jun 17 09:29:24 2005 From: huangjen.wang at gmail.com (Huang-Jen Wang) Date: Fri, 17 Jun 2005 15:29:24 +0800 Subject: [LinuxBIOS] A question in auto.c Message-ID: <4325815c05061700297d9d0a45@mail.gmail.com> Dear all, One part of auto.c, I can't understand , hope you can tell me. In the "static unsigned int generate_row(uint8_t node, uint8_t row, uint8_t maxnodes)" function, how do I get the values of "static const unsigned int rows_4p[4][4]" array , I see an example : /* Link0 of CPU0 to Link0 of CPU1 */ /* Link1 of CPU0 to Link2 of CPU2 */ /* Link2 of CPU1 to Link1 of CPU3 */ /* Link0 of CPU2 to Link0 of CPU3 */ static const unsigned int rows_4p[4][4] = { { 0x00070101, 0x00010202, 0x00030404, 0x00010204 }, { 0x00010202, 0x000b0101, 0x00010208, 0x00030808 }, { 0x00030808, 0x00010208, 0x000b0101, 0x00010202 }, { 0x00010204, 0x00030404, 0x00010202, 0x00070101 } }; but I still can't understand why? From stepan at openbios.org Fri Jun 17 10:21:42 2005 From: stepan at openbios.org (Stefan Reinauer) Date: Fri, 17 Jun 2005 10:21:42 +0200 Subject: [LinuxBIOS] A question in auto.c In-Reply-To: <4325815c05061700297d9d0a45@mail.gmail.com> References: <4325815c05061700297d9d0a45@mail.gmail.com> Message-ID: <20050617082142.GA7338@openbios.org> * Huang-Jen Wang [050617 09:29]: > One part of auto.c, I can't understand , hope you can tell me. > In the "static unsigned int generate_row(uint8_t node, uint8_t row, > uint8_t maxnodes)" function, how do I get the values of "static const > unsigned int rows_4p[4][4]" array , I see an example : > > /* Link0 of CPU0 to Link0 of CPU1 */ > /* Link1 of CPU0 to Link2 of CPU2 */ > /* Link2 of CPU1 to Link1 of CPU3 */ > /* Link0 of CPU2 to Link0 of CPU3 */ > static const unsigned int rows_4p[4][4] = { > { 0x00070101, 0x00010202, 0x00030404, 0x00010204 }, > { 0x00010202, 0x000b0101, 0x00010208, 0x00030808 }, > { 0x00030808, 0x00010208, 0x000b0101, 0x00010202 }, > { 0x00010204, 0x00030404, 0x00010202, 0x00070101 } > }; > > but I still can't understand why? It is the hypertransport routing table, describing how hypertransport packets are routed from each CPU to each other CPU. See the AMD K8 BKDG for the register description of the routing table entries. BUT: This looks like an obsolete piece of code to me. Nowadays the routing table should be dynamically evaluated in coherent_ht.c Stefan From noodles at earth.li Fri Jun 17 18:42:17 2005 From: noodles at earth.li (Jonathan McDowell) Date: Fri, 17 Jun 2005 17:42:17 +0100 Subject: [LinuxBIOS] S2735 tree is totall broken In-Reply-To: <3174569B9743D511922F00A0C94314230A4043D1@TYANWEB> References: <3174569B9743D511922F00A0C94314230A4043D1@TYANWEB> Message-ID: <20050617164217.GB26687@earth.li> On Thu, Jun 16, 2005 at 08:55:49PM -0700, YhLu wrote: > It hang somewhere before ending "reading resources", > > what could cause that? > > Allocating resources... > Reading resources... > PCI: 01:1d.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 2 prefmem > PCI: 01:1f.0 1c <- [0x000000f000 - 0x000000efff] bus 3 io > PCI: 01:1f.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 3 prefmem > PCI: 01:1f.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 3 mem > PCI: 00:02.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 1 prefmem > PCI: 00:1e.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 4 prefmem I've seen this with the EPIA-M work (which is still ongoing; Adam's been testing bits and I've been trying to understand the chip and waiting impatiently for my programmer to turn up). We solved it by changing pci_moving_config32. The current in-tree version reads the value, sets the reg to all 1s, reads the value, sets the reg to all 0s, reads the value, restores the regs to the original value and works out the mask by XORing the bits. However from my reading of the PCI spec (v2.2) it just says to set the BAR to all 1s, read the value and work out the bits at the bottom you can ignore from whether it's an IO or MEM resource. I don't know if the writing all 0s is the problem or not though; presumably it works everywhere else or the tree wouldn't currently do that. J. -- I am Pentium of Borg. Division is Futile. You will be approximated. This .sig brought to you by the letter F and the number 30 Product of the Republic of HuggieTag From steve at digidescorp.com Sat Jun 18 04:45:51 2005 From: steve at digidescorp.com (Steve Magnani) Date: Fri, 17 Jun 2005 21:45:51 -0500 Subject: [LinuxBIOS] ROMCC bug Message-ID: I've stumbled across a ROMCC bug that results in incorrect code being generated. As near as I can tell, multi-layer "if" statements are at risk of being miscompiled when optimization is enabled. The following program snippet induces the bug when compiled via "romcc -mcpu=p4 -O2" (or -O): /************************************************/ void die(void) { } static void miscompiled_function(unsigned short param) { unsigned int data = __builtin_inl(0); if (data == 0) param = 12; else if (data == 4) param = 42; else die(); __builtin_outl(param, 0); } static void internal_compiler_error(unsigned short param) { unsigned int data = __builtin_inl(0); if (data == 0) param = 12; if (data == 4) param = 42; if ((data != 0) && (data != 4)) die(); __builtin_outl(param, 0); } void main(void) { miscompiled_function(0); // internal_compiler_error(0); } /************************************************/ The assembly output for the miscompiled function is such that when data == 4, param is set to zero, instead of 42. The function 'internal_compiler_error' is logically equivalent to 'miscompiled_function', but attempting to call it results in the following message: bug.c:20.1: bug.c:36.32: warning: edge: bug.c:20.1: bug.c:36.32: warning: 0x9e53b08 copy :0.0: warning: 0x9e542d8 convert :1.0: bug.c:21.42: bug.c:36.32: warning: def: :1.0: bug.c:21.42: bug.c:36.32: warning: 0x9e53ea8 __inl :1.0: bug.c:21.42: bug.c:36.32: 0x9e53ea8 __inl Internal compiler error: live range with already used color %eax Aborted ----------------------------- Steve Magnani www.digidescorp.com From steve at digidescorp.com Sat Jun 18 05:21:37 2005 From: steve at digidescorp.com (Steve Magnani) Date: Fri, 17 Jun 2005 22:21:37 -0500 Subject: [LinuxBIOS] Re: ROMCC bug In-Reply-To: References: Message-ID: This logically-equivalent function appears to compile correctly. static void proper_function(unsigned short param) { unsigned int data = __builtin_inl(0); switch (data) { case 0: param = 12; break; case 4: param = 42; break; default: die(); break; } __builtin_outl(param, 0); } From yinghailu at gmail.com Sat Jun 18 05:53:31 2005 From: yinghailu at gmail.com (yhlu) Date: Fri, 17 Jun 2005 20:53:31 -0700 Subject: [LinuxBIOS] Re: ROMCC bug In-Reply-To: References: Message-ID: <2ea3fae105061720536b79a2d6@mail.gmail.com> So we must make cache_as_ram work on other 86 platform besides amd cpu... Is there any intel public doc about using cache_as_ram? I have tried amd cache_as_ram in intel platform, it seem if access some position several times, the contents of that address will become to 0xff.... YH On 6/17/05, Steve Magnani wrote: > This logically-equivalent function appears to compile correctly. > > > static void proper_function(unsigned short param) > { > unsigned int data = __builtin_inl(0); > > switch (data) > { > case 0: > param = 12; > break; > > case 4: > param = 42; > break; > > default: > die(); > break; > } > > __builtin_outl(param, 0); > } > > > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From huangjen.wang at gmail.com Sat Jun 18 11:01:42 2005 From: huangjen.wang at gmail.com (Huang-Jen Wang) Date: Sat, 18 Jun 2005 17:01:42 +0800 Subject: [LinuxBIOS] A question in auto.c In-Reply-To: <20050617082142.GA7338@openbios.org> References: <4325815c05061700297d9d0a45@mail.gmail.com> <20050617082142.GA7338@openbios.org> Message-ID: <4325815c05061802016ea9afb1@mail.gmail.com> Stefan, So the values of the array depend on the links of cpu to cpu? If I got an example : Link0 of CPU0 to Link1 of CPU1 Link1 of CPU0 to Link0 of CPU3 Link0 of CPU1 to Link0 of CPU2 Link2 of CPU2 to Link1 of CPU3 (L2) (L1) CPU2-------------CPU3 (L0) | | (L0) | | | | | | | | (L0)| | (L1) CPU1-------------CPU0------ (L1) (L0) what are the values of the array?I hope I can realize from some examples... BTW, I search the keyword "AMD K8 BKDG(or AMD K8 BGDG)" in google, it has a little information, could you tell where can get more infromations? Thanks.... HJ Wang On 6/17/05, Stefan Reinauer wrote: > * Huang-Jen Wang [050617 09:29]: > > One part of auto.c, I can't understand , hope you can tell me. > > In the "static unsigned int generate_row(uint8_t node, uint8_t row, > > uint8_t maxnodes)" function, how do I get the values of "static const > > unsigned int rows_4p[4][4]" array , I see an example : > > > > /* Link0 of CPU0 to Link0 of CPU1 */ > > /* Link1 of CPU0 to Link2 of CPU2 */ > > /* Link2 of CPU1 to Link1 of CPU3 */ > > /* Link0 of CPU2 to Link0 of CPU3 */ > > static const unsigned int rows_4p[4][4] = { > > { 0x00070101, 0x00010202, 0x00030404, 0x00010204 }, > > { 0x00010202, 0x000b0101, 0x00010208, 0x00030808 }, > > { 0x00030808, 0x00010208, 0x000b0101, 0x00010202 }, > > { 0x00010204, 0x00030404, 0x00010202, 0x00070101 } > > }; > > > > but I still can't understand why? > > It is the hypertransport routing table, describing how hypertransport > packets are routed from each CPU to each other CPU. See the AMD K8 BKDG > for the register description of the routing table entries. > > BUT: This looks like an obsolete piece of code to me. Nowadays the > routing table should be dynamically evaluated in coherent_ht.c > > Stefan > > From ajacoutot at lphp.org Sat Jun 18 11:13:07 2005 From: ajacoutot at lphp.org (Antoine Jacoutot) Date: Sat, 18 Jun 2005 11:13:07 +0200 Subject: [LinuxBIOS] cv860a motherboard Message-ID: <42B3E5A3.9000906@lphp.org> Hello :) I was wondering if I could change the Award BIOS from my lex motherboard with LinuxBIOS. Indeed, I would like to have a real BIOS redirection to serial console which is, as far as I know, impossible to do with the original BIOS. Here are the motherboard details (via c3): http://web.lex.com.tw:7777/cv860a.htm Thanks :) Regards, Antoine From stepan at openbios.org Sat Jun 18 12:10:09 2005 From: stepan at openbios.org (Stefan Reinauer) Date: Sat, 18 Jun 2005 12:10:09 +0200 Subject: [LinuxBIOS] Re: ROMCC bug In-Reply-To: <2ea3fae105061720536b79a2d6@mail.gmail.com> References: <2ea3fae105061720536b79a2d6@mail.gmail.com> Message-ID: <20050618101009.GA12172@openbios.org> * yhlu [050618 05:53]: > So we must make cache_as_ram work on other 86 platform besides amd cpu... > > I have tried amd cache_as_ram in intel platform, it seem if access > some position several times, the contents of that address will become > to 0xff.... AFAICR, Intel has not been as thorough with their design wrt cache as ram. LinuxBIOS v1 has some mainboards doing CAR, but it was hard to maintain because the Xeons changed their behaviour with every stepping.. This might very well have improved by now, hard to say, as Intel specs are hard to get. Stefan From stepan at openbios.org Sat Jun 18 12:22:28 2005 From: stepan at openbios.org (Stefan Reinauer) Date: Sat, 18 Jun 2005 12:22:28 +0200 Subject: [LinuxBIOS] A question in auto.c In-Reply-To: <4325815c05061802016ea9afb1@mail.gmail.com> References: <4325815c05061700297d9d0a45@mail.gmail.com> <20050617082142.GA7338@openbios.org> <4325815c05061802016ea9afb1@mail.gmail.com> Message-ID: <20050618102228.GA12313@openbios.org> * Huang-Jen Wang [050618 11:01]: > Stefan, > So the values of the array depend on the links of cpu to cpu? yes, indeed. > If I got an example : > Link0 of CPU0 to Link1 of CPU1 > Link1 of CPU0 to Link0 of CPU3 > Link0 of CPU1 to Link0 of CPU2 > Link2 of CPU2 to Link1 of CPU3 > > what are the values of the array? I hope I can realize from some examples... http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/26094.PDF Check chapter 3.3.6: "Routing Table Node i Registers" But note: since the topology is nowadays detected automatically, you don't need to care anyways... > BTW, I search the keyword "AMD K8 BKDG(or AMD K8 BGDG)" in google, > it has a little information, could you tell where can get more infromations? > Thanks.... Sorry,.. I was starting to use LinuxBIOS slang. The full name is "BIOS and Kernel Developer's Guide for AMD Athlon(tm)64 and AMD Opteron(tm) Processors".. BKDG is just so much quicker to write ;)) Regards, Stefan From yinghailu at gmail.com Sat Jun 18 16:38:07 2005 From: yinghailu at gmail.com (yhlu) Date: Sat, 18 Jun 2005 07:38:07 -0700 Subject: [LinuxBIOS] A question in auto.c In-Reply-To: <20050618102228.GA12313@openbios.org> References: <4325815c05061700297d9d0a45@mail.gmail.com> <20050617082142.GA7338@openbios.org> <4325815c05061802016ea9afb1@mail.gmail.com> <20050618102228.GA12313@openbios.org> Message-ID: <2ea3fae105061807389d9d8b1@mail.gmail.com> next to do bout ht related is make linuxbios support 1. more generic ht host bridge 2. ht-ht bridge 3. ht linked coprocessor.... YH On 6/18/05, Stefan Reinauer wrote: > * Huang-Jen Wang [050618 11:01]: > > Stefan, > > So the values of the array depend on the links of cpu to cpu? > > yes, indeed. > > > If I got an example : > > Link0 of CPU0 to Link1 of CPU1 > > Link1 of CPU0 to Link0 of CPU3 > > Link0 of CPU1 to Link0 of CPU2 > > Link2 of CPU2 to Link1 of CPU3 > > > > what are the values of the array? I hope I can realize from some examples... > > http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/26094.PDF > > Check chapter 3.3.6: "Routing Table Node i Registers" > > But note: since the topology is nowadays detected automatically, you > don't need to care anyways... > > > BTW, I search the keyword "AMD K8 BKDG(or AMD K8 BGDG)" in google, > > it has a little information, could you tell where can get more infromations? > > Thanks.... > > Sorry,.. I was starting to use LinuxBIOS slang. The full name is "BIOS > and Kernel Developer's Guide for AMD Athlon(tm)64 and AMD Opteron(tm) > Processors".. BKDG is just so much quicker to write ;)) > > Regards, > Stefan > > > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From huangjen.wang at gmail.com Sun Jun 19 11:56:18 2005 From: huangjen.wang at gmail.com (Huang-Jen Wang) Date: Sun, 19 Jun 2005 17:56:18 +0800 Subject: [LinuxBIOS] Mainboard Config.lb file Message-ID: <4325815c0506190256399f8c74@mail.gmail.com> Dear all, Is there a utiltiy to help generate a new mainboard config.lb file or a document described how to write mainboard config.lb file.... thanks HJ Wang From stepan at openbios.org Sun Jun 19 12:37:59 2005 From: stepan at openbios.org (Stefan Reinauer) Date: Sun, 19 Jun 2005 12:37:59 +0200 Subject: [LinuxBIOS] Mainboard Config.lb file In-Reply-To: <4325815c0506190256399f8c74@mail.gmail.com> References: <4325815c0506190256399f8c74@mail.gmail.com> Message-ID: <20050619103759.GA25914@openbios.org> * Huang-Jen Wang [050619 11:56]: > Dear all, > Is there a utiltiy to help generate a new mainboard config.lb file or a > document described how to write mainboard config.lb file.... > thanks Have a look at http://www.openbios.org/LinuxBIOS-AMD64.pdf It's getting a bit out of date, so any hints and problem reports are welcome. Stefan From linuxbios at xdr.com Sun Jun 19 16:45:21 2005 From: linuxbios at xdr.com (Dave Ashley) Date: Sun, 19 Jun 2005 07:45:21 -0700 Subject: [LinuxBIOS] CN400 support Message-ID: <200506191445.j5JEjLEB004912@xdr.com> >cn400 & vt8237 support is in the works. Is there anything I can do to assist? For example I can supply one or more EPIA-SP 800 mhz boards, we have some of them. Possibly I can make funds available to get developers to focus on the problem. At the very least I can test + offer feedback. I'm trying to come up with alternatives to diving in and doing it myself :^). -Dave From a.borisov at tesv.tmb.ru Mon Jun 20 06:38:30 2005 From: a.borisov at tesv.tmb.ru (Anton Borisov) Date: Mon, 20 Jun 2005 08:38:30 +0400 Subject: [LinuxBIOS] EPIA-M Code Message-ID: <20050620083830.5c9801f4.a.borisov@tesv.tmb.ru> Hello. I've played with EPIA-M tree recently. Interesting facts: 1) I'm always turning to "fallback" image. How LB decides which image to load? I guess this is done with CMOS entry (which one?), but I want boot VIA's AwardBIOS as well as LB (by switching Flash Chips in BIOS Savior). 2) I included file minicom.capped1.bz2. It's a minicom's output. I bet jmp_to_elf_entry() do the wrong staff (src/arch/i386/boot/boot.c) thus not loading payload at all. 3) Moreover. Looking at minicom.capped2.bz2. I've changed jmp_to_elf_entry() a little (put the code from PPC part). Ok, loading FILO now works. But reverting to "Normal" image. And finally, "SMBUS controller not found" because of wrong DEV (DEV = 0xFF). P.S. Booting in cold restart loading "Normal" image. "Normal" image don't boot - it stops at enable_smbus(). Any clues? -- Sincerely, Anton Borisov From a.borisov at tesv.tmb.ru Mon Jun 20 06:43:49 2005 From: a.borisov at tesv.tmb.ru (Anton Borisov) Date: Mon, 20 Jun 2005 08:43:49 +0400 Subject: [LinuxBIOS] EPIA-M Code (bz2) Message-ID: <20050620084349.0fb77f74.a.borisov@tesv.tmb.ru> My apologies. Didn't attach anything :) -- Sincerely, Anton Borisov -------------- next part -------------- A non-text attachment was scrubbed... Name: minicom.capped1.bz2 Type: application/octet-stream Size: 3962 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: minicom.capped2.bz2 Type: application/octet-stream Size: 4370 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: minicom.capped3.bz2 Type: application/octet-stream Size: 4431 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: minicom.capped4_.bz2 Type: application/octet-stream Size: 4218 bytes Desc: not available URL: From a.borisov at tesv.tmb.ru Mon Jun 20 07:01:33 2005 From: a.borisov at tesv.tmb.ru (Anton Borisov) Date: Mon, 20 Jun 2005 09:01:33 +0400 Subject: [LinuxBIOS] VIA's KT400 + VT82C8231 Message-ID: <20050620090133.0ee4f2d1.a.borisov@tesv.tmb.ru> Hello. ASUS A7V8X-X carries northbridge KT400 and southbridge VT82C8231. FlashChip is PMC. flash_and_rom enables writes to flash and freezes system. Any workarounds? -- Sincerely, Anton Borisov From huangjen.wang at gmail.com Mon Jun 20 13:20:44 2005 From: huangjen.wang at gmail.com (Huang-Jen Wang) Date: Mon, 20 Jun 2005 19:20:44 +0800 Subject: [LinuxBIOS] How to study the source code...? Message-ID: <4325815c0506200420416fecd3@mail.gmail.com> Dear all, Recently I am studying the source code , because I want to try to porting new mainboard later, but it is not easy to realize source code I begin my study from the src/southbridge/amd8111/amd8111.c There are some lines that I can't understand even I have amd8111 datasheet....hope you can tell me 1.devfn = bus_dev->path.u.pci.devfn + (1 << 3); 2.index = ((dev->path.u.pci.devfn & ~7) >> 3) + 8; 3.devfn = (dev->path.u.pci.devfn) & ~7; Thanks advanced... HJ Wang From noodles at earth.li Mon Jun 20 13:32:33 2005 From: noodles at earth.li (Jonathan McDowell) Date: Mon, 20 Jun 2005 12:32:33 +0100 Subject: [LinuxBIOS] EPIA-M Code In-Reply-To: <20050620083830.5c9801f4.a.borisov@tesv.tmb.ru> References: <20050620083830.5c9801f4.a.borisov@tesv.tmb.ru> Message-ID: <20050620113233.GV26687@earth.li> On Mon, Jun 20, 2005 at 08:38:30AM +0400, Anton Borisov wrote: > I've played with EPIA-M tree recently. Interesting facts: Which tree is this? From your output it looks a little like mine? > 1) I'm always turning to "fallback" image. How LB decides which image > to load? I guess this is done with CMOS entry (which one?), but I want > boot VIA's AwardBIOS as well as LB (by switching Flash Chips in BIOS > Savior). > 2) I included file minicom.capped1.bz2. It's a minicom's output. I bet > jmp_to_elf_entry() do the wrong staff (src/arch/i386/boot/boot.c) thus > not loading payload at all. > 3) Moreover. Looking at minicom.capped2.bz2. I've changed > jmp_to_elf_entry() a little (put the code from PPC part). Ok, loading > FILO now works. But reverting to "Normal" image. And finally, "SMBUS > controller not found" because of wrong DEV (DEV = 0xFF). What changes did you make for jmp_to_elf_entry? How much memory is on your board? I think the RAM detection stuff is wrong and that's possibly causing FILO problems; from your minicom.capped2.bz2: I would set ram size to 0x3fc000 Kbytes and then later, in FILO: collect_sys_info: RAM 4032 MB > P.S. Booting in cold restart loading "Normal" image. "Normal" image > don't boot - it stops at enable_smbus(). Adam Talbot and I have been looking at this; it doesn't seem to be a specific piece of code that's crashing, as we've seen it hang at various points around the initialisation code. My current guess is that some interrupt that we're not handling yet is occurring, or that we need to do some further chipset initialisation before trying to enable the SMBUS. I've got a list of chipset registers the Award BIOS seems to twiddle, so I might add those to the enable_mainboard function to see if that at least gets us further. J. -- Thesaurus: ancient reptile with an excellent vocabulary From a.borisov at tesv.tmb.ru Mon Jun 20 13:44:39 2005 From: a.borisov at tesv.tmb.ru (Anton Borisov) Date: Mon, 20 Jun 2005 15:44:39 +0400 Subject: [LinuxBIOS] EPIA-M Code In-Reply-To: <20050620113233.GV26687@earth.li> References: <20050620083830.5c9801f4.a.borisov@tesv.tmb.ru> <20050620113233.GV26687@earth.li> Message-ID: <20050620154439.69b1c1f6.a.borisov@tesv.tmb.ru> On Mon, 20 Jun 2005 12:32:33 +0100 Jonathan McDowell wrote: > On Mon, Jun 20, 2005 at 08:38:30AM +0400, Anton Borisov wrote: > > > I've played with EPIA-M tree recently. Interesting facts: > > Which tree is this? From your output it looks a little like mine? Exactly. > What changes did you make for jmp_to_elf_entry? void jmp_to_elf_entry(void *entry, unsigned long buffer) { void (*kernel_entry)(void); kernel_entry = entry; kernel_entry(); } Code is from PPC part. I removed flush_dcache(); > > How much memory is on your board? I think the RAM detection stuff is 256 MB of RAM. > wrong and that's possibly causing FILO problems; from your > minicom.capped2.bz2: > > I would set ram size to 0x3fc000 Kbytes Should I learn about a new option inside Config.filo.lb? > > and then later, in FILO: > > collect_sys_info: RAM 4032 MB > > > P.S. Booting in cold restart loading "Normal" image. "Normal" image > > don't boot - it stops at enable_smbus(). > > Adam Talbot and I have been looking at this; it doesn't seem to be a > specific piece of code that's crashing, as we've seen it hang at various > points around the initialisation code. My current guess is that some > interrupt that we're not handling yet is occurring, or that we need to > do some further chipset initialisation before trying to enable the > SMBUS. > > I've got a list of chipset registers the Award BIOS seems to twiddle, so > I might add those to the enable_mainboard function to see if that at > least gets us further. Well, this could help. Can you attach it? I don't remember but it seems to me I've seen somewhere the CMOS map according to each LB decides which image to load "Normal" or "Fallback". Am I right? -- Sincerely, Anton Borisov From ollie at lanl.gov Mon Jun 20 16:43:12 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Mon, 20 Jun 2005 08:43:12 -0600 Subject: [LinuxBIOS] How to study the source code...? In-Reply-To: <4325815c0506200420416fecd3@mail.gmail.com> References: <4325815c0506200420416fecd3@mail.gmail.com> Message-ID: <1119278592.13364.14.camel@logarithm.lanl.gov> On Mon, 2005-06-20 at 19:20 +0800, Huang-Jen Wang wrote: > Dear all, > Recently I am studying the source code , because I want to try to > porting new mainboard later, but it is not easy to realize source code > I begin my study from the src/southbridge/amd8111/amd8111.c > There are some lines that I can't understand even I have amd8111 > datasheet....hope you can tell me > > 1.devfn = bus_dev->path.u.pci.devfn + (1 << 3); > 2.index = ((dev->path.u.pci.devfn & ~7) >> 3) + 8; > 3.devfn = (dev->path.u.pci.devfn) & ~7; > You choose the worst file in the whole tree to start. You are not supposed understand it unless you are Eric Biederman ;-) The reason that file is so complicated is because the LPC bridge inside amd8111 controls the enable and disable of devices on both side of the PCI bridge (in amd8111). The function in amd8111.c is call with every devices in the 8111 chip as argument. The function has to figure out which device it is given and how to enable or disable the device. This is done by device_t to devfn magic you see. -- Li-Ta Lo Los Alamos National Lab From noodles at earth.li Mon Jun 20 19:18:32 2005 From: noodles at earth.li (Jonathan McDowell) Date: Mon, 20 Jun 2005 18:18:32 +0100 Subject: [LinuxBIOS] EPIA-M Code In-Reply-To: <20050620154439.69b1c1f6.a.borisov@tesv.tmb.ru> References: <20050620083830.5c9801f4.a.borisov@tesv.tmb.ru> <20050620113233.GV26687@earth.li> <20050620154439.69b1c1f6.a.borisov@tesv.tmb.ru> Message-ID: <20050620171832.GE26687@earth.li> On Mon, Jun 20, 2005 at 03:44:39PM +0400, Anton Borisov wrote: > On Mon, 20 Jun 2005 12:32:33 +0100 > Jonathan McDowell wrote: > > How much memory is on your board? I think the RAM detection stuff is > > 256 MB of RAM. > > > wrong and that's possibly causing FILO problems; from your > > minicom.capped2.bz2: > > > > I would set ram size to 0x3fc000 Kbytes > > Should I learn about a new option inside Config.filo.lb? No, that's in your log output; from line 223 in vt8623/northbridge.c > > I've got a list of chipset registers the Award BIOS seems to twiddle, so > > I might add those to the enable_mainboard function to see if that at > > least gets us further. > > Well, this could help. Can you attach it? I've attached a modified src/mainboard/via/epia-m/auto.c which sets all the chipset registers from the Award table I extracted. I don't know if it'll help or not though. >I don't remember but it seems to me I've seen somewhere the CMOS map >according to each LB decides which image to load "Normal" or >"Fallback". Am I right? I /think/ so; see do_normal_boot in src/pc80/mc146818rtc_early.c J. -- /-\ | 101 things you can't have too much |@/ Debian GNU/Linux Developer | of : 39 - silver bullets. \- | -------------- next part -------------- A non-text attachment was scrubbed... Name: auto.c Type: text/x-csrc Size: 6095 bytes Desc: not available URL: From ebiederman at lnxi.com Tue Jun 21 00:19:22 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon, 20 Jun 2005 16:19:22 -0600 Subject: [BULK] [LinuxBIOS] ROMCC bug In-Reply-To: (Steve Magnani's message of "Fri, 17 Jun 2005 21:45:51 -0500") References: Message-ID: "Steve Magnani" writes: > I've stumbled across a ROMCC bug that results in incorrect code being > generated. As near as I can tell, multi-layer "if" statements are at risk > of being miscompiled when optimization is enabled. The following program > snippet induces the bug when compiled via "romcc -mcpu=p4 -O2" (or -O): Thanks. I will take a look. This looks similar to another bug I am tracking as well. For that bug by specifying -fno-simplify-phi I was able to avoid the problem. For that bug I got as far a deciding that there was an interaction bug between several optimizations that appear correctly in and of themselves. I will take a look at what you have given me, as it looks like a nice test case, and see what I can find. I suggest you play with disabling individual optimizations so you can at least move forward until this bug is fixed. Eric From ebiederman at lnxi.com Tue Jun 21 00:28:43 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon, 20 Jun 2005 16:28:43 -0600 Subject: [BULK] Re: [LinuxBIOS] Re: ROMCC bug In-Reply-To: <2ea3fae105061720536b79a2d6@mail.gmail.com> (yinghailu@gmail.com's message of "Fri, 17 Jun 2005 20:53:31 -0700") References: <2ea3fae105061720536b79a2d6@mail.gmail.com> Message-ID: yhlu writes: > So we must make cache_as_ram work on other 86 platform besides amd cpu... It is a good idea and for new cpus it is probably an option. For people in the embedded space we still need romcc. > Is there any intel public doc about using cache_as_ram? I have not seen any yet which is a puzzle. For the first round of Intel cpus that supported it you had to load a microcode update, before it would work. I have yet to see if AMD's flavor will work on k8 revisions B3, C0, CG, Ex. I expect it will but I have been burnt too many times. > I have tried amd cache_as_ram in intel platform, it seem if access > some position several times, the contents of that address will become > to 0xff.... Exactly the problem. If you aren't using a supported flavor of cache as ram it fails more often and in less predictable ways than romcc. That is why I avoid it unless the manufacturer supports it. And that is why we cannot decompress and run code out of the cache. Eric From ebiederman at lnxi.com Tue Jun 21 00:31:13 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon, 20 Jun 2005 16:31:13 -0600 Subject: [BULK] Re: [LinuxBIOS] How to study the source code...? In-Reply-To: <1119278592.13364.14.camel@logarithm.lanl.gov> (Li-Ta Lo's message of "Mon, 20 Jun 2005 08:43:12 -0600") References: <4325815c0506200420416fecd3@mail.gmail.com> <1119278592.13364.14.camel@logarithm.lanl.gov> Message-ID: Li-Ta Lo writes: > On Mon, 2005-06-20 at 19:20 +0800, Huang-Jen Wang wrote: >> Dear all, >> Recently I am studying the source code , because I want to try to >> porting new mainboard later, but it is not easy to realize source code >> I begin my study from the src/southbridge/amd8111/amd8111.c >> There are some lines that I can't understand even I have amd8111 >> datasheet....hope you can tell me >> >> 1.devfn = bus_dev->path.u.pci.devfn + (1 << 3); >> 2.index = ((dev->path.u.pci.devfn & ~7) >> 3) + 8; >> 3.devfn = (dev->path.u.pci.devfn) & ~7; >> > > You choose the worst file in the whole tree to start. You are not > supposed understand it unless you are Eric Biederman ;-) Hmm. It must need a good comment then :( But I agree that is pretty abstract way to start. You certainly need to understand how pci encodes bus/device/function information and how LinuxBIOS deals with it to make sense of those lines. > The reason that file is so complicated is because the LPC bridge inside > amd8111 controls the enable and disable of devices on both side of the > PCI bridge (in amd8111). The function in amd8111.c is call with every > devices in the 8111 chip as argument. The function has to figure out > which device it is given and how to enable or disable the device. > This is done by device_t to devfn magic you see. Eric From yinghailu at gmail.com Tue Jun 21 01:23:20 2005 From: yinghailu at gmail.com (yhlu) Date: Mon, 20 Jun 2005 16:23:20 -0700 Subject: [BULK] Re: [LinuxBIOS] Re: ROMCC bug In-Reply-To: References: <2ea3fae105061720536b79a2d6@mail.gmail.com> Message-ID: <2ea3fae105062016235e71481c@mail.gmail.com> AMD i have tried c0 and Ex. On 6/20/05, Eric W. Biederman wrote: > yhlu writes: > > > So we must make cache_as_ram work on other 86 platform besides amd cpu... > > It is a good idea and for new cpus it is probably an option. > For people in the embedded space we still need romcc. > > > Is there any intel public doc about using cache_as_ram? > > I have not seen any yet which is a puzzle. For the first round > of Intel cpus that supported it you had to load a microcode update, > before it would work. I have yet to see if AMD's flavor will work > on k8 revisions B3, C0, CG, Ex. I expect it will but I have been > burnt too many times. > > > I have tried amd cache_as_ram in intel platform, it seem if access > > some position several times, the contents of that address will become > > to 0xff.... > > Exactly the problem. If you aren't using a supported flavor of cache > as ram it fails more often and in less predictable ways than romcc. > That is why I avoid it unless the manufacturer supports it. And that > is why we cannot decompress and run code out of the cache. > > Eric > From yinghailu at gmail.com Tue Jun 21 01:25:24 2005 From: yinghailu at gmail.com (yhlu) Date: Mon, 20 Jun 2005 16:25:24 -0700 Subject: [BULK] Re: [LinuxBIOS] How to study the source code...? In-Reply-To: References: <4325815c0506200420416fecd3@mail.gmail.com> <1119278592.13364.14.camel@logarithm.lanl.gov> Message-ID: <2ea3fae10506201625357091be@mail.gmail.com> that code is good. Also the AMD numbering device enable bit is good and professional. other SB that enble bit have nothing to do with device id or function... YH On 6/20/05, Eric W. Biederman wrote: > Li-Ta Lo writes: > > > On Mon, 2005-06-20 at 19:20 +0800, Huang-Jen Wang wrote: > >> Dear all, > >> Recently I am studying the source code , because I want to try to > >> porting new mainboard later, but it is not easy to realize source code > >> I begin my study from the src/southbridge/amd8111/amd8111.c > >> There are some lines that I can't understand even I have amd8111 > >> datasheet....hope you can tell me > >> > >> 1.devfn = bus_dev->path.u.pci.devfn + (1 << 3); > >> 2.index = ((dev->path.u.pci.devfn & ~7) >> 3) + 8; > >> 3.devfn = (dev->path.u.pci.devfn) & ~7; > >> > > > > You choose the worst file in the whole tree to start. You are not > > supposed understand it unless you are Eric Biederman ;-) > > Hmm. It must need a good comment then :( > But I agree that is pretty abstract way to start. > > You certainly need to understand how pci encodes bus/device/function information > and how LinuxBIOS deals with it to make sense of those lines. > > > The reason that file is so complicated is because the LPC bridge inside > > amd8111 controls the enable and disable of devices on both side of the > > PCI bridge (in amd8111). The function in amd8111.c is call with every > > devices in the 8111 chip as argument. The function has to figure out > > which device it is given and how to enable or disable the device. > > This is done by device_t to devfn magic you see. > > Eric > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From ebiederman at lnxi.com Tue Jun 21 01:49:27 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon, 20 Jun 2005 17:49:27 -0600 Subject: [BULK] [LinuxBIOS] cache as ram for x86 In-Reply-To: <2ea3fae10506162149283a49db@mail.gmail.com> (yinghailu@gmail.com's message of "Thu, 16 Jun 2005 21:49:39 -0700") References: <3174569B9743D511922F00A0C94314230A404282@TYANWEB> <2ea3fae10506162149283a49db@mail.gmail.com> Message-ID: yhlu writes: > Ron, > > It turns out that Cache as Ram can work in intel xeon too. The only > difference is AMD need to set some bits in SYSCFG_MSR. > > So final cache as ram support for x86 will be > cpu/x86/car/cache_as_ram.inc > cpu/x86/car/cache_as_ram_post.c > cpu/x86/car/copy_and_run.c We may have something here, especially code to do the copy once the are is initialized but this can never be completely generic. > there is special version for AMD > cpu/amd/car/cache_as_ram.inc > cpu/amd/car/cache_as_ram_post.c > > in MB dir > cache_as_ram_auto.c it will include old failover.c and auto.c and > corresponding cache_as_ram_post.c and copy_and_run.c > > the cache_as_ram_post.c will stop the cache as ram and switch to ram stack. > copy_and_run will decode linuxbios_ram to memory, and jmp to it. > > USE_DCACHE_RAM ---> use romcc or gcc for auto.c... > CONFIG_USE_INIT ----> use init or not. > > the code can coexist with romcc ..... Cool. > If it is ok, I will check in cache as ram support for s2735 and > s2885/s2891/s2895 tomorrow. > > Also I would help to verify that on other x86 platform. If it's not intrusive I don't mind. But in general for developments like this I would like to put the code on a branch in the public tree first before merging it. That way multiple people can look at and test the code before it merges and potentially breaks something. I'm probably the worst offender though :) So Ron if someone wants to remind me later... Eric From bari at onelabs.com Tue Jun 21 04:37:15 2005 From: bari at onelabs.com (Bari Ari) Date: Mon, 20 Jun 2005 21:37:15 -0500 Subject: [LinuxBIOS] VIA's KT400 + VT82C8231 In-Reply-To: <20050620090133.0ee4f2d1.a.borisov@tesv.tmb.ru> References: <20050620090133.0ee4f2d1.a.borisov@tesv.tmb.ru> Message-ID: <42B77D5B.7050204@onelabs.com> Anton Borisov wrote: > Hello. > ASUS A7V8X-X carries northbridge KT400 and southbridge VT82C8231. FlashChip is PMC. flash_and_rom enables writes to flash and freezes system. Any workarounds? > > Does it freeze when you are probing or only when you write to flash? -Bari From smithbone at gmail.com Tue Jun 21 16:35:01 2005 From: smithbone at gmail.com (Richard Smith) Date: Tue, 21 Jun 2005 09:35:01 -0500 Subject: [LinuxBIOS] How to study the source code...? In-Reply-To: <1119278592.13364.14.camel@logarithm.lanl.gov> References: <4325815c0506200420416fecd3@mail.gmail.com> <1119278592.13364.14.camel@logarithm.lanl.gov> Message-ID: <8a0c367805062107352fe9a846@mail.gmail.com> > > You choose the worst file in the whole tree to start. You are not > supposed understand it unless you are Eric Biederman ;-) > I disagree with the above. When I was produceing the base files for the 440bx I looked at a lot of the different files in the tree and IMO the amd source code was some of the cleanist and well designed of all the files I looked at. I found those files easyiest to follow and the most consistent in naming and in methodoloy. I think they are an excellent place to start. The only thing the user should recognize is that those devices are somewhat complicated and that all the layers are a result of that. -- Richard A. Smith From hamish at prodigi.ch Tue Jun 21 19:17:04 2005 From: hamish at prodigi.ch (Hamish Guthrie) Date: Tue, 21 Jun 2005 19:17:04 +0200 Subject: [LinuxBIOS] Init wierdness without initrd - kernel 2.6.x Message-ID: I am wondering if anyone has come across this strange anomoly I am seeing: I have a device with an 8M NAND device, and running short of RAM. I am using SquashFS for the root filesystem. If I use a tftpboot scenario with an initrd, everything functions correctly. I am wanting to get rid of the initrd completely, and use a CramFS root filesystem directly on the NAND flash device. I set everything up correctly and am able to mount the root filesystem and execute /sbin/init directly from the NAND device (using MTD drivers), however, the init process, which is process 1, does not have superuser permissions, however, in the environment with initrd, it does have superuser permissions. Has anyone seen anything like this before - btw, I am using kernel 2.6.11 and the latest MTD drivers etc. TIA Hamish -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.7.9/23 - Release Date: 20.06.2005 From ebiederman at lnxi.com Wed Jun 22 00:12:28 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue, 21 Jun 2005 16:12:28 -0600 Subject: [BULK] Re: [LinuxBIOS] How to study the source code...? In-Reply-To: <8a0c367805062107352fe9a846@mail.gmail.com> (Richard Smith's message of "Tue, 21 Jun 2005 09:35:01 -0500") References: <4325815c0506200420416fecd3@mail.gmail.com> <1119278592.13364.14.camel@logarithm.lanl.gov> <8a0c367805062107352fe9a846@mail.gmail.com> Message-ID: Richard Smith writes: >> >> You choose the worst file in the whole tree to start. You are not >> supposed understand it unless you are Eric Biederman ;-) >> > > I disagree with the above. When I was produceing the base files for > the 440bx I looked at a lot of the different files in the tree and IMO > the amd source code was some of the cleanist and well designed of all > the files I looked at. I found those files easyiest to follow and the > most consistent in naming and in methodoloy. > > I think they are an excellent place to start. The only thing the user > should recognize is that those devices are somewhat complicated and > that all the layers are a result of that. amd8111.c in particular is a challenge because it operates at such a high level of abstraction. The hardest thing about learning the v2 tree is the code is written in a reusable fashion that when you don't know how all of the pieces fit make it a little hard to understand. It isn't a simple a calls b calls c. Multiple levels of abstraction can be very useful, but until you learn then it is easy to get lost. At least I think that is what was happening with amd8111.c Eric From YhLu at tyan.com Wed Jun 22 03:01:50 2005 From: YhLu at tyan.com (YhLu) Date: Tue, 21 Jun 2005 18:01:50 -0700 Subject: [LinuxBIOS] commited cache as ram for amd and some intel Message-ID: <3174569B9743D511922F00A0C94314230AF96EC7@TYANWEB> just commited amd cache as ram and some intel.... You can use CONFIG_DCACHE_RAM to switch back to romcc also CONFIG_USE_INIT is used to decide to use cache_as_ram_auto.c as auto.inc or auto.o MB: s2881/s2882/s2885/s2891/s2892/s2895/s4882 s2735 if you have problem with your MB, please add uses CONFIG_USE_INIT in your MB Config.lb YH From vigmond at ucalgary.ca Wed Jun 22 05:30:04 2005 From: vigmond at ucalgary.ca (Edward Vigmond) Date: Tue, 21 Jun 2005 21:30:04 -0600 Subject: [LinuxBIOS] Asus/Via Support Message-ID: <42B8DB3C.2020903@ucalgary.ca> Hello Is there any chance that an ASUS CUV4X-D mainboard with the VIA 694 XDP chipset will work? The OS doesn't have lspci (sorry). Thanks -- Dr. Edward Vigmond, P.Eng Department of Electrical and Computer Engineering University of Calgary From a.borisov at tesv.tmb.ru Wed Jun 22 11:18:31 2005 From: a.borisov at tesv.tmb.ru (Anton Borisov) Date: Wed, 22 Jun 2005 13:18:31 +0400 Subject: [LinuxBIOS] Do hardware vendors see benefits from LB? Message-ID: <20050622131831.74175125.a.borisov@tesv.tmb.ru> Hi, guys. I've been wondering for some time - why hardware vendors are so unwilling to provide their hardware products to adapt it to run LinuxBIOS? I don't mention Tyan or SIS which are quite involved into the process and already have bargains. Any ideas? -- Sincerely, Anton Borisov From ebiederman at lnxi.com Wed Jun 22 11:50:26 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed, 22 Jun 2005 03:50:26 -0600 Subject: [LinuxBIOS] Merge complete.... Message-ID: Ok. After I finally developed a sane common ancestor between the two trees it did not take much time to finish the merge. >From that ancestor linuxbios at linuxbios.org--devel/frebios--devel--2.0--base-0 I have merged each patch individually with star-merge and that worked well allowing me to fix the small handful of conflicts that the new development created. I would love to move the changes into the public tree the same way but it does not appear easily possible, instead it is trivial to simply merge my entire tree into the public tree. Since I want to avoid breaking things by acting too hastily I have performed the merge and placed the code in the branch: linuxbios at linuxbios.org--devel/freebios--lnxi--1--patch-1 If no one has any real objections after looking at it I will merge with the main branch. Otherwise I will listen to the objections and see where I go from there. Eric From rminnich at lanl.gov Wed Jun 22 16:45:59 2005 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Wed, 22 Jun 2005 08:45:59 -0600 (MDT) Subject: [LinuxBIOS] Merge complete.... In-Reply-To: References: Message-ID: thanks Eric. Please don't do a real merge until we have positive confirmation from people that it will be ok. thanks ron From ollie at lanl.gov Wed Jun 22 17:33:38 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Wed, 22 Jun 2005 09:33:38 -0600 Subject: [LinuxBIOS] Merge complete.... In-Reply-To: References: Message-ID: <1119454419.6163.0.camel@logarithm.lanl.gov> On Wed, 2005-06-22 at 03:50 -0600, Eric W. Biederman wrote: > Ok. After I finally developed a sane common ancestor between > the two trees it did not take much time to finish the merge. > > >From that ancestor linuxbios at linuxbios.org--devel/frebios--devel--2.0--base-0 > I have merged each patch individually with star-merge and that worked > well allowing me to fix the small handful of conflicts that the new > development created. > > I would love to move the changes into the public tree the same way but it does > not appear easily possible, instead it is trivial to simply merge my entire > tree into the public tree. > > Since I want to avoid breaking things by acting too hastily I have > performed the merge and placed the code in the branch: > linuxbios at linuxbios.org--devel/freebios--lnxi--1--patch-1 > > How am I going to check out that branch? [ollie at logarithm tmp]$ tla get linuxbios at linuxbios.org--devel/freebios-- lxni--1 freebios_lxni No such package (freebios--lxni) name: linuxbios at linuxbios.org--devel location: sftp://lxbios at openbios.org/srv/arch/linuxbios at linuxbios.org--devel package-version: freebios--lxni--1 Do I have to "tla register archive" or something? -- Li-Ta Lo Los Alamos National Lab From ollie at lanl.gov Wed Jun 22 18:00:49 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Wed, 22 Jun 2005 10:00:49 -0600 Subject: [LinuxBIOS] Merge complete.... In-Reply-To: <1119454419.6163.0.camel@logarithm.lanl.gov> References: <1119454419.6163.0.camel@logarithm.lanl.gov> Message-ID: <1119456049.6163.2.camel@logarithm.lanl.gov> On Wed, 2005-06-22 at 09:33 -0600, Li-Ta Lo wrote: > On Wed, 2005-06-22 at 03:50 -0600, Eric W. Biederman wrote: > > Ok. After I finally developed a sane common ancestor between > > the two trees it did not take much time to finish the merge. > > > > >From that ancestor linuxbios at linuxbios.org--devel/frebios--devel--2.0--base-0 > > I have merged each patch individually with star-merge and that worked > > well allowing me to fix the small handful of conflicts that the new > > development created. > > > > I would love to move the changes into the public tree the same way but it does > > not appear easily possible, instead it is trivial to simply merge my entire > > tree into the public tree. > > > > Since I want to avoid breaking things by acting too hastily I have > > performed the merge and placed the code in the branch: > > linuxbios at linuxbios.org--devel/freebios--lnxi--1--patch-1 > > > > > > How am I going to check out that branch? > > [ollie at logarithm tmp]$ tla get linuxbios at linuxbios.org--devel/freebios-- > lxni--1 freebios_lxni > No such package (freebios--lxni) > name: linuxbios at linuxbios.org--devel > location: > sftp://lxbios at openbios.org/srv/arch/linuxbios at linuxbios.org--devel > package-version: freebios--lxni--1 > > Do I have to "tla register archive" or something? > Sorry, it a typo. -- Li-Ta Lo Los Alamos National Lab From ebiederman at lnxi.com Wed Jun 22 18:07:07 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed, 22 Jun 2005 10:07:07 -0600 Subject: [LinuxBIOS] Merge complete.... In-Reply-To: <1119454419.6163.0.camel@logarithm.lanl.gov> (Li-Ta Lo's message of "Wed, 22 Jun 2005 09:33:38 -0600") References: <1119454419.6163.0.camel@logarithm.lanl.gov> Message-ID: Li-Ta Lo writes: > > How am I going to check out that branch? > > [ollie at logarithm tmp]$ tla get linuxbios at linuxbios.org--devel/freebios--lxni--1 freebios_lxni > No such package (freebios--lxni) > name: linuxbios at linuxbios.org--devel > location: > sftp://lxbios at openbios.org/srv/arch/linuxbios at linuxbios.org--devel > package-version: freebios--lxni--1 > > Do I have to "tla register archive" or something? The following just worked for me: tla get linuxbios at linuxbios.org--devel/freebios--lnxi--1 so I think there is some subtle typo somewhere that was causing you problems. The first time I tried it. I had a failure as well. But I can't see anything wrong :( Ok. It looks like you just came to the same conclusion. Eric From rminnich at lanl.gov Wed Jun 22 18:14:17 2005 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Wed, 22 Jun 2005 10:14:17 -0600 (MDT) Subject: [LinuxBIOS] Merge complete.... In-Reply-To: <1119454419.6163.0.camel@logarithm.lanl.gov> References: <1119454419.6163.0.camel@logarithm.lanl.gov> Message-ID: On Wed, 22 Jun 2005, Li-Ta Lo wrote: > On Wed, 2005-06-22 at 03:50 -0600, Eric W. Biederman wrote: > > Ok. After I finally developed a sane common ancestor between > > the two trees it did not take much time to finish the merge. > > > > >From that ancestor linuxbios at linuxbios.org--devel/frebios--devel--2.0--base-0 > > I have merged each patch individually with star-merge and that worked > > well allowing me to fix the small handful of conflicts that the new > > development created. > > > > I would love to move the changes into the public tree the same way but it does > > not appear easily possible, instead it is trivial to simply merge my entire > > tree into the public tree. > > > > Since I want to avoid breaking things by acting too hastily I have > > performed the merge and placed the code in the branch: > > linuxbios at linuxbios.org--devel/freebios--lnxi--1--patch-1 > > > > > > How am I going to check out that branch? > > [ollie at logarithm tmp]$ tla get linuxbios at linuxbios.org--devel/freebios-- > lxni--1 freebios_lxni lnxi not lxni ron From kfuchs at winternet.com Wed Jun 22 18:29:56 2005 From: kfuchs at winternet.com (Ken Fuchs) Date: Wed, 22 Jun 2005 11:29:56 -0500 (CDT) Subject: [LinuxBIOS] Asus/Via Support Message-ID: <200506221629.j5MGTuPr016614@tundra.winternet.com> Dr. Vigmond wrote: > Is there any chance that an ASUS CUV4X-D mainboard with the VIA 694 XDP > chipset will work? Can someone please answer this question. > The OS doesn't have lspci (sorry). If the Linux kernel has the proc filesystem included (almost all default installation kernels do), the same information should be available in /proc/pci or somewhere in /proc/bus/pci. Take a look at the lspci sources. Try: cat /proc/pci Sincerely, Ken Fuchs From yinghailu at gmail.com Wed Jun 22 19:19:09 2005 From: yinghailu at gmail.com (yhlu) Date: Wed, 22 Jun 2005 10:19:09 -0700 Subject: [LinuxBIOS] Merge complete.... In-Reply-To: References: <1119454419.6163.0.camel@logarithm.lanl.gov> Message-ID: <2ea3fae10506221019745d968e@mail.gmail.com> At last Eric put the E7520 to the public.... YH On 6/22/05, Ronald G. Minnich wrote: > > > On Wed, 22 Jun 2005, Li-Ta Lo wrote: > > > On Wed, 2005-06-22 at 03:50 -0600, Eric W. Biederman wrote: > > > Ok. After I finally developed a sane common ancestor between > > > the two trees it did not take much time to finish the merge. > > > > > > >From that ancestor linuxbios at linuxbios.org--devel/frebios--devel--2.0--base-0 > > > I have merged each patch individually with star-merge and that worked > > > well allowing me to fix the small handful of conflicts that the new > > > development created. > > > > > > I would love to move the changes into the public tree the same way but it does > > > not appear easily possible, instead it is trivial to simply merge my entire > > > tree into the public tree. > > > > > > Since I want to avoid breaking things by acting too hastily I have > > > performed the merge and placed the code in the branch: > > > linuxbios at linuxbios.org--devel/freebios--lnxi--1--patch-1 > > > > > > > > > > How am I going to check out that branch? > > > > [ollie at logarithm tmp]$ tla get linuxbios at linuxbios.org--devel/freebios-- > > lxni--1 freebios_lxni > lnxi > > not lxni > > ron > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From rminnich at lanl.gov Wed Jun 22 19:21:52 2005 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Wed, 22 Jun 2005 11:21:52 -0600 (MDT) Subject: [LinuxBIOS] Asus/Via Support In-Reply-To: <200506221629.j5MGTuPr016614@tundra.winternet.com> References: <200506221629.j5MGTuPr016614@tundra.winternet.com> Message-ID: On Wed, 22 Jun 2005, Ken Fuchs wrote: > Dr. Vigmond wrote: > > > Is there any chance that an ASUS CUV4X-D mainboard with the VIA 694 XDP > > chipset will work? > > Can someone please answer this question. will via let us see docs? That's the real question. ron From ollie at lanl.gov Wed Jun 22 19:42:49 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Wed, 22 Jun 2005 11:42:49 -0600 Subject: [LinuxBIOS] Merge complete.... In-Reply-To: References: Message-ID: <1119462169.8134.3.camel@logarithm.lanl.gov> On Wed, 2005-06-22 at 03:50 -0600, Eric W. Biederman wrote: > Since I want to avoid breaking things by acting too hastily I have > performed the merge and placed the code in the branch: > linuxbios at linuxbios.org--devel/freebios--lnxi--1--patch-1 > > > If no one has any real objections after looking at it I will merge with > the main branch. Otherwise I will listen to the objections and see > where I go from there. > First pass of objections, I think these files are cvs/tla removed (by you?) long time ago? New-files: src/mainboard/Iwill/DK8S2/debug.c src/mainboard/Iwill/DK8S2/reset.c src/mainboard/Iwill/DK8X/debug.c src/mainboard/Iwill/DK8X/reset.c src/mainboard/amd/quartet/debug.c src/mainboard/amd/quartet/reset.c src/mainboard/amd/serenade/reset.c src/mainboard/amd/solo/debug.c src/mainboard/amd/solo/reset.c src/mainboard/arima/hdama/debug.c src/mainboard/arima/hdama/reset.c src/mainboard/ibm/e325/reset.c src/mainboard/newisys/khepri/debug.c src/mainboard/newisys/khepri/reset.c src/mainboard/tyan/s2735/reset.c src/mainboard/tyan/s2850/adaptec_scsi.c src/mainboard/tyan/s2850/broadcom_nic.c src/mainboard/tyan/s2850/debug.c src/mainboard/tyan/s2850/hypertransport.c src/mainboard/tyan/s2850/intel_nic.c src/mainboard/tyan/s2850/promise_sata.c src/mainboard/tyan/s2850/reset.c src/mainboard/tyan/s2875/reset.c src/mainboard/tyan/s2880/adaptec_scsi.c src/mainboard/tyan/s2880/debug.c src/mainboard/tyan/s2880/hypertransport.c src/mainboard/tyan/s2880/intel_nic.c src/mainboard/tyan/s2880/promise_sata.c src/mainboard/tyan/s2880/reset.c src/mainboard/tyan/s2880/tyan-fallback.config src/mainboard/tyan/s2880/tyan-normal.config src/mainboard/tyan/s2881/adaptec_scsi.c src/mainboard/tyan/s2881/debug.c src/mainboard/tyan/s2881/hypertransport.c src/mainboard/tyan/s2881/intel_nic.c src/mainboard/tyan/s2881/reset.c src/mainboard/tyan/s2881/si_sata.c src/mainboard/tyan/s2882/adaptec_scsi.c src/mainboard/tyan/s2882/debug.c src/mainboard/tyan/s2882/hypertransport.c src/mainboard/tyan/s2882/intel_nic.c src/mainboard/tyan/s2882/reset.c src/mainboard/tyan/s2882/si_sata.c src/mainboard/tyan/s2882/tyan-fallback.config src/mainboard/tyan/s2882/tyan-normal.config src/mainboard/tyan/s2885/adaptec_scsi.c src/mainboard/tyan/s2885/broadcom_nic.c src/mainboard/tyan/s2885/debug.c src/mainboard/tyan/s2885/hypertransport.c src/mainboard/tyan/s2885/intel_nic.c src/mainboard/tyan/s2885/reset.c src/mainboard/tyan/s2885/si_sata.c src/mainboard/tyan/s2885/ti_firewire.c src/mainboard/tyan/s2885/tyan-fallback.config src/mainboard/tyan/s2885/tyan-normal.config src/mainboard/tyan/s4880/adaptec_scsi.c src/mainboard/tyan/s4880/debug.c src/mainboard/tyan/s4880/hypertransport.c src/mainboard/tyan/s4880/intel_nic.c src/mainboard/tyan/s4880/reset.c src/mainboard/tyan/s4880/si_sata.c src/mainboard/tyan/s4882/reset.c -- Li-Ta Lo Los Alamos National Lab From ollie at lanl.gov Wed Jun 22 19:59:00 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Wed, 22 Jun 2005 11:59:00 -0600 Subject: [LinuxBIOS] Merge complete.... In-Reply-To: <1119462169.8134.3.camel@logarithm.lanl.gov> References: <1119462169.8134.3.camel@logarithm.lanl.gov> Message-ID: <1119463140.8134.6.camel@logarithm.lanl.gov> On Wed, 2005-06-22 at 11:42 -0600, Li-Ta Lo wrote: > On Wed, 2005-06-22 at 03:50 -0600, Eric W. Biederman wrote: > > Since I want to avoid breaking things by acting too hastily I have > > performed the merge and placed the code in the branch: > > linuxbios at linuxbios.org--devel/freebios--lnxi--1--patch-1 > > > > > > If no one has any real objections after looking at it I will merge with > > the main branch. Otherwise I will listen to the objections and see > > where I go from there. > > > > First pass of objections, I think these files are cvs/tla removed (by > you?) long time ago? > > New-files: > src/mainboard/Iwill/DK8S2/debug.c > src/mainboard/Iwill/DK8S2/reset.c > src/mainboard/Iwill/DK8X/debug.c > src/mainboard/Iwill/DK8X/reset.c > src/mainboard/amd/quartet/debug.c > src/mainboard/amd/quartet/reset.c > src/mainboard/amd/serenade/reset.c > src/mainboard/amd/solo/debug.c > src/mainboard/amd/solo/reset.c > src/mainboard/arima/hdama/debug.c > src/mainboard/arima/hdama/reset.c > src/mainboard/ibm/e325/reset.c > src/mainboard/newisys/khepri/debug.c > src/mainboard/newisys/khepri/reset.c > src/mainboard/tyan/s2735/reset.c > src/mainboard/tyan/s2850/adaptec_scsi.c > src/mainboard/tyan/s2850/broadcom_nic.c > src/mainboard/tyan/s2850/debug.c > src/mainboard/tyan/s2850/hypertransport.c > src/mainboard/tyan/s2850/intel_nic.c > src/mainboard/tyan/s2850/promise_sata.c > src/mainboard/tyan/s2850/reset.c > src/mainboard/tyan/s2875/reset.c > src/mainboard/tyan/s2880/adaptec_scsi.c > src/mainboard/tyan/s2880/debug.c > src/mainboard/tyan/s2880/hypertransport.c > src/mainboard/tyan/s2880/intel_nic.c > src/mainboard/tyan/s2880/promise_sata.c > src/mainboard/tyan/s2880/reset.c > src/mainboard/tyan/s2880/tyan-fallback.config > src/mainboard/tyan/s2880/tyan-normal.config > src/mainboard/tyan/s2881/adaptec_scsi.c > src/mainboard/tyan/s2881/debug.c > src/mainboard/tyan/s2881/hypertransport.c > src/mainboard/tyan/s2881/intel_nic.c > src/mainboard/tyan/s2881/reset.c > src/mainboard/tyan/s2881/si_sata.c > src/mainboard/tyan/s2882/adaptec_scsi.c > src/mainboard/tyan/s2882/debug.c > src/mainboard/tyan/s2882/hypertransport.c > src/mainboard/tyan/s2882/intel_nic.c > src/mainboard/tyan/s2882/reset.c > src/mainboard/tyan/s2882/si_sata.c > src/mainboard/tyan/s2882/tyan-fallback.config > src/mainboard/tyan/s2882/tyan-normal.config > src/mainboard/tyan/s2885/adaptec_scsi.c > src/mainboard/tyan/s2885/broadcom_nic.c > src/mainboard/tyan/s2885/debug.c > src/mainboard/tyan/s2885/hypertransport.c > src/mainboard/tyan/s2885/intel_nic.c > src/mainboard/tyan/s2885/reset.c > src/mainboard/tyan/s2885/si_sata.c > src/mainboard/tyan/s2885/ti_firewire.c > src/mainboard/tyan/s2885/tyan-fallback.config > src/mainboard/tyan/s2885/tyan-normal.config > src/mainboard/tyan/s4880/adaptec_scsi.c > src/mainboard/tyan/s4880/debug.c > src/mainboard/tyan/s4880/hypertransport.c > src/mainboard/tyan/s4880/intel_nic.c > src/mainboard/tyan/s4880/reset.c > src/mainboard/tyan/s4880/si_sata.c > src/mainboard/tyan/s4882/reset.c Are these files reversed patch too? Modified-files: src/mainboard/Iwill/DK8S2/Config.lb src/mainboard/Iwill/DK8S2/Options.lb src/mainboard/Iwill/DK8S2/cmos.layout src/mainboard/Iwill/DK8S2/failover.c src/mainboard/Iwill/DK8S2/irq_tables.c src/mainboard/Iwill/DK8S2/mptable.c src/mainboard/Iwill/DK8X/Config.lb src/mainboard/Iwill/DK8X/Options.lb src/mainboard/amd/quartet/Config.lb src/mainboard/amd/quartet/Options.lb src/mainboard/amd/serenade/Config.lb src/mainboard/amd/serenade/Options.lb src/mainboard/amd/solo/Config.lb src/mainboard/amd/solo/Options.lb src/mainboard/arima/hdama/Config.lb src/mainboard/arima/hdama/Options.lb src/mainboard/arima/hdama/auto.c src/mainboard/arima/hdama/mptable.c src/mainboard/emulation/qemu-i386/Options.lb src/mainboard/ibm/e325/Config.lb src/mainboard/ibm/e325/Options.lb src/mainboard/newisys/khepri/Config.lb src/mainboard/newisys/khepri/Options.lb src/mainboard/tyan/s2735/Config.lb src/mainboard/tyan/s2735/Options.lb src/mainboard/tyan/s2850/Config.lb src/mainboard/tyan/s2850/Options.lb src/mainboard/tyan/s2875/Config.lb src/mainboard/tyan/s2875/Options.lb src/mainboard/tyan/s2880/Config.lb src/mainboard/tyan/s2880/Options.lb src/mainboard/tyan/s2881/Config.lb src/mainboard/tyan/s2881/Options.lb src/mainboard/tyan/s2882/Config.lb src/mainboard/tyan/s2882/Options.lb src/mainboard/tyan/s2882/auto.c src/mainboard/tyan/s2882/mptable.c src/mainboard/tyan/s2885/Config.lb src/mainboard/tyan/s2885/Options.lb src/mainboard/tyan/s2885/auto.c src/mainboard/tyan/s4880/Config.lb src/mainboard/tyan/s4880/Options.lb src/mainboard/tyan/s4882/Config.lb src/mainboard/tyan/s4882/Options.lb src/mainboard/tyan/s4882/auto.c src/mainboard/tyan/s4882/chip.h src/mainboard/tyan/s4882/failover.c src/mainboard/tyan/s4882/mainboard.c -- Li-Ta Lo Los Alamos National Lab From YhLu at tyan.com Wed Jun 22 20:17:59 2005 From: YhLu at tyan.com (YhLu) Date: Wed, 22 Jun 2005 11:17:59 -0700 Subject: [LinuxBIOS] Merge complete.... Message-ID: <3174569B9743D511922F00A0C94314230AF96F2D@TYANWEB> filo is removed too. more generic support for pci-x, pci-e, ht, Eric, is it support HT-HT bridge now? also diff -r freebios_lnxi/src/arch/i386/init/ldscript.lb ../freebios2/src/arch/i386/init/ldscript.lb 44,49d43 < < /* Move up the location counter if the start of the rom section is < * too low. < */ < . = ( ( ( _ROMBASE + ROM_IMAGE_SIZE - 1 ) == 0xffffffff ) && ( . < 0xffff0000 ) ) ? 0xffff0000 : . ; < there is some problem too. for some 8 way opteron system with romcc i need linuxbios_ram auto.inc ---- it is very big entry32.inc --- _start is here failover.inc jmp auto.inc out: _main in crt0.S then you will push auto.inc into the top 64k too, but the 64k can not fit. So please merge that into main tree... YH > -----Original Message----- > From: Li-Ta Lo [mailto:ollie at lanl.gov] > Sent: Wednesday, June 22, 2005 10:59 AM > To: Eric W. Biederman > Cc: LinuxBIOS > Subject: Re: [LinuxBIOS] Merge complete.... > > On Wed, 2005-06-22 at 11:42 -0600, Li-Ta Lo wrote: > > On Wed, 2005-06-22 at 03:50 -0600, Eric W. Biederman wrote: > > > Since I want to avoid breaking things by acting too > hastily I have > > > performed the merge and placed the code in the branch: > > > linuxbios at linuxbios.org--devel/freebios--lnxi--1--patch-1 > > > > > > > > > If no one has any real objections after looking at it I > will merge > > > with the main branch. Otherwise I will listen to the > objections and > > > see where I go from there. > > > > > > > First pass of objections, I think these files are cvs/tla > removed (by > > you?) long time ago? > > > > New-files: > > src/mainboard/Iwill/DK8S2/debug.c > > src/mainboard/Iwill/DK8S2/reset.c > > src/mainboard/Iwill/DK8X/debug.c > > src/mainboard/Iwill/DK8X/reset.c > > src/mainboard/amd/quartet/debug.c > > src/mainboard/amd/quartet/reset.c > > src/mainboard/amd/serenade/reset.c > > src/mainboard/amd/solo/debug.c > > src/mainboard/amd/solo/reset.c > > src/mainboard/arima/hdama/debug.c > > src/mainboard/arima/hdama/reset.c > > src/mainboard/ibm/e325/reset.c > > src/mainboard/newisys/khepri/debug.c > > src/mainboard/newisys/khepri/reset.c > > src/mainboard/tyan/s2735/reset.c > > src/mainboard/tyan/s2850/adaptec_scsi.c > > src/mainboard/tyan/s2850/broadcom_nic.c > > src/mainboard/tyan/s2850/debug.c > > src/mainboard/tyan/s2850/hypertransport.c > > src/mainboard/tyan/s2850/intel_nic.c > > src/mainboard/tyan/s2850/promise_sata.c > > src/mainboard/tyan/s2850/reset.c > > src/mainboard/tyan/s2875/reset.c > > src/mainboard/tyan/s2880/adaptec_scsi.c > > src/mainboard/tyan/s2880/debug.c > > src/mainboard/tyan/s2880/hypertransport.c > > src/mainboard/tyan/s2880/intel_nic.c > > src/mainboard/tyan/s2880/promise_sata.c > > src/mainboard/tyan/s2880/reset.c > > src/mainboard/tyan/s2880/tyan-fallback.config > > src/mainboard/tyan/s2880/tyan-normal.config > > src/mainboard/tyan/s2881/adaptec_scsi.c > > src/mainboard/tyan/s2881/debug.c > > src/mainboard/tyan/s2881/hypertransport.c > > src/mainboard/tyan/s2881/intel_nic.c > > src/mainboard/tyan/s2881/reset.c > > src/mainboard/tyan/s2881/si_sata.c > > src/mainboard/tyan/s2882/adaptec_scsi.c > > src/mainboard/tyan/s2882/debug.c > > src/mainboard/tyan/s2882/hypertransport.c > > src/mainboard/tyan/s2882/intel_nic.c > > src/mainboard/tyan/s2882/reset.c > > src/mainboard/tyan/s2882/si_sata.c > > src/mainboard/tyan/s2882/tyan-fallback.config > > src/mainboard/tyan/s2882/tyan-normal.config > > src/mainboard/tyan/s2885/adaptec_scsi.c > > src/mainboard/tyan/s2885/broadcom_nic.c > > src/mainboard/tyan/s2885/debug.c > > src/mainboard/tyan/s2885/hypertransport.c > > src/mainboard/tyan/s2885/intel_nic.c > > src/mainboard/tyan/s2885/reset.c > > src/mainboard/tyan/s2885/si_sata.c > > src/mainboard/tyan/s2885/ti_firewire.c > > src/mainboard/tyan/s2885/tyan-fallback.config > > src/mainboard/tyan/s2885/tyan-normal.config > > src/mainboard/tyan/s4880/adaptec_scsi.c > > src/mainboard/tyan/s4880/debug.c > > src/mainboard/tyan/s4880/hypertransport.c > > src/mainboard/tyan/s4880/intel_nic.c > > src/mainboard/tyan/s4880/reset.c > > src/mainboard/tyan/s4880/si_sata.c > > src/mainboard/tyan/s4882/reset.c > > Are these files reversed patch too? > > Modified-files: > src/mainboard/Iwill/DK8S2/Config.lb > src/mainboard/Iwill/DK8S2/Options.lb > src/mainboard/Iwill/DK8S2/cmos.layout > src/mainboard/Iwill/DK8S2/failover.c > src/mainboard/Iwill/DK8S2/irq_tables.c > src/mainboard/Iwill/DK8S2/mptable.c > src/mainboard/Iwill/DK8X/Config.lb > src/mainboard/Iwill/DK8X/Options.lb > src/mainboard/amd/quartet/Config.lb > src/mainboard/amd/quartet/Options.lb > src/mainboard/amd/serenade/Config.lb > src/mainboard/amd/serenade/Options.lb > src/mainboard/amd/solo/Config.lb > src/mainboard/amd/solo/Options.lb > src/mainboard/arima/hdama/Config.lb > src/mainboard/arima/hdama/Options.lb > src/mainboard/arima/hdama/auto.c > src/mainboard/arima/hdama/mptable.c > src/mainboard/emulation/qemu-i386/Options.lb > src/mainboard/ibm/e325/Config.lb > src/mainboard/ibm/e325/Options.lb > src/mainboard/newisys/khepri/Config.lb > src/mainboard/newisys/khepri/Options.lb > src/mainboard/tyan/s2735/Config.lb > src/mainboard/tyan/s2735/Options.lb > src/mainboard/tyan/s2850/Config.lb > src/mainboard/tyan/s2850/Options.lb > src/mainboard/tyan/s2875/Config.lb > src/mainboard/tyan/s2875/Options.lb > src/mainboard/tyan/s2880/Config.lb > src/mainboard/tyan/s2880/Options.lb > src/mainboard/tyan/s2881/Config.lb > src/mainboard/tyan/s2881/Options.lb > src/mainboard/tyan/s2882/Config.lb > src/mainboard/tyan/s2882/Options.lb > src/mainboard/tyan/s2882/auto.c > src/mainboard/tyan/s2882/mptable.c > src/mainboard/tyan/s2885/Config.lb > src/mainboard/tyan/s2885/Options.lb > src/mainboard/tyan/s2885/auto.c > src/mainboard/tyan/s4880/Config.lb > src/mainboard/tyan/s4880/Options.lb > src/mainboard/tyan/s4882/Config.lb > src/mainboard/tyan/s4882/Options.lb > src/mainboard/tyan/s4882/auto.c > src/mainboard/tyan/s4882/chip.h > src/mainboard/tyan/s4882/failover.c > src/mainboard/tyan/s4882/mainboard.c > -- > Li-Ta Lo > Los Alamos National Lab > > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From rminnich at lanl.gov Wed Jun 22 20:20:46 2005 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Wed, 22 Jun 2005 12:20:46 -0600 (MDT) Subject: [LinuxBIOS] Merge complete.... In-Reply-To: <3174569B9743D511922F00A0C94314230AF96F2D@TYANWEB> References: <3174569B9743D511922F00A0C94314230AF96F2D@TYANWEB> Message-ID: On Wed, 22 Jun 2005, YhLu wrote: > So please merge that into main tree... NOT YET! this merge is huge. Ollie is going through it bit by bit. We are not ready to merge yet. Eric, please hold on for a while, Ollie will finish up his summary. ron From YhLu at tyan.com Wed Jun 22 20:29:38 2005 From: YhLu at tyan.com (YhLu) Date: Wed, 22 Jun 2005 11:29:38 -0700 Subject: [LinuxBIOS] Merge complete.... Message-ID: <3174569B9743D511922F00A0C94314230AF96F33@TYANWEB> define HARD_RESET_BUS removed, Good, get amd8111 bus from config_bus_map... YH > -----Original Message----- > From: Ronald G. Minnich [mailto:rminnich at lanl.gov] > Sent: Wednesday, June 22, 2005 11:21 AM > To: YhLu > Cc: Li-Ta Lo; Eric W. Biederman; LinuxBIOS > Subject: RE: [LinuxBIOS] Merge complete.... > > > > On Wed, 22 Jun 2005, YhLu wrote: > > > So please merge that into main tree... > > > NOT YET! > > this merge is huge. Ollie is going through it bit by bit. We > are not ready to merge yet. > > Eric, please hold on for a while, Ollie will finish up his summary. > > ron > From ollie at lanl.gov Wed Jun 22 20:34:57 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Wed, 22 Jun 2005 12:34:57 -0600 Subject: [LinuxBIOS] Merge complete.... In-Reply-To: <3174569B9743D511922F00A0C94314230AF96F33@TYANWEB> References: <3174569B9743D511922F00A0C94314230AF96F33@TYANWEB> Message-ID: <1119465297.8134.9.camel@logarithm.lanl.gov> On Wed, 2005-06-22 at 11:29 -0700, YhLu wrote: > define HARD_RESET_BUS > > removed, Good, get amd8111 bus from config_bus_map... > Eric, Is there any reason you put reset.c in every mainboard directory but the only thing in these reset.c is #include "amd8111_reset.c" ? -- Li-Ta Lo Los Alamos National Lab From ollie at lanl.gov Wed Jun 22 20:39:54 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Wed, 22 Jun 2005 12:39:54 -0600 Subject: [LinuxBIOS] Merge complete.... In-Reply-To: <1119465297.8134.9.camel@logarithm.lanl.gov> References: <3174569B9743D511922F00A0C94314230AF96F33@TYANWEB> <1119465297.8134.9.camel@logarithm.lanl.gov> Message-ID: <1119465595.8134.12.camel@logarithm.lanl.gov> On Wed, 2005-06-22 at 12:34 -0600, Li-Ta Lo wrote: > On Wed, 2005-06-22 at 11:29 -0700, YhLu wrote: > > define HARD_RESET_BUS > > > > removed, Good, get amd8111 bus from config_bus_map... > > > > Eric, > > Is there any reason you put reset.c in every mainboard directory but > the only thing in these reset.c is #include "amd8111_reset.c" ? > And node_link_to_bus in amd8111_reset.c and every auto.c? -- Li-Ta Lo Los Alamos National Lab From YhLu at tyan.com Wed Jun 22 20:53:04 2005 From: YhLu at tyan.com (YhLu) Date: Wed, 22 Jun 2005 11:53:04 -0700 Subject: [LinuxBIOS] Merge complete.... Message-ID: <3174569B9743D511922F00A0C94314230AF96F44@TYANWEB> if(is_cpu_d0()) { /* Erratum 110 ...*/ msr = rdmsr_amd(CPU_ID_HYPER_EXT_FEATURES); msr.hi |=1; wrmsr_amd(CPU_ID_HYPER_EXT_FEATURES, msr); } if (is_cpu_pre_e0()) { /* Erratum 110 ... */ msr = rdmsr_amd(CPU_ID_EXT_FEATURES_MSR); msr.hi |=1; wrmsr_amd(CPU_ID_EXT_FEATURES_MSR, msr); } also in model_fxx_init.c you miss sth should be if(is_cpu_d0()) { /* Erratum 110 ...*/ msr = rdmsr_amd(CPU_ID_HYPER_EXT_FEATURES); msr.hi |=1; wrmsr_amd(CPU_ID_HYPER_EXT_FEATURES, msr); } if (!is_cpu_pre_e0()) { ------------------------------don't forget ! /* Erratum 110 ... */ msr = rdmsr_amd(CPU_ID_EXT_FEATURES_MSR); msr.hi |=1; wrmsr_amd(CPU_ID_EXT_FEATURES_MSR, msr); } YH > -----Original Message----- > From: Li-Ta Lo [mailto:ollie at lanl.gov] > Sent: Wednesday, June 22, 2005 11:40 AM > To: YhLu > Cc: LinuxBIOS > Subject: RE: [LinuxBIOS] Merge complete.... > > On Wed, 2005-06-22 at 12:34 -0600, Li-Ta Lo wrote: > > On Wed, 2005-06-22 at 11:29 -0700, YhLu wrote: > > > define HARD_RESET_BUS > > > > > > removed, Good, get amd8111 bus from config_bus_map... > > > > > > > Eric, > > > > Is there any reason you put reset.c in every mainboard > directory but > > the only thing in these reset.c is #include "amd8111_reset.c" ? > > > > And node_link_to_bus in amd8111_reset.c and every auto.c? > > -- > Li-Ta Lo > Los Alamos National Lab > From ebiederman at lnxi.com Wed Jun 22 21:18:18 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed, 22 Jun 2005 13:18:18 -0600 Subject: [LinuxBIOS] Merge complete.... In-Reply-To: <1119462169.8134.3.camel@logarithm.lanl.gov> (Li-Ta Lo's message of "Wed, 22 Jun 2005 11:42:49 -0600") References: <1119462169.8134.3.camel@logarithm.lanl.gov> Message-ID: Li-Ta Lo writes: > On Wed, 2005-06-22 at 03:50 -0600, Eric W. Biederman wrote: >> Since I want to avoid breaking things by acting too hastily I have >> performed the merge and placed the code in the branch: >> linuxbios at linuxbios.org--devel/freebios--lnxi--1--patch-1 >> >> >> If no one has any real objections after looking at it I will merge with >> the main branch. Otherwise I will listen to the objections and see >> where I go from there. >> > > First pass of objections, I think these files are cvs/tla removed (by > you?) long time ago? Not by me. Someone realized the code in reset.c was very similar and made a common factor that wasn't truly common or generic, and there were cases where the code would not work but we didn't have a choice not to use it. So in reset.c I removed the common factor and put reset.c back. It is now a single motherboard dependent function call but it is general. debug.c could go in a lot of cases but I don't quite find a generic debug.c for a northbridge persuasive either. At least on the boards I am messing with I wrote debug.c to get my local debugging hacks out of the mainline of the code. And my debug.c continuted to mutate. But everyone doesn't need one, and arguably production code could do completely without one. The rest may indeed be files someone else deleted that I missed. Eric From steve at digidescorp.com Wed Jun 22 21:19:39 2005 From: steve at digidescorp.com (Steven J. Magnani) Date: Wed, 22 Jun 2005 14:19:39 -0500 Subject: [LinuxBIOS] E7501 raminit changes Message-ID: <000801c5775f$595b47c0$6ffea8c0@banana> Yh Lu, I noticed that you added code to the E7501 raminit to change the mapping between system bus and southbridge stop grants from the default of 1:1 to 2:1 when the file is compiled with CAS_LATENCY defined to CAS_2_0. Is the stop grant change needed only for CL 2.0, or should it be applied to both 2.0 and 2.5? If the former, I'll put it in the function that configures the CAS latency based on SPD info (i.e. make the configuration change programmatic rather than table-driven). If the latter, I'll move the code you added outside the #if block it's currently in. Also, I believe you mentioned earlier (re: s2735 is totally broken) that you were seeing a weird reset in the raminit code. On my platform I was getting an exception during RCOMP configuration (Ram1.00), which I traced to the definition of RCOMP_MMIO as 0x100000. I think because that address lies below the default Top of Low Memory that accesses to that space weren't going to the RCOMP registers. Redefining RCOMP_MMIO as 0x80000000 fixed that problem for me. Regards, Steve Magnani www.digidescorp.com From ebiederman at lnxi.com Wed Jun 22 21:23:02 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed, 22 Jun 2005 13:23:02 -0600 Subject: [LinuxBIOS] Merge complete.... In-Reply-To: <1119463140.8134.6.camel@logarithm.lanl.gov> (Li-Ta Lo's message of "Wed, 22 Jun 2005 11:59:00 -0600") References: <1119462169.8134.3.camel@logarithm.lanl.gov> <1119463140.8134.6.camel@logarithm.lanl.gov> Message-ID: Li-Ta Lo writes: > Are these files reversed patch too? I think it is mostly node_link_to_bus and the like. I have a DK8S2 (I think) and there were some significant problems with that port. Removing HARD_RESET_BUS and the like. My change history isn't perfect but you have it all and that may help. The history of 2 parallel CVS trees what fun. It may be a good idea to get my act together and push out my main branch so you can see what pieces everything came in. Unfortunately there wasn't a true common reference until a couple of days ago. Just two parallel trees. So I think you will find on examination most of these changes are fairly sane, and not arbitrary code reversions. Eric From ebiederman at lnxi.com Wed Jun 22 21:26:23 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed, 22 Jun 2005 13:26:23 -0600 Subject: [LinuxBIOS] Merge complete.... In-Reply-To: <3174569B9743D511922F00A0C94314230AF96F2D@TYANWEB> (YhLu@tyan.com's message of "Wed, 22 Jun 2005 11:17:59 -0700") References: <3174569B9743D511922F00A0C94314230AF96F2D@TYANWEB> Message-ID: YhLu writes: > filo is removed too. Yes. I think if we are going to keep it we need a filo branch that can periodically sync. I'm really not comfortable with filo in there. > more generic support for pci-x, pci-e, ht, Eric, is it support HT-HT > bridge now? A HT-HT bridge should probably work. And if not the infrastructure is complete enough that it should be minor bug fixes to make it work. Yes there is auto-tuning for the all busses I know how to tune so we can get that code out of drivers and into the BIOS which should be current on the errata that affect a given board. > also > > diff -r freebios_lnxi/src/arch/i386/init/ldscript.lb > ../freebios2/src/arch/i386/init/ldscript.lb > 44,49d43 > < > < /* Move up the location counter if the start of the rom section is > < * too low. > < */ > < . = ( ( ( _ROMBASE + ROM_IMAGE_SIZE - 1 ) == 0xffffffff ) && ( . < > 0xffff0000 ) ) ? 0xffff0000 : . ; > < > there is some problem too. > for some 8 way opteron system with romcc > i need > linuxbios_ram > auto.inc ---- it is very big > entry32.inc --- _start is here > failover.inc > jmp auto.inc > out: > _main in crt0.S > > then you will push auto.inc into the top 64k too, but the 64k can not fit. > > So please merge that into main tree... I believe you are asking for a change. But I don't quite follow. Eric From ebiederman at lnxi.com Wed Jun 22 21:27:13 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed, 22 Jun 2005 13:27:13 -0600 Subject: [LinuxBIOS] Merge complete.... In-Reply-To: (Ronald G. Minnich's message of "Wed, 22 Jun 2005 12:20:46 -0600 (MDT)") References: <3174569B9743D511922F00A0C94314230AF96F2D@TYANWEB> Message-ID: "Ronald G. Minnich" writes: > On Wed, 22 Jun 2005, YhLu wrote: > >> So please merge that into main tree... > > > NOT YET! > > this merge is huge. Ollie is going through it bit by bit. We are not ready > to merge yet. > > Eric, please hold on for a while, Ollie will finish up his summary. For changes that are needed I suspect we will want to make them to the branch and then merge the branch. At least if we are doing much collaborating on getting it done. Eric From ebiederman at lnxi.com Wed Jun 22 21:29:14 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed, 22 Jun 2005 13:29:14 -0600 Subject: [LinuxBIOS] Merge complete.... In-Reply-To: <1119465297.8134.9.camel@logarithm.lanl.gov> (Li-Ta Lo's message of "Wed, 22 Jun 2005 12:34:57 -0600") References: <3174569B9743D511922F00A0C94314230AF96F33@TYANWEB> <1119465297.8134.9.camel@logarithm.lanl.gov> Message-ID: Li-Ta Lo writes: > On Wed, 2005-06-22 at 11:29 -0700, YhLu wrote: >> define HARD_RESET_BUS >> >> removed, Good, get amd8111 bus from config_bus_map... >> > > Eric, > > Is there any reason you put reset.c in every mainboard directory but > the only thing in these reset.c is #include "amd8111_reset.c" ? Because hard_reset() needs a per motherboard definition. hard_reset and a small handful of other routines are effectively motherboard methods, and if you have someone creative building hardware you can get into some ugly situations if you over generalize, and define them at the chipset level. What if you have 2 8111's? Eric From ebiederman at lnxi.com Wed Jun 22 21:30:45 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed, 22 Jun 2005 13:30:45 -0600 Subject: [LinuxBIOS] Merge complete.... In-Reply-To: <3174569B9743D511922F00A0C94314230AF96F44@TYANWEB> (YhLu@tyan.com's message of "Wed, 22 Jun 2005 11:53:04 -0700") References: <3174569B9743D511922F00A0C94314230AF96F44@TYANWEB> Message-ID: YhLu writes: > if(is_cpu_d0()) { > /* Erratum 110 ...*/ > msr = rdmsr_amd(CPU_ID_HYPER_EXT_FEATURES); > msr.hi |=1; > wrmsr_amd(CPU_ID_HYPER_EXT_FEATURES, msr); > } > > if (is_cpu_pre_e0()) { > /* Erratum 110 ... */ > msr = rdmsr_amd(CPU_ID_EXT_FEATURES_MSR); > msr.hi |=1; > wrmsr_amd(CPU_ID_EXT_FEATURES_MSR, msr); > } > > also in model_fxx_init.c you miss sth > should be > > if(is_cpu_d0()) { > /* Erratum 110 ...*/ > msr = rdmsr_amd(CPU_ID_HYPER_EXT_FEATURES); > msr.hi |=1; > wrmsr_amd(CPU_ID_HYPER_EXT_FEATURES, msr); > } > > if (!is_cpu_pre_e0()) { ------------------------------don't forget > ! > /* Erratum 110 ... */ > msr = rdmsr_amd(CPU_ID_EXT_FEATURES_MSR); > msr.hi |=1; > wrmsr_amd(CPU_ID_EXT_FEATURES_MSR, msr); > } Good catch. That was a recent case where I had to merge by hand I guess I was tired when I did that one. Eric From YhLu at tyan.com Wed Jun 22 21:33:56 2005 From: YhLu at tyan.com (YhLu) Date: Wed, 22 Jun 2005 12:33:56 -0700 Subject: [LinuxBIOS] Merge complete.... Message-ID: <3174569B9743D511922F00A0C94314230AF96F4B@TYANWEB> > > diff -r freebios_lnxi/src/arch/i386/init/ldscript.lb > > ../freebios2/src/arch/i386/init/ldscript.lb > > 44,49d43 > > < > > < /* Move up the location counter if the start of the > rom section is > > < * too low. > > < */ > > < . = ( ( ( _ROMBASE + ROM_IMAGE_SIZE - 1 ) == > 0xffffffff ) && ( . < > > 0xffff0000 ) ) ? 0xffff0000 : . ; > > < > > there is some problem too. > > for some 8 way opteron system with romcc i need > linuxbios_ram auto.inc > > ---- it is very big entry32.inc --- _start is here > failover.inc jmp > > auto.inc > > out: > > _main in crt0.S > > > > then you will push auto.inc into the top 64k too, but the > 64k can not fit. > > > > So please merge that into main tree... > > I believe you are asking for a change. But I don't quite follow. > > Eric > that is verified, and it is used for romcc with 8 ways opteron, at that case the auto.inc get very big, and it make _start too low, so i put auto.inc before _start, and use jmp to it and after it done, auto.inc will jmp to __main. YH From YhLu at tyan.com Wed Jun 22 21:53:54 2005 From: YhLu at tyan.com (YhLu) Date: Wed, 22 Jun 2005 12:53:54 -0700 Subject: [LinuxBIOS] Merge complete.... Message-ID: <3174569B9743D511922F00A0C94314230AF96F4C@TYANWEB> I suugest put node_link_to_bus to inconherent_ht.c YH From YhLu at tyan.com Thu Jun 23 00:39:58 2005 From: YhLu at tyan.com (YhLu) Date: Wed, 22 Jun 2005 15:39:58 -0700 Subject: [LinuxBIOS] Merge complete.... Message-ID: <3174569B9743D511922F00A0C94314230AF96F7D@TYANWEB> Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM DONE fixed MTRRs Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-16) Type: WB Setting fixed MTRRs(24-88) Type: WB DONE fixed MTRRs Setting variable MTRR 0, base: 0MB, range: 8192MB, type WB Setting variable MTRR 1, base: 8192MB, range: 1024MB, type WB Setting variable MTRR 2, base: 3072MB, range: 1024MB, type UC DONE variable MTRRs Clear out the extra MTRR's MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled Setting up local apic... apic_id: 0 done. i got two copy set fixed mtrr again. Eric, it is good you pass the address bits x86_setup_mtrrs. but for amd it is need to enable the fix mtrr mod enable bit in SYSCFG_MSR. ... amd_mtrr need some change ... YH > -----Original Message----- > From: YhLu > Sent: Wednesday, June 22, 2005 12:54 PM > To: ebiederman at lnxi.com > Cc: LinuxBIOS > Subject: RE: [LinuxBIOS] Merge complete.... > > I suugest put > node_link_to_bus > to inconherent_ht.c > > YH > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From YhLu at tyan.com Thu Jun 23 00:42:17 2005 From: YhLu at tyan.com (YhLu) Date: Wed, 22 Jun 2005 15:42:17 -0700 Subject: [LinuxBIOS] Merge complete.... Message-ID: <3174569B9743D511922F00A0C94314230AF96F7F@TYANWEB> or void x86_setup_mtrrs(unsigned address_bits) /* this routine needs to know how many address bits a given processor * supports. CPUs get grumpy when you set too many bits in * their mtrr registers :( I would generically call cpuid here * and find out how many physically supported but some cpus are * buggy, and report more bits then they actually support. */ { /* Try this the simple way of incrementally adding together * mtrrs. If this doesn't work out we can get smart again * and clear out the mtrrs. */ struct var_mtrr_state var_state; if(address_bits != 40) { ---------------------------------------- skip it for AMD printk_debug("\n"); /* Initialized the fixed_mtrrs to uncached */ printk_debug("Setting fixed MTRRs(%d-%d) type: UC\n", 0, NUM_FIXED_RANGES); set_fixed_mtrrs(0, NUM_FIXED_RANGES, MTRR_TYPE_UNCACHEABLE); /* Now see which of the fixed mtrrs cover ram. */ search_global_resources( IORESOURCE_MEM | IORESOURCE_CACHEABLE, IORESOURCE_MEM | IORESOURCE_CACHEABLE, set_fixed_mtrr_resource, NULL); printk_debug("DONE fixed MTRRs\n"); } From YhLu at tyan.com Thu Jun 23 01:06:40 2005 From: YhLu at tyan.com (YhLu) Date: Wed, 22 Jun 2005 16:06:40 -0700 Subject: [LinuxBIOS] Merge complete.... Message-ID: <3174569B9743D511922F00A0C94314230AF96F8C@TYANWEB> Eric, what's the purpose of the bus-> reset_needed? can you talk about reset_bus and scan_bus working sequence...? YH From YhLu at tyan.com Thu Jun 23 01:19:01 2005 From: YhLu at tyan.com (YhLu) Date: Wed, 22 Jun 2005 16:19:01 -0700 Subject: [LinuxBIOS] Merge complete.... Message-ID: <3174569B9743D511922F00A0C94314230AF96F90@TYANWEB> unsigned int scan_bus(device_t bus, unsigned int max) { unsigned int new_max; int do_scan_bus; if ( !bus || !bus->enabled || !bus->ops || !bus->ops->scan_bus) { return max; } do_scan_bus = 1; while(do_scan_bus) { int link; new_max = bus->ops->scan_bus(bus, max); do_scan_bus = 0; for(link = 0; link < bus->links; link++) { if (bus->link[link].reset_needed) { if (reset_bus(&bus->link[link])) { do_scan_bus = 1; } else { bus->bus->reset_needed = 1; } } } } return new_max; } suggest change bus to dev, otherwise is some confusing. YH From YhLu at tyan.com Thu Jun 23 01:44:05 2005 From: YhLu at tyan.com (YhLu) Date: Wed, 22 Jun 2005 16:44:05 -0700 Subject: [LinuxBIOS] Merge complete.... Message-ID: <3174569B9743D511922F00A0C94314230AF96FA3@TYANWEB> the code reset_bus and scan_bus seem quite neat. but do one simutation, it doesn't work. I set ht frq to 800Mhz in auto.c and reset that in hypertransport.c to 1GHz. it hangs after print out "Reseting board..." my hard_reset for ck804 doesn't work? hard_reset is suposed to work, because i can do restart and hardwaremain already call that...... YH From ebiederman at lnxi.com Thu Jun 23 02:26:15 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed, 22 Jun 2005 18:26:15 -0600 Subject: [LinuxBIOS] Merge complete.... In-Reply-To: <3174569B9743D511922F00A0C94314230AF96F8C@TYANWEB> (YhLu@tyan.com's message of "Wed, 22 Jun 2005 16:06:40 -0700") References: <3174569B9743D511922F00A0C94314230AF96F8C@TYANWEB> Message-ID: YhLu writes: > Eric, > > what's the purpose of the bus-> reset_needed? > > can you talk about reset_bus and scan_bus working sequence...? Some busses and especially hypertransport need a reset to for the new bus speed settings to take effect. Plus it resetting a bus is a fairly generally available bus capability. Eric From ebiederman at lnxi.com Thu Jun 23 02:28:49 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed, 22 Jun 2005 18:28:49 -0600 Subject: [LinuxBIOS] Merge complete.... In-Reply-To: <3174569B9743D511922F00A0C94314230AF96FA3@TYANWEB> (YhLu@tyan.com's message of "Wed, 22 Jun 2005 16:44:05 -0700") References: <3174569B9743D511922F00A0C94314230AF96FA3@TYANWEB> Message-ID: YhLu writes: > the code reset_bus and scan_bus seem quite neat. > > but do one simutation, it doesn't work. > > I set ht frq to 800Mhz in auto.c > and reset that in hypertransport.c to 1GHz. > > it hangs after print out "Reseting board..." And the nice thing you get at most one reset of the board everything will be setup and tuned first. > my hard_reset for ck804 doesn't work? > hard_reset is suposed to work, because i can do restart and hardwaremain > already call that...... Sounds like that is the problem. Quite possibly there is a bus number change somewhere messing things up. The other possibility is that there is some tuning problem and the board does not come back from the reset. Eric From YhLu at tyan.com Thu Jun 23 02:37:00 2005 From: YhLu at tyan.com (YhLu) Date: Wed, 22 Jun 2005 17:37:00 -0700 Subject: [LinuxBIOS] Merge complete.... Message-ID: <3174569B9743D511922F00A0C94314230AF96FBF@TYANWEB> ck804 is using cf9 to do reset, ......may be i lost the control of that port. YH > -----Original Message----- > From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] > Sent: Wednesday, June 22, 2005 5:29 PM > To: YhLu > Cc: 'LinuxBIOS' > Subject: Re: [LinuxBIOS] Merge complete.... > > YhLu writes: > > > the code reset_bus and scan_bus seem quite neat. > > > > but do one simutation, it doesn't work. > > > > I set ht frq to 800Mhz in auto.c > > and reset that in hypertransport.c to 1GHz. > > > > it hangs after print out "Reseting board..." > > And the nice thing you get at most one reset of the board > everything will be setup and tuned first. > > > my hard_reset for ck804 doesn't work? > > hard_reset is suposed to work, because i can do restart and > > hardwaremain already call that...... > > Sounds like that is the problem. Quite possibly there is a > bus number change somewhere messing things up. > > The other possibility is that there is some tuning problem > and the board does not come back from the reset. > > Eric > From YhLu at tyan.com Thu Jun 23 03:34:03 2005 From: YhLu at tyan.com (YhLu) Date: Wed, 22 Jun 2005 18:34:03 -0700 Subject: [LinuxBIOS] Merge complete.... Message-ID: <3174569B9743D511922F00A0C94314230AF96FCB@TYANWEB> 1. if not optimize the link in auto.c stage, and let hypertranport.c do the optimization, the hard_reset from reset_bus can works.... 2. if optimize the link in auto.c and hard_reset will be not called, and if call hard_reset from debug device....it works well. 3. if optimize the link in auto.c and reset freq to high value in hypertransport.c, the hard_reset from reset_bus will hang.... YH > -----Original Message----- > From: YhLu > Sent: Wednesday, June 22, 2005 5:37 PM > To: ebiederman at lnxi.com > Cc: 'LinuxBIOS' > Subject: RE: [LinuxBIOS] Merge complete.... > > ck804 is using cf9 to do reset, ......may be i lost the > control of that port. > > YH > > > -----Original Message----- > > From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] > > Sent: Wednesday, June 22, 2005 5:29 PM > > To: YhLu > > Cc: 'LinuxBIOS' > > Subject: Re: [LinuxBIOS] Merge complete.... > > > > YhLu writes: > > > > > the code reset_bus and scan_bus seem quite neat. > > > > > > but do one simutation, it doesn't work. > > > > > > I set ht frq to 800Mhz in auto.c > > > and reset that in hypertransport.c to 1GHz. > > > > > > it hangs after print out "Reseting board..." > > > > And the nice thing you get at most one reset of the board > everything > > will be setup and tuned first. > > > > > my hard_reset for ck804 doesn't work? > > > hard_reset is suposed to work, because i can do restart and > > > hardwaremain already call that...... > > > > Sounds like that is the problem. Quite possibly there is a > bus number > > change somewhere messing things up. > > > > The other possibility is that there is some tuning problem and the > > board does not come back from the reset. > > > > Eric > > > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From YhLu at tyan.com Thu Jun 23 03:42:19 2005 From: YhLu at tyan.com (YhLu) Date: Wed, 22 Jun 2005 18:42:19 -0700 Subject: [LinuxBIOS] Merge complete.... Message-ID: <3174569B9743D511922F00A0C94314230AF96FCF@TYANWEB> hard code in hyperstransport.c with bus->reset_needed = 1; //debug the hard_reset from reset_bus works well. maybe the ck804 don't allow us to do second optimize.....? I will forget about it. YH > -----Original Message----- > From: YhLu > Sent: Wednesday, June 22, 2005 6:34 PM > To: ebiederman at lnxi.com > Cc: 'LinuxBIOS' > Subject: RE: [LinuxBIOS] Merge complete.... > > 1. if not optimize the link in auto.c stage, and let > hypertranport.c do the optimization, the hard_reset from > reset_bus can works.... > 2. if optimize the link in auto.c and hard_reset will be not > called, and if call hard_reset from debug device....it works well. > 3. if optimize the link in auto.c and reset freq to high > value in hypertransport.c, the hard_reset from reset_bus will hang.... > > YH > > From Stephen.Kimball at bench.com Thu Jun 23 15:15:59 2005 From: Stephen.Kimball at bench.com (Stephen.Kimball at bench.com) Date: Thu, 23 Jun 2005 09:15:59 -0400 Subject: [LinuxBIOS] Merge complete.... Message-ID: <9B124F08B3EFDA4F8813B05102DC719503A40C81@nh-ex01.bench.com> YH, Looking at your hard_reset() in src/mainboard/tyan/s2895/auto.c src/nvidia/ck804/ck804_reset.c The two hard_reset's are different. I think one might be wrong. The one in auto.c writes a & e to cf9, that's a hard reset. The one in ck804_reset.c writes 2 and 6 to cf9, that's a soft reset. Also I'm not sure how you enable the cf9 port. I think you should write LPC:e8 in hard_reset() to be sure it's enabled. Also I noticed in the commercial BIOS's hard_reset they include a loop forever or JMP * or L1: go to L1 after the cf9 writes. Steve -----Original Message----- From: linuxbios-bounces at openbios.org [mailto:linuxbios-bounces at openbios.org] On Behalf Of YhLu Sent: Wednesday, June 22, 2005 8:37 PM To: ebiederman at lnxi.com Cc: 'LinuxBIOS' Subject: RE: [LinuxBIOS] Merge complete.... ck804 is using cf9 to do reset, ......may be i lost the control of that port. YH > -----Original Message----- > From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] > Sent: Wednesday, June 22, 2005 5:29 PM > To: YhLu > Cc: 'LinuxBIOS' > Subject: Re: [LinuxBIOS] Merge complete.... > > YhLu writes: > > > the code reset_bus and scan_bus seem quite neat. > > > > but do one simutation, it doesn't work. > > > > I set ht frq to 800Mhz in auto.c > > and reset that in hypertransport.c to 1GHz. > > > > it hangs after print out "Reseting board..." > > And the nice thing you get at most one reset of the board > everything will be setup and tuned first. > > > my hard_reset for ck804 doesn't work? > > hard_reset is suposed to work, because i can do restart and > > hardwaremain already call that...... > > Sounds like that is the problem. Quite possibly there is a > bus number change somewhere messing things up. > > The other possibility is that there is some tuning problem > and the board does not come back from the reset. > > Eric > _______________________________________________ LinuxBIOS mailing list LinuxBIOS at openbios.org http://www.openbios.org/mailman/listinfo/linuxbios From stepan at openbios.org Thu Jun 23 15:23:09 2005 From: stepan at openbios.org (Stefan Reinauer) Date: Thu, 23 Jun 2005 15:23:09 +0200 Subject: [LinuxBIOS] Merge complete.... In-Reply-To: <9B124F08B3EFDA4F8813B05102DC719503A40C81@nh-ex01.bench.com> References: <9B124F08B3EFDA4F8813B05102DC719503A40C81@nh-ex01.bench.com> Message-ID: <20050623132309.GA11734@openbios.org> * Stephen.Kimball at bench.com [050623 15:15]: > Looking at your hard_reset() in > src/mainboard/tyan/s2895/auto.c > src/nvidia/ck804/ck804_reset.c > The two hard_reset's are different. I think one might be wrong. The > one in auto.c writes a & e to cf9, that's a hard reset. The one in > ck804_reset.c writes 2 and 6 to cf9, that's a soft reset. Also I'm not > sure how you enable the cf9 port. I think you should write LPC:e8 in > hard_reset() to be sure it's enabled. 0xcf9 is indeed not enabled. This causes problems with reboot from Linux in some circumstances. (ie when using ACPI with an FADT) IIRC 0xcf9 needs to be enabled in devB:x41 register, set [D5]. Stefan From steve at digidescorp.com Thu Jun 23 15:47:36 2005 From: steve at digidescorp.com (Steven J. Magnani) Date: Thu, 23 Jun 2005 08:47:36 -0500 Subject: [LinuxBIOS] RE: E7501 raminit changes Message-ID: <001101c577fa$1d518be0$6ffea8c0@banana> A correction: I'm pretty sure now my RCOMP_MMIO problems were due to "A20 hell", not TOLM. Does anyone know if de-asserting A20M# is enough to cause A20 to behave normally? On our board, after we force A20M# high, the system continues to behave as if A20 is always zero. We're using an embedded board, so there is no keyboard controller in the mix - I/O port 0x92 is enough to toggle A20M#. Some of the Intel documentation mentions an "A20M# interrupt" in passing, but there are no specifics. Is there something else that firmware needs to do after driving A20M# high? Color me confused, Steve -----Original Message----- From: Steven J. Magnani [mailto:steve at digidescorp.com] Sent: Wednesday, June 22, 2005 1:20 PM To: 'linuxbios at openbios.org' Subject: E7501 raminit changes Yh Lu, I noticed that you added code to the E7501 raminit to change the mapping between system bus and southbridge stop grants from the default of 1:1 to 2:1 when the file is compiled with CAS_LATENCY defined to CAS_2_0. Is the stop grant change needed only for CL 2.0, or should it be applied to both 2.0 and 2.5? If the former, I'll put it in the function that configures the CAS latency based on SPD info (i.e. make the configuration change programmatic rather than table-driven). If the latter, I'll move the code you added outside the #if block it's currently in. Also, I believe you mentioned earlier (re: s2735 is totally broken) that you were seeing a weird reset in the raminit code. On my platform I was getting an exception during RCOMP configuration (Ram1.00), which I traced to the definition of RCOMP_MMIO as 0x100000. I think because that address lies below the default Top of Low Memory that accesses to that space weren't going to the RCOMP registers. Redefining RCOMP_MMIO as 0x80000000 fixed that problem for me. Regards, Steve Magnani www.digidescorp.com From yinghailu at gmail.com Thu Jun 23 17:30:16 2005 From: yinghailu at gmail.com (yhlu) Date: Thu, 23 Jun 2005 08:30:16 -0700 Subject: [LinuxBIOS] Merge complete.... In-Reply-To: <9B124F08B3EFDA4F8813B05102DC719503A40C81@nh-ex01.bench.com> References: <9B124F08B3EFDA4F8813B05102DC719503A40C81@nh-ex01.bench.com> Message-ID: <2ea3fae105062308306a760a34@mail.gmail.com> stephen, that's right. in auto.c stage, the hard reset is real one it will reset pci space and ht (freq/width). the soft reset will keep the ht (freq/width). the hard_reset is called when ram init exception. in the linuxbios_ram stage totally in c ( from hardwaremain, or the root_reset_bus) is actually a soft reset, it will keep the ht (freq/width) the problem i met is problem ck804 doesn't reconfig ht two times. YH On 6/23/05, Stephen.Kimball at bench.com wrote: > YH, > > Looking at your hard_reset() in > src/mainboard/tyan/s2895/auto.c > src/nvidia/ck804/ck804_reset.c > The two hard_reset's are different. I think one might be wrong. The > one in auto.c writes a & e to cf9, that's a hard reset. The one in > ck804_reset.c writes 2 and 6 to cf9, that's a soft reset. Also I'm not > sure how you enable the cf9 port. I think you should write LPC:e8 in > hard_reset() to be sure it's enabled. > > Also I noticed in the commercial BIOS's hard_reset they include a loop > forever or JMP * or L1: go to L1 after the cf9 writes. > > Steve > > -----Original Message----- > From: linuxbios-bounces at openbios.org > [mailto:linuxbios-bounces at openbios.org] On Behalf Of YhLu > Sent: Wednesday, June 22, 2005 8:37 PM > To: ebiederman at lnxi.com > Cc: 'LinuxBIOS' > Subject: RE: [LinuxBIOS] Merge complete.... > > ck804 is using cf9 to do reset, ......may be i lost the control of that > port. > > YH > > > -----Original Message----- > > From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] > > Sent: Wednesday, June 22, 2005 5:29 PM > > To: YhLu > > Cc: 'LinuxBIOS' > > Subject: Re: [LinuxBIOS] Merge complete.... > > > > YhLu writes: > > > > > the code reset_bus and scan_bus seem quite neat. > > > > > > but do one simutation, it doesn't work. > > > > > > I set ht frq to 800Mhz in auto.c > > > and reset that in hypertransport.c to 1GHz. > > > > > > it hangs after print out "Reseting board..." > > > > And the nice thing you get at most one reset of the board > > everything will be setup and tuned first. > > > > > my hard_reset for ck804 doesn't work? > > > hard_reset is suposed to work, because i can do restart and > > > hardwaremain already call that...... > > > > Sounds like that is the problem. Quite possibly there is a > > bus number change somewhere messing things up. > > > > The other possibility is that there is some tuning problem > > and the board does not come back from the reset. > > > > Eric > > > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From yinghailu at gmail.com Thu Jun 23 17:31:53 2005 From: yinghailu at gmail.com (yhlu) Date: Thu, 23 Jun 2005 08:31:53 -0700 Subject: [LinuxBIOS] RE: E7501 raminit changes In-Reply-To: <001101c577fa$1d518be0$6ffea8c0@banana> References: <001101c577fa$1d518be0$6ffea8c0@banana> Message-ID: <2ea3fae105062308315ca8a092@mail.gmail.com> steven, Please feel free to try it, and send out your patch to us. YH On 6/23/05, Steven J. Magnani wrote: > A correction: I'm pretty sure now my RCOMP_MMIO problems were due to > "A20 hell", not TOLM. > > Does anyone know if de-asserting A20M# is enough to cause A20 to behave > normally? On our board, after we force A20M# high, the system continues > to behave as if A20 is always zero. We're using an embedded board, so > there is no keyboard controller in the mix - I/O port 0x92 is enough to > toggle A20M#. > > Some of the Intel documentation mentions an "A20M# interrupt" in > passing, but there are no specifics. Is there something else that > firmware needs to do after driving A20M# high? > > Color me confused, > > Steve > > > -----Original Message----- > From: Steven J. Magnani [mailto:steve at digidescorp.com] > Sent: Wednesday, June 22, 2005 1:20 PM > To: 'linuxbios at openbios.org' > Subject: E7501 raminit changes > > > Yh Lu, > > I noticed that you added code to the E7501 raminit to change the mapping > between system bus and southbridge stop grants from the default of 1:1 > to 2:1 when the file is compiled with CAS_LATENCY defined to CAS_2_0. > > Is the stop grant change needed only for CL 2.0, or should it be applied > to both 2.0 and 2.5? If the former, I'll put it in the function that > configures the CAS latency based on SPD info (i.e. make the > configuration change programmatic rather than table-driven). If the > latter, I'll move the code you added outside the #if block it's > currently in. > > Also, I believe you mentioned earlier (re: s2735 is totally broken) that > you were seeing a weird reset in the raminit code. On my platform I was > getting an exception during RCOMP configuration (Ram1.00), which I > traced to the definition of RCOMP_MMIO as 0x100000. I think because that > address lies below the default Top of Low Memory that accesses to that > space weren't going to the RCOMP registers. Redefining RCOMP_MMIO as > 0x80000000 fixed that problem for me. > > Regards, > Steve Magnani > www.digidescorp.com > > > > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From Stephen.Kimball at bench.com Thu Jun 23 18:03:22 2005 From: Stephen.Kimball at bench.com (Stephen.Kimball at bench.com) Date: Thu, 23 Jun 2005 12:03:22 -0400 Subject: [LinuxBIOS] Merge complete.... Message-ID: <9B124F08B3EFDA4F8813B05102DC719503A40C82@nh-ex01.bench.com> OK. Maybe I'm the only one confused but why should the hard_reset called from hardwaremain in C really do a soft reset. Wouldn't it be better to call it soft_reset? Or maybe comment the code if hard_reset needs to do a soft reset? And your sure the cf9 port is enabled? Right? Steve -----Original Message----- From: yhlu [mailto:yinghailu at gmail.com] Sent: Thursday, June 23, 2005 11:30 AM To: Kimball, Stephen Cc: YhLu at tyan.com; linuxbios at openbios.org Subject: Re: [LinuxBIOS] Merge complete.... stephen, that's right. in auto.c stage, the hard reset is real one it will reset pci space and ht (freq/width). the soft reset will keep the ht (freq/width). the hard_reset is called when ram init exception. in the linuxbios_ram stage totally in c ( from hardwaremain, or the root_reset_bus) is actually a soft reset, it will keep the ht (freq/width) the problem i met is problem ck804 doesn't reconfig ht two times. YH From yinghailu at gmail.com Thu Jun 23 18:25:35 2005 From: yinghailu at gmail.com (yhlu) Date: Thu, 23 Jun 2005 09:25:35 -0700 Subject: [LinuxBIOS] Merge complete.... In-Reply-To: <9B124F08B3EFDA4F8813B05102DC719503A40C82@nh-ex01.bench.com> References: <9B124F08B3EFDA4F8813B05102DC719503A40C82@nh-ex01.bench.com> Message-ID: <2ea3fae105062309255b4f57fe@mail.gmail.com> for AMD platform, if we do hard_reset, then will do another soft reset in auto.c stage to make ht (freq/width) effective. ck804 the cf9 is default enabled. We don't need to bother to enable it. there is comment in ck804_reset.c, but i guess that is removed when someone reiviewd my code. YH On 6/23/05, Stephen.Kimball at bench.com wrote: > > OK. Maybe I'm the only one confused but why should the hard_reset called > from hardwaremain in C really do a soft reset. Wouldn't it be better to > call it soft_reset? Or maybe comment the code if hard_reset needs to do > a soft reset? And your sure the cf9 port is enabled? Right? > > Steve > > -----Original Message----- > From: yhlu [mailto:yinghailu at gmail.com] > Sent: Thursday, June 23, 2005 11:30 AM > To: Kimball, Stephen > Cc: YhLu at tyan.com; linuxbios at openbios.org > Subject: Re: [LinuxBIOS] Merge complete.... > > stephen, > > that's right. > > in auto.c stage, the hard reset is real one it will reset pci space > and ht (freq/width). > the soft reset will keep the ht (freq/width). the hard_reset is called > when ram init exception. > > in the linuxbios_ram stage totally in c ( from hardwaremain, or the > root_reset_bus) is actually a soft reset, it will keep the ht > (freq/width) > > the problem i met is problem ck804 doesn't reconfig ht two times. > > YH > From steve at digidescorp.com Thu Jun 23 22:33:45 2005 From: steve at digidescorp.com (Steven J. Magnani) Date: Thu, 23 Jun 2005 15:33:45 -0500 Subject: [LinuxBIOS] RE: E7501 raminit changes Message-ID: <002801c57832$da5d6960$6ffea8c0@banana> >Does anyone know if de-asserting A20M# is enough to cause A20 to behave >normally? On our board, after we force A20M# high, the system continues to >behave as if A20 is always zero. We're using an embedded board, so there is no >keyboard controller in the mix - I/O port 0x92 is enough to toggle A20M#. A note for the record. It appears to be a feature of the Xeon that a change in A20M# doesn't take effect until after the processor steps forward at least one instruction. So if you use an emulator to stop the processor and toggle A20M#, you won't see any change in memory behavior until you step through the next instruction. Doh! Steve From steve at digidescorp.com Fri Jun 24 12:14:43 2005 From: steve at digidescorp.com (Steve Magnani) Date: Fri, 24 Jun 2005 05:14:43 -0500 Subject: [LinuxBIOS] RE: E7501 raminit changes In-Reply-To: <2ea3fae105062308315ca8a092@mail.gmail.com> References: <001101c577fa$1d518be0$6ffea8c0@banana> <2ea3fae105062308315ca8a092@mail.gmail.com> Message-ID: From: yhlu > Please feel free to try it, and send out your patch to us. Yh Lu, Without knowing _why_ you added the stop grant configuration, I can't tell whether it is something that needs to happen all the time, needs to happen only when the system is to run at CL 2.0, or doesn't really need to happen at all. All I know is that my board seems to run OK at CL 2.0 without changing the default stop grant ratio. If there's any insight you can provide, I would have a better idea how to merge this into the reworked E7501 code. Thanks, Steve From YhLu at tyan.com Fri Jun 24 19:45:26 2005 From: YhLu at tyan.com (YhLu) Date: Fri, 24 Jun 2005 10:45:26 -0700 Subject: [LinuxBIOS] more safe stack in ram for cache_as_ram Message-ID: <3174569B9743D511922F00A0C94314230AF97102@TYANWEB> just committed some change for cache_as_ram in every cache_as_ram_auto.c __asm__ volatile ( /* set new esp */ /* before _RAMBASE */ "movl %0, %%ebp\n\t" "movl %0, %%esp\n\t" ::"a"( _RAMBASE -4 ) ); ====> __asm__ volatile ( /* set new esp */ /* before _RAMBASE */ "subl %0, %%ebp\n\t" "subl %0, %%esp\n\t" ::"a"( (DCACHE_RAM_BASE + DCACHE_RAM_SIZE)- _RAMBASE ) ); YH From liutao1980 at gmail.com Mon Jun 27 05:47:34 2005 From: liutao1980 at gmail.com (Tao Liu) Date: Mon, 27 Jun 2005 11:47:34 +0800 Subject: [LinuxBIOS] Linuxbios is always 421bytes larger than allowed Message-ID: <8eca059b0506262047248353e4@mail.gmail.com> Hello, I updated the code to try amd64's cache_as_ram feature, and during making got the error: ./buildrom linuxbios.strip linuxbios.rom ../../../payloads/eb_8111_filo.zelf 0x17800 0x40000 linuxbios image is 96677 bytes; only 96256 allowed Linuxbios input file larger than allowed size! if I enlarge the ROM_IMAGE_SIZE in Options.lb, the linuxbios image enlarges also, and is always 421bytes larger than ROM_IMAGE_SIZE. Are there some misconfigures for linking the linuxbios image? Regards, Liu Tao From yinghailu at gmail.com Mon Jun 27 06:01:02 2005 From: yinghailu at gmail.com (yhlu) Date: Sun, 26 Jun 2005 21:01:02 -0700 Subject: [LinuxBIOS] Linuxbios is always 421bytes larger than allowed In-Reply-To: <8eca059b0506262047248353e4@mail.gmail.com> References: <8eca059b0506262047248353e4@mail.gmail.com> Message-ID: <2ea3fae105062621014a394ee@mail.gmail.com> I can not tell if you don't post your MB Config.lb To use cache_as_ram you need to update your MB Config.lb and Option.lb and have your new cache_as_ram_auto.c YH On 6/26/05, Tao Liu wrote: > Hello, > > I updated the code to try amd64's cache_as_ram feature, and during > making got the error: > > ./buildrom linuxbios.strip linuxbios.rom > ../../../payloads/eb_8111_filo.zelf 0x17800 0x40000 > linuxbios image is 96677 bytes; only 96256 allowed > Linuxbios input file larger than allowed size! > > if I enlarge the ROM_IMAGE_SIZE in Options.lb, the linuxbios image > enlarges also, > and is always 421bytes larger than ROM_IMAGE_SIZE. Are there some misconfigures > for linking the linuxbios image? > > Regards, > Liu Tao > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From liutao1980 at gmail.com Mon Jun 27 08:54:37 2005 From: liutao1980 at gmail.com (Tao Liu) Date: Mon, 27 Jun 2005 14:54:37 +0800 Subject: [LinuxBIOS] Re: Linuxbios is always 421bytes larger than allowed In-Reply-To: <8eca059b05062621117551c588@mail.gmail.com> References: <8eca059b0506262047248353e4@mail.gmail.com> <2ea3fae105062621014a394ee@mail.gmail.com> <8eca059b05062621117551c588@mail.gmail.com> Message-ID: <8eca059b050626235431cd0cfc@mail.gmail.com> On 6/27/05, yhlu wrote: > I can not tell if you don't post your MB Config.lb > > To use cache_as_ram you need to update your MB Config.lb and Option.lb > and have your new cache_as_ram_auto.c I referenced tyan s2885 codes to modify my Config.lb, Options.lb and cache_as_ram_auto.c I just tried to build tyan s2885 images form a clean updated tree and met the same problem. Regards, Liu Tao -------------- next part -------------- A non-text attachment was scrubbed... Name: Config.lb Type: application/octet-stream Size: 7922 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Options.lb Type: application/octet-stream Size: 5544 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Config.lb Type: application/octet-stream Size: 714 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cache_as_ram_auto.c Type: text/x-c Size: 11687 bytes Desc: not available URL: From huangjen.wang at gmail.com Mon Jun 27 11:11:06 2005 From: huangjen.wang at gmail.com (Huang-Jen Wang) Date: Mon, 27 Jun 2005 17:11:06 +0800 Subject: [LinuxBIOS] post code stop in "10".... Message-ID: <4325815c050627021124a5faef@mail.gmail.com> Dear all, I build a rom , but it can't work, I attach a serial console, display nothing, therefore I use post card, it display post code "10", I trace the code , I found it maybe stop in src/cpu/x86/32bit/entry32.inc line 53 I am confused, the part of code , I didn't modified, why it has error? Does it related other files? From steve at digidescorp.com Mon Jun 27 17:17:25 2005 From: steve at digidescorp.com (Steve Magnani) Date: Mon, 27 Jun 2005 10:17:25 -0500 Subject: [LinuxBIOS] Re: Linuxbios is always 421bytes larger than allowed Message-ID: I ran into something like this not long ago. It might be that _start is too far away from the top of memory. Try editing src/cpu/x86/16bit/reset16.lds and change this: _ROMTOP = (_start >= 0xffff0000) ? 0xfffffff0 : 0xffffffff8; to this: _ROMTOP = (_start >= 0xffff0000) ? 0xfffffff0 : 0xffffffff0; Then re-build. If it builds successfully, that's the problem, and you'll have to juggle your code or reduce it so that _start ends up at 0xFFFF0000 or greater. On an editorial note, it's nice that the build system catches this problem, but I really wish it did it in a way that made it more obvious what the problem is. Steve From rminnich at lanl.gov Mon Jun 27 17:30:34 2005 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Mon, 27 Jun 2005 09:30:34 -0600 (MDT) Subject: [LinuxBIOS] Re: Linuxbios is always 421bytes larger than allowed In-Reply-To: References: Message-ID: On Mon, 27 Jun 2005, Steve Magnani wrote: > On an editorial note, it's nice that the build system catches this > problem, but I really wish it did it in a way that made it more obvious > what the problem is. you are absolutely right. This is on a list of things we are fixing this summer. ron From yinghailu at gmail.com Mon Jun 27 19:12:22 2005 From: yinghailu at gmail.com (yhlu) Date: Mon, 27 Jun 2005 10:12:22 -0700 Subject: [LinuxBIOS] Re: Linuxbios is always 421bytes larger than allowed In-Reply-To: <8eca059b050626235431cd0cfc@mail.gmail.com> References: <8eca059b0506262047248353e4@mail.gmail.com> <2ea3fae105062621014a394ee@mail.gmail.com> <8eca059b05062621117551c588@mail.gmail.com> <8eca059b050626235431cd0cfc@mail.gmail.com> Message-ID: <2ea3fae105062710122079bd56@mail.gmail.com> Please try to reduce the ROM_IMAGE_SIZE to 0x13000 YH On 6/26/05, Tao Liu wrote: > On 6/27/05, yhlu wrote: > > I can not tell if you don't post your MB Config.lb > > > > To use cache_as_ram you need to update your MB Config.lb and Option.lb > > and have your new cache_as_ram_auto.c > > I referenced tyan s2885 codes to modify my Config.lb, Options.lb and > cache_as_ram_auto.c > I just tried to build tyan s2885 images form a clean updated tree and > met the same problem. > > Regards, > Liu Tao > > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > > > From yinghailu at gmail.com Mon Jun 27 19:32:16 2005 From: yinghailu at gmail.com (yhlu) Date: Mon, 27 Jun 2005 10:32:16 -0700 Subject: [LinuxBIOS] Re: Linuxbios is always 421bytes larger than allowed In-Reply-To: References: Message-ID: <2ea3fae1050627103213775fc9@mail.gmail.com> There is two case 1. auto.inc create by romcc is very big (because no call in romcc allowed), So entry32.inc+fallback.inc+auto.inc+c_start.S will be bigger than 64k, the _start in entry32.inc will lower than 0xffff0000, that is not allowd because some SB only allow 64k in ROM can be accessed. 2. Current linuxbios_ram.rom + linuxbios_rom.rom could be greater 0x64k, some time if you set ROM_IMAGE_SIZE too big, and linuxbios_ram.rom is not bigger enough, it will _start in entry32.inc lower than 0xffff0000. That is more easy happen when you are trying to enable VGA CONSOLE so increase the value, but when you disable that and forget change ROM_IMAGE_SIZE back. Solution will be for 2. Eric added one line in ldsripts.lds to force linuxbios_rom.rom start only from 0xffff0000, if the ROM_IMAGE_SIZE is set to big. for 1. esp for four way and 8 way system, my solution is auto.inc+(jmp to c_start.s)+entry32.inc+fallback.inc+(jmp to auto.c)+c_start.S So we can keep _start in entry32.inc still high than 0xffff0000. and fallback.inc will enable the 4M space from ROM access. You can not together 1 with 2 solution. Fortunely, when using cache_as_ram, even enable every debug info and in 8 way system, the entry32.inc+auto.c+c_start.s (inc mode) and init mode will never be great than 64k bytes. So we can put eric's line in ldsscript.lds. but if someone still like romcc for four way and 8 way system you need to remove that line. Hope it is clear enough. YH On 6/27/05, Ronald G. Minnich wrote: > > > On Mon, 27 Jun 2005, Steve Magnani wrote: > > > On an editorial note, it's nice that the build system catches this > > problem, but I really wish it did it in a way that made it more obvious > > what the problem is. > > you are absolutely right. This is on a list of things we are fixing this > summer. > > ron > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From yinghailu at gmail.com Mon Jun 27 19:55:53 2005 From: yinghailu at gmail.com (yhlu) Date: Mon, 27 Jun 2005 10:55:53 -0700 Subject: [LinuxBIOS] Re: Linuxbios is always 421bytes larger than allowed In-Reply-To: <2ea3fae1050627103213775fc9@mail.gmail.com> References: <2ea3fae1050627103213775fc9@mail.gmail.com> Message-ID: <2ea3fae1050627105535af7426@mail.gmail.com> eric's line is diff -r freebios_lnxi/src/arch/i386/init/ldscript.lb ../freebios2/src/arch/i386/init/ldscript.lb 45,49d44 < /* Move up the location counter if the start of the rom section is < * too low. < */ < . = ( ( ( _ROMBASE + ROM_IMAGE_SIZE - 1 ) == 0xffffffff ) && ( . < 0xffff0000 ) ) ? 0xffff0000 : . ; < On 6/27/05, yhlu wrote: > There is two case > 1. auto.inc create by romcc is very big (because no call in romcc allowed), So > entry32.inc+fallback.inc+auto.inc+c_start.S will be bigger than > 64k, the _start in entry32.inc will lower than 0xffff0000, that is not > allowd because some SB only allow 64k in ROM can be accessed. > 2. Current linuxbios_ram.rom + linuxbios_rom.rom could be greater > 0x64k, some time if you set ROM_IMAGE_SIZE too big, and > linuxbios_ram.rom is not bigger enough, it will _start in entry32.inc > lower than 0xffff0000. That is more easy happen when you are trying to > enable VGA CONSOLE so increase the value, but when you disable that > and forget change ROM_IMAGE_SIZE back. > > Solution will be > for 2. Eric added one line in ldsripts.lds to force linuxbios_rom.rom > start only from 0xffff0000, if the ROM_IMAGE_SIZE is set to big. > > for 1. esp for four way and 8 way system, my solution is > auto.inc+(jmp to c_start.s)+entry32.inc+fallback.inc+(jmp to auto.c)+c_start.S > So we can keep _start in entry32.inc still high than 0xffff0000. and > fallback.inc will enable the 4M space from ROM access. > You can not together 1 with 2 solution. > > Fortunely, when using cache_as_ram, even enable every debug info and > in 8 way system, the entry32.inc+auto.c+c_start.s (inc mode) and init > mode will never be great than 64k bytes. So we can put eric's line in > ldsscript.lds. > but if someone still like romcc for four way and 8 way system you need > to remove that line. > > Hope it is clear enough. > > YH > > > > On 6/27/05, Ronald G. Minnich wrote: > > > > > > On Mon, 27 Jun 2005, Steve Magnani wrote: > > > > > On an editorial note, it's nice that the build system catches this > > > problem, but I really wish it did it in a way that made it more obvious > > > what the problem is. > > > > you are absolutely right. This is on a list of things we are fixing this > > summer. > > > > ron > > > > _______________________________________________ > > LinuxBIOS mailing list > > LinuxBIOS at openbios.org > > http://www.openbios.org/mailman/listinfo/linuxbios > > > From yinghailu at gmail.com Mon Jun 27 19:59:38 2005 From: yinghailu at gmail.com (yhlu) Date: Mon, 27 Jun 2005 10:59:38 -0700 Subject: [LinuxBIOS] Re: Linuxbios is always 421bytes larger than allowed In-Reply-To: <2ea3fae1050627105535af7426@mail.gmail.com> References: <2ea3fae1050627103213775fc9@mail.gmail.com> <2ea3fae1050627105535af7426@mail.gmail.com> Message-ID: <2ea3fae10506271059cfe91a5@mail.gmail.com> eric line in reset16.lds diff -r freebios_lnxi/src/cpu/x86/16bit/reset16.lds ../freebios2/src/cpu/x86/16bit/reset16.lds 8,9c8 < _bogus = ASSERT(_start >= 0xffff0000, "_start to low please decrease ROM_IMAGE_SIZE"); < _ROMTOP = 0xfffffff0; --- > _ROMTOP = (_start >= 0xffff0000) ? 0xfffffff0 : 0xfffffff8; So i suggest we put the line in reset16.lds and dont accept the line in ldscript.lb YH On 6/27/05, yhlu wrote: > eric's line is > > diff -r freebios_lnxi/src/arch/i386/init/ldscript.lb > ../freebios2/src/arch/i386/init/ldscript.lb > 45,49d44 > < /* Move up the location counter if the start of the rom section is > < * too low. > < */ > < . = ( ( ( _ROMBASE + ROM_IMAGE_SIZE - 1 ) == 0xffffffff ) && > ( . < 0xffff0000 ) ) ? 0xffff0000 : . ; > < > > On 6/27/05, yhlu wrote: > > There is two case > > 1. auto.inc create by romcc is very big (because no call in romcc allowed), So > > entry32.inc+fallback.inc+auto.inc+c_start.S will be bigger than > > 64k, the _start in entry32.inc will lower than 0xffff0000, that is not > > allowd because some SB only allow 64k in ROM can be accessed. > > 2. Current linuxbios_ram.rom + linuxbios_rom.rom could be greater > > 0x64k, some time if you set ROM_IMAGE_SIZE too big, and > > linuxbios_ram.rom is not bigger enough, it will _start in entry32.inc > > lower than 0xffff0000. That is more easy happen when you are trying to > > enable VGA CONSOLE so increase the value, but when you disable that > > and forget change ROM_IMAGE_SIZE back. > > > > Solution will be > > for 2. Eric added one line in ldsripts.lds to force linuxbios_rom.rom > > start only from 0xffff0000, if the ROM_IMAGE_SIZE is set to big. > > > > for 1. esp for four way and 8 way system, my solution is > > auto.inc+(jmp to c_start.s)+entry32.inc+fallback.inc+(jmp to auto.c)+c_start.S > > So we can keep _start in entry32.inc still high than 0xffff0000. and > > fallback.inc will enable the 4M space from ROM access. > > You can not together 1 with 2 solution. > > > > Fortunely, when using cache_as_ram, even enable every debug info and > > in 8 way system, the entry32.inc+auto.c+c_start.s (inc mode) and init > > mode will never be great than 64k bytes. So we can put eric's line in > > ldsscript.lds. > > but if someone still like romcc for four way and 8 way system you need > > to remove that line. > > > > Hope it is clear enough. > > > > YH > > > > > > > > On 6/27/05, Ronald G. Minnich wrote: > > > > > > > > > On Mon, 27 Jun 2005, Steve Magnani wrote: > > > > > > > On an editorial note, it's nice that the build system catches this > > > > problem, but I really wish it did it in a way that made it more obvious > > > > what the problem is. > > > > > > you are absolutely right. This is on a list of things we are fixing this > > > summer. > > > > > > ron > > > > > > _______________________________________________ > > > LinuxBIOS mailing list > > > LinuxBIOS at openbios.org > > > http://www.openbios.org/mailman/listinfo/linuxbios > > > > > > From rminnich at lanl.gov Mon Jun 27 20:03:28 2005 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Mon, 27 Jun 2005 12:03:28 -0600 (MDT) Subject: [LinuxBIOS] Re: Linuxbios is always 421bytes larger than allowed In-Reply-To: <2ea3fae10506271059cfe91a5@mail.gmail.com> References: <2ea3fae1050627103213775fc9@mail.gmail.com> <2ea3fae1050627105535af7426@mail.gmail.com> <2ea3fae10506271059cfe91a5@mail.gmail.com> Message-ID: On Mon, 27 Jun 2005, yhlu wrote: > eric line in reset16.lds > diff -r freebios_lnxi/src/cpu/x86/16bit/reset16.lds > ../freebios2/src/cpu/x86/16bit/reset16.lds > 8,9c8 > < _bogus = ASSERT(_start >= 0xffff0000, "_start to low please > decrease ROM_IMAGE_SIZE"); > < _ROMTOP = 0xfffffff0; > --- > > _ROMTOP = (_start >= 0xffff0000) ? 0xfffffff0 : 0xfffffff8; > > So i suggest we put the line in reset16.lds and dont accept the line > in ldscript.lb at best this is a temporary fix. Putting computations into the ldscript is going to cause us trouble later. ron From yinghailu at gmail.com Mon Jun 27 20:25:48 2005 From: yinghailu at gmail.com (yhlu) Date: Mon, 27 Jun 2005 11:25:48 -0700 Subject: [LinuxBIOS] Re: Linuxbios is always 421bytes larger than allowed In-Reply-To: References: <2ea3fae1050627103213775fc9@mail.gmail.com> <2ea3fae1050627105535af7426@mail.gmail.com> <2ea3fae10506271059cfe91a5@mail.gmail.com> Message-ID: <2ea3fae1050627112534b72fb0@mail.gmail.com> long term solution will depend still using romcc for 4 way and 8 way Opteron system?, if we are using cache_as_ram we don't have a chance to make entry32.inc+auto.inc+crt0.S bigger than 64K. or we reorginze the map to linuxbios_ram auto.inc -->init section ----> it will jmp to linuxbios_ram entry32.inc+fallback.inc----> it will call real_main at last problem is to make use gcc to produce auto.inc and avoid the duplicate Label problm, i already merge auto.c and failback.c into cache_as_ram.c YH On 6/27/05, Ronald G. Minnich wrote: > > > On Mon, 27 Jun 2005, yhlu wrote: > > > eric line in reset16.lds > > diff -r freebios_lnxi/src/cpu/x86/16bit/reset16.lds > > ../freebios2/src/cpu/x86/16bit/reset16.lds > > 8,9c8 > > < _bogus = ASSERT(_start >= 0xffff0000, "_start to low please > > decrease ROM_IMAGE_SIZE"); > > < _ROMTOP = 0xfffffff0; > > --- > > > _ROMTOP = (_start >= 0xffff0000) ? 0xfffffff0 : 0xfffffff8; > > > > So i suggest we put the line in reset16.lds and dont accept the line > > in ldscript.lb > > at best this is a temporary fix. Putting computations into the ldscript is > going to cause us trouble later. > > ron > From ebiederman at lnxi.com Mon Jun 27 21:50:14 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Mon, 27 Jun 2005 13:50:14 -0600 Subject: [BULK] Re: [LinuxBIOS] Re: Linuxbios is always 421bytes larger than allowed In-Reply-To: (Ronald G. Minnich's message of "Mon, 27 Jun 2005 12:03:28 -0600 (MDT)") References: <2ea3fae1050627103213775fc9@mail.gmail.com> <2ea3fae1050627105535af7426@mail.gmail.com> <2ea3fae10506271059cfe91a5@mail.gmail.com> Message-ID: "Ronald G. Minnich" writes: > On Mon, 27 Jun 2005, yhlu wrote: > >> eric line in reset16.lds >> diff -r freebios_lnxi/src/cpu/x86/16bit/reset16.lds >> ../freebios2/src/cpu/x86/16bit/reset16.lds >> 8,9c8 >> < _bogus = ASSERT(_start >= 0xffff0000, "_start to low please >> decrease ROM_IMAGE_SIZE"); >> < _ROMTOP = 0xfffffff0; >> --- >> > _ROMTOP = (_start >= 0xffff0000) ? 0xfffffff0 : 0xfffffff8; >> >> So i suggest we put the line in reset16.lds and dont accept the line >> in ldscript.lb > > at best this is a temporary fix. Putting computations into the ldscript is > going to cause us trouble later. Ron it sounds like you have an idea in mind, could you elaborate. Currently all I am computing are things that the linker needs to deal with. The selection of addresses of specific files. The ASSERT is especially useful as it turns a very mysterious error message into something readable and comprehensible. It is weird that you have to assign ASSERT to a variable to have the declaration work in nested linker scripts but hey it works. Eric From liutao1980 at gmail.com Tue Jun 28 06:13:39 2005 From: liutao1980 at gmail.com (Tao Liu) Date: Tue, 28 Jun 2005 12:13:39 +0800 Subject: [LinuxBIOS] Re: Linuxbios is always 421bytes larger than allowed In-Reply-To: <2ea3fae105062710122079bd56@mail.gmail.com> References: <8eca059b0506262047248353e4@mail.gmail.com> <2ea3fae105062621014a394ee@mail.gmail.com> <8eca059b05062621117551c588@mail.gmail.com> <8eca059b050626235431cd0cfc@mail.gmail.com> <2ea3fae105062710122079bd56@mail.gmail.com> Message-ID: <8eca059b05062721133d9a92e1@mail.gmail.com> On 6/28/05, yhlu wrote: > Please try to reduce the ROM_IMAGE_SIZE to 0x13000 > > YH I set ROM_IMAGE_SIZE to 0x13000 and still got the 421bytes error. after set ROM_IMAGE_SIZE to 0x12000 got the following error: gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld crt0.o init.o /usr/bin/ld: section .reset [00000000fffbfff0 -> 00000000fffbffff] overlaps section .init [00000000fffbaab0 -> 00000000fffc0ccf] /usr/bin/ld: section .id [00000000fffbffd9 -> 00000000fffbffef] overlaps section .init [00000000fffbaab0 -> 00000000fffc0ccf] /usr/bin/ld: section .rodata.str1.32 [00000000fffc0000 -> 00000000fffc01a4] overlaps section .init [00000000fffbaab0 -> 00000000fffc0ccf] collect2: ld returned 1 exit status make[1]: *** [linuxbios] Error 1 make[1]: Leaving directory `/home/lt/vvvv/freebios2-work/targets/ncic/x1000/x1000/normal' make: *** [normal/linuxbios.rom] Error 1 the error occurs when building the normal image, and the size of .rodata.str1.32 is just 421 byte. Are there errors setting sections? -------------- next part -------------- A non-text attachment was scrubbed... Name: ldoptions Type: application/octet-stream Size: 1978 bytes Desc: not available URL: From lje at kontron.dk Tue Jun 28 14:42:03 2005 From: lje at kontron.dk (Lasse Jensen) Date: Tue, 28 Jun 2005 14:42:03 +0200 Subject: [LinuxBIOS] print_stack() error? Message-ID: Hi Anyone know why this happens?! In the old builds I didn't see this error, any hints?! It does this on 4-5 builds... Processing mainboard/digitallogic/adl855pc (i386: ok) Creating config file... ok Creating builddir...FAILED! Log excerpt: File "digitallogic_adl855pc/config.py", line 1058, in getoption v = getoptionvalue(name, o, image) File "digitallogic_adl855pc/config.py", line 1033, in getoptionvalue print_stack() NameError: global name 'print_stack' is not defined Ps. I know the adl855pc don't work..... /Lasse -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at lanl.gov Tue Jun 28 16:10:08 2005 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Tue, 28 Jun 2005 08:10:08 -0600 (MDT) Subject: [LinuxBIOS] Re: Linuxbios is always 421bytes larger than allowed In-Reply-To: <8eca059b05062721133d9a92e1@mail.gmail.com> References: <8eca059b0506262047248353e4@mail.gmail.com> <2ea3fae105062621014a394ee@mail.gmail.com> <8eca059b05062621117551c588@mail.gmail.com> <8eca059b050626235431cd0cfc@mail.gmail.com> <2ea3fae105062710122079bd56@mail.gmail.com> <8eca059b05062721133d9a92e1@mail.gmail.com> Message-ID: I forget, did you send us your targets Config.lb? I think you still have got something wrong. ron From jschildt at lnxi.com Tue Jun 28 16:13:37 2005 From: jschildt at lnxi.com (Jason Schildt) Date: Tue, 28 Jun 2005 08:13:37 -0600 Subject: [LinuxBIOS] print_stack() error? In-Reply-To: References: Message-ID: <20050628141337.GI5190@zoot.lnxi.com> I'm getting similar errors in all of my builds and am looking into it. If anyone knows what's going on, I would appreciate some insight. It _might_ have something to do with how the Python scripts read the Config.lb, but that's just a guess at this point. --jason-- On Tue, Jun 28, 2005 at 02:42:03PM +0200, Lasse Jensen wrote: > Hi > > Anyone know why this happens?! > In the old builds I didn't see this error, any hints?! > It does this on 4-5 builds... > > > Processing mainboard/digitallogic/adl855pc (i386: ok) > Creating config file... ok > Creating builddir...FAILED! Log excerpt: > File "digitallogic_adl855pc/config.py", line 1058, in getoption > v = getoptionvalue(name, o, image) > File "digitallogic_adl855pc/config.py", line 1033, in getoptionvalue > print_stack() > NameError: global name 'print_stack' is not defined > > > Ps. I know the adl855pc don't work..... > > /Lasse > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios -- Jason W. Schildt LinuxBIOS Software Engineer Linux Networx From rminnich at lanl.gov Tue Jun 28 16:17:07 2005 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Tue, 28 Jun 2005 08:17:07 -0600 (MDT) Subject: [LinuxBIOS] print_stack() error? In-Reply-To: <20050628141337.GI5190@zoot.lnxi.com> References: <20050628141337.GI5190@zoot.lnxi.com> Message-ID: oh, heck, I'm not seeing this except in one case where I had a config error. print_stack is only needed when there is a problem. Will someone please try a build for the digitallogic/msm586seg I want to see if it is in the repo or not. ron From lje at kontron.dk Tue Jun 28 16:24:50 2005 From: lje at kontron.dk (Lasse Jensen) Date: Tue, 28 Jun 2005 16:24:50 +0200 Subject: [LinuxBIOS] print_stack() error? Message-ID: When I do a auto build (./abuild) I get this: Processing mainboard/amd/quartet (i386: ok) ( mainboard/amd/quartet previously ok ) Processing mainboard/amd/serenade (i386: ok) ( mainboard/amd/serenade previously ok ) Processing mainboard/amd/solo (i386: ok) ( mainboard/amd/solo previously ok ) Processing mainboard/arima/hdama (i386: ok) ( mainboard/arima/hdama previously ok ) Processing mainboard/densitron/dpx114 (i386: ok) Creating config file... ok Creating builddir...FAILED! Log excerpt: File "densitron_dpx114/config.py", line 1058, in getoption v = getoptionvalue(name, o, image) File "densitron_dpx114/config.py", line 1033, in getoptionvalue print_stack() NameError: global name 'print_stack' is not defined Processing mainboard/digitallogic/adl855pc (i386: ok) Creating config file... ok Creating builddir...FAILED! Log excerpt: File "digitallogic_adl855pc/config.py", line 1058, in getoption v = getoptionvalue(name, o, image) File "digitallogic_adl855pc/config.py", line 1033, in getoptionvalue print_stack() NameError: global name 'print_stack' is not defined Processing mainboard/digitallogic/msm586seg (i386: ok) Creating config file... ok Creating builddir...FAILED! Log excerpt: File "digitallogic_msm586seg/config.py", line 1058, in getoption v = getoptionvalue(name, o, image) File "digitallogic_msm586seg/config.py", line 1033, in getoptionvalue print_stack() NameError: global name 'print_stack' is not defined Processing mainboard/eaglelion/5bcm (i386: ok) Creating config file... ok Creating builddir...FAILED! Log excerpt: File "eaglelion_5bcm/config.py", line 1058, in getoption v = getoptionvalue(name, o, image) File "eaglelion_5bcm/config.py", line 1033, in getoptionvalue print_stack() NameError: global name 'print_stack' is not defined Processing mainboard/embeddedplanet/ep405pc (ppc: skipped, we're i386) Processing mainboard/emulation/qemu-i386 (i386: ok) Creating config file... ok Creating builddir...FAILED! Log excerpt: File "emulation_qemu-i386/config.py", line 1058, in getoption v = getoptionvalue(name, o, image) File "emulation_qemu-i386/config.py", line 1033, in getoptionvalue print_stack() NameError: global name 'print_stack' is not defined Processing mainboard/ibm/e325 (i386: ok) ( mainboard/ibm/e325 previously ok ) Processing mainboard/island/aruma (i386: ok) Creating config file... ok Creating builddir...ok Compiling image ..FAILED! Log excerpt: coherent_ht.c:1543.39: coherent_ht.c:1805.27: auto.c:166.47: 0x9f621f8 phi Internal compiler error: Cannot find block dominated by 0x9dc0678 make[1]: *** [auto.inc] Aborted make[1]: Leaving directory `/root/51/freebios/util/abuild/linuxbios-builds/island_aruma/normal' make: *** [normal/linuxbios.rom] Error 1 Processing mainboard/Iwill/DK8S2 (i386: ok) Creating config file... ok Creating builddir...ok Compiling image ..FAILED! Log excerpt: Unexpected token: ) make[1]: *** [auto.inc] Error 1 make[1]: Leaving directory `/root/51/freebios/util/abuild/linuxbios-builds/Iwill_DK8S2/normal' make: *** [normal/linuxbios.rom] Error 1 Processing mainboard/Iwill/DK8X (i386: ok) Creating config file... ok Creating builddir...ok Compiling image ..FAILED! Log excerpt: Unexpected token: ) make[1]: *** [auto.inc] Error 1 make[1]: Leaving directory `/root/51/freebios/util/abuild/linuxbios-builds/Iwill_DK8X/normal' make: *** [normal/linuxbios.rom] Error 1 Processing mainboard/motorola/sandpoint (ppc: skipped, we're i386) Processing mainboard/motorola/sandpointx3_altimus_mpc7410 (: skipped, we're i386) Processing mainboard/newisys/khepri (i386: ok) Creating config file... ok Creating builddir...ok Compiling image ..FAILED! Log excerpt: Unexpected token: ) make[1]: *** [auto.inc] Error 1 make[1]: Leaving directory `/root/51/freebios/util/abuild/linuxbios-builds/newisys_khepri/normal' make: *** [normal/linuxbios.rom] Error 1 Processing mainboard/technologic/ts5300 (i386: ok) Creating config file... ok Creating builddir...FAILED! Log excerpt: File "technologic_ts5300/config.py", line 1058, in getoption v = getoptionvalue(name, o, image) File "technologic_ts5300/config.py", line 1033, in getoptionvalue print_stack() NameError: global name 'print_stack' is not defined Processing mainboard/totalimpact/briq (ppc: skipped, we're i386) Processing mainboard/tyan/s2735 (i386: ok) Creating config file... ok Creating builddir...ok Compiling image ..FAILED! Log excerpt: then true; else exit 1; fi; make[1]: Entering directory `/root/51/freebios/util/abuild/linuxbios-builds/tyan_s2735/normal' make[1]: *** No rule to make target `/root/51/freebios/src/cpu/intel/car/cache_as_ram.inc', needed by `crt0.s'. Stop. make[1]: Leaving directory `/root/51/freebios/util/abuild/linuxbios-builds/tyan_s2735/normal' make: *** [normal/linuxbios.rom] Error 1 Processing mainboard/tyan/s2850 (i386: ok) ( mainboard/tyan/s2850 previously ok ) Processing mainboard/tyan/s2875 (i386: ok) ( mainboard/tyan/s2875 previously ok ) Processing mainboard/tyan/s2880 (i386: ok) Creating config file... ok Creating builddir...FAILED! Log excerpt: ===> NOTE: Option CONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2 using default value 0 ===> ERROR: Could not open file "/root/51/freebios/src/drivers/lsi/53c1030/Config.lb" Config-tyan_s2880.lb:0 mainboard/tyan/s2880/Config.lb:0 drivers/lsi/53c1030/Config.lb:0 Processing mainboard/tyan/s2881 (i386: ok) ( mainboard/tyan/s2881 previously ok ) Processing mainboard/tyan/s2882 (i386: ok) ( mainboard/tyan/s2882 previously ok ) Processing mainboard/tyan/s2885 (i386: ok) ( mainboard/tyan/s2885 previously ok ) Processing mainboard/tyan/s2891 (i386: ok) ( mainboard/tyan/s2891 previously ok ) Processing mainboard/tyan/s2892 (i386: ok) ( mainboard/tyan/s2892 previously ok ) Processing mainboard/tyan/s2895 (i386: ok) ( mainboard/tyan/s2895 previously ok ) Processing mainboard/tyan/s4880 (i386: ok) Creating config file... ok Creating builddir...FAILED! Log excerpt: ===> NOTE: Option CONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2 using default value 0 ===> ERROR: Could not open file "/root/51/freebios/src/drivers/lsi/53c1030/Config.lb" Config-tyan_s4880.lb:0 mainboard/tyan/s4880/Config.lb:0 drivers/lsi/53c1030/Config.lb:0 Processing mainboard/tyan/s4882 (i386: ok) ( mainboard/tyan/s4882 previously ok ) Processing mainboard/via/epia (i386: ok) Creating config file... ok Creating builddir...FAILED! Log excerpt: File "via_epia/config.py", line 1058, in getoption v = getoptionvalue(name, o, image) File "via_epia/config.py", line 1033, in getoptionvalue print_stack() NameError: global name 'print_stack' is not defined Processing mainboard/via/epia-m (i386: ok) Creating config file... ok Creating builddir...FAILED! Log excerpt: File "via_epia-m/config.py", line 1058, in getoption v = getoptionvalue(name, o, image) File "via_epia-m/config.py", line 1033, in getoptionvalue print_stack() NameError: global name 'print_stack' is not defined I could build a lot more images a couple of months ago, around Patch 30 I think... -----Original Message----- From: Ronald G. Minnich [mailto:rminnich at lanl.gov] Sent: 28. juni 2005 16:17 To: Jason Schildt Cc: Lasse Jensen; linuxbios at openbios.org Subject: Re: [LinuxBIOS] print_stack() error? oh, heck, I'm not seeing this except in one case where I had a config error. print_stack is only needed when there is a problem. Will someone please try a build for the digitallogic/msm586seg I want to see if it is in the repo or not. ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at lanl.gov Tue Jun 28 16:31:15 2005 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Tue, 28 Jun 2005 08:31:15 -0600 (MDT) Subject: [LinuxBIOS] print_stack() error? In-Reply-To: References: Message-ID: thanks. YIKES! something has broken big time. I'll talk to Ollie when he gets in. I'm on travel again (!@#$!@#$#@) but will sync up my copy of the repo and see what's going on. ron From rminnich at lanl.gov Tue Jun 28 16:51:24 2005 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Tue, 28 Jun 2005 08:51:24 -0600 (MDT) Subject: [LinuxBIOS] print_stack() error? In-Reply-To: References: Message-ID: ok, somebody broke the repo ... badly. I just did an update and my build no longer works. Folks, if you can , check out rev -50 and see if the problem goes away. rev -50 is the last working rev for me. Yh Lu, I think you broke something. thanks ron From ollie at lanl.gov Tue Jun 28 17:13:06 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Tue, 28 Jun 2005 09:13:06 -0600 Subject: [LinuxBIOS] print_stack() error? In-Reply-To: References: Message-ID: <1119971586.21213.47.camel@exponential.lanl.gov> On Tue, 2005-06-28 at 08:51 -0600, Ronald G. Minnich wrote: > ok, somebody broke the repo ... badly. I just did an update and my build > no longer works. > > Folks, if you can , check out rev -50 and see if the problem goes away. > rev -50 is the last working rev for me. > > Yh Lu, I think you broke something. > We have to put uses CONFIG_USE_INIT in every mainboard Option.lb. Appereantly, the default or export keyword in the global Option.lb does not well. -- Li-Ta Lo Los Alamos National Lab From jschildt at lnxi.com Tue Jun 28 17:38:33 2005 From: jschildt at lnxi.com (Jason Schildt) Date: Tue, 28 Jun 2005 09:38:33 -0600 Subject: [BULK] RE: [LinuxBIOS] print_stack() error? In-Reply-To: <1119971586.21213.47.camel@exponential.lanl.gov> References: <1119971586.21213.47.camel@exponential.lanl.gov> Message-ID: <20050628153833.GM5190@zoot.lnxi.com> That's the magic. Thanks Ollie, you're the tops. --jason-- On Tue, Jun 28, 2005 at 09:13:06AM -0600, Li-Ta Lo wrote: > On Tue, 2005-06-28 at 08:51 -0600, Ronald G. Minnich wrote: > > ok, somebody broke the repo ... badly. I just did an update and my build > > no longer works. > > > > Folks, if you can , check out rev -50 and see if the problem goes away. > > rev -50 is the last working rev for me. > > > > Yh Lu, I think you broke something. > > > > We have to put > > uses CONFIG_USE_INIT > > in every mainboard Option.lb. > Appereantly, the default or export keyword in the global Option.lb does > not well. > > -- > Li-Ta Lo > Los Alamos National Lab > > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios -- Jason W. Schildt LinuxBIOS Software Engineer Linux Networx From yinghailu at gmail.com Tue Jun 28 19:01:14 2005 From: yinghailu at gmail.com (yhlu) Date: Tue, 28 Jun 2005 10:01:14 -0700 Subject: [LinuxBIOS] Re: Linuxbios is always 421bytes larger than allowed In-Reply-To: <8eca059b05062721133d9a92e1@mail.gmail.com> References: <8eca059b0506262047248353e4@mail.gmail.com> <2ea3fae105062621014a394ee@mail.gmail.com> <8eca059b05062621117551c588@mail.gmail.com> <8eca059b050626235431cd0cfc@mail.gmail.com> <2ea3fae105062710122079bd56@mail.gmail.com> <8eca059b05062721133d9a92e1@mail.gmail.com> Message-ID: <2ea3fae105062810017aafc743@mail.gmail.com> Please check your MB Config.lb there should be no "section .rodata.str1.32" section because it is already be change to .init.rodata.... YH On 6/27/05, Tao Liu wrote: > On 6/28/05, yhlu wrote: > > Please try to reduce the ROM_IMAGE_SIZE to 0x13000 > > > > YH > > I set ROM_IMAGE_SIZE to 0x13000 and still got the 421bytes error. > after set ROM_IMAGE_SIZE to 0x12000 got the following error: > > gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld > crt0.o init.o > /usr/bin/ld: section .reset [00000000fffbfff0 -> 00000000fffbffff] > overlaps section .init [00000000fffbaab0 -> 00000000fffc0ccf] > /usr/bin/ld: section .id [00000000fffbffd9 -> 00000000fffbffef] > overlaps section .init [00000000fffbaab0 -> 00000000fffc0ccf] > /usr/bin/ld: section .rodata.str1.32 [00000000fffc0000 -> > 00000000fffc01a4] overlaps section .init [00000000fffbaab0 -> > 00000000fffc0ccf] > collect2: ld returned 1 exit status > make[1]: *** [linuxbios] Error 1 > make[1]: Leaving directory > `/home/lt/vvvv/freebios2-work/targets/ncic/x1000/x1000/normal' > make: *** [normal/linuxbios.rom] Error 1 > > the error occurs when building the normal image, and the size of > .rodata.str1.32 is just 421 byte. Are there errors setting sections? > > > From yinghailu at gmail.com Tue Jun 28 19:08:35 2005 From: yinghailu at gmail.com (yhlu) Date: Tue, 28 Jun 2005 10:08:35 -0700 Subject: [LinuxBIOS] print_stack() error? In-Reply-To: <1119971586.21213.47.camel@exponential.lanl.gov> References: <1119971586.21213.47.camel@exponential.lanl.gov> Message-ID: <2ea3fae105062810086c37b232@mail.gmail.com> I only added that for several Opteron MB. Also I already state that when I commited the cache_as_ram. If you have problem you need to add "uses CONFIG_USE_INIT" I don't know why even I change that in config/Option.lb to always. We still need "uses CONFIG_USE_INIT" in MB Config.lb Also the new config util does report corret error, if you forget add "uses XXXX" before seperate the Config.lb to MB Config.lb and Option.lb, it seems it could report such kind of error.... YH On 6/28/05, Li-Ta Lo wrote: > On Tue, 2005-06-28 at 08:51 -0600, Ronald G. Minnich wrote: > > ok, somebody broke the repo ... badly. I just did an update and my build > > no longer works. > > > > Folks, if you can , check out rev -50 and see if the problem goes away. > > rev -50 is the last working rev for me. > > > > Yh Lu, I think you broke something. > > > > We have to put > > uses CONFIG_USE_INIT > > in every mainboard Option.lb. > Appereantly, the default or export keyword in the global Option.lb does > not well. > > -- > Li-Ta Lo > Los Alamos National Lab > > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From ollie at lanl.gov Tue Jun 28 21:00:31 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Tue, 28 Jun 2005 13:00:31 -0600 Subject: [LinuxBIOS] print_stack() error? In-Reply-To: <2ea3fae105062810086c37b232@mail.gmail.com> References: <1119971586.21213.47.camel@exponential.lanl.gov> <2ea3fae105062810086c37b232@mail.gmail.com> Message-ID: <1119985231.21213.51.camel@exponential.lanl.gov> On Tue, 2005-06-28 at 10:08 -0700, yhlu wrote: > I only added that for several Opteron MB. > > Also I already state that when I commited the cache_as_ram. If you > have problem you need to add "uses CONFIG_USE_INIT" > > I don't know why even I change that in config/Option.lb to always. We > still need "uses CONFIG_USE_INIT" in MB Config.lb > > Also the new config util does report corret error, if you forget add "uses XXXX" > > before seperate the Config.lb to MB Config.lb and Option.lb, it seems > it could report such kind of error.... > > YH You are using the CONFIG_USE_INIT in the global Config.lb. I think is is processsed before the global Options.lb is loaded. I wll try if adding that line in the global Config.lb helps. -- Li-Ta Lo Los Alamos National Lab From ollie at lanl.gov Tue Jun 28 21:09:14 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Tue, 28 Jun 2005 13:09:14 -0600 Subject: [LinuxBIOS] driver/lsi ?? Message-ID: <1119985754.21213.54.camel@exponential.lanl.gov> YhLu, In s2880 and s4880, you referenced driver/lsi/53c1030, do we actually have that in the public tree? -- Li-Ta Lo Los Alamos National Lab From yinghailu at gmail.com Tue Jun 28 21:11:19 2005 From: yinghailu at gmail.com (yhlu) Date: Tue, 28 Jun 2005 12:11:19 -0700 Subject: [LinuxBIOS] driver/lsi ?? In-Reply-To: <1119985754.21213.54.camel@exponential.lanl.gov> References: <1119985754.21213.54.camel@exponential.lanl.gov> Message-ID: <2ea3fae10506281211202f8f95@mail.gmail.com> Oh, please comment out these lines... YH On 6/28/05, Li-Ta Lo wrote: > YhLu, > > In s2880 and s4880, you referenced driver/lsi/53c1030, do we actually > have that in the public tree? > > -- > Li-Ta Lo > Los Alamos National Lab > > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From ollie at lanl.gov Tue Jun 28 22:03:18 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Tue, 28 Jun 2005 14:03:18 -0600 Subject: [LinuxBIOS] Abuild test Message-ID: <1119988998.21213.72.camel@exponential.lanl.gov> Hi, I tried to make as many boards to pass abuild test as possible. Now I have most of them working. The non working boards are in three categories: 1. Known to be broken: technologic/ts5300, via/epia-m 2. Bug in ROMCC: island/aruma, ROMCC complain about something in coherent_ht.c:1543.39: coherent_ht.c:1805.27: auto.c:166.47: 0x88cd720 phi Internal compiler error: Cannot find block dominated by 0x83b8150 3. Bug in Abuild: digitallogic/msm586seg, emulation/qemu-i386, Abuild generates incorrect value (0x-5000) for PAYLOAD_SIZE in Makefile.setting. I can figure out why it generate such a insane thing. 4. Bug in ldscript: tyan/s2880, tyan/s4880, the default ROM_IMAGE_SIZE generated by Abuild is wrong for these boards. The value in target Config.lb is good. 5. CAR WIP: tyan/s2735, YhLu, did you ever get CAR working on this one? make[1]: Entering directory `/tmp/freebios2_test/util/abuild/linuxbios- builds/tyan_s2735/normal' make[1]: *** No rule to make target `/tmp/freebios2_test/src/cpu/intel/car/cache_as_ram.inc', needed by `crt0.s'. Stop. -- Li-Ta Lo Los Alamos National Lab From noodles at earth.li Tue Jun 28 22:25:29 2005 From: noodles at earth.li (Jonathan McDowell) Date: Tue, 28 Jun 2005 21:25:29 +0100 Subject: [LinuxBIOS] Abuild test In-Reply-To: <1119988998.21213.72.camel@exponential.lanl.gov> References: <1119988998.21213.72.camel@exponential.lanl.gov> Message-ID: <20050628202529.GO26687@earth.li> On Tue, Jun 28, 2005 at 02:03:18PM -0600, Li-Ta Lo wrote: > I tried to make as many boards to pass abuild test as possible. Now I > have most of them working. The non working boards are in three > categories: > > 1. Known to be broken: > technologic/ts5300, via/epia-m I have epia-m compiling and running, but it's crashing apparently randomly during the phase 1 setup (ie before it's copied into RAM). Still trying to investigate this; the main obvious difference I can see between v1 (which seems to work) and v2 is that v1 does a little bit of setup and then a reset before doing the copy into ram stage. I can't see that other boards in v1 do this. There was talk of work happening on EPIA-M - is anyone else actually doing this? I know about Adam Talbot and Anton Borisov, both of whom I've been in contact with. J. -- [ Zed's dead, baby. Zed's dead. ] [ http://www.blackcatnetworks.co.uk/ - IPv6 enabled ADSL/dialup/colo ] From rminnich at lanl.gov Tue Jun 28 22:29:22 2005 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Tue, 28 Jun 2005 14:29:22 -0600 (MDT) Subject: [LinuxBIOS] Abuild test In-Reply-To: <20050628202529.GO26687@earth.li> References: <1119988998.21213.72.camel@exponential.lanl.gov> <20050628202529.GO26687@earth.li> Message-ID: well, we have had to fight a few other linuxbios fires in the last 2 weeks, and more are happening as I speak, so epia-m is in suspension here again ... sorry ron From yinghailu at gmail.com Tue Jun 28 22:32:55 2005 From: yinghailu at gmail.com (yhlu) Date: Tue, 28 Jun 2005 13:32:55 -0700 Subject: [LinuxBIOS] Abuild test In-Reply-To: <1119988998.21213.72.camel@exponential.lanl.gov> References: <1119988998.21213.72.camel@exponential.lanl.gov> Message-ID: <2ea3fae105062813321f17e9e2@mail.gmail.com> Ok try s2735 again. On 6/28/05, Li-Ta Lo wrote: > Hi, > > I tried to make as many boards to pass abuild test as possible. Now I > have most of them working. The non working boards are in three > categories: > > 1. Known to be broken: > technologic/ts5300, via/epia-m > > 2. Bug in ROMCC: > island/aruma, ROMCC complain about something in > > coherent_ht.c:1543.39: coherent_ht.c:1805.27: auto.c:166.47: > 0x88cd720 phi Internal compiler error: Cannot find block > dominated by 0x83b8150 > > 3. Bug in Abuild: > digitallogic/msm586seg, emulation/qemu-i386, > Abuild generates incorrect value (0x-5000) for > PAYLOAD_SIZE in Makefile.setting. I can figure out > why it generate such a insane thing. > 4. Bug in ldscript: > tyan/s2880, tyan/s4880, the default ROM_IMAGE_SIZE > generated by Abuild is wrong for these boards. The > value in target Config.lb is good. > > 5. CAR WIP: > tyan/s2735, YhLu, did you ever get CAR working on this > one? > > make[1]: Entering directory `/tmp/freebios2_test/util/abuild/linuxbios- > builds/tyan_s2735/normal' > make[1]: *** No rule to make target > `/tmp/freebios2_test/src/cpu/intel/car/cache_as_ram.inc', needed by > `crt0.s'. Stop. > > -- > Li-Ta Lo > Los Alamos National Lab > > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From noodles at earth.li Tue Jun 28 22:39:21 2005 From: noodles at earth.li (Jonathan McDowell) Date: Tue, 28 Jun 2005 21:39:21 +0100 Subject: [LinuxBIOS] Abuild test In-Reply-To: References: <1119988998.21213.72.camel@exponential.lanl.gov> <20050628202529.GO26687@earth.li> Message-ID: <20050628203921.GP26687@earth.li> On Tue, Jun 28, 2005 at 02:29:22PM -0600, Ronald G. Minnich wrote: > well, we have had to fight a few other linuxbios fires in the last 2 > weeks, and more are happening as I speak, so epia-m is in suspension > here again ... > > sorry No worries; I'm not expecting anyone else to make it work for me, just don't want to end up duplicating effort or banging my head against a wall when someone else has solved the problem. (I've had a bunch of embarrassing self inflicted setbacks in terms of being able to get my test rig sorted; Adam's done basically all the testing work so far. However, all being well I'll be sorted by next week and able to get more done.) J. -- /------------------------------------\ | Run like hell! | | http://www.blackcatnetworks.co.uk/ | \------------------------------------/ From huangjen.wang at gmail.com Wed Jun 29 02:37:06 2005 From: huangjen.wang at gmail.com (Huang-Jen Wang) Date: Wed, 29 Jun 2005 08:37:06 +0800 Subject: [LinuxBIOS] mianboard Config.lb question.... Message-ID: <4325815c05062817375cc801fa@mail.gmail.com> Dear all, I am porting a new mainboard, and its chipset are ServerWorks HT1000 and HT2000, in HT1000, it looks like its SMBUS is not a pci device. Because I can find it device number and function number, I have a very serious problem, how do I edit the mainboard Config.lbfile.Dose anyone has the same situation before....or any idea? Thanks From YhLu at tyan.com Wed Jun 29 02:45:18 2005 From: YhLu at tyan.com (YhLu) Date: Tue, 28 Jun 2005 17:45:18 -0700 Subject: [LinuxBIOS] mianboard Config.lb question.... Message-ID: <3174569B9743D511922F00A0C94314230AF9739C@TYANWEB> ha ha, my coding is done and waiting for HW to debug..... YH > -----Original Message----- > From: Huang-Jen Wang [mailto:huangjen.wang at gmail.com] > Sent: Tuesday, June 28, 2005 5:37 PM > To: linuxbios at openbios.org > Subject: [LinuxBIOS] mianboard Config.lb question.... > > Dear all, > I am porting a new mainboard, and its chipset are ServerWorks > HT1000 and HT2000, in HT1000, it looks like its SMBUS is not > a pci device. > Because I can find it device number and function number, I > have a very serious problem, how do I edit the mainboard > Config.lbfile.Dose anyone has the same situation before....or > any idea? > > Thanks > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From kfuchs at winternet.com Wed Jun 29 16:56:32 2005 From: kfuchs at winternet.com (Ken Fuchs) Date: Wed, 29 Jun 2005 09:56:32 -0500 (CDT) Subject: [LinuxBIOS] mianboard Config.lb question.... Message-ID: <200506291456.j5TEuWFt020989@tundra.winternet.com> YH, please explain your comment. Sincerely, Ken Fuchs > -----Original Message----- > From: linuxbios-bounces at openbios.org > [mailto:linuxbios-bounces at openbios.org] On Behalf Of YhLu > Sent: Tuesday, June 28, 2005 19:45 > To: Huang-Jen Wang; linuxbios at openbios.org > Subject: RE: [LinuxBIOS] mianboard Config.lb question.... > > > ha ha, my coding is done and waiting for HW to debug..... > > YH > > > -----Original Message----- > > From: Huang-Jen Wang [mailto:huangjen.wang at gmail.com] > > Sent: Tuesday, June 28, 2005 5:37 PM > > To: linuxbios at openbios.org > > Subject: [LinuxBIOS] mianboard Config.lb question.... > > > > Dear all, > > I am porting a new mainboard, and its chipset are ServerWorks > > HT1000 and HT2000, in HT1000, it looks like its SMBUS is not > > a pci device. > > Because I can find it device number and function number, I > > have a very serious problem, how do I edit the mainboard > > Config.lbfile.Dose anyone has the same situation before....or > > any idea? > > > > Thanks From yinghailu at gmail.com Wed Jun 29 18:02:36 2005 From: yinghailu at gmail.com (yhlu) Date: Wed, 29 Jun 2005 09:02:36 -0700 Subject: [LinuxBIOS] mianboard Config.lb question.... In-Reply-To: <200506291456.j5TEuWFt020989@tundra.winternet.com> References: <200506291456.j5TEuWFt020989@tundra.winternet.com> Message-ID: <2ea3fae1050629090229dce1f3@mail.gmail.com> It's not clear? The HT1000 and HT2000 linuxBIOS support is relatively simple.....according to history of Serverworks, everything is fixed.... YH On 6/29/05, Ken Fuchs wrote: > YH, please explain your comment. > > Sincerely, > > Ken Fuchs > > > -----Original Message----- > > From: linuxbios-bounces at openbios.org > > [mailto:linuxbios-bounces at openbios.org] On Behalf Of YhLu > > Sent: Tuesday, June 28, 2005 19:45 > > To: Huang-Jen Wang; linuxbios at openbios.org > > Subject: RE: [LinuxBIOS] mianboard Config.lb question.... > > > > > > ha ha, my coding is done and waiting for HW to debug..... > > > > YH > > > > > -----Original Message----- > > > From: Huang-Jen Wang [mailto:huangjen.wang at gmail.com] > > > Sent: Tuesday, June 28, 2005 5:37 PM > > > To: linuxbios at openbios.org > > > Subject: [LinuxBIOS] mianboard Config.lb question.... > > > > > > Dear all, > > > I am porting a new mainboard, and its chipset are ServerWorks > > > HT1000 and HT2000, in HT1000, it looks like its SMBUS is not > > > a pci device. > > > Because I can find it device number and function number, I > > > have a very serious problem, how do I edit the mainboard > > > Config.lbfile.Dose anyone has the same situation before....or > > > any idea? > > > > > > Thanks > > _______________________________________________ > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From steve at digidescorp.com Thu Jun 30 04:52:15 2005 From: steve at digidescorp.com (Steve Magnani) Date: Wed, 29 Jun 2005 21:52:15 -0500 Subject: [LinuxBIOS] Local APIC IDs for dual Xeons Message-ID: Hi all, I've reached the point where LB is attempting to start the secondary CPU on my custom board. As near as I can tell, LB thinks the secondary CPU isn't responding. This could be a hardware problem, or a LB issue of some sort. CPU 6 would not start! CPU 6 did not initialize! First thing I wanted to check was that LB is using the right APIC ID in the messages it's sending. But I haven't been able to find a good explanation anywhere of how local APIC IDs are assigned in dual-Xeon systems. All Intel says with any certainty is that the power-up sequence includes setting a unique ID for each LAPIC. There is a format to the IDs (i.e. some bits for logical processor, some for socket, some for APIC cluster), but nothing that says (for instance) "One Xeon chip is assigned LAPIC IDs 0 & 1 and the second is assigned LAPIC IDs 6 & 7". Looking over the s2735 config, and anything I found on the Internet, it seems that this is how dual-Xeon boards work. Does anyone know why? Do the addresses come out like this any time you have a dual-Xeon board, and every time you power it up? Or are there some pins that have to be strapped a certain way to end up with these IDs? (Side note, some Xeons support reset-time config of APIC cluster ID - mine don't). The way I'm interpreting the Intel documentation, it looks like the only way to find out a secondary CPU's LAPIC ID is to start it (via an IPI broadcast?) and have it write it somewhere. Thanks, Steve www.digidescorp.com From rminnich at lanl.gov Thu Jun 30 14:57:57 2005 From: rminnich at lanl.gov (Ronald G. Minnich) Date: Thu, 30 Jun 2005 06:57:57 -0600 (MDT) Subject: [LinuxBIOS] Local APIC IDs for dual Xeons In-Reply-To: References: Message-ID: On Wed, 29 Jun 2005, Steve Magnani wrote: > I've reached the point where LB is attempting to start the secondary CPU > on my custom board. As near as I can tell, LB thinks the secondary CPU > isn't responding. This could be a hardware problem, or a LB issue of some > sort. hmm. I think it should be 6, IIRC. There was a problem once, on another product, where the two wires for LAPIC got reversed and caused all kinds of fun. I just can't remember all the details. But you might want to double-, triple-, and friple-check your connections. > cluster), but nothing that says (for instance) "One Xeon chip is assigned > LAPIC IDs 0 & 1 and the second is assigned LAPIC IDs 6 & 7". it always seems to work out that way ... ron