From bari at onelabs.com Thu Sep 1 05:02:33 2005 From: bari at onelabs.com (Bari Ari) Date: Wed, 31 Aug 2005 22:02:33 -0500 Subject: [LinuxBIOS] Open Gaming Console In-Reply-To: <4315FE78.8010900@comcast.net> References: <200508240041.35258.AvatarofVirgo@gmail.com> <200508311750.34880.vanag@telecom.ntua.gr> <4315E68D.1070806@onelabs.com> <8a0c367805083111382f4ea6d0@mail.gmail.com> <4315FE78.8010900@comcast.net> Message-ID: <43166F49.5040304@onelabs.com> Adam Talbot wrote: > Would there be any thing wrong with using something along the lines of a > SFF based computer. Something like. > http://global.shuttle.com/Product/barebone/brb_OverView.asp?B_id=26 > > Some of the older systems are cheap, and we dont need buy/build a nice > case and power supply. The box comes in at around $180 for the case, > power supply and motherboard. I dont think we will be able to build an > itx based system for less. These systems are very fast and allows for us > to use any graphics card we want. Just an idea. It's great, except that socket A cpu's are about to totally disappear from production. Here are the current AMD roadmaps and status: http://www.amd.com/us-en/Processors/ProductInformation/0,,30_118_609,00.html?redir=CPT301 http://www.amd.com/us-en/Processors/ProductInformation/0,,30_118_608,00.html Look at socket 754 based systems for a bit more life. Semprons look like the current bargains. Any input from AMD on the cpu sweet spots for the next year? -Bari From justin at street-vision.com Thu Sep 1 11:30:40 2005 From: justin at street-vision.com (Justin Cormack) Date: Thu, 1 Sep 2005 10:30:40 +0100 Subject: [LinuxBIOS] Open Gaming Console In-Reply-To: <43166F49.5040304@onelabs.com> References: <200508240041.35258.AvatarofVirgo@gmail.com> <200508311750.34880.vanag@telecom.ntua.gr> <4315E68D.1070806@onelabs.com> <8a0c367805083111382f4ea6d0@mail.gmail.com> <4315FE78.8010900@comcast.net> <43166F49.5040304@onelabs.com> Message-ID: <1ACE72EF-3E9D-4F4E-8EFC-81DD9072B6D0@street-vision.com> On 1 Sep 2005, at 04:02, Bari Ari wrote: > Adam Talbot wrote: > >> Would there be any thing wrong with using something along the >> lines of a SFF based computer. Something like. >> http://global.shuttle.com/Product/barebone/brb_OverView.asp?B_id=26 >> Some of the older systems are cheap, and we dont need buy/build a >> nice case and power supply. The box comes in at around $180 for >> the case, power supply and motherboard. I dont think we will be >> able to build an itx based system for less. These systems are very >> fast and allows for us to use any graphics card we want. Just an >> idea. >> > > It's great, except that socket A cpu's are about to totally > disappear from production. Here are the current AMD roadmaps and > status: Except the Geode NX (which is basically the old Athlon mobile) which is staying in socket A it seems http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/ 0,,50_2330_9863_10837%5E10858,00.html Justin From Narahari.Narasimhaiah at honeywell.com Thu Sep 1 11:45:04 2005 From: Narahari.Narasimhaiah at honeywell.com (Narahari, Narasimhaiah (IE10)) Date: Thu, 1 Sep 2005 02:45:04 -0700 Subject: [LinuxBIOS] Building Linuxbiosv2 Message-ID: <77ED2BF75D59D1439F90412CC5B1097423C3E1CA@ie10-sahara.hiso.honeywell.com> Hi everyone, I could build the LinuxBIOSv2 on cygwin, but it is asking for some payload to build the eventual image, linuxbios.rom. This is the error it gives while executing the last build step, **************************************************************************** ****************************************** i386-elf-objcopy --gap-fill 0xff -O binary linuxbios linuxbios.strip --> Linuxbios.strip generated ./buildrom linuxbios.strip linuxbios.rom ../../../payloads/tg3--ide_disk.zelf 0x14000 0x60000 ../../../payloads/tg3--ide_disk.zelf: No such file or directory make[1]: *** [linuxbios.rom] Error 2 make[1]: Leaving directory `/cygdrive/d/LinuxBIOSv2/targets/amd/solo/solo/normal' make: *** [normal/linuxbios.rom] Error 1 **************************************************************************** ****************************************** Can any body tell me where do I get this payload image (tg3--ide_disk.zelf )? I have got one more small question. Can we boot the windows 2000 using the image build of LinuxBIOSv2 sources? Does it need any other stuffs like ADLOBochs or something? With regards, Narahari -------------- next part -------------- An HTML attachment was scrubbed... URL: From talbotx at comcast.net Thu Sep 1 19:33:22 2005 From: talbotx at comcast.net (Adam Talbot) Date: Thu, 01 Sep 2005 10:33:22 -0700 Subject: [LinuxBIOS] Open Gaming Console In-Reply-To: <1ACE72EF-3E9D-4F4E-8EFC-81DD9072B6D0@street-vision.com> References: <200508240041.35258.AvatarofVirgo@gmail.com> <200508311750.34880.vanag@telecom.ntua.gr> <4315E68D.1070806@onelabs.com> <8a0c367805083111382f4ea6d0@mail.gmail.com> <4315FE78.8010900@comcast.net> <43166F49.5040304@onelabs.com> <1ACE72EF-3E9D-4F4E-8EFC-81DD9072B6D0@street-vision.com> Message-ID: <43173B62.1040800@comcast.net> I have no problems with a 939 based board. The major problem there is the nForce 4 chipset. Most of the 939 SFF are based of the Nforce chips. So far i think linux bios has never run on a nForce based board. Is that correct? -Adam Justin Cormack wrote: > > On 1 Sep 2005, at 04:02, Bari Ari wrote: > >> Adam Talbot wrote: >> >>> Would there be any thing wrong with using something along the lines >>> of a SFF based computer. Something like. >>> http://global.shuttle.com/Product/barebone/brb_OverView.asp?B_id=26 >>> Some of the older systems are cheap, and we dont need buy/build a >>> nice case and power supply. The box comes in at around $180 for the >>> case, power supply and motherboard. I dont think we will be able to >>> build an itx based system for less. These systems are very fast and >>> allows for us to use any graphics card we want. Just an idea. >>> >> >> It's great, except that socket A cpu's are about to totally >> disappear from production. Here are the current AMD roadmaps and >> status: > > > Except the Geode NX (which is basically the old Athlon mobile) which > is staying in socket A it seems > http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/ > 0,,50_2330_9863_10837%5E10858,00.html > > Justin > > From arc at Xiph.org Thu Sep 1 19:52:18 2005 From: arc at Xiph.org (Arc) Date: Thu, 1 Sep 2005 10:52:18 -0700 Subject: [LinuxBIOS] Open Gaming Console In-Reply-To: <43173B62.1040800@comcast.net> References: <200508240041.35258.AvatarofVirgo@gmail.com> <200508311750.34880.vanag@telecom.ntua.gr> <4315E68D.1070806@onelabs.com> <8a0c367805083111382f4ea6d0@mail.gmail.com> <4315FE78.8010900@comcast.net> <43166F49.5040304@onelabs.com> <1ACE72EF-3E9D-4F4E-8EFC-81DD9072B6D0@street-vision.com> <43173B62.1040800@comcast.net> Message-ID: <20050901175218.GN15242@xiph.org> On Thu, Sep 01, 2005 at 10:33:22AM -0700, Adam Talbot wrote: > I have no problems with a 939 based board. The major problem there is > the nForce 4 chipset. Most of the 939 SFF are based of the Nforce > chips. So far i think linux bios has never run on a nForce based > board. Is that correct? That's less of an issue than their hardware accelerated 3d support being only available through proprietary drivers. That nice GPU is worthless on a game console if you can't boot with it, but instead have some cheesy 2d splash screen while the system boots to the point that the nVidia drivers and X11 can load. That's one reason why VIA is a better option, and why we need to support them. Unlike nVidia, it's possible to build a 3d bootloader which doesn't require a full "boot" to get you through the first screen or two. It's also possible to build support directly into the kernel making booting faster. -- Diversity is the Fuel of Evolution, Conformity it's Starvation. Be Radical. Be New. Be Different. Feed Evolution with Everything You Are. From smithbone at gmail.com Thu Sep 1 20:53:35 2005 From: smithbone at gmail.com (Richard Smith) Date: Thu, 1 Sep 2005 13:53:35 -0500 Subject: [LinuxBIOS] Open Gaming Console In-Reply-To: <20050901175218.GN15242@xiph.org> References: <200508240041.35258.AvatarofVirgo@gmail.com> <200508311750.34880.vanag@telecom.ntua.gr> <4315E68D.1070806@onelabs.com> <8a0c367805083111382f4ea6d0@mail.gmail.com> <4315FE78.8010900@comcast.net> <43166F49.5040304@onelabs.com> <1ACE72EF-3E9D-4F4E-8EFC-81DD9072B6D0@street-vision.com> <43173B62.1040800@comcast.net> <20050901175218.GN15242@xiph.org> Message-ID: <8a0c3678050901115331fc0e98@mail.gmail.com> > That's less of an issue than their hardware accelerated 3d support being > only available through proprietary drivers. That nice GPU is worthless An "Open" gaming console that depends on proprietary drivers is probally not a good marketing tool. *grin* -- Richard A. Smith From dbell at nxtv.com Thu Sep 1 23:28:47 2005 From: dbell at nxtv.com (Doug Bell) Date: Thu, 01 Sep 2005 14:28:47 -0700 Subject: [LinuxBIOS] mmx problems on VIA EPIA-SP resolved Message-ID: <1125610127.1831.30.camel@Doug> We are working on VIA EPIA-SP with C3-2 processsor and have resolved problems related to the use of the mmx as seen in the auto.inc. The code was hanging unless we used -mno-mmx in Config.lb. We then modified /src/cpu/via/model_centaur_init.c cpu_table[] to include {X86_VENDOR_CENTAUR, 0698}, // VIA C3 Nehemiah If anyone else is doing work on this board please let us know! Our code isn't far enough along to check in. Some questions remain: 1) Is the C3-2 supported yet? What's needed to add? 2) Which if any of the LinuxBIOS v2 via boards ( epia, epia-m ) in subversion are building AND booting? Has anyone done DRAM init using SPD under v2? Doug Bell - NXTV From ollie at lanl.gov Thu Sep 1 23:45:04 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Thu, 01 Sep 2005 15:45:04 -0600 Subject: [LinuxBIOS] mmx problems on VIA EPIA-SP resolved In-Reply-To: <1125610127.1831.30.camel@Doug> References: <1125610127.1831.30.camel@Doug> Message-ID: <1125611104.6731.4.camel@logarithm.lanl.gov> On Thu, 2005-09-01 at 14:28 -0700, Doug Bell wrote: > > We are working on VIA EPIA-SP with C3-2 processsor and have resolved > problems related to the use of the mmx as seen in the > auto.inc. The code was hanging unless we used -mno-mmx in Config.lb. > > We then modified /src/cpu/via/model_centaur_init.c cpu_table[] to > include > {X86_VENDOR_CENTAUR, 0698}, // VIA C3 Nehemiah > > If anyone else is doing work on this board please let us know! Our code > isn't far enough along to check in. > > > > Some questions remain: > > > 1) Is the C3-2 supported yet? What's needed to add? > > 2) Which if any of the LinuxBIOS v2 via boards ( epia, epia-m ) in > subversion are building AND booting? Has anyone done DRAM init using > SPD under v2? > EPIA should use SPD in V2. It is not very stable for some unknown reason. -- Li-Ta Lo Los Alamos National Lab From stuge-linuxbios at cdy.org Fri Sep 2 09:45:01 2005 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Fri, 2 Sep 2005 09:45:01 +0200 Subject: [LinuxBIOS] Building Linuxbiosv2 In-Reply-To: <77ED2BF75D59D1439F90412CC5B1097423C3E1CA@ie10-sahara.hiso.honeywell.com> References: <77ED2BF75D59D1439F90412CC5B1097423C3E1CA@ie10-sahara.hiso.honeywell.com> Message-ID: <20050902074501.6661.qmail@cdy.org> On Thu, Sep 01, 2005 at 02:45:04AM -0700, Narahari, Narasimhaiah (IE10) wrote: > Can any body tell me where do I get this payload image > (tg3--ide_disk.zelf)? You can create one at http://www.rom-o-matic.net/ //Peter From yinghai.lu at amd.com Fri Sep 2 18:26:22 2005 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Fri, 2 Sep 2005 09:26:22 -0700 Subject: [LinuxBIOS] Building Linuxbiosv2 Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E060F5@ssvlexmb2.amd.com> I don't think so, That web only for normal BIOS payloads? He need to download the source code, and set the option to LinuxBIOS and compile it. http://www.linuxbios.org/index.php/Etherboot YH -----Original Message----- From: linuxbios-bounces at openbios.org [mailto:linuxbios-bounces at openbios.org] On Behalf Of Peter Stuge Sent: Friday, September 02, 2005 12:45 AM To: linuxbios at openbios.org Subject: Re: [LinuxBIOS] Building Linuxbiosv2 On Thu, Sep 01, 2005 at 02:45:04AM -0700, Narahari, Narasimhaiah (IE10) wrote: > Can any body tell me where do I get this payload image > (tg3--ide_disk.zelf)? You can create one at http://www.rom-o-matic.net/ //Peter -- LinuxBIOS mailing list LinuxBIOS at openbios.org http://www.openbios.org/mailman/listinfo/linuxbios From stuge-linuxbios at cdy.org Fri Sep 2 21:02:43 2005 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Fri, 2 Sep 2005 21:02:43 +0200 Subject: [LinuxBIOS] Building Linuxbiosv2 In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4201E060F5@ssvlexmb2.amd.com> References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E060F5@ssvlexmb2.amd.com> Message-ID: <20050902190243.20169.qmail@cdy.org> On Fri, Sep 02, 2005 at 09:26:22AM -0700, Lu, Yinghai wrote: > I don't think so, That web only for normal BIOS payloads? > > He need to download the source code, and set the option to > LinuxBIOS and compile it. Actually it's possible to set all options on the web page too. Click the Configure button instead of Get ROM, and you can set LINUXBIOS, unset PC_BIOS, and set any and all other options. :) > http://www.linuxbios.org/index.php/Etherboot This page is a very good idea to visit! //Peter From yinghai.lu at AMD.com Fri Sep 2 21:15:13 2005 From: yinghai.lu at AMD.com (Lu, Yinghai) Date: Fri, 2 Sep 2005 12:15:13 -0700 Subject: [LinuxBIOS] Building Linuxbiosv2 Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E060FA@ssvlexmb2.amd.com> Yes, But you can not enable filo in Etherboot.... YH From stuge-linuxbios at cdy.org Fri Sep 2 22:05:09 2005 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Fri, 2 Sep 2005 22:05:09 +0200 Subject: [LinuxBIOS] Building Linuxbiosv2 In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4201E060FA@ssvlexmb2.amd.com> References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E060FA@ssvlexmb2.amd.com> Message-ID: <20050902200509.27615.qmail@cdy.org> On Fri, Sep 02, 2005 at 12:15:13PM -0700, Lu, Yinghai wrote: > Yes, But you can not enable filo in Etherboot.... I haven't tried so you may be right, but I can select ide_disk in the device list before clicking Configure and CONFIG_FILO is available in the options list. Anyway, nothing beats source tarball if you want to control what you get! :) //Peter From jschildt at lnxi.com Fri Sep 2 22:44:24 2005 From: jschildt at lnxi.com (Jason Schildt) Date: Fri, 2 Sep 2005 14:44:24 -0600 Subject: [LinuxBIOS] LNXI merge: lnxi-patch-00/16 Message-ID: <20050902204424.GC30635@zoot.lnxi.com> All, I've taken the ill-fated merge attempt from a few weeks ago and have reworked it into 16 smaller, logical patches. I've also made certain that in the end, when all patches are applied all of the touched boards will build. Each patch I submit will consist of a brief description of what was changed and why, as well as a diffstat and the patch itself. I'll start submitting the diffs for review. --jason-- -- Jason W. Schildt LinuxBIOS Software Engineer Linux Networx From jschildt at lnxi.com Sat Sep 3 00:03:29 2005 From: jschildt at lnxi.com (jason schildt) Date: Fri, 02 Sep 2005 16:03:29 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-05/16 Message-ID: DESCRIPTION: ------------------------------------------------- ## lnxi-patch-5 ## src/superio/NSC/pc87360/superio.c Bug fix from &pnp_ops to &ops DIFFSTAT: ------------------------------------------------- superio.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) PATCH: ------------------------------------------------- Index: superio/NSC/pc87360/superio.c =================================================================== --- superio/NSC/pc87360/superio.c (revision 1105) +++ superio/NSC/pc87360/superio.c (working copy) @@ -66,7 +66,7 @@ static void enable_dev(struct device *dev) { - pnp_enable_devices(dev, &pnp_ops, + pnp_enable_devices(dev, &ops, sizeof(pnp_dev_info)/sizeof(pnp_dev_info[0]), pnp_dev_info); } -- Jason W. Schildt LinuxBIOS Software Engineer Linux Networx From jschildt at lnxi.com Sat Sep 3 00:03:29 2005 From: jschildt at lnxi.com (jason schildt) Date: Fri, 02 Sep 2005 16:03:29 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-08/16 Message-ID: DESCRIPTION: ---------------------------------------------------- ## lnxi-patch-8 ## src/mainboard/arima/hdama/mptable.c Add smp_write_processors_inorder() to workaround 2.6.11 bug. dynamically compute ioapic_id vs. hardcode. Add SATA support. Added reboot_if_hotswap() to catch bad board strapping hardware bug. DIFFSTAT: ---------------------------------------------------- mptable.c | 213 ++++++++++++++++++++++++++++++++++++++++++++++++-------------- 1 files changed, 167 insertions(+), 46 deletions(-) PATCH: ---------------------------------------------------- Index: mainboard/arima/hdama/mptable.c =================================================================== --- mainboard/arima/hdama/mptable.c (revision 1105) +++ mainboard/arima/hdama/mptable.c (working copy) @@ -3,7 +3,61 @@ #include #include #include +#include +#include +#include +#define HT_INIT_CONTROL 0x6c +#define HTIC_BIOSR_Detect (1<<5) + +/* If we assume a symmetric processor configuration we can + * get all of the information we need to write the processor + * entry from the bootstrap processor. + * Plus I don't think linux really even cares. + * Having the proper apicid's in the table so the non-bootstrap + * processors can be woken up should be enough. + */ +void smp_write_processors_inorder(struct mp_config_table *mc) +{ + int boot_apic_id; + int order_id; + unsigned apic_version; + unsigned cpu_features; + unsigned cpu_feature_flags; + struct cpuid_result result; + device_t cpu; + + boot_apic_id = lapicid(); + apic_version = lapic_read(LAPIC_LVR) & 0xff; + result = cpuid(1); + cpu_features = result.eax; + cpu_feature_flags = result.edx; + /* order the output of the cpus to fix a bug in kernel 6 11 */ + for(order_id = 0;order_id <256; order_id++) { + for(cpu = all_devices; cpu; cpu = cpu->next) { + unsigned long cpu_flag; + if ((cpu->path.type != DEVICE_PATH_APIC) || + (cpu->bus->dev->path.type != DEVICE_PATH_APIC_CLUSTER)) + { + continue; + } + if (!cpu->enabled) { + continue; + } + cpu_flag = MPC_CPU_ENABLED; + if (boot_apic_id == cpu->path.u.apic.apic_id) { + cpu_flag = MPC_CPU_ENABLED | MPC_CPU_BOOTPROCESSOR; + } + if(cpu->path.u.apic.apic_id == order_id) { + smp_write_processor(mc, + cpu->path.u.apic.apic_id, apic_version, + cpu_flag, cpu_features, cpu_feature_flags); + break; + } + } + } +} + static unsigned node_link_to_bus(unsigned node, unsigned link) { device_t dev; @@ -38,6 +92,21 @@ return 0; } +unsigned max_apicid(void) +{ + unsigned max_apicid; + device_t dev; + max_apicid = 0; + for(dev = all_devices; dev; dev = dev->next) { + if (dev->path.type != DEVICE_PATH_APIC) + continue; + if (dev->path.u.apic.apic_id > max_apicid) { + max_apicid = dev->path.u.apic.apic_id; + } + } + return max_apicid; +} + void *smp_write_config_table(void *v) { static const char sig[4] = "PCMP"; @@ -50,6 +119,10 @@ unsigned char bus_8131_1; unsigned char bus_8131_2; unsigned char bus_8111_1; + unsigned apicid_base; + unsigned apicid_8111; + unsigned apicid_8131_1; + unsigned apicid_8131_2; mc = (void *)(((char *)v) + SMP_FLOATING_TABLE_LEN); memset(mc, 0, sizeof(*mc)); @@ -68,8 +141,12 @@ mc->mpe_checksum = 0; mc->reserved = 0; - smp_write_processors(mc); + smp_write_processors_inorder(mc); + apicid_base = max_apicid() + 1; + apicid_8111 = apicid_base; + apicid_8131_1 = apicid_base + 1; + apicid_8131_2 = apicid_base + 2; { device_t dev; @@ -124,7 +201,7 @@ smp_write_bus(mc, bus_isa, "ISA "); /* IOAPIC handling */ - smp_write_ioapic(mc, 2, 0x11, 0xfec00000); + smp_write_ioapic(mc, apicid_8111, 0x11, 0xfec00000); { device_t dev; struct resource *res; @@ -133,7 +210,7 @@ if (dev) { res = find_resource(dev, PCI_BASE_ADDRESS_0); if (res) { - smp_write_ioapic(mc, 0x03, 0x11, res->base); + smp_write_ioapic(mc, apicid_8131_1, 0x11, res->base); } } /* 8131 apic 4 */ @@ -141,44 +218,44 @@ if (dev) { res = find_resource(dev, PCI_BASE_ADDRESS_0); if (res) { - smp_write_ioapic(mc, 0x04, 0x11, res->base); + smp_write_ioapic(mc, apicid_8131_2, 0x11, res->base); } } } /* ISA backward compatibility interrupts */ smp_write_intsrc(mc, mp_ExtINT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x00, 0x02, 0x00); + bus_isa, 0x00, apicid_8111, 0x00); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x01, 0x02, 0x01); + bus_isa, 0x01, apicid_8111, 0x01); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x00, 0x02, 0x02); + bus_isa, 0x00, apicid_8111, 0x02); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x03, 0x02, 0x03); + bus_isa, 0x03, apicid_8111, 0x03); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x04, 0x02, 0x04); + bus_isa, 0x04, apicid_8111, 0x04); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x05, 0x02, 0x05); + bus_isa, 0x05, apicid_8111, 0x05); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x06, 0x02, 0x06); + bus_isa, 0x06, apicid_8111, 0x06); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x07, 0x02, 0x07); + bus_isa, 0x07, apicid_8111, 0x07); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x08, 0x02, 0x08); + bus_isa, 0x08, apicid_8111, 0x08); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x09, 0x02, 0x09); + bus_isa, 0x09, apicid_8111, 0x09); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x0a, 0x02, 0x0a); + bus_isa, 0x0a, apicid_8111, 0x0a); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x0b, 0x02, 0x0b); + bus_isa, 0x0b, apicid_8111, 0x0b); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x0c, 0x02, 0x0c); + bus_isa, 0x0c, apicid_8111, 0x0c); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x0d, 0x02, 0x0d); + bus_isa, 0x0d, apicid_8111, 0x0d); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x0e, 0x02, 0x0e); + bus_isa, 0x0e, apicid_8111, 0x0e); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x0f, 0x02, 0x0f); + bus_isa, 0x0f, apicid_8111, 0x0f); /* Standard local interrupt assignments */ smp_write_lintsrc(mc, mp_ExtINT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, @@ -188,46 +265,48 @@ /* PCI Ints: Type Trigger Polarity Bus ID PCIDEVNUM|IRQ APIC ID PIN# */ /* On board nics */ - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x03<<2)|0, 0x02, 0x13); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x04<<2)|0, 0x02, 0x13); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x03<<2)|0, apicid_8111, 0x13); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x04<<2)|0, apicid_8111, 0x13); + /* On board SATA */ + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x05<<2)|0, apicid_8111, 0x11); /* PCI Slot 1 */ - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x01<<2)|0, 0x02, 0x11); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x01<<2)|1, 0x02, 0x12); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x01<<2)|2, 0x02, 0x13); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x01<<2)|3, 0x02, 0x10); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x01<<2)|0, apicid_8111, 0x11); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x01<<2)|1, apicid_8111, 0x12); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x01<<2)|2, apicid_8111, 0x13); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x01<<2)|3, apicid_8111, 0x10); /* PCI Slot 2 */ - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x02<<2)|0, 0x02, 0x12); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x02<<2)|1, 0x02, 0x13); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x02<<2)|2, 0x02, 0x10); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x02<<2)|3, 0x02, 0x11); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x02<<2)|0, apicid_8111, 0x12); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x02<<2)|1, apicid_8111, 0x13); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x02<<2)|2, apicid_8111, 0x10); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x02<<2)|3, apicid_8111, 0x11); /* PCI Slot 3 */ - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x01<<2)|0, 0x02, 0x11); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x01<<2)|1, 0x02, 0x12); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x01<<2)|2, 0x02, 0x13); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x01<<2)|3, 0x02, 0x10); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x01<<2)|0, apicid_8111, 0x11); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x01<<2)|1, apicid_8111, 0x12); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x01<<2)|2, apicid_8111, 0x13); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x01<<2)|3, apicid_8111, 0x10); /* PCI Slot 4 */ - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x02<<2)|0, 0x02, 0x12); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x02<<2)|1, 0x02, 0x13); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x02<<2)|2, 0x02, 0x10); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x02<<2)|3, 0x02, 0x11); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x02<<2)|0, apicid_8111, 0x12); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x02<<2)|1, apicid_8111, 0x13); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x02<<2)|2, apicid_8111, 0x10); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x02<<2)|3, apicid_8111, 0x11); /* PCI Slot 5 */ #warning "FIXME get the irqs right, it's just hacked to work for now" - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x05<<2)|0, 0x02, 0x11); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x05<<2)|1, 0x02, 0x12); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x05<<2)|2, 0x02, 0x13); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x05<<2)|3, 0x02, 0x10); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x05<<2)|0, apicid_8111, 0x11); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x05<<2)|1, apicid_8111, 0x12); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x05<<2)|2, apicid_8111, 0x13); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x05<<2)|3, apicid_8111, 0x10); /* PCI Slot 6 */ #warning "FIXME get the irqs right, it's just hacked to work for now" - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x04<<2)|0, 0x02, 0x10); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x04<<2)|1, 0x02, 0x11); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x04<<2)|2, 0x02, 0x12); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x04<<2)|3, 0x02, 0x13); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x04<<2)|0, apicid_8111, 0x10); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x04<<2)|1, apicid_8111, 0x11); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x04<<2)|2, apicid_8111, 0x12); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x04<<2)|3, apicid_8111, 0x13); /* There is no extension information... */ @@ -239,9 +318,51 @@ return smp_next_mpe_entry(mc); } +void reboot_if_hotswap(void) +{ + /* Hack patch work around for hot swap enable 33mhz problem */ + device_t dev; + uint32_t data; + unsigned long htic; + int reset; + int i; + + reset = 0; + printk_debug("Looking for bad PCIX MHz input\n"); + dev = dev_find_slot(1, PCI_DEVFN(0x02,0)); + data = pci_read_config32(dev, 0xa0); + if(!(((data>>16)&0x03)==0x03)) { + reset=1; + printk_debug("Bad PCIX MHz - Reset\n"); + } + printk_debug("Looking for bad Hot Swap Enable\n"); + dev = dev_find_slot(1, PCI_DEVFN(0x01,0)); + data = pci_read_config32(dev, 0x48); + if(data & 0x0c) { + reset=1; + printk_debug("Bad Hot Swap start - Reset\n"); + } + if(reset) { + /* enable cf9 */ + dev = dev_find_slot(node_link_to_bus(0, 0), PCI_DEVFN(0x04,3)); + pci_write_config8(dev, 0x41, 0xf1); + /* reset */ + dev = dev_find_slot(0, PCI_DEVFN(0x18,0)); + htic = pci_read_config32(dev, HT_INIT_CONTROL); + htic &= ~HTIC_BIOSR_Detect; + pci_write_config32(dev, HT_INIT_CONTROL, htic); + outb(0x0e, 0x0cf9); + } + else { + printk_debug("OK 133MHz & Hot Swap is off\n"); + } +} + unsigned long write_smp_table(unsigned long addr) { void *v; + reboot_if_hotswap(); + v = smp_write_floating_table(addr); return (unsigned long)smp_write_config_table(v); } -- Jason W. Schildt LinuxBIOS Software Engineer Linux Networx From jschildt at lnxi.com Sat Sep 3 00:03:29 2005 From: jschildt at lnxi.com (jason schildt) Date: Fri, 02 Sep 2005 16:03:29 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-07/16 Message-ID: DESCRIPTION: ----------------------------------------- ## lnxi-patch-7 ## src/mainboard/arima/hdama/Config.lb Allow cpu autodetection code to do its job instead of hardcoding it. DIFFSTAT: ----------------------------------------- Config.lb | 13 +++++-------- 1 files changed, 5 insertions(+), 8 deletions(-) PATCH: ----------------------------------------- Index: mainboard/arima/hdama/Config.lb =================================================================== --- mainboard/arima/hdama/Config.lb (revision 1105) +++ mainboard/arima/hdama/Config.lb (working copy) @@ -129,6 +129,11 @@ # config for arima/hdama chip northbridge/amd/amdk8/root_complex + device apic_cluster 0 on + chip cpu/amd/socket_940 + device apic 0 on end + end + end device pci_domain 0 on chip northbridge/amd/amdk8 device pci 18.0 on # northbridge @@ -317,13 +322,5 @@ device pci 19.3 on end end end - device apic_cluster 0 on - chip cpu/amd/socket_940 - device apic 0 on end - end - chip cpu/amd/socket_940 - device apic 1 on end - end - end end -- Jason W. Schildt LinuxBIOS Software Engineer Linux Networx From jschildt at lnxi.com Sat Sep 3 00:03:29 2005 From: jschildt at lnxi.com (jason schildt) Date: Fri, 02 Sep 2005 16:03:29 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-09/16 Message-ID: DESCRIPTION: ----------------------------------------- ## lnxi-patch-9 ## src/mainboard/arima/hdama/Options.lb Enable Dualcore in hdama and max_cpus=4. default CONFIG_LOGICAL_CPUS=1 src/mainboard/arima/hdama/cmos.layout included dualcore support. DIFFSTAT: ----------------------------------------- Options.lb | 8 +++++++- cmos.layout | 1 + 2 files changed, 8 insertions(+), 1 deletion(-) PATCH: ----------------------------------------- Index: mainboard/arima/hdama/Options.lb =================================================================== --- mainboard/arima/hdama/Options.lb (revision 1105) +++ mainboard/arima/hdama/Options.lb (working copy) @@ -49,6 +49,7 @@ uses OBJCOPY uses CONFIG_CONSOLE_VGA uses CONFIG_PCI_ROM_RUN +uses CONFIG_LOGICAL_CPUS uses CONFIG_USE_INIT @@ -57,6 +58,11 @@ ### ## +## CONFIG_LOGICAL_CPUS enables dual core support +## +default CONFIG_LOGICAL_CPUS=1 + +## ## ROM_SIZE is the size of boot ROM that this board will use. ## default ROM_SIZE=524288 @@ -105,7 +111,7 @@ ## Only worry about 2 micro processors ## default CONFIG_SMP=1 -default CONFIG_MAX_CPUS=2 +default CONFIG_MAX_CPUS=4 default CONFIG_MAX_PHYSICAL_CPUS=2 ## Index: mainboard/arima/hdama/cmos.layout =================================================================== --- mainboard/arima/hdama/cmos.layout (revision 1105) +++ mainboard/arima/hdama/cmos.layout (working copy) @@ -32,6 +32,7 @@ 395 1 e 1 hw_scrubber 396 1 e 1 interleave_chip_selects 397 2 e 8 max_mem_clock +399 1 e 2 dual_core 400 1 e 1 power_on_after_fail 412 4 e 6 debug_level 416 4 e 7 boot_first -- Jason W. Schildt LinuxBIOS Software Engineer Linux Networx From jschildt at lnxi.com Sat Sep 3 00:03:29 2005 From: jschildt at lnxi.com (jason schildt) Date: Fri, 02 Sep 2005 16:03:29 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-06/16 Message-ID: DESCRIPTION: ---------------------------------------------- ## lnxi-patch-6 ## src/cpu/x86/tsc/delay_tsc.c cpu_relax() gets called unconditionally. DIFFSTAT: ---------------------------------------------- delay_tsc.c | 4 ---- 1 files changed, 4 deletions(-) PATCH: ---------------------------------------------- Index: delay_tsc.c =================================================================== --- delay_tsc.c (revision 1105) +++ delay_tsc.c (working copy) @@ -159,11 +159,7 @@ count = rdtscll(); stop = clocks + count; while(stop > count) { -#ifdef CONFIG_SMP -#if CONFIG_SMP == 1 cpu_relax(); -#endif -#endif count = rdtscll(); } } -- Jason W. Schildt LinuxBIOS Software Engineer Linux Networx From jschildt at lnxi.com Sat Sep 3 00:03:28 2005 From: jschildt at lnxi.com (jason schildt) Date: Fri, 02 Sep 2005 16:03:28 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch02/16 Message-ID: DESCRIPTION: --------------------------------------------------------- ## lnxi-patch-2 ## - (3)files src/southbridge/amd/amd8111/amd8111_lpc.c powermanagment removed. copied to public tree src/southbridge/amd/amd8111/Config.lb src/southbridge/amd/amd8111/amd8111_usb.c uncommented amd8111_enable DIFFSTAT: --------------------------------------------------------- Config.lb | 9 ++++----- amd8111_lpc.c | 12 ++++-------- amd8111_usb.c | 2 +- 3 files changed, 9 insertions(+), 14 deletions(-) PATCH: --------------------------------------------------------- Index: amd8111_lpc.c =================================================================== --- amd8111_lpc.c (revision 1105) +++ amd8111_lpc.c (working copy) @@ -84,7 +84,7 @@ return; } printk_spew("for IRQ, reg 0x%08x value 0x%08x 0x%08x\n", - a->reg, a->value_low, a->value_high); + a->reg, a->value_low, a->value_high); } } @@ -113,13 +113,9 @@ byte = pci_read_config8(dev, 0x46); pci_write_config8(dev, 0x46, byte | (1<<0)); - /* power after power fail */ + /* Enable 5Mib Rom window */ byte = pci_read_config8(dev, 0x43); - if (pwr_on) { - byte &= ~(1<<6); - } else { - byte |= (1<<6); - } + byte |= 0xC0; pci_write_config8(dev, 0x43, byte); /* Enable Port 92 fast reset */ @@ -179,7 +175,7 @@ static void lpci_set_subsystem(device_t dev, unsigned vendor, unsigned device) { pci_write_config32(dev, 0x70, - ((device & 0xffff) << 16) | (vendor & 0xffff)); + ((device & 0xffff) << 16) | (vendor & 0xffff)); } static struct pci_operations lops_pci = { Index: Config.lb =================================================================== --- Config.lb (revision 1105) +++ Config.lb (working copy) @@ -1,12 +1,11 @@ config chip.h driver amd8111.o -#driver amd8111_usb.o +driver amd8111_usb.o driver amd8111_lpc.o driver amd8111_ide.o driver amd8111_acpi.o -#driver amd8111_usb2.o -#driver amd8111_ac97.o -#driver amd8111_nic.o +driver amd8111_usb2.o +driver amd8111_ac97.o +driver amd8111_nic.o driver amd8111_pci.o driver amd8111_smbus.o -object amd8111_reset.o Index: amd8111_usb.c =================================================================== --- amd8111_usb.c (revision 1105) +++ amd8111_usb.c (working copy) @@ -26,7 +26,7 @@ .enable_resources = pci_dev_enable_resources, .init = 0, .scan_bus = scan_static_bus, -// .enable = amd8111_enable, + .enable = amd8111_enable, .ops_pci = &lops_pci, }; -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From jschildt at lnxi.com Sat Sep 3 00:03:29 2005 From: jschildt at lnxi.com (jason schildt) Date: Fri, 02 Sep 2005 16:03:29 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-11/16 Message-ID: DESCRIPTION: ------------------------------------------------ ## lnxi-patch-11 ## src/northbridge/amd/amdk8/incoherent_ht.c Removed K8_HT_FREQ_1G test as we can now compile this with romcc. Bug fix added to ht_optimize_link() To ignore status bits when we read the link freq. Comment added that suggests s/uint8_t/unsigned/g that could save code generated by romcc. DIFFSTAT: ------------------------------------------------ incoherent_ht.c | 22 ++++++++++++---------- 1 files changed, 12 insertions(+), 10 deletions(-) PATCH: ------------------------------------------------ Index: northbridge/amd/amdk8/incoherent_ht.c =================================================================== --- northbridge/amd/amdk8/incoherent_ht.c (revision 1105) +++ northbridge/amd/amdk8/incoherent_ht.c (working copy) @@ -1,15 +1,16 @@ /* This should be done by Eric 2004.12 yhlu add multi ht chain dynamically support + */ #include #include #include -#ifndef K8_HT_FREQ_1G_SUPPORT - #define K8_HT_FREQ_1G_SUPPORT 0 -#endif - +/* We can reduce the size of code generated by romcc by + * changing all of the fixed size types that live in registers + * into simple unsigned variables. (ie s/uint8_t/unsigned/g) + */ #ifndef K8_SCAN_PCI_BUS #define K8_SCAN_PCI_BUS 0 #endif @@ -130,21 +131,20 @@ /* AMD 8131 Errata 48 */ if (id == (PCI_VENDOR_ID_AMD | (PCI_DEVICE_ID_AMD_8131_PCIX << 16))) { freq_cap &= ~(1 << HT_FREQ_800Mhz); - return freq_cap; } /* AMD 8151 Errata 23 */ if (id == (PCI_VENDOR_ID_AMD | (PCI_DEVICE_ID_AMD_8151_SYSCTRL << 16))) { freq_cap &= ~(1 << HT_FREQ_800Mhz); - return freq_cap; } /* AMD K8 Unsupported 1Ghz? */ if (id == (PCI_VENDOR_ID_AMD | (0x1100 << 16))) { - #if K8_HT_FREQ_1G_SUPPORT == 1 - if (is_cpu_pre_e0()) // CK804 support 1G? - #endif - freq_cap &= ~(1 << HT_FREQ_1000Mhz); + /* Supported starting with E0 */ + device_t dev_2 = PCI_DEV(0,0x18,2); + if(pci_read_config32(dev_2,0x9c) < 0x20f00) { + freq_cap &= ~(1 << HT_FREQ_1000Mhz); + } } return freq_cap; @@ -199,8 +199,10 @@ /* See if I am changing the link freqency */ old_freq = pci_read_config8(dev1, pos1 + LINK_FREQ(offs1)); + old_freq &= 0x0f; needs_reset |= old_freq != freq; old_freq = pci_read_config8(dev2, pos2 + LINK_FREQ(offs2)); + old_freq &= 0x0f; needs_reset |= old_freq != freq; /* Set the Calulcated link frequency */ -- Jason W. Schildt LinuxBIOS Software Engineer Linux Networx From jschildt at lnxi.com Sat Sep 3 00:03:29 2005 From: jschildt at lnxi.com (jason schildt) Date: Fri, 02 Sep 2005 16:03:29 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-03/16 Message-ID: DESCRIPTION: ----------------------------------------------------------- ## lnxi-patch-3 ## - (1)file src/cpu/x86/mtrr/earlymtrr.c Add early_mtrr_init_detected(). A generic x86 init style reset detection. DIFFSTAT: ------------------------------------------------------------ earlymtrr.c | 13 +++++++++++++ 1 files changed, 13 insertions(+) PATCH: ------------------------------------------------------------ Index: cpu/x86/mtrr/earlymtrr.c =================================================================== --- cpu/x86/mtrr/earlymtrr.c (revision 1105) +++ cpu/x86/mtrr/earlymtrr.c (working copy) @@ -117,4 +117,17 @@ enable_cache(); } +static int early_mtrr_init_detected(void) +{ + msr_t msr; + /* See if MTRR's are enabled. + * a #RESET disables them while an #INIT + * preserves their state. This works + * on both Intel and AMD cpus, at least + * according to the documentation. + */ + msr = rdmsr(MTRRdefType_MSR); + return msr.lo & 0x00000800; +} + #endif /* EARLYMTRR_C */ -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From jschildt at lnxi.com Sat Sep 3 00:03:31 2005 From: jschildt at lnxi.com (jason schildt) Date: Fri, 02 Sep 2005 16:03:31 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-14/16 Message-ID: DESCRIPTION: ---------------------------------------------- ## lnxi-patch-14 ## src/mainboard/arima/hdama/mptable.c Removed: max_apicid() renamed it to max_lapicid() and moved it into generic code /cpu/x86/lapic/lapic.c (See next) src/cpu/x86/lapic/lapic.c Added: generic max_lapicid() to replace get_apicid_base() src/mainboard/.../mptable.c Replaced: get_apicid_base() with max_lapicid() tyan/s2850/mptable.c tyan/s2881/mptable.c tyan/s2882/mptable.c tyan/s2891/mptable.c tyan/s4880/mptable.c tyan/s2892/mptable.c tyan/s2875/mptable.c tyan/s4882/mptable.c tyan/s2885/mptable.c tyan/s2895/mptable.c DIFFSTAT: ---------------------------------------------- ../cpu/x86/lapic/lapic.c | 24 +++++ arima/hdama/mptable.c | 198 ++++++++++++++++++++++++++++++++++++----------- tyan/s2850/mptable.c | 6 - tyan/s2875/mptable.c | 6 - tyan/s2881/mptable.c | 6 - tyan/s2882/mptable.c | 6 - tyan/s2885/mptable.c | 7 - tyan/s2891/mptable.c | 6 - tyan/s2892/mptable.c | 6 - tyan/s2895/mptable.c | 6 - tyan/s4880/mptable.c | 6 - tyan/s4882/mptable.c | 2 12 files changed, 187 insertions(+), 92 deletions(-) PATCH: ---------------------------------------------- Index: tyan/s2850/mptable.c =================================================================== --- tyan/s2850/mptable.c (revision 1105) +++ tyan/s2850/mptable.c (working copy) @@ -107,11 +107,7 @@ /*I/O APICs: APIC ID Version State Address*/ -#if CONFIG_LOGICAL_CPUS==1 - apicid_base = get_apicid_base(1); -#else - apicid_base = CONFIG_MAX_PHYSICAL_CPUS; -#endif + apicid_base = max_lapicid() + 1; apicid_8111 = apicid_base+0; smp_write_ioapic(mc, apicid_8111, 0x11, 0xfec00000); Index: tyan/s2875/mptable.c =================================================================== --- tyan/s2875/mptable.c (revision 1105) +++ tyan/s2875/mptable.c (working copy) @@ -123,11 +123,7 @@ smp_write_bus(mc, bus_isa, "ISA "); /*I/O APICs: APIC ID Version State Address*/ -#if CONFIG_LOGICAL_CPUS==1 - apicid_base = get_apicid_base(1); -#else - apicid_base = CONFIG_MAX_PHYSICAL_CPUS; -#endif + apicid_base = max_lapicid() + 1; apicid_8111 = apicid_base+0; smp_write_ioapic(mc, apicid_8111, 0x11, 0xfec00000); Index: tyan/s2881/mptable.c =================================================================== --- tyan/s2881/mptable.c (revision 1105) +++ tyan/s2881/mptable.c (working copy) @@ -136,11 +136,7 @@ /*I/O APICs: APIC ID Version State Address*/ -#if CONFIG_LOGICAL_CPUS - apicid_base = get_apicid_base(3); -#else - apicid_base = CONFIG_MAX_PHYSICAL_CPUS; -#endif + apicid_base = max_lapicid() + 1; apicid_8111 = apicid_base+0; apicid_8131_1 = apicid_base+1; apicid_8131_2 = apicid_base+2; Index: tyan/s2882/mptable.c =================================================================== --- tyan/s2882/mptable.c (revision 1105) +++ tyan/s2882/mptable.c (working copy) @@ -134,11 +134,7 @@ /*I/O APICs: APIC ID Version State Address*/ -#if CONFIG_LOGICAL_CPUS==1 - apicid_base = get_apicid_base(3); -#else - apicid_base = CONFIG_MAX_PHYSICAL_CPUS; -#endif + apicid_base = max_lapicid() + 1; apicid_8111 = apicid_base+0; apicid_8131_1 = apicid_base+1; apicid_8131_2 = apicid_base+2; Index: tyan/s2885/mptable.c =================================================================== --- tyan/s2885/mptable.c (revision 1105) +++ tyan/s2885/mptable.c (working copy) @@ -158,14 +158,11 @@ smp_write_bus(mc, bus_isa, "ISA "); /*I/O APICs: APIC ID Version State Address*/ -#if CONFIG_LOGICAL_CPUS==1 - apicid_base = get_apicid_base(3); -#else - apicid_base = CONFIG_MAX_PHYSICAL_CPUS; -#endif + apicid_base = max_lapicid() + 1; apicid_8111 = apicid_base+0; apicid_8131_1 = apicid_base+1; apicid_8131_2 = apicid_base+2; + smp_write_ioapic(mc, apicid_8111, 0x11, 0xfec00000); //8111 { device_t dev; Index: tyan/s2891/mptable.c =================================================================== --- tyan/s2891/mptable.c (revision 1105) +++ tyan/s2891/mptable.c (working copy) @@ -204,11 +204,7 @@ smp_write_bus(mc, bus_isa, "ISA "); /*I/O APICs: APIC ID Version State Address*/ -#if CONFIG_LOGICAL_CPUS==1 - apicid_base = get_apicid_base(3); -#else - apicid_base = CONFIG_MAX_PHYSICAL_CPUS; -#endif + apicid_base = max_lapicid() + 1; apicid_ck804 = apicid_base; apicid_8131_1 = apicid_base+1; apicid_8131_2 = apicid_base+2; Index: tyan/s2892/mptable.c =================================================================== --- tyan/s2892/mptable.c (revision 1105) +++ tyan/s2892/mptable.c (working copy) @@ -204,11 +204,7 @@ smp_write_bus(mc, bus_isa, "ISA "); /*I/O APICs: APIC ID Version State Address*/ -#if CONFIG_LOGICAL_CPUS==1 - apicid_base = get_apicid_base(3); -#else - apicid_base = CONFIG_MAX_PHYSICAL_CPUS; -#endif + apicid_base = max_lapicid() + 1; apicid_ck804 = apicid_base; apicid_8131_1 = apicid_base+1; apicid_8131_2 = apicid_base+2; Index: tyan/s2895/mptable.c =================================================================== --- tyan/s2895/mptable.c (revision 1105) +++ tyan/s2895/mptable.c (working copy) @@ -284,11 +284,7 @@ smp_write_bus(mc, bus_isa, "ISA "); /*I/O APICs: APIC ID Version State Address*/ -#if CONFIG_LOGICAL_CPUS==1 - apicid_base = get_apicid_base(4); -#else - apicid_base = CONFIG_MAX_PHYSICAL_CPUS; -#endif + apicid_base = max_lapicid() + 1; apicid_ck804 = apicid_base; apicid_8131_1 = apicid_base+1; apicid_8131_2 = apicid_base+2; Index: tyan/s4880/mptable.c =================================================================== --- tyan/s4880/mptable.c (revision 1105) +++ tyan/s4880/mptable.c (working copy) @@ -135,11 +135,7 @@ /*I/O APICs: APIC ID Version State Address*/ -#if CONFIG_LOGICAL_CPUS==1 - apicid_base = get_apicid_base(3); -#else - apicid_base = CONFIG_MAX_PHYSICAL_CPUS; -#endif + apicid_base = max_lapicid() + 1; apicid_8111 = apicid_base+0; apicid_8131_1 = apicid_base+1; apicid_8131_2 = apicid_base+2; Index: tyan/s4882/mptable.c =================================================================== --- tyan/s4882/mptable.c (revision 1105) +++ tyan/s4882/mptable.c (working copy) @@ -94,7 +94,7 @@ /*I/O APICs: APIC ID Version State Address*/ #if CONFIG_LOGICAL_CPUS==1 - apicid_base = get_apicid_base(3); + apicid_base = max_lapicid() + 1; #else apicid_base = CONFIG_MAX_PHYSICAL_CPUS; #endif Index: ../cpu/x86/lapic/lapic.c =================================================================== --- ../cpu/x86/lapic/lapic.c (revision 1105) +++ ../cpu/x86/lapic/lapic.c (working copy) @@ -3,6 +3,8 @@ #include #include +#include + void setup_lapic(void) { /* this is so interrupts work. This is very limited scope -- @@ -70,3 +72,25 @@ printk_info("done.\n"); post_code(0x9b); } + +unsigned max_lapicid(void) +{ + /* Walk through the device tree and find the + maximum local apic id. + We use this when assigning apic ids to the + IOAPICs. + */ + + unsigned max_lapicid; + device_t dev; + max_lapicid = 0; + for(dev = all_devices; dev; dev = dev->next) { + if (dev->path.type != DEVICE_PATH_APIC) + continue; + if (dev->path.u.apic.apic_id > max_lapicid) { + max_lapicid = dev->path.u.apic.apic_id; + } + } + return max_lapicid; +} + Index: arima/hdama/mptable.c =================================================================== --- arima/hdama/mptable.c (revision 1105) +++ arima/hdama/mptable.c (working copy) @@ -3,7 +3,61 @@ #include #include #include +#include +#include +#include +#define HT_INIT_CONTROL 0x6c +#define HTIC_BIOSR_Detect (1<<5) + +/* If we assume a symmetric processor configuration we can + * get all of the information we need to write the processor + * entry from the bootstrap processor. + * Plus I don't think linux really even cares. + * Having the proper apicid's in the table so the non-bootstrap + * processors can be woken up should be enough. + */ +void smp_write_processors_inorder(struct mp_config_table *mc) +{ + int boot_apic_id; + int order_id; + unsigned apic_version; + unsigned cpu_features; + unsigned cpu_feature_flags; + struct cpuid_result result; + device_t cpu; + + boot_apic_id = lapicid(); + apic_version = lapic_read(LAPIC_LVR) & 0xff; + result = cpuid(1); + cpu_features = result.eax; + cpu_feature_flags = result.edx; + /* order the output of the cpus to fix a bug in kernel 6 11 */ + for(order_id = 0;order_id <256; order_id++) { + for(cpu = all_devices; cpu; cpu = cpu->next) { + unsigned long cpu_flag; + if ((cpu->path.type != DEVICE_PATH_APIC) || + (cpu->bus->dev->path.type != DEVICE_PATH_APIC_CLUSTER)) + { + continue; + } + if (!cpu->enabled) { + continue; + } + cpu_flag = MPC_CPU_ENABLED; + if (boot_apic_id == cpu->path.u.apic.apic_id) { + cpu_flag = MPC_CPU_ENABLED | MPC_CPU_BOOTPROCESSOR; + } + if(cpu->path.u.apic.apic_id == order_id) { + smp_write_processor(mc, + cpu->path.u.apic.apic_id, apic_version, + cpu_flag, cpu_features, cpu_feature_flags); + break; + } + } + } +} + static unsigned node_link_to_bus(unsigned node, unsigned link) { device_t dev; @@ -50,6 +104,10 @@ unsigned char bus_8131_1; unsigned char bus_8131_2; unsigned char bus_8111_1; + unsigned apicid_base; + unsigned apicid_8111; + unsigned apicid_8131_1; + unsigned apicid_8131_2; mc = (void *)(((char *)v) + SMP_FLOATING_TABLE_LEN); memset(mc, 0, sizeof(*mc)); @@ -68,8 +126,12 @@ mc->mpe_checksum = 0; mc->reserved = 0; - smp_write_processors(mc); + smp_write_processors_inorder(mc); + apicid_base = max_lapicid() + 1; + apicid_8111 = apicid_base; + apicid_8131_1 = apicid_base + 1; + apicid_8131_2 = apicid_base + 2; { device_t dev; @@ -124,7 +186,7 @@ smp_write_bus(mc, bus_isa, "ISA "); /* IOAPIC handling */ - smp_write_ioapic(mc, 2, 0x11, 0xfec00000); + smp_write_ioapic(mc, apicid_8111, 0x11, 0xfec00000); { device_t dev; struct resource *res; @@ -133,7 +195,7 @@ if (dev) { res = find_resource(dev, PCI_BASE_ADDRESS_0); if (res) { - smp_write_ioapic(mc, 0x03, 0x11, res->base); + smp_write_ioapic(mc, apicid_8131_1, 0x11, res->base); } } /* 8131 apic 4 */ @@ -141,44 +203,44 @@ if (dev) { res = find_resource(dev, PCI_BASE_ADDRESS_0); if (res) { - smp_write_ioapic(mc, 0x04, 0x11, res->base); + smp_write_ioapic(mc, apicid_8131_2, 0x11, res->base); } } } /* ISA backward compatibility interrupts */ smp_write_intsrc(mc, mp_ExtINT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x00, 0x02, 0x00); + bus_isa, 0x00, apicid_8111, 0x00); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x01, 0x02, 0x01); + bus_isa, 0x01, apicid_8111, 0x01); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x00, 0x02, 0x02); + bus_isa, 0x00, apicid_8111, 0x02); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x03, 0x02, 0x03); + bus_isa, 0x03, apicid_8111, 0x03); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x04, 0x02, 0x04); + bus_isa, 0x04, apicid_8111, 0x04); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x05, 0x02, 0x05); + bus_isa, 0x05, apicid_8111, 0x05); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x06, 0x02, 0x06); + bus_isa, 0x06, apicid_8111, 0x06); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x07, 0x02, 0x07); + bus_isa, 0x07, apicid_8111, 0x07); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x08, 0x02, 0x08); + bus_isa, 0x08, apicid_8111, 0x08); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x09, 0x02, 0x09); + bus_isa, 0x09, apicid_8111, 0x09); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x0a, 0x02, 0x0a); + bus_isa, 0x0a, apicid_8111, 0x0a); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x0b, 0x02, 0x0b); + bus_isa, 0x0b, apicid_8111, 0x0b); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x0c, 0x02, 0x0c); + bus_isa, 0x0c, apicid_8111, 0x0c); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x0d, 0x02, 0x0d); + bus_isa, 0x0d, apicid_8111, 0x0d); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x0e, 0x02, 0x0e); + bus_isa, 0x0e, apicid_8111, 0x0e); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, - bus_isa, 0x0f, 0x02, 0x0f); + bus_isa, 0x0f, apicid_8111, 0x0f); /* Standard local interrupt assignments */ smp_write_lintsrc(mc, mp_ExtINT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, @@ -188,46 +250,48 @@ /* PCI Ints: Type Trigger Polarity Bus ID PCIDEVNUM|IRQ APIC ID PIN# */ /* On board nics */ - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x03<<2)|0, 0x02, 0x13); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x04<<2)|0, 0x02, 0x13); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x03<<2)|0, apicid_8111, 0x13); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x04<<2)|0, apicid_8111, 0x13); + /* On board SATA */ + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x05<<2)|0, apicid_8111, 0x11); /* PCI Slot 1 */ - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x01<<2)|0, 0x02, 0x11); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x01<<2)|1, 0x02, 0x12); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x01<<2)|2, 0x02, 0x13); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x01<<2)|3, 0x02, 0x10); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x01<<2)|0, apicid_8111, 0x11); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x01<<2)|1, apicid_8111, 0x12); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x01<<2)|2, apicid_8111, 0x13); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x01<<2)|3, apicid_8111, 0x10); /* PCI Slot 2 */ - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x02<<2)|0, 0x02, 0x12); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x02<<2)|1, 0x02, 0x13); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x02<<2)|2, 0x02, 0x10); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x02<<2)|3, 0x02, 0x11); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x02<<2)|0, apicid_8111, 0x12); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x02<<2)|1, apicid_8111, 0x13); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x02<<2)|2, apicid_8111, 0x10); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x02<<2)|3, apicid_8111, 0x11); /* PCI Slot 3 */ - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x01<<2)|0, 0x02, 0x11); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x01<<2)|1, 0x02, 0x12); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x01<<2)|2, 0x02, 0x13); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x01<<2)|3, 0x02, 0x10); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x01<<2)|0, apicid_8111, 0x11); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x01<<2)|1, apicid_8111, 0x12); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x01<<2)|2, apicid_8111, 0x13); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x01<<2)|3, apicid_8111, 0x10); /* PCI Slot 4 */ - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x02<<2)|0, 0x02, 0x12); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x02<<2)|1, 0x02, 0x13); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x02<<2)|2, 0x02, 0x10); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x02<<2)|3, 0x02, 0x11); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x02<<2)|0, apicid_8111, 0x12); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x02<<2)|1, apicid_8111, 0x13); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x02<<2)|2, apicid_8111, 0x10); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x02<<2)|3, apicid_8111, 0x11); /* PCI Slot 5 */ #warning "FIXME get the irqs right, it's just hacked to work for now" - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x05<<2)|0, 0x02, 0x11); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x05<<2)|1, 0x02, 0x12); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x05<<2)|2, 0x02, 0x13); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x05<<2)|3, 0x02, 0x10); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x05<<2)|0, apicid_8111, 0x11); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x05<<2)|1, apicid_8111, 0x12); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x05<<2)|2, apicid_8111, 0x13); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x05<<2)|3, apicid_8111, 0x10); /* PCI Slot 6 */ #warning "FIXME get the irqs right, it's just hacked to work for now" - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x04<<2)|0, 0x02, 0x10); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x04<<2)|1, 0x02, 0x11); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x04<<2)|2, 0x02, 0x12); - smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x04<<2)|3, 0x02, 0x13); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x04<<2)|0, apicid_8111, 0x10); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x04<<2)|1, apicid_8111, 0x11); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x04<<2)|2, apicid_8111, 0x12); + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x04<<2)|3, apicid_8111, 0x13); /* There is no extension information... */ @@ -239,9 +303,51 @@ return smp_next_mpe_entry(mc); } +void reboot_if_hotswap(void) +{ + /* Hack patch work around for hot swap enable 33mhz problem */ + device_t dev; + uint32_t data; + unsigned long htic; + int reset; + int i; + + reset = 0; + printk_debug("Looking for bad PCIX MHz input\n"); + dev = dev_find_slot(1, PCI_DEVFN(0x02,0)); + data = pci_read_config32(dev, 0xa0); + if(!(((data>>16)&0x03)==0x03)) { + reset=1; + printk_debug("Bad PCIX MHz - Reset\n"); + } + printk_debug("Looking for bad Hot Swap Enable\n"); + dev = dev_find_slot(1, PCI_DEVFN(0x01,0)); + data = pci_read_config32(dev, 0x48); + if(data & 0x0c) { + reset=1; + printk_debug("Bad Hot Swap start - Reset\n"); + } + if(reset) { + /* enable cf9 */ + dev = dev_find_slot(node_link_to_bus(0, 0), PCI_DEVFN(0x04,3)); + pci_write_config8(dev, 0x41, 0xf1); + /* reset */ + dev = dev_find_slot(0, PCI_DEVFN(0x18,0)); + htic = pci_read_config32(dev, HT_INIT_CONTROL); + htic &= ~HTIC_BIOSR_Detect; + pci_write_config32(dev, HT_INIT_CONTROL, htic); + outb(0x0e, 0x0cf9); + } + else { + printk_debug("OK 133MHz & Hot Swap is off\n"); + } +} + unsigned long write_smp_table(unsigned long addr) { void *v; + reboot_if_hotswap(); + v = smp_write_floating_table(addr); return (unsigned long)smp_write_config_table(v); } -- Jason W. Schildt LinuxBIOS Software Engineer Linux Networx From jschildt at lnxi.com Sat Sep 3 00:03:29 2005 From: jschildt at lnxi.com (jason schildt) Date: Fri, 02 Sep 2005 16:03:29 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-04/16 Message-ID: DESCRIPTION: -------------------------------------------- ## lnxi-patch-4 Big Dual Core Changes ## - (8)files src/include/cpu/amd/dualcore.h Code Cleanup. src/cpu/amd/model_fxx/model_fxx_init.c Code cleanup: config guards in header. dynamic memory hoisting instead of hard coding. cpu ranges instead of exact cpu matching. naming change (dev -> cpu) src/cpu/amd/dualcore/dualcore.c Remove chunk with these function calls #if'd out: get_core_num_in_bsp() # Not used. set_apicid_cpuid_lo() # Used in Tyan Opteron boards. real_start_other_core() # Not used. start_other_core() # Not used. get_nodes() # Not used. start_other_cores() # Used in Tyan Opteron Boards. src/cpu/amd/dualcore/amd_sibling.c Make amd_sibling_init work and generalize get_node_core_id. src/cpu/amd/dualcore/dualcore_id.c Optimized struct node_core_id so that it fits in 1 register with romcc. src/northbridge/amd/amdk8/coherent_ht.c Dualcore cleanup work: Added startup_othercores() only look at low nibble to see link freq. src/northbridge/amd/amdk8/amdk8.h Added e0 register src/northbridge/amd/amdk8/northbridge.c Added dynamic memory hoisting - hoist_memory() included 2.6.11/12 kernel bug fix Cleaned up cpu_bus_scan() src/northbridge/amd/amdk8/raminit.c factored out set_dimm_map() from set_dimm_size() added e_step_cpu() This function holds the logic only needed for e-step. removed hardcoded memory hole - set_e0_mem_hole() DIFFSTAT: -------------------------------------------- cpu/amd/dualcore/amd_sibling.c | 180 +++++++++++------------------- cpu/amd/dualcore/dualcore.c | 127 ++++++++------------- cpu/amd/dualcore/dualcore_id.c | 4 cpu/amd/model_fxx/model_fxx_init.c | 98 +++++----------- include/cpu/amd/dualcore.h | 9 - northbridge/amd/amdk8/amdk8.h | 1 northbridge/amd/amdk8/coherent_ht.c | 89 +++++++------- northbridge/amd/amdk8/northbridge.c | 215 ++++++++++++------------------------ northbridge/amd/amdk8/raminit.c | 154 ++++++++++++------------- 9 files changed, 346 insertions(+), 531 deletions(-) PATCH: -------------------------------------------- Index: src/include/cpu/amd/dualcore.h =================================================================== --- src/include/cpu/amd/dualcore.h (revision 1105) +++ src/include/cpu/amd/dualcore.h (working copy) @@ -2,18 +2,13 @@ #define CPU_AMD_DUALCORE_H struct device; -void amd_sibling_init(struct device *cpu); -int is_e0_later_in_bsp(int nodeid); -unsigned int read_nb_cfg_54(void); - struct node_core_id { unsigned nodeid; unsigned coreid; }; -// it can be used to get unitid and coreid it running only -struct node_core_id get_node_core_id(unsigned int nb_cfg_54); -unsigned get_apicid_base(unsigned ioapic_num); +void amd_sibling_init(struct device *cpu, struct node_core_id id); +struct node_core_id get_node_core_id(void); #endif /* CPU_AMD_DUALCORE_H */ Index: src/cpu/amd/model_fxx/model_fxx_init.c =================================================================== --- src/cpu/amd/model_fxx/model_fxx_init.c (revision 1105) +++ src/cpu/amd/model_fxx/model_fxx_init.c (working copy) @@ -21,10 +21,7 @@ #include #include #include - -#if CONFIG_LOGICAL_CPUS==1 #include -#endif #include "model_fxx_msr.h" @@ -152,9 +149,6 @@ static void init_ecc_memory(unsigned node_id) { unsigned long startk, begink, endk; -#if K8_E0_MEM_HOLE_SIZEK != 0 - unsigned long hole_startk = 0, hole_endk = 0; -#endif unsigned long basek; struct mtrr_state mtrr_state; device_t f1_dev, f2_dev, f3_dev; @@ -199,25 +193,13 @@ startk = (pci_read_config32(f1_dev, 0x40 + (node_id*8)) & 0xffff0000) >> 2; endk = ((pci_read_config32(f1_dev, 0x44 + (node_id*8)) & 0xffff0000) >> 2) + 0x4000; -#if K8_E0_MEM_HOLE_SIZEK != 0 - if (!is_cpu_pre_e0()) { - uint32_t val; - val = pci_read_config32(f1_dev, 0xf0); - if((val & 1)==1) { - hole_startk = ((val & (0xff<<24)) >> 10); - hole_endk = ((val & (0xff<<8))<<(16-10)) - startk; - hole_endk += hole_startk; - } - } -#endif - /* Don't start too early */ begink = startk; if (begink < CONFIG_LB_MEM_TOPK) { begink = CONFIG_LB_MEM_TOPK; } - printk_debug("Clearing memory %uK - %uK: ", startk, endk); + printk_debug("Clearing memory %uK - %uK: ", begink, endk); /* Save the normal state */ save_mtrr_state(&mtrr_state); @@ -234,9 +216,6 @@ unsigned long size; void *addr; -#if K8_E0_MEM_HOLE_SIZEK != 0 - if ((basek >= hole_startk) && (basek < hole_endk)) continue; -#endif /* Report every 64M */ if ((basek % (64*1024)) == 0) { /* Restore the normal state */ @@ -340,6 +319,7 @@ /* Erratum 91 prefetch miss is handled in the kernel */ + /* Erratum 106 ... */ msr = rdmsr_amd(LS_CFG_MSR); msr.lo |= 1 << 25; @@ -350,7 +330,7 @@ msr.hi |= 1 << (43 - 32); wrmsr_amd(BU_CFG_MSR, msr); - if(is_cpu_d0()) { + if (is_cpu_pre_e0() && !is_cpu_pre_d0()) { /* Erratum 110 ...*/ msr = rdmsr_amd(CPU_ID_HYPER_EXT_FEATURES); msr.hi |=1; @@ -362,26 +342,34 @@ msr = rdmsr_amd(CPU_ID_EXT_FEATURES_MSR); msr.hi |=1; wrmsr_amd(CPU_ID_EXT_FEATURES_MSR, msr); + + /* Erratum 113 ... */ + msr = rdmsr_amd(BU_CFG_MSR); + msr.hi |= (1 << 16); + wrmsr_amd(BU_CFG_MSR, msr); } /* Erratum 122 */ - msr = rdmsr(HWCR_MSR); - msr.lo |= 1 << 6; - wrmsr(HWCR_MSR, msr); + if (!is_cpu_pre_c0()) { + msr = rdmsr(HWCR_MSR); + msr.lo |= 1 << 6; + wrmsr(HWCR_MSR, msr); + } + + /* Erratum 123? dual core deadlock? */ + /* Erratum 131 */ + msr = rdmsr(NB_CFG_MSR); + msr.lo |= 1 << 20; + wrmsr(NB_CFG_MSR, msr); + } -void model_fxx_init(device_t dev) +void model_fxx_init(device_t cpu) { unsigned long i; msr_t msr; -#if CONFIG_LOGICAL_CPUS struct node_core_id id; - unsigned siblings; - id.coreid=0; -#else - unsigned nodeid; -#endif /* Turn on caching if we haven't already */ x86_enable_cache(); @@ -404,43 +392,18 @@ /* Enable the local cpu apics */ setup_lapic(); -#if CONFIG_LOGICAL_CPUS == 1 - siblings = cpuid_ecx(0x80000008) & 0xff; + /* Find our node and core */ + id = get_node_core_id(); - id = get_node_core_id(read_nb_cfg_54()); // pre e0 nb_cfg_54 can not be set - - if(siblings>0) { - msr = rdmsr_amd(CPU_ID_FEATURES_MSR); - msr.lo |= 1 << 28; - wrmsr_amd(CPU_ID_FEATURES_MSR, msr); - - msr = rdmsr_amd(LOGICAL_CPUS_NUM_MSR); - msr.lo = (siblings+1)<<16; - wrmsr_amd(LOGICAL_CPUS_NUM_MSR, msr); - - msr = rdmsr_amd(CPU_ID_EXT_FEATURES_MSR); - msr.hi |= 1<<(33-32); - wrmsr_amd(CPU_ID_EXT_FEATURES_MSR, msr); - } - - - /* Is this a bad location? In particular can another node prefecth + /* Is this a bad location? In particular can another node prefetch * data from this node before we have initialized it? */ - if (id.coreid == 0) init_ecc_memory(id.nodeid); // only do it for core 0 -#else - /* Is this a bad location? In particular can another node prefecth - * data from this node before we have initialized it? - */ - nodeid = lapicid() & 0xf; - init_ecc_memory(nodeid); -#endif + if (id.coreid == 0) { + init_ecc_memory(id.nodeid); // only do it for core 0 + } -#if CONFIG_LOGICAL_CPUS==1 - /* Start up my cpu siblings */ -// if(id.coreid==0) amd_sibling_init(dev); // Don't need core1 is already be put in the CPU BUS in bus_cpu_scan -#endif - + /* Deal with sibling cpus */ + amd_sibling_init(cpu, id); } static struct device_operations cpu_dev_ops = { @@ -451,7 +414,7 @@ { X86_VENDOR_AMD, 0xf51 }, /* SH7-B3 */ { X86_VENDOR_AMD, 0xf58 }, /* SH7-C0 */ { X86_VENDOR_AMD, 0xf48 }, -#if 1 + { X86_VENDOR_AMD, 0xf5A }, /* SH7-CG */ { X86_VENDOR_AMD, 0xf4A }, { X86_VENDOR_AMD, 0xf7A }, @@ -483,7 +446,6 @@ { X86_VENDOR_AMD, 0x20fc2 }, { X86_VENDOR_AMD, 0x20f12 }, /* JH-E6 */ { X86_VENDOR_AMD, 0x20f32 }, -#endif { 0, 0 }, }; Index: src/cpu/amd/dualcore/dualcore.c =================================================================== --- src/cpu/amd/dualcore/dualcore.c (revision 1105) +++ src/cpu/amd/dualcore/dualcore.c (working copy) @@ -1,99 +1,68 @@ /* 2004.12 yhlu add dual core support */ - -#ifndef SET_NB_CFG_54 -#define SET_NB_CFG_54 1 -#endif - #include "cpu/amd/dualcore/dualcore_id.c" -static inline unsigned get_core_num_in_bsp(unsigned nodeid) +static void do_k8_init_and_stop_secondaries(void) { - return ((pci_read_config32(PCI_DEV(0, 0x18+nodeid, 3), 0xe8)>>12) & 3); -} - -static inline -#if SET_NB_CFG_54 == 1 - uint8_t -#else - void -#endif - set_apicid_cpuid_lo(void) { -#if SET_NB_CFG_54 - //for pre_e0, even we set nb_cfg_54, but it will still be 0 - //for e0 later you should use get_node_id(read_nb_cfg_54()) even for single core cpu - //get siblings via cpuid(0x80000008) ecx[7:0] - #if CONFIG_MAX_PHYSICAL_CPUS != 8 - if( get_core_num_in_bsp(0) == 0) { - /*first node only has one core, pre_e0 - all e0 single core installed don't need enable lo too, - So if mixing e0 single core and dual core, - don't put single core in first socket */ - return 0; - } - #endif + struct node_core_id id; + device_t dev; + unsigned apicid; + unsigned max_siblings; + msr_t msr; - if(read_option(CMOS_VSTART_dual_core, CMOS_VLEN_dual_core, 0) != 0) { // disable dual_core - return 0; - } + /* Skip this if there was a built in self test failure */ - // set the NB_CFG[54]=1; why the OS will be happy with that ??? - msr_t msr; - msr = rdmsr(NB_CFG_MSR); - msr.hi |= (1<<(54-32)); // InitApicIdCpuIdLo - wrmsr(NB_CFG_MSR, msr); + if (is_cpu_pre_e0()) { + id.nodeid = lapicid() & 0x7; + id.coreid = 0; + } else { + /* Which cpu are we on? */ + id = get_node_core_id_x(); - return 1; + /* Set NB_CFG_MSR + * Linux expect the core to be in the least signficant bits. + */ + msr = rdmsr(NB_CFG_MSR); + msr.hi |= (1<<(54-32)); // InitApicIdCpuIdLo + wrmsr(NB_CFG_MSR, msr); + } -#endif + /* For now assume all cpus have the same number of siblings */ + max_siblings = (cpuid_ecx(0x80000008) & 0xff) + 1; -} + /* Set the lapicid */ + lapic_write(LAPIC_ID,((id.nodeid*max_siblings) + id.coreid) << 24); -static inline void real_start_other_core(unsigned nodeid) -{ - uint32_t dword; - // set PCI_DEV(0, 0x18+nodeid, 3), 0x44 bit 27 to redirect all MC4 accesses and error logging to core0 - dword = pci_read_config32(PCI_DEV(0, 0x18+nodeid, 3), 0x44); - dword |= 1<<27; // NbMcaToMstCpuEn bit - pci_write_config32(PCI_DEV(0, 0x18+nodeid, 3), 0x44, dword); - // set PCI_DEV(0, 0x18+nodeid, 0), 0x68 bit 5 to start core1 - dword = pci_read_config32(PCI_DEV(0, 0x18+nodeid, 0), 0x68); - dword |= 1<<5; - pci_write_config32(PCI_DEV(0, 0x18+nodeid, 0), 0x68, dword); + /* Remember the cpuid */ + if (id.coreid == 0) { + dev = PCI_DEV(0, 0x18 + id.nodeid, 2); + pci_write_config32(dev, 0x9c, cpuid_eax(1)); + } + + /* Maybe call distinguish_cpu_resets only on the last core? */ + distinguish_cpu_resets(id.nodeid); + if (!boot_cpu()) { + stop_this_cpu(); + } } -//it is running on core0 of every node -static inline void start_other_core(unsigned nodeid) { - - if(read_option(CMOS_VSTART_dual_core, CMOS_VLEN_dual_core, 0) != 0) { // disable dual_core - return; - } - - if( get_core_num() >0) { // defined in dualcore_id.c - real_start_other_core(nodeid); - } -} - -static inline unsigned get_nodes(void) +static void k8_init_and_stop_secondaries(void) { - return ((pci_read_config32(PCI_DEV(0, 0x18, 0), 0x60)>>4) & 7) + 1; -} + /* This doesn't work with Cache As Ram because it messes with + the MTRR state, which breaks the init detection. + do_k8_init_and_stop_secondaries should be usable by CAR code. + */ -//it is running on core0 of node0 -static inline void start_other_cores(void) { - unsigned nodes; - unsigned nodeid; + int init_detected; - if(read_option(CMOS_VSTART_dual_core, CMOS_VLEN_dual_core, 0) != 0) { // disable dual_core - return; - } + init_detected = early_mtrr_init_detected(); + amd_early_mtrr_init(); - nodes = get_nodes(); - - for(nodeid=0; nodeid 0) { - real_start_other_core(nodeid); - } + enable_lapic(); + init_timer(); + if (init_detected) { + asm volatile ("jmp __cpu_reset"); } + do_k8_init_and_stop_secondaries(); } Index: src/cpu/amd/dualcore/amd_sibling.c =================================================================== --- src/cpu/amd/dualcore/amd_sibling.c (revision 1105) +++ src/cpu/amd/dualcore/amd_sibling.c (working copy) @@ -1,4 +1,5 @@ /* 2004.12 yhlu add dual core support */ +/* 24 June 2005 Cleaned up dual core support Eric Biederman */ #include #include @@ -14,59 +15,87 @@ static int first_time = 1; static int disable_siblings = !CONFIG_LOGICAL_CPUS; +void amd_sibling_init(device_t cpu, struct node_core_id id) +{ + unsigned long i; + unsigned siblings, max_siblings; + /* On the bootstrap processor see if I want sibling cpus enabled */ + if (first_time) { + first_time = 0; + get_option(&disable_siblings, "dual_core"); + } -int is_e0_later_in_bsp(int nodeid) -{ - uint32_t val; - uint32_t val_old; - int e0_later; - if(nodeid==0) { // we don't need to do that for node 0 in core0/node0 - return !is_cpu_pre_e0(); + siblings = cpuid_ecx(0x80000008) & 0xff; + printk_debug("%d Sibling Cores found\n", siblings); + + /* For now assume all cpus have the same number of siblings */ + max_siblings = siblings + 1; + + /* Wishlist? make dual cores look like hyperthreading */ + + /* See if I am a sibling cpu */ + if (disable_siblings && (id.coreid != 0)) { + cpu->enabled = 0; } - // d0 will be treated as e0 with this methods, but the d0 nb_cfg_54 always 0 - device_t dev; - dev = dev_find_slot(0, PCI_DEVFN(0x18+nodeid,2)); - if(!dev) return 0; - val_old = pci_read_config32(dev, 0x80); - val = val_old; - val |= (1<<3); - pci_write_config32(dev, 0x80, val); - val = pci_read_config32(dev, 0x80); - e0_later = !!(val & (1<<3)); - if(e0_later) { // pre_e0 bit 3 always be 0 and can not be changed - pci_write_config32(dev, 0x80, val_old); // restore it + + if (id.coreid == 0) { + /* On the primary cpu find the siblings */ + for (i = 1; i <= siblings; i++) { + struct device_path cpu_path; + device_t new; + /* Build the cpu device path */ + cpu_path.type = DEVICE_PATH_APIC; + cpu_path.u.apic.apic_id = + (id.nodeid*max_siblings) + i; + new = alloc_dev(cpu->bus, &cpu_path); + if (!new) { + continue; + } + /* Report what I have done */ + printk_debug("CPU: %s %s\n", + dev_path(new), new->enabled?"enabled":"disabled"); + } } - - return e0_later; } -unsigned int read_nb_cfg_54(void) +struct node_core_id get_node_core_id(void) { - msr_t msr; - msr = rdmsr(NB_CFG_MSR); - return ( ( msr.hi >> (54-32)) & 1); -} - -struct node_core_id get_node_core_id(unsigned int nb_cfg_54) { struct node_core_id id; - // get the apicid via cpuid(1) ebx[27:24] - if(nb_cfg_54) { - // when NB_CFG[54] is set, nodid = ebx[27:25], coreid = ebx[24] - id.coreid = (cpuid_ebx(1) >> 24) & 0xf; - id.nodeid = (id.coreid>>1); - id.coreid &= 1; - } else { // single core should be here too + unsigned siblings; + /* Get the apicid at reset */ + id.nodeid = (cpuid_ebx(1) >> 24) & 0xff; + id.coreid = 0; + /* Find out how many siblings we have */ + siblings = cpuid_ecx(0x80000008) & 0xff; + if (siblings) { + unsigned bits; + msr_t msr; + bits = 0; + while ((1 << bits) <= siblings) + bits++; + + msr = rdmsr(NB_CFG_MSR); + if ((msr.hi >> (54-32)) & 1) { + // when NB_CFG[54] is set, nodeid = ebx[27:25], coreid = ebx[24] + id.coreid = id.nodeid & ((1 << bits) - 1); + id.nodeid >>= bits; + } else { // when NB_CFG[54] is clear, nodeid = ebx[26:24], coreid = ebx[27] - id.nodeid = (cpuid_ebx(1) >> 24) & 0xf; - id.coreid = (id.nodeid>>3); - id.nodeid &= 7; + id.coreid = id.nodeid >> 3; + id.nodeid &= 7; + } + } else { + if (!is_cpu_pre_e0()) { + id.nodeid >>= 1; + } } - return id; + return id; +} -} +#if 0 static int get_max_siblings(int nodes) { device_t dev; @@ -169,76 +198,5 @@ return apicid_base; } -#if 0 -void amd_sibling_init(device_t cpu) -{ - unsigned i, siblings; - struct cpuid_result result; - unsigned nb_cfg_54; - struct node_core_id id; - /* On the bootstrap processor see if I want sibling cpus enabled */ - if (first_time) { - first_time = 0; - get_option(&disable_siblings, "dual_core"); - } - result = cpuid(0x80000008); - /* See how many sibling cpus we have */ - /* Is dualcore supported */ - siblings = (result.ecx & 0xff); - if ( siblings < 1) { - return; - } - -#if 1 - printk_debug("CPU: %u %d siblings\n", - cpu->path.u.apic.apic_id, - siblings); #endif - - nb_cfg_54 = read_nb_cfg_54(); -#if 1 - id = get_node_core_id(nb_cfg_54); // pre e0 nb_cfg_54 can not be set - - /* See if I am a sibling cpu */ - //if ((cpu->path.u.apic.apic_id>>(nb_cfg_54?0:3)) & siblings ) { // siblings = 1, 3, 7, 15,.... - //if ( ( (cpu->path.u.apic.apic_id>>(nb_cfg_54?0:3)) % (siblings+1) ) != 0 ) { - if(id.coreid != 0) { - if (disable_siblings) { - cpu->enabled = 0; - } - return; - } -#endif - - /* I am the primary cpu start up my siblings */ - - for(i = 1; i <= siblings; i++) { - struct device_path cpu_path; - device_t new; - /* Build the cpu device path */ - cpu_path.type = DEVICE_PATH_APIC; - cpu_path.u.apic.apic_id = cpu->path.u.apic.apic_id + i * (nb_cfg_54?1:8); - - /* See if I can find the cpu */ - new = find_dev_path(cpu->bus, &cpu_path); - /* Allocate the new cpu device structure */ - if(!new) { - new = alloc_dev(cpu->bus, &cpu_path); - new->enabled = 1; - new->initialized = 0; - } - -#if 1 - printk_debug("CPU: %u has sibling %u\n", - cpu->path.u.apic.apic_id, - new->path.u.apic.apic_id); -#endif - /* Start the new cpu */ - if(new->enabled && !new->initialized) - start_cpu(new); - } - -} -#endif - Index: src/cpu/amd/dualcore/dualcore_id.c =================================================================== --- src/cpu/amd/dualcore/dualcore_id.c (revision 1105) +++ src/cpu/amd/dualcore/dualcore_id.c (working copy) @@ -11,8 +11,8 @@ } struct node_core_id { - unsigned nodeid; - unsigned coreid; + unsigned nodeid:8; + unsigned coreid:8; }; static inline struct node_core_id get_node_core_id(unsigned nb_cfg_54) { Index: src/northbridge/amd/amdk8/coherent_ht.c =================================================================== --- src/northbridge/amd/amdk8/coherent_ht.c (revision 1105) +++ src/northbridge/amd/amdk8/coherent_ht.c (working copy) @@ -155,23 +155,6 @@ } -#ifndef ENABLE_APIC_EXT_ID -#define ENABLE_APIC_EXT_ID 0 -#endif - -static void enable_apic_ext_id(u8 node) -{ -#if ENABLE_APIC_EXT_ID==1 -#warning "FIXME Is the right place to enable apic ext id here?" - - u32 val; - - val = pci_read_config32(NODE_HT(node), 0x68); - val |= (HTTC_APIC_EXT_SPUR | HTTC_APIC_EXT_ID | HTTC_APIC_EXT_BRD_CST); - pci_write_config32(NODE_HT(node), 0x68, val); -#endif -} - static void enable_routing(u8 node) { u32 val; @@ -292,20 +275,18 @@ return 1; } -static uint16_t read_freq_cap(device_t dev, uint8_t pos) +static unsigned read_freq_cap(device_t dev, unsigned pos) { /* Handle bugs in valid hypertransport frequency reporting */ - uint16_t freq_cap; + unsigned freq_cap; uint32_t id; freq_cap = pci_read_config16(dev, pos); freq_cap &= ~(1 << HT_FREQ_VENDOR); /* Ignore Vendor HT frequencies */ -#if K8_HT_FREQ_1G_SUPPORT == 1 if (!is_cpu_pre_e0()) { return freq_cap; } -#endif id = pci_read_config32(dev, 0); @@ -339,8 +320,10 @@ /* See if I am changing the link freqency */ old_freq = pci_read_config8(node1, link1 + PCI_HT_CAP_HOST_FREQ); + old_freq &= 0x0f; needs_reset |= old_freq != freq; old_freq = pci_read_config8(node2, link2 + PCI_HT_CAP_HOST_FREQ); + old_freq &= 0x0f; needs_reset |= old_freq != freq; /* Set the Calulcated link frequency */ @@ -382,7 +365,6 @@ /* Set node2's widths */ pci_write_config8(node2, link2 + PCI_HT_CAP_HOST_WIDTH + 1, width); - return needs_reset; } @@ -1625,9 +1607,9 @@ } #endif /* CONFIG_MAX_PHYSICAL_CPUS > 1 */ +static unsigned count_cpus(unsigned nodes) +{ #if CONFIG_LOGICAL_CPUS==1 -static unsigned verify_dualcore(unsigned nodes) -{ unsigned node, totalcpus, tmp; totalcpus = 0; @@ -1637,25 +1619,21 @@ } return totalcpus; +#else + return nodes; +#endif } -#endif static void coherent_ht_finalize(unsigned nodes) { + unsigned total_cpus; + unsigned cpu_node_count; unsigned node; int rev_a0; -#if CONFIG_LOGICAL_CPUS==1 - unsigned total_cpus; + total_cpus = count_cpus(nodes); + cpu_node_count = ((total_cpus -1)<<16)|((nodes - 1) << 4); - if(read_option(CMOS_VSTART_dual_core, CMOS_VLEN_dual_core, 0) == 0) { /* dual_core */ - total_cpus = verify_dualcore(nodes); - } - else { - total_cpus = nodes; - } -#endif - /* set up cpu count and node count and enable Limit * Config Space Range for all available CPUs. * Also clear non coherent hypertransport bus range @@ -1672,11 +1650,7 @@ /* Set the Total CPU and Node count in the system */ val = pci_read_config32(dev, 0x60); val &= (~0x000F0070); -#if CONFIG_LOGICAL_CPUS==1 - val |= ((total_cpus-1)<<16)|((nodes-1)<<4); -#else - val |= ((nodes-1)<<16)|((nodes-1)<<4); -#endif + val |= cpu_node_count; pci_write_config32(dev, 0x60, val); /* Only respond to real cpu pci configuration cycles @@ -1786,6 +1760,33 @@ return needs_reset; } +static void startup_other_cores(unsigned nodes) +{ + unsigned node; + for(node = 0; node < nodes; node++) { + device_t dev; + unsigned siblings; + dev = NODE_MC(node); + siblings = (pci_read_config32(dev, 0xe8) >> 12) & 0x3; + + if (siblings) { + device_t dev_f0; + unsigned val; + /* Redirect all MC4 accesses and error logging to core0 */ + val = pci_read_config32(dev, 0x44); + val |= (1 << 27); //NbMcaToMstCpuEn bit + pci_write_config32(dev, 0x44, val); + + dev_f0 = NODE_HT(node); + /* Enable extended apic id's and second core */ + val = pci_read_config32(dev_f0, 0x68); + val |= (1 << 18) | (1 << 17) | ( 1 << 5); + pci_write_config32(dev_f0, 0x68, val); + } + } +} + + static int setup_coherent_ht_domain(void) { struct setup_smp_result result; @@ -1799,15 +1800,15 @@ enable_bsp_routing(); #if CONFIG_MAX_PHYSICAL_CPUS > 1 - result = setup_smp(); - result.nodes = verify_mp_capabilities(result.nodes); - clear_dead_routes(result.nodes); + result = setup_smp(); #endif - + result.nodes = verify_mp_capabilities(result.nodes); + clear_dead_routes(result.nodes); if (result.nodes == 1) { setup_uniprocessor(); } coherent_ht_finalize(result.nodes); + startup_other_cores(result.nodes); result.needs_reset = apply_cpu_errata_fixes(result.nodes, result.needs_reset); result.needs_reset = optimize_link_read_pointers(result.nodes, result.needs_reset); return result.needs_reset; Index: src/northbridge/amd/amdk8/amdk8.h =================================================================== --- src/northbridge/amd/amdk8/amdk8.h (revision 1105) +++ src/northbridge/amd/amdk8/amdk8.h (working copy) @@ -136,6 +136,7 @@ #define DCL_DisInRcvrs (1<<24) #define DCL_BypMax_SHIFT 25 #define DCL_En2T (1<<28) +#define DCL_UpperCSMap (1<<29) #define DRAM_CONFIG_HIGH 0x94 #define DCH_ASYNC_LAT_SHIFT 0 #define DCH_ASYNC_LAT_MASK 0xf Index: src/northbridge/amd/amdk8/northbridge.c =================================================================== --- src/northbridge/amd/amdk8/northbridge.c (revision 1105) +++ src/northbridge/amd/amdk8/northbridge.c (working copy) @@ -17,9 +17,9 @@ #include #include +#include #if CONFIG_LOGICAL_CPUS==1 -#include #include #endif @@ -27,11 +27,8 @@ #include "root_complex/chip.h" #include "northbridge.h" #include "amdk8.h" +#include "cpu_rev.c" -#if K8_E0_MEM_HOLE_SIZEK != 0 -#include "./cpu_rev.c" -#endif - #define FX_DEVS 8 static device_t __f0_dev[FX_DEVS]; static device_t __f1_dev[FX_DEVS]; @@ -640,6 +637,41 @@ return tolm; } +static uint32_t hoist_memory(unsigned long mmio_basek, int i) +{ + int ii; + uint32_t carry_over; + device_t dev; + uint32_t base, limit; + uint32_t basek; + uint32_t hoist; + + carry_over = (4*1024*1024) - mmio_basek; + for(ii=7;ii>i;ii--) { + + base = f1_read_config32(0x40 + (ii << 3)); + limit = f1_read_config32(0x44 + (ii << 3)); + if ((base & ((1<<1)|(1<<0))) != ((1<<1)|(1<<0))) { + continue; + } + f1_write_config32(0x44 + (ii << 3),limit + (carry_over << 2)); + f1_write_config32(0x40 + (ii << 3),base + (carry_over << 2)); + } + limit = f1_read_config32(0x44 + (i << 3)); + f1_write_config32(0x44 + (i << 3),limit + (carry_over << 2)); + dev = __f1_dev[i]; + base = pci_read_config32(dev, 0x40 + (i << 3)); + basek = (pci_read_config32(dev, 0x40 + (i << 3)) & 0xffff0000) >> 2; + hoist = /* hole start address */ + ((mmio_basek << 10) & 0xff000000) + + /* hole address to memory controller address */ + (((basek + carry_over) >> 6) & 0x0000ff00) + + /* enable */ + 1; + pci_write_config32(dev, 0xf0, hoist); + return carry_over; +} + static void pci_domain_set_resources(device_t dev) { unsigned long mmio_basek; @@ -648,41 +680,23 @@ pci_tolm = find_pci_tolm(&dev->link[0]); + /* Work around for NUMA bug in all kernels before 2.6.13. + If pci memory hole is too small, the kernel memory to NUMA + node mapping will fail to initialize and system will run in + non-NUMA mode. + */ + if(pci_tolm > 0xf8000000) pci_tolm = 0xf8000000; + #warning "FIXME handle interleaved nodes" mmio_basek = pci_tolm >> 10; /* Round mmio_basek to something the processor can support */ mmio_basek &= ~((1 << 6) -1); -#if 1 -#warning "FIXME improve mtrr.c so we don't use up all of the mtrrs with a 64M MMIO hole" - /* Round the mmio hold to 64M */ - mmio_basek &= ~((64*1024) - 1); -#endif - -#if K8_E0_MEM_HOLE_SIZEK != 0 - if (!is_cpu_pre_e0()) - for (i = 0; i < 8; i++) { - uint32_t base; - base = f1_read_config32(0x40 + (i << 3)); - if ((base & ((1<<1)|(1<<0))) != ((1<<1)|(1<<0))) { - continue; - } - - base = pci_read_config32(__f1_dev[i], 0xf0); - if((base & 1)==0) continue; - base &= 0xff<<24; - base >>= 10; - if (mmio_basek > base) { - mmio_basek = base; - } - break; // only one hole - } -#endif - idx = 10; for(i = 0; i < 8; i++) { uint32_t base, limit; unsigned basek, limitk, sizek; + base = f1_read_config32(0x40 + (i << 3)); limit = f1_read_config32(0x44 + (i << 3)); if ((base & ((1<<1)|(1<<0))) != ((1<<1)|(1<<0))) { @@ -708,6 +722,9 @@ pre_sizek = mmio_basek - basek; ram_resource(dev, idx++, basek, pre_sizek); sizek -= pre_sizek; + if(! is_cpu_pre_e0() ) { + sizek += hoist_memory(mmio_basek,i); + } basek = mmio_basek; } if ((basek + sizek) <= 4*1024*1024) { @@ -767,55 +784,21 @@ .ops_pci_bus = &pci_cf8_conf1, }; -#define APIC_ID_OFFSET 0x10 - static unsigned int cpu_bus_scan(device_t dev, unsigned int max) { struct bus *cpu_bus; device_t dev_mc; - int bsp_apic_id; - int apic_id_offset; + unsigned max_siblings; int i,j; - unsigned nb_cfg_54; - int enable_apic_ext_id; - unsigned siblings; -#if CONFIG_LOGICAL_CPUS == 1 - int e0_later_single_core; - int disable_siblings; -#endif - nb_cfg_54 = 0; - enable_apic_ext_id = 0; - siblings = 0; - - /* Find the bootstrap processors apicid */ - bsp_apic_id = lapicid(); - - /* See if I will enable extended ids' */ - apic_id_offset = bsp_apic_id; - -#if CONFIG_LOGICAL_CPUS == 1 - disable_siblings = !CONFIG_LOGICAL_CPUS; - get_option(&disable_siblings, "dual_core"); - - // for pre_e0, nb_cfg_54 can not be set, ( even set, when you read it still be 0) - // How can I get the nb_cfg_54 of every node' nb_cfg_54 in bsp??? and differ d0 and e0 single core - - nb_cfg_54 = read_nb_cfg_54(); -#endif dev_mc = dev_find_slot(0, PCI_DEVFN(0x18, 0)); if (!dev_mc) { die("0:18.0 not found?"); } - if (pci_read_config32(dev_mc, 0x68) & (HTTC_APIC_EXT_ID|HTTC_APIC_EXT_BRD_CST)) - { - enable_apic_ext_id = 1; - if (apic_id_offset == 0) { - /* bsp apic id is not changed */ - apic_id_offset = APIC_ID_OFFSET; - } - } + /* For now assume all cpus have the same number of siblings */ + max_siblings = (cpuid_ecx(0x80000008) & 0xff) + 1; + /* Find which cpus are present */ cpu_bus = &dev->link[0]; for(i = 0; i < 8; i++) { @@ -834,82 +817,36 @@ PCI_DEVFN(0x18 + i, j)); } } + + /* Build the cpu device path */ + cpu_path.type = DEVICE_PATH_APIC; + cpu_path.u.apic.apic_id = i*max_siblings; -#if CONFIG_LOGICAL_CPUS == 1 - e0_later_single_core = 0; - if ((!disable_siblings) && dev && dev->enabled) { - j = (pci_read_config32(dev, 0xe8) >> 12) & 3; // dev is func 3 - printk_debug(" %s siblings=%d\r\n", dev_path(dev), j); + /* See if I can find the cpu */ + cpu = find_dev_path(cpu_bus, &cpu_path); - if(nb_cfg_54) { - // For e0 single core if nb_cfg_54 is set, apicid will be 0, 2, 4.... - // ----> you can mixed single core e0 and dual core e0 at any sequence - // That is the typical case - - if(j == 0 ){ - e0_later_single_core = is_e0_later_in_bsp(i); // single core - } else { - e0_later_single_core = 0; - } - if(e0_later_single_core) { - printk_debug("\tFound e0 single core\r\n"); - j=1; - } - - if(siblings > j ) { - //actually we can't be here, because d0 nb_cfg_54 can not be set - //even worse is_e0_later_in_bsp() can not find out if it is d0 or e0 - - die("When NB_CFG_54 is set, if you want to mix e0 (single core and dual core) and single core(pre e0) CPUs, you need to put all the single core (pre e0) CPUs before all the (e0 single or dual core) CPUs\r\n"); - } - else { - siblings = j; - } - } else { - siblings = j; - } - } -#endif -#if CONFIG_LOGICAL_CPUS==1 - for (j = 0; j <= (e0_later_single_core?0:siblings); j++ ) { -#else - for (j = 0; j <= siblings; j++ ) { -#endif - /* Build the cpu device path */ - cpu_path.type = DEVICE_PATH_APIC; - cpu_path.u.apic.apic_id = i * (nb_cfg_54?(siblings+1):1) + j * (nb_cfg_54?1:8); - - /* See if I can find the cpu */ - cpu = find_dev_path(cpu_bus, &cpu_path); - - /* Enable the cpu if I have the processor */ - if (dev && dev->enabled) { - if (!cpu) { - cpu = alloc_dev(cpu_bus, &cpu_path); - } - if (cpu) { - cpu->enabled = 1; - } + /* Enable the cpu if I have the processor */ + if (dev && dev->enabled) { + if (!cpu) { + cpu = alloc_dev(cpu_bus, &cpu_path); } - - /* Disable the cpu if I don't have the processor */ - if (cpu && (!dev || !dev->enabled)) { - cpu->enabled = 0; - } - - /* Report what I have done */ if (cpu) { - if(enable_apic_ext_id) { - if(cpu->path.u.apic.apic_idpath.u.apic.apic_id > siblings) || (bsp_apic_id!=0) ) - cpu->path.u.apic.apic_id += apic_id_offset; - } - } - printk_debug("CPU: %s %s\n", - dev_path(cpu), cpu->enabled?"enabled":"disabled"); + cpu->enabled = 1; } - } //j + } + + /* Disable the cpu if I don't have the processor */ + if (cpu && (!dev || !dev->enabled)) { + cpu->enabled = 0; + } + + /* Report what I have done */ + if (cpu) { + printk_debug("CPU: %s %s\n", + dev_path(cpu), cpu->enabled?"enabled":"disabled"); + } } + return max; } Index: src/northbridge/amd/amdk8/raminit.c =================================================================== --- src/northbridge/amd/amdk8/raminit.c (revision 1105) +++ src/northbridge/amd/amdk8/raminit.c (working copy) @@ -585,6 +585,16 @@ } +static void e_step_cpu(const struct mem_controller *ctrl) +{ + uint32_t dcl,data32; + + /* set bit 29 (upper cs map) of function 2 offset 0x90 */ + dcl = pci_read_config32(ctrl->f2, DRAM_CONFIG_LOW); + dcl |= DCL_UpperCSMap; + pci_write_config32(ctrl->f2, DRAM_CONFIG_LOW, dcl); +} + static int is_dual_channel(const struct mem_controller *ctrl) { uint32_t dcl; @@ -714,28 +724,14 @@ return sz; } -static const unsigned cs_map_aa[15] = { - /* (row=12, col=8)(14, 12) ---> (0, 0) (2, 4) */ - 0, 1, 3, 6, 0, - 0, 2, 4, 7, 9, - 0, 0, 5, 8,10, -}; - static void set_dimm_size(const struct mem_controller *ctrl, struct dimm_size sz, unsigned index) { - uint32_t base0, base1, map; + uint32_t base0, base1; uint32_t dch; if (sz.side1 != sz.side2) { sz.side2 = 0; } - map = pci_read_config32(ctrl->f2, DRAM_BANK_ADDR_MAP); - map &= ~(0xf << (index * 4)); -#if K8_4RANK_DIMM_SUPPORT == 1 - if(sz.rank == 4) { - map &= ~(0xf << ( (index + 2) * 4)); - } -#endif /* For each base register. * Place the dimm size in 32 MB quantities in the bits 31 - 21. @@ -747,22 +743,6 @@ /* Make certain side1 of the dimm is at least 32MB */ if (sz.side1 >= (25 +3)) { - if(is_cpu_pre_d0()) { - map |= (sz.side1 - (25 + 3)) << (index *4); -#if K8_4RANK_DIMM_SUPPORT == 1 - if(sz.rank == 4) { - map |= (sz.side1 - (25 + 3)) << ( (index + 2) * 4); - } -#endif - } - else { - map |= cs_map_aa[(sz.rows - 12) * 5 + (sz.col - 8) ] << (index*4); -#if K8_4RANK_DIMM_SUPPORT == 1 - if(sz.rank == 4) { - map |= cs_map_aa[(sz.rows - 12) * 5 + (sz.col - 8) ] << ( (index + 2) * 4); - } -#endif - } base0 = (1 << ((sz.side1 - (25 + 3)) + 21)) | 1; } @@ -791,8 +771,6 @@ } #endif - pci_write_config32(ctrl->f2, DRAM_BANK_ADDR_MAP, map); - /* Enable the memory clocks for this DIMM */ if (base0) { dch = pci_read_config32(ctrl->f2, DRAM_CONFIG_HIGH); @@ -806,6 +784,52 @@ } } + +static void set_dimm_map(const struct mem_controller *ctrl, + struct dimm_size sz, unsigned index) +{ + static const unsigned cs_map_aa[15] = { + /* (row=12, col=8)(14, 12) ---> (0, 0) (2, 4) */ + 0, 1, 3, 6, 0, + 0, 2, 4, 7, 9, + 0, 0, 5, 8,10, + }; + uint32_t map; + int row,col; + + map = pci_read_config32(ctrl->f2, DRAM_BANK_ADDR_MAP); + map &= ~(0xf << (index * 4)); + +#if K8_4RANK_DIMM_SUPPORT == 1 + if(sz.rank == 4) { + map &= ~(0xf << ( (index + 2) * 4)); + } +#endif + + if (is_cpu_pre_d0()) { + map |= (sz.side1 - (25 + 3)) << (index *4); +#if K8_4RANK_DIMM_SUPPORT == 1 + if(sz.rank == 4) { + map |= (sz.side1 - (25 + 3)) << ( (index + 2) * 4); + } +#endif + } else { + unsigned val; + val = cs_map_aa[(sz.rows - 12) * 5 + (sz.col - 8) ]; + if(val == 0) { + print_err("Invalid Column or Row count\r\n"); + val = 7; + } + map |= val << (index*4); +#if K8_4RANK_DIMM_SUPPORT == 1 + if(sz.rank == 4) { + map |= val << ( (index + 2) * 4); + } +#endif + } + pci_write_config32(ctrl->f2, DRAM_BANK_ADDR_MAP, map); +} + static long spd_set_ram_size(const struct mem_controller *ctrl, long dimm_mask) { int i; @@ -820,6 +844,7 @@ return -1; /* Report SPD error */ } set_dimm_size(ctrl, sz, i); + set_dimm_map(ctrl, sz, i); } return dimm_mask; } @@ -865,6 +890,13 @@ print_spew_hex32(tom_k); print_spew(" KB\r\n"); +#if 0 + /* Report the amount of memory. */ + print_debug("RAM: 0x"); + print_debug_hex32(tom_k); + print_debug(" KB\r\n"); +#endif + /* Now set top of memory */ msr_t msr; msr.lo = (tom_k & 0x003fffff) << 10; @@ -971,7 +1003,7 @@ if(is_dual_channel(ctrl)) { /* Also we run out of address mask bits if we try and interleave 8 4GB dimms */ if ((bits == 3) && (common_size == (1 << (32 - 3)))) { -// print_debug("8 4GB chip selects cannot be interleaved\r\n"); + print_spew("8 4GB chip selects cannot be interleaved\r\n"); return 0; } csbase_inc <<=1; @@ -981,7 +1013,7 @@ csbase_inc = csbase_low_d0[common_cs_mode]; if(is_dual_channel(ctrl)) { if( (bits==3) && (common_cs_mode > 8)) { -// print_debug("8 cs_mode>8 chip selects cannot be interleaved\r\n"); + print_spew("8 cs_mode>8 chip selects cannot be interleaved\r\n"); return 0; } csbase_inc <<=1; @@ -1100,25 +1132,6 @@ return end_k; } -#if K8_E0_MEM_HOLE_SIZEK != 0 -#define K8_E0_MEM_HOLE_LIMITK 4*1024*1024 -#define K8_E0_MEM_HOLE_BASEK (K8_E0_MEM_HOLE_LIMITK - K8_E0_MEM_HOLE_SIZEK ) - -static void set_e0_mem_hole(const struct mem_controller *ctrl, unsigned base_k) -{ - /* Route the addresses to the controller node */ - unsigned val; - - val = pci_read_config32(ctrl->f1,0xf0); - - val &= 0x00ff00fe; - val = (K8_E0_MEM_HOLE_BASEK << 10) | ((K8_E0_MEM_HOLE_SIZEK+base_k)>>(16-10)) | 1; - - pci_write_config32(ctrl->f1, 0xf0, val); -} - -#endif - static void order_dimms(const struct mem_controller *ctrl) { unsigned long tom_k, base_k; @@ -1135,14 +1148,6 @@ /* Compute the memory base address */ base_k = memory_end_k(ctrl, ctrl->node_id); tom_k += base_k; -#if K8_E0_MEM_HOLE_SIZEK != 0 - if(!is_cpu_pre_e0()) { - /* See if I need to check the range cover hole */ - if ((base_k <= K8_E0_MEM_HOLE_BASEK) && (tom_k > K8_E0_MEM_HOLE_BASEK)) { - tom_k += K8_E0_MEM_HOLE_SIZEK; - } - } -#endif route_dram_accesses(ctrl, base_k, tom_k); set_top_mem(tom_k); } @@ -2145,12 +2150,11 @@ struct spd_set_memclk_result result; const struct mem_param *param; long dimm_mask; -#if 1 + if (!controller_present(ctrl)) { -// print_debug("No memory controller present\r\n"); + print_debug("No memory controller present\r\n"); return; } -#endif hw_enable_ecc(ctrl); activate_spd_rom(ctrl); dimm_mask = spd_detect_dimms(ctrl); @@ -2176,6 +2180,10 @@ if (dimm_mask < 0) goto hw_spd_err; order_dimms(ctrl); + if( !is_cpu_pre_e0() ) { + print_debug("E step CPU\r\n"); + e_step_cpu(ctrl); + } return; hw_spd_err: /* Unrecoverable error reading SPD data */ @@ -2280,22 +2288,6 @@ } while(((dcl & DCL_MemClrStatus) == 0) || ((dcl & DCL_DramEnable) == 0) ); } - // init e0 mem hole here -#if K8_E0_MEM_HOLE_SIZEK != 0 - if (!is_cpu_pre_e0()) { - uint32_t base, limit; - unsigned base_k, limit_k; - base = pci_read_config32(ctrl->f1, 0x40 + (i << 3)); - limit = pci_read_config32(ctrl->f1, 0x44 + (i << 3)); - base_k = (base & 0xffff0000) >> 2; - limit_k = ((limit + 0x00010000) & 0xffff0000) >> 2; - if ((base_k <= K8_E0_MEM_HOLE_BASEK) && (limit_k > K8_E0_MEM_HOLE_BASEK)) { - set_e0_mem_hole(ctrl+i, base_k); - } - } - -#endif - print_debug(" done\r\n"); } -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From jschildt at lnxi.com Sat Sep 3 00:03:31 2005 From: jschildt at lnxi.com (jason schildt) Date: Fri, 02 Sep 2005 16:03:31 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-15/16 Message-ID: DESCRIPTION: ------------------------------------------------ ## lnxi-patch-15 ## src/mainboard/.../Options.lb Disabled cache_as_ram: USE_CACHE_RAM CONFIG_USE_INIT tyan/s2881/Options.lb tyan/s2882/Options.lb tyan/s2891/Options.lb tyan/s4880/Options.lb tyan/s2892/Options.lb tyan/s2875/Options.lb tyan/s4882/Options.lb tyan/s2885/Options.lb tyan/s2895/Options.lb DIFFSTAT: ------------------------------------------------ s2875/Options.lb | 4 ++-- s2881/Options.lb | 4 ++-- s2882/Options.lb | 4 ++-- s2885/Options.lb | 4 ++-- s2891/Options.lb | 4 ++-- s2892/Options.lb | 4 ++-- s2895/Options.lb | 4 ++-- s4880/Options.lb | 4 ++-- s4882/Options.lb | 4 ++-- 9 files changed, 18 insertions(+), 18 deletions(-) PATCH: ------------------------------------------------ Index: s2881/Options.lb =================================================================== --- s2881/Options.lb (revision 1105) +++ s2881/Options.lb (working copy) @@ -130,10 +130,10 @@ ## ## enable CACHE_AS_RAM specifics ## -default USE_DCACHE_RAM=1 +default USE_DCACHE_RAM=0 default DCACHE_RAM_BASE=0xcf000 default DCACHE_RAM_SIZE=0x1000 -default CONFIG_USE_INIT=1 +default CONFIG_USE_INIT=0 ## ## Build code to setup a generic IOAPIC Index: s2882/Options.lb =================================================================== --- s2882/Options.lb (revision 1105) +++ s2882/Options.lb (working copy) @@ -130,10 +130,10 @@ ## ## enable CACHE_AS_RAM specifics ## -default USE_DCACHE_RAM=1 +default USE_DCACHE_RAM=0 default DCACHE_RAM_BASE=0xcf000 default DCACHE_RAM_SIZE=0x1000 -default CONFIG_USE_INIT=1 +default CONFIG_USE_INIT=0 ## ## Build code to setup a generic IOAPIC Index: s2891/Options.lb =================================================================== --- s2891/Options.lb (revision 1105) +++ s2891/Options.lb (working copy) @@ -139,10 +139,10 @@ ## ## enable CACHE_AS_RAM specifics ## -default USE_DCACHE_RAM=1 +default USE_DCACHE_RAM=0 default DCACHE_RAM_BASE=0xcf000 default DCACHE_RAM_SIZE=0x1000 -default CONFIG_USE_INIT=1 +default CONFIG_USE_INIT=0 ## Index: s4880/Options.lb =================================================================== --- s4880/Options.lb (revision 1105) +++ s4880/Options.lb (working copy) @@ -130,10 +130,10 @@ ## ## enable CACHE_AS_RAM specifics ## -default USE_DCACHE_RAM=1 +default USE_DCACHE_RAM=0 default DCACHE_RAM_BASE=0xcf000 default DCACHE_RAM_SIZE=0x1000 -default CONFIG_USE_INIT=1 +default CONFIG_USE_INIT=0 ## ## Build code to setup a generic IOAPIC Index: s2892/Options.lb =================================================================== --- s2892/Options.lb (revision 1105) +++ s2892/Options.lb (working copy) @@ -139,10 +139,10 @@ ## ## enable CACHE_AS_RAM specifics ## -default USE_DCACHE_RAM=1 +default USE_DCACHE_RAM=0 default DCACHE_RAM_BASE=0xcf000 default DCACHE_RAM_SIZE=0x1000 -default CONFIG_USE_INIT=1 +default CONFIG_USE_INIT=0 ## Index: s2875/Options.lb =================================================================== --- s2875/Options.lb (revision 1105) +++ s2875/Options.lb (working copy) @@ -130,10 +130,10 @@ ## ## enable CACHE_AS_RAM specifics ## -default USE_DCACHE_RAM=1 +default USE_DCACHE_RAM=0 default DCACHE_RAM_BASE=0xcf000 default DCACHE_RAM_SIZE=0x1000 -default CONFIG_USE_INIT=1 +default CONFIG_USE_INIT=0 ## ## Build code to setup a generic IOAPIC Index: s4882/Options.lb =================================================================== --- s4882/Options.lb (revision 1105) +++ s4882/Options.lb (working copy) @@ -130,10 +130,10 @@ ## ## enable CACHE_AS_RAM specifics ## -default USE_DCACHE_RAM=1 +default USE_DCACHE_RAM=0 default DCACHE_RAM_BASE=0xcf000 default DCACHE_RAM_SIZE=0x1000 -default CONFIG_USE_INIT=1 +default CONFIG_USE_INIT=0 ## ## Build code to setup a generic IOAPIC Index: s2885/Options.lb =================================================================== --- s2885/Options.lb (revision 1105) +++ s2885/Options.lb (working copy) @@ -130,10 +130,10 @@ ## ## enable CACHE_AS_RAM specifics ## -default USE_DCACHE_RAM=1 +default USE_DCACHE_RAM=0 default DCACHE_RAM_BASE=0xcf000 default DCACHE_RAM_SIZE=0x1000 -default CONFIG_USE_INIT=1 +default CONFIG_USE_INIT=0 ## ## Build code to setup a generic IOAPIC Index: s2895/Options.lb =================================================================== --- s2895/Options.lb (revision 1105) +++ s2895/Options.lb (working copy) @@ -136,10 +136,10 @@ ## ## enable CACHE_AS_RAM specifics ## -default USE_DCACHE_RAM=1 +default USE_DCACHE_RAM=0 default DCACHE_RAM_BASE=0xcf000 default DCACHE_RAM_SIZE=0x1000 -default CONFIG_USE_INIT=1 +default CONFIG_USE_INIT=0 ## ## Build code to setup a generic IOAPIC -- Jason W. Schildt LinuxBIOS Software Engineer Linux Networx From jschildt at lnxi.com Sat Sep 3 00:03:31 2005 From: jschildt at lnxi.com (jason schildt) Date: Fri, 02 Sep 2005 16:03:31 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-01/16 Message-ID: ## lnxi-patch-1 ## - (2)files src/southbridge/amd/amd8111/amd8111_acpi.c // amd8111_enable is commented out in public tree, but enabled in // hdama. resolution: copied over for merge DIFFSTAT --------------------------------------------------------- amd8111_acpi.c | 5 +++-- amd8111_pci.c | 1 + 2 files changed, 4 insertions(+), 2 deletions(-) PATCH --------------------------------------------------------- Index: southbridge/amd/amd8111/amd8111_pci.c =================================================================== --- southbridge/amd/amd8111/amd8111_pci.c (revision 1105) +++ southbridge/amd/amd8111/amd8111_pci.c (working copy) @@ -55,6 +55,7 @@ .enable_resources = pci_bus_enable_resources, .init = pci_init, .scan_bus = pci_scan_bridge, + /* PCI Subordinate bus reset is not implemented */ .ops_pci = &lops_pci, }; Index: southbridge/amd/amd8111/amd8111_acpi.c =================================================================== --- southbridge/amd/amd8111/amd8111_acpi.c (revision 1105) +++ southbridge/amd/amd8111/amd8111_acpi.c (working copy) @@ -97,6 +97,7 @@ #endif + /* power after power fail */ on = MAINBOARD_POWER_ON_AFTER_POWER_FAIL; get_option(&on, "power_on_after_fail"); byte = pci_read_config8(dev, PREVIOUS_POWER_STATE); @@ -106,7 +107,7 @@ } pci_write_config8(dev, PREVIOUS_POWER_STATE, byte); printk_info("set power %s after power fail\n", on?"on":"off"); - + /* Throttle the CPU speed down for testing */ on = SLOW_CPU_OFF; get_option(&on, "slow_cpu"); @@ -177,7 +178,7 @@ .enable_resources = acpi_enable_resources, .init = acpi_init, .scan_bus = scan_static_bus, -// .enable = amd8111_enable, + .enable = amd8111_enable, .ops_pci = &lops_pci, .ops_smbus_bus = &lops_smbus_bus, }; Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From jschildt at lnxi.com Sat Sep 3 00:03:31 2005 From: jschildt at lnxi.com (jason schildt) Date: Fri, 02 Sep 2005 16:03:31 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-13/16 Message-ID: DESCRIPTION: ------------------------------------------------ ## lnxi-patch-13 ## (20)files src/mainboard/{all_opteron_boards}/failover.c /Iwill/DK8S2/failover.c: /Iwill/DK8X/failover.c: /arima/hdama/failover.c: /newisys/khepri/failover.c: /amd/quartet/failover.c: /amd/serenade/failover.c: /amd/solo/failover.c: /ibm/e326/failover.c: /ibm/e325/failover.c: /island/aruma/failover.c: /tyan/s2880/failover.c: /tyan/s2881/failover.c: /tyan/s2882/failover.c: /tyan/s2891/failover.c: /tyan/s4880/failover.c: /tyan/s2892/failover.c: /tyan/s2875/failover.c: /tyan/s4882/failover.c: /tyan/s2885/failover.c: /tyan/s2895/failover.c: Replaced cpu_init_detected() with early_mtrr_init_detected(). And killed the direct jump to cpu_reset() in failover.c in the above listed boards. DIFFSTAT: ------------------------------------------------ Iwill/DK8S2/failover.c | 11 +++-------- Iwill/DK8X/failover.c | 11 +++-------- amd/quartet/failover.c | 11 +++-------- amd/serenade/failover.c | 11 +++-------- amd/solo/failover.c | 11 +++-------- arima/hdama/failover.c | 8 +------- ibm/e325/failover.c | 11 +++-------- ibm/e326/failover.c | 11 +++-------- island/aruma/failover.c | 11 +++-------- newisys/khepri/failover.c | 11 +++-------- tyan/s2875/failover.c | 25 +++---------------------- tyan/s2880/failover.c | 25 +++---------------------- tyan/s2881/failover.c | 25 +++---------------------- tyan/s2882/failover.c | 25 +++---------------------- tyan/s2885/failover.c | 29 +++-------------------------- tyan/s2891/failover.c | 26 +++----------------------- tyan/s2892/failover.c | 27 +++------------------------ tyan/s2895/failover.c | 30 +++--------------------------- tyan/s4880/failover.c | 25 +++---------------------- tyan/s4882/failover.c | 28 +++------------------------- 20 files changed, 58 insertions(+), 314 deletions(-) PATCH: ------------------------------------------------ Index: Iwill/DK8S2/failover.c =================================================================== --- Iwill/DK8S2/failover.c (revision 1105) +++ Iwill/DK8S2/failover.c (working copy) @@ -9,6 +9,7 @@ #include "southbridge/amd/amd8111/amd8111_enable_rom.c" #include "northbridge/amd/amdk8/early_ht.c" #include "cpu/x86/lapic/boot_cpu.c" +#include "cpu/x86/mtrr/earlymtrr.c" #include "northbridge/amd/amdk8/reset_test.c" static unsigned long main(unsigned long bist) @@ -19,11 +20,11 @@ enable_lapic(); /* Is this a cpu only reset? */ - if (cpu_init_detected(nodeid)) { + if (early_mtrr_init_detected()) { if (last_boot_normal()) { goto normal_image; } else { - goto cpu_reset; + goto fallback_image; } } /* Is this a secondary cpu? */ @@ -60,12 +61,6 @@ : "a" (bist) /* inputs */ : /* clobbers */ ); - cpu_reset: - asm volatile ("jmp __cpu_reset" - : /* outputs */ - : "a"(bist) /* inputs */ - : /* clobbers */ - ); fallback_image: return bist; } Index: Iwill/DK8X/failover.c =================================================================== --- Iwill/DK8X/failover.c (revision 1105) +++ Iwill/DK8X/failover.c (working copy) @@ -9,6 +9,7 @@ #include "southbridge/amd/amd8111/amd8111_enable_rom.c" #include "northbridge/amd/amdk8/early_ht.c" #include "cpu/x86/lapic/boot_cpu.c" +#include "cpu/x86/mtrr/earlymtrr.c" #include "northbridge/amd/amdk8/reset_test.c" static unsigned long main(unsigned long bist) @@ -19,11 +20,11 @@ enable_lapic(); /* Is this a cpu only reset? */ - if (cpu_init_detected(nodeid)) { + if (early_mtrr_init_detected()) { if (last_boot_normal()) { goto normal_image; } else { - goto cpu_reset; + goto fallback_image; } } /* Is this a secondary cpu? */ @@ -60,12 +61,6 @@ : "a" (bist) /* inputs */ : /* clobbers */ ); - cpu_reset: - asm volatile ("jmp __cpu_reset" - : /* outputs */ - : "a"(bist) /* inputs */ - : /* clobbers */ - ); fallback_image: return bist; } Index: arima/hdama/failover.c =================================================================== --- arima/hdama/failover.c (revision 1105) +++ arima/hdama/failover.c (working copy) @@ -25,7 +25,7 @@ if (last_boot_normal()) { goto normal_image; } else { - goto cpu_reset; + goto fallback_image; } } /* Is this a secondary cpu? */ @@ -62,12 +62,6 @@ : "a" (bist) /* inputs */ : /* clobbers */ ); - cpu_reset: - asm volatile ("jmp __cpu_reset" - : /* outputs */ - : "a"(bist) /* inputs */ - : /* clobbers */ - ); fallback_image: return bist; } Index: newisys/khepri/failover.c =================================================================== --- newisys/khepri/failover.c (revision 1105) +++ newisys/khepri/failover.c (working copy) @@ -9,6 +9,7 @@ #include "southbridge/amd/amd8111/amd8111_enable_rom.c" #include "northbridge/amd/amdk8/early_ht.c" #include "cpu/x86/lapic/boot_cpu.c" +#include "cpu/x86/mtrr/earlymtrr.c" #include "northbridge/amd/amdk8/reset_test.c" static unsigned long main(unsigned long bist) @@ -19,11 +20,11 @@ nodeid=lapicid(); /* Is this a cpu only reset? */ - if (cpu_init_detected(nodeid)) { + if (early_mtrr_init_detected()) { if (last_boot_normal()) { goto normal_image; } else { - goto cpu_reset; + goto fallback_image; } } /* Is this a secondary cpu? */ @@ -60,12 +61,6 @@ : "a" (bist) /* inputs */ : /* clobbers */ ); - cpu_reset: - asm volatile ("jmp __cpu_reset" - : /* outputs */ - : "a"(bist) /* inputs */ - : /* clobbers */ - ); fallback_image: return bist; } Index: amd/quartet/failover.c =================================================================== --- amd/quartet/failover.c (revision 1105) +++ amd/quartet/failover.c (working copy) @@ -9,6 +9,7 @@ #include "southbridge/amd/amd8111/amd8111_enable_rom.c" #include "northbridge/amd/amdk8/early_ht.c" #include "cpu/x86/lapic/boot_cpu.c" +#include "cpu/x86/mtrr/earlymtrr.c" #include "northbridge/amd/amdk8/reset_test.c" static unsigned long main(unsigned long bist) @@ -21,11 +22,11 @@ nodeid = lapicid() & 0xf; /* Is this a cpu only reset? */ - if (cpu_init_detected(nodeid)) { + if (early_mtrr_init_detected()) { if (last_boot_normal()) { goto normal_image; } else { - goto cpu_reset; + goto fallback_image; } } /* Is this a secondary cpu? */ @@ -62,12 +63,6 @@ : "a" (bist) /* inputs */ : /* clobbers */ ); - cpu_reset: - asm volatile ("jmp __cpu_reset" - : /* outputs */ - : "a"(bist) /* inputs */ - : /* clobbers */ - ); fallback_image: return bist; } Index: amd/serenade/failover.c =================================================================== --- amd/serenade/failover.c (revision 1105) +++ amd/serenade/failover.c (working copy) @@ -9,6 +9,7 @@ #include "southbridge/amd/amd8111/amd8111_enable_rom.c" #include "northbridge/amd/amdk8/early_ht.c" #include "cpu/x86/lapic/boot_cpu.c" +#include "cpu/x86/mtrr/earlymtrr.c" #include "northbridge/amd/amdk8/reset_test.c" static unsigned long main(unsigned long bist) @@ -21,11 +22,11 @@ nodeid = lapicid() & 0xf; /* Is this a cpu only reset? */ - if (cpu_init_detected(nodeid)) { + if (early_mtrr_init_detected()) { if (last_boot_normal()) { goto normal_image; } else { - goto cpu_reset; + goto fallback_image; } } /* Is this a secondary cpu? */ @@ -62,12 +63,6 @@ : "a" (bist) /* inputs */ : /* clobbers */ ); - cpu_reset: - asm volatile ("jmp __cpu_reset" - : /* outputs */ - : "a"(bist) /* inputs */ - : /* clobbers */ - ); fallback_image: return bist; } Index: amd/solo/failover.c =================================================================== --- amd/solo/failover.c (revision 1105) +++ amd/solo/failover.c (working copy) @@ -9,6 +9,7 @@ #include "southbridge/amd/amd8111/amd8111_enable_rom.c" #include "northbridge/amd/amdk8/early_ht.c" #include "cpu/x86/lapic/boot_cpu.c" +#include "cpu/x86/mtrr/earlymtrr.c" #include "northbridge/amd/amdk8/reset_test.c" static unsigned long main(unsigned long bist) @@ -21,11 +22,11 @@ nodeid = lapicid() & 0xf; /* Is this a cpu only reset? */ - if (cpu_init_detected(nodeid)) { + if (early_mtrr_init_detected()) { if (last_boot_normal()) { goto normal_image; } else { - goto cpu_reset; + goto fallback_image; } } /* Is this a secondary cpu? */ @@ -62,12 +63,6 @@ : "a" (bist) /* inputs */ : /* clobbers */ ); - cpu_reset: - asm volatile ("jmp __cpu_reset" - : /* outputs */ - : "a"(bist) /* inputs */ - : /* clobbers */ - ); fallback_image: return bist; } Index: ibm/e326/failover.c =================================================================== --- ibm/e326/failover.c (revision 1105) +++ ibm/e326/failover.c (working copy) @@ -9,6 +9,7 @@ #include "southbridge/amd/amd8111/amd8111_enable_rom.c" #include "northbridge/amd/amdk8/early_ht.c" #include "cpu/x86/lapic/boot_cpu.c" +#include "cpu/x86/mtrr/earlymtrr.c" #include "northbridge/amd/amdk8/reset_test.c" static unsigned long main(unsigned long bist) @@ -20,11 +21,11 @@ nodeid = lapicid() & 0xf; /* Is this a cpu only reset? */ - if (cpu_init_detected(nodeid)) { + if (early_mtrr_init_detected()) { if (last_boot_normal()) { goto normal_image; } else { - goto cpu_reset; + goto fallback_image; } } /* Is this a secondary cpu? */ @@ -61,12 +62,6 @@ : "a" (bist) /* inputs */ : /* clobbers */ ); - cpu_reset: - asm volatile ("jmp __cpu_reset" - : /* outputs */ - : "a"(bist) /* inputs */ - : /* clobbers */ - ); fallback_image: return bist; } Index: ibm/e325/failover.c =================================================================== --- ibm/e325/failover.c (revision 1105) +++ ibm/e325/failover.c (working copy) @@ -9,6 +9,7 @@ #include "southbridge/amd/amd8111/amd8111_enable_rom.c" #include "northbridge/amd/amdk8/early_ht.c" #include "cpu/x86/lapic/boot_cpu.c" +#include "cpu/x86/mtrr/earlymtrr.c" #include "northbridge/amd/amdk8/reset_test.c" static unsigned long main(unsigned long bist) @@ -20,11 +21,11 @@ nodeid = lapicid() & 0xf; /* Is this a cpu only reset? */ - if (cpu_init_detected(nodeid)) { + if (early_mtrr_init_detected()) { if (last_boot_normal()) { goto normal_image; } else { - goto cpu_reset; + goto fallback_image; } } /* Is this a secondary cpu? */ @@ -61,12 +62,6 @@ : "a" (bist) /* inputs */ : /* clobbers */ ); - cpu_reset: - asm volatile ("jmp __cpu_reset" - : /* outputs */ - : "a"(bist) /* inputs */ - : /* clobbers */ - ); fallback_image: return bist; } Index: island/aruma/failover.c =================================================================== --- island/aruma/failover.c (revision 1105) +++ island/aruma/failover.c (working copy) @@ -9,6 +9,7 @@ #include "southbridge/amd/amd8111/amd8111_enable_rom.c" #include "northbridge/amd/amdk8/early_ht.c" #include "cpu/x86/lapic/boot_cpu.c" +#include "cpu/x86/mtrr/earlymtrr.c" #include "northbridge/amd/amdk8/reset_test.c" static unsigned long main(unsigned long bist) @@ -19,11 +20,11 @@ nodeid=lapicid(); /* Is this a cpu only reset? */ - if (cpu_init_detected(nodeid)) { + if (early_mtrr_init_detected()) { if (last_boot_normal()) { goto normal_image; } else { - goto cpu_reset; + goto fallback_image; } } /* Is this a secondary cpu? */ @@ -60,12 +61,6 @@ : "a" (bist) /* inputs */ : /* clobbers */ ); - cpu_reset: - asm volatile ("jmp __cpu_reset" - : /* outputs */ - : "a"(bist) /* inputs */ - : /* clobbers */ - ); fallback_image: return bist; } Index: tyan/s2880/failover.c =================================================================== --- tyan/s2880/failover.c (revision 1105) +++ tyan/s2880/failover.c (working copy) @@ -9,6 +9,7 @@ #include "southbridge/amd/amd8111/amd8111_enable_rom.c" #include "northbridge/amd/amdk8/early_ht.c" #include "cpu/x86/lapic/boot_cpu.c" +#include "cpu/x86/mtrr/earlymtrr.c" #include "northbridge/amd/amdk8/reset_test.c" #if CONFIG_LOGICAL_CPUS==1 @@ -18,27 +19,15 @@ static unsigned long main(unsigned long bist) { -#if CONFIG_LOGICAL_CPUS==1 - struct node_core_id id; -#else - unsigned nodeid; -#endif /* Make cerain my local apic is useable */ enable_lapic(); -#if CONFIG_LOGICAL_CPUS==1 - id = get_node_core_id_x(); /* Is this a cpu only reset? */ - if (cpu_init_detected(id.nodeid)) { -#else - nodeid = lapicid(); - /* Is this a cpu only reset? */ - if (cpu_init_detected(nodeid)) { -#endif + if (early_mtrr_init_detected()) { if (last_boot_normal()) { goto normal_image; } else { - goto cpu_reset; + goto fallback_image; } } /* Is this a secondary cpu? */ @@ -74,14 +63,6 @@ : "a" (bist) /* inputs */ : /* clobbers */ ); - cpu_reset: -#if 0 - asm volatile ("jmp __cpu_reset" - : /* outputs */ - : "a"(bist) /* inputs */ - : /* clobbers */ - ); -#endif fallback_image: return bist; } Index: tyan/s2881/failover.c =================================================================== --- tyan/s2881/failover.c (revision 1105) +++ tyan/s2881/failover.c (working copy) @@ -9,6 +9,7 @@ #include "southbridge/amd/amd8111/amd8111_enable_rom.c" #include "northbridge/amd/amdk8/early_ht.c" #include "cpu/x86/lapic/boot_cpu.c" +#include "cpu/x86/mtrr/earlymtrr.c" #include "northbridge/amd/amdk8/reset_test.c" #if CONFIG_LOGICAL_CPUS==1 @@ -18,27 +19,15 @@ static unsigned long main(unsigned long bist) { -#if CONFIG_LOGICAL_CPUS==1 - struct node_core_id id; -#else - unsigned nodeid; -#endif /* Make cerain my local apic is useable */ enable_lapic(); -#if CONFIG_LOGICAL_CPUS==1 - id = get_node_core_id_x(); /* Is this a cpu only reset? */ - if (cpu_init_detected(id.nodeid)) { -#else - nodeid = lapicid(); - /* Is this a cpu only reset? */ - if (cpu_init_detected(nodeid)) { -#endif + if (early_mtrr_init_detected()) { if (last_boot_normal()) { goto normal_image; } else { - goto cpu_reset; + goto fallback_image; } } /* Is this a secondary cpu? */ @@ -75,14 +64,6 @@ : "a" (bist) /* inputs */ : /* clobbers */ ); - cpu_reset: -#if 0 - asm volatile ("jmp __cpu_reset" - : /* outputs */ - : "a"(bist) /* inputs */ - : /* clobbers */ - ); -#endif fallback_image: return bist; } Index: tyan/s2882/failover.c =================================================================== --- tyan/s2882/failover.c (revision 1105) +++ tyan/s2882/failover.c (working copy) @@ -9,6 +9,7 @@ #include "southbridge/amd/amd8111/amd8111_enable_rom.c" #include "northbridge/amd/amdk8/early_ht.c" #include "cpu/x86/lapic/boot_cpu.c" +#include "cpu/x86/mtrr/earlymtrr.c" #include "northbridge/amd/amdk8/reset_test.c" #if CONFIG_LOGICAL_CPUS==1 @@ -18,27 +19,15 @@ static unsigned long main(unsigned long bist) { -#if CONFIG_LOGICAL_CPUS==1 - struct node_core_id id; -#else - unsigned nodeid; -#endif /* Make cerain my local apic is useable */ enable_lapic(); -#if CONFIG_LOGICAL_CPUS==1 - id = get_node_core_id_x(); /* Is this a cpu only reset? */ - if (cpu_init_detected(id.nodeid)) { -#else - nodeid = lapicid(); - /* Is this a cpu only reset? */ - if (cpu_init_detected(nodeid)) { -#endif + if (early_mtrr_init_detected()) { if (last_boot_normal()) { goto normal_image; } else { - goto cpu_reset; + goto fallback_image; } } /* Is this a secondary cpu? */ @@ -74,14 +63,6 @@ : "a" (bist) /* inputs */ : /* clobbers */ ); - cpu_reset: -#if 0 - asm volatile ("jmp __cpu_reset" - : /* outputs */ - : "a"(bist) /* inputs */ - : /* clobbers */ - ); -#endif fallback_image: return bist; } Index: tyan/s2891/failover.c =================================================================== --- tyan/s2891/failover.c (revision 1105) +++ tyan/s2891/failover.c (working copy) @@ -10,6 +10,7 @@ #include "southbridge/nvidia/ck804/ck804_enable_rom.c" #include "northbridge/amd/amdk8/early_ht.c" #include "cpu/x86/lapic/boot_cpu.c" +#include "cpu/x86/mtrr/earlymtrr.c" #include "northbridge/amd/amdk8/reset_test.c" static void sio_setup(void) @@ -42,27 +43,15 @@ static unsigned long main(unsigned long bist) { -#if CONFIG_LOGICAL_CPUS==1 - struct node_core_id id; -#else - unsigned nodeid; -#endif /* Make cerain my local apic is useable */ enable_lapic(); -#if CONFIG_LOGICAL_CPUS==1 - id = get_node_core_id_x(); /* Is this a cpu only reset? */ - if (cpu_init_detected(id.nodeid)) { -#else - nodeid = lapicid(); - /* Is this a cpu only reset? */ - if (cpu_init_detected(nodeid)) { -#endif + if (early_mtrr_init_detected(nodeid)) { if (last_boot_normal()) { goto normal_image; } else { - goto cpu_reset; + goto fallback_image; } } @@ -102,15 +91,6 @@ : "a" (bist) /* inputs */ : /* clobbers */ ); - cpu_reset: -#if 0 - //CPU reset will reset memtroller ??? - asm volatile ("jmp __cpu_reset" - : /* outputs */ - : "a"(bist) /* inputs */ - : /* clobbers */ - ); -#endif fallback_image: return bist; Index: tyan/s4880/failover.c =================================================================== --- tyan/s4880/failover.c (revision 1105) +++ tyan/s4880/failover.c (working copy) @@ -9,6 +9,7 @@ #include "southbridge/amd/amd8111/amd8111_enable_rom.c" #include "northbridge/amd/amdk8/early_ht.c" #include "cpu/x86/lapic/boot_cpu.c" +#include "cpu/x86/mtrr/earlymtrr.c" #include "northbridge/amd/amdk8/reset_test.c" #if CONFIG_LOGICAL_CPUS==1 @@ -18,27 +19,15 @@ static unsigned long main(unsigned long bist) { -#if CONFIG_LOGICAL_CPUS==1 - struct node_core_id id; -#else - unsigned nodeid; -#endif /* Make cerain my local apic is useable */ enable_lapic(); -#if CONFIG_LOGICAL_CPUS==1 - id = get_node_core_id_x(); /* Is this a cpu only reset? */ - if (cpu_init_detected(id.nodeid)) { -#else - nodeid = lapicid(); - /* Is this a cpu only reset? */ - if (cpu_init_detected(nodeid)) { -#endif + if (early_mtrr_init_detected()) { if (last_boot_normal()) { goto normal_image; } else { - goto cpu_reset; + goto fallback_image; } } /* Is this a secondary cpu? */ @@ -75,14 +64,6 @@ : "a" (bist) /* inputs */ : /* clobbers */ ); - cpu_reset: -#if 0 - asm volatile ("jmp __cpu_reset" - : /* outputs */ - : "a"(bist) /* inputs */ - : /* clobbers */ - ); -#endif fallback_image: return bist; } Index: tyan/s2892/failover.c =================================================================== --- tyan/s2892/failover.c (revision 1105) +++ tyan/s2892/failover.c (working copy) @@ -10,6 +10,7 @@ #include "southbridge/nvidia/ck804/ck804_enable_rom.c" #include "northbridge/amd/amdk8/early_ht.c" #include "cpu/x86/lapic/boot_cpu.c" +#include "cpu/x86/mtrr/earlymtrr.c" #include "northbridge/amd/amdk8/reset_test.c" static void sio_setup(void) @@ -36,27 +37,15 @@ static unsigned long main(unsigned long bist) { -#if CONFIG_LOGICAL_CPUS==1 - struct node_core_id id; -#else - unsigned nodeid; -#endif /* Make cerain my local apic is useable */ enable_lapic(); -#if CONFIG_LOGICAL_CPUS==1 - id = get_node_core_id_x(); /* Is this a cpu only reset? */ - if (cpu_init_detected(id.nodeid)) { -#else - nodeid = lapicid(); - /* Is this a cpu only reset? */ - if (cpu_init_detected(nodeid)) { -#endif + if (early_mtrr_init_detected()) { if (last_boot_normal()) { goto normal_image; } else { - goto cpu_reset; + goto fallback_image; } } @@ -96,16 +85,6 @@ : "a" (bist) /* inputs */ : /* clobbers */ ); - cpu_reset: -#if 0 - //CPU reset will reset memtroller ??? - asm volatile ("jmp __cpu_reset" - : /* outputs */ - : "a"(bist) /* inputs */ - : /* clobbers */ - ); -#endif - fallback_image: return bist; } Index: tyan/s2875/failover.c =================================================================== --- tyan/s2875/failover.c (revision 1105) +++ tyan/s2875/failover.c (working copy) @@ -9,6 +9,7 @@ #include "southbridge/amd/amd8111/amd8111_enable_rom.c" #include "northbridge/amd/amdk8/early_ht.c" #include "cpu/x86/lapic/boot_cpu.c" +#include "cpu/x86/mtrr/earlymtrr.c" #include "northbridge/amd/amdk8/reset_test.c" #if CONFIG_LOGICAL_CPUS==1 @@ -18,27 +19,15 @@ static unsigned long main(unsigned long bist) { -#if CONFIG_LOGICAL_CPUS==1 - struct node_core_id id; -#else - unsigned nodeid; -#endif /* Make cerain my local apic is useable */ enable_lapic(); -#if CONFIG_LOGICAL_CPUS==1 - id = get_node_core_id_x(); /* Is this a cpu only reset? */ - if (cpu_init_detected(id.nodeid)) { -#else - nodeid = lapicid(); - /* Is this a cpu only reset? */ - if (cpu_init_detected(nodeid)) { -#endif + if (early_mtrr_init_detected()) { if (last_boot_normal()) { goto normal_image; } else { - goto cpu_reset; + goto fallback_image; } } /* Is this a secondary cpu? */ @@ -75,14 +64,6 @@ : "a" (bist) /* inputs */ : /* clobbers */ ); - cpu_reset: -#if 0 - asm volatile ("jmp __cpu_reset" - : /* outputs */ - : "a"(bist) /* inputs */ - : /* clobbers */ - ); -#endif fallback_image: return bist; } Index: tyan/s4882/failover.c =================================================================== --- tyan/s4882/failover.c (revision 1105) +++ tyan/s4882/failover.c (working copy) @@ -9,6 +9,7 @@ #include "southbridge/amd/amd8111/amd8111_enable_rom.c" #include "northbridge/amd/amdk8/early_ht.c" #include "cpu/x86/lapic/boot_cpu.c" +#include "cpu/x86/mtrr/earlymtrr.c" #include "northbridge/amd/amdk8/reset_test.c" #if CONFIG_LOGICAL_CPUS==1 @@ -20,28 +21,13 @@ static unsigned long main(unsigned long bist) { -#if CONFIG_LOGICAL_CPUS==1 - struct node_core_id id; -#else - unsigned nodeid; -#endif - /* Make cerain my local apic is useable */ -// enable_lapic(); -#if CONFIG_LOGICAL_CPUS==1 - id = get_node_core_id_x(); /* Is this a cpu only reset? */ - if (cpu_init_detected(id.nodeid)) { -#else -// nodeid = lapicid() & 0xf; - nodeid = get_node_id(); - /* Is this a cpu only reset? */ - if (cpu_init_detected(nodeid)) { -#endif + if (early_mtrr_init_detected()) { if (last_boot_normal()) { goto normal_image; } else { - goto cpu_reset; + goto fallback_image; } } /* Is this a secondary cpu? */ @@ -77,14 +63,6 @@ : "a" (bist) /* inputs */ : /* clobbers */ ); - cpu_reset: -#if 0 - asm volatile ("jmp __cpu_reset" - : /* outputs */ - : "a"(bist) /* inputs */ - : /* clobbers */ - ); -#endif fallback_image: return bist; } Index: tyan/s2885/failover.c =================================================================== --- tyan/s2885/failover.c (revision 1105) +++ tyan/s2885/failover.c (working copy) @@ -9,6 +9,7 @@ #include "southbridge/amd/amd8111/amd8111_enable_rom.c" #include "northbridge/amd/amdk8/early_ht.c" #include "cpu/x86/lapic/boot_cpu.c" +#include "cpu/x86/mtrr/earlymtrr.c" #include "northbridge/amd/amdk8/reset_test.c" #if CONFIG_LOGICAL_CPUS==1 @@ -19,29 +20,13 @@ static unsigned long main(unsigned long bist) { -#if CONFIG_LOGICAL_CPUS==1 - struct node_core_id id; -#else - unsigned nodeid; -#endif - /* Make cerain my local apic is useable */ -// enable_lapic(); - -#if CONFIG_LOGICAL_CPUS==1 - id = get_node_core_id_x(); /* Is this a cpu only reset? */ - if (cpu_init_detected(id.nodeid)) { -#else -// nodeid = lapicid() & 0xf; - nodeid = get_node_id(); + if (early_mtrr_init_detected()) { /* Is this a cpu only reset? */ - if (cpu_init_detected(nodeid)) { -#endif - /* Is this a cpu only reset? */ if (last_boot_normal()) { goto normal_image; } else { - goto cpu_reset; + goto fallback_image; } } /* Is this a secondary cpu? */ @@ -77,14 +62,6 @@ : "a" (bist) /* inputs */ : /* clobbers */ ); - cpu_reset: -#if 0 - asm volatile ("jmp __cpu_reset" - : /* outputs */ - : "a"(bist) /* inputs */ - : /* clobbers */ - ); -#endif fallback_image: return bist; } Index: tyan/s2895/failover.c =================================================================== --- tyan/s2895/failover.c (revision 1105) +++ tyan/s2895/failover.c (working copy) @@ -13,6 +13,7 @@ #include "southbridge/nvidia/ck804/ck804_enable_rom.c" #include "northbridge/amd/amdk8/early_ht.c" #include "cpu/x86/lapic/boot_cpu.c" +#include "cpu/x86/mtrr/earlymtrr.c" #include "northbridge/amd/amdk8/reset_test.c" #include "superio/smsc/lpc47b397/lpc47b397_early_serial.c" @@ -59,27 +60,12 @@ static unsigned long main(unsigned long bist) { -#if CONFIG_LOGICAL_CPUS==1 - struct node_core_id id; -#else - unsigned nodeid; -#endif - /* Make cerain my local apic is useable */ -// enable_lapic(); - -#if CONFIG_LOGICAL_CPUS==1 - id = get_node_core_id_x(); /* Is this a cpu only reset? */ - if (cpu_init_detected(id.nodeid)) { -#else - nodeid = get_node_id(); - /* Is this a cpu only reset? */ - if (cpu_init_detected(nodeid)) { -#endif + if (early_mtrr_init_detected()) { if (last_boot_normal()) { goto normal_image; } else { - goto cpu_reset; + goto fallback_image; } } @@ -119,16 +105,6 @@ : "a" (bist) /* inputs */ : /* clobbers */ ); - cpu_reset: -#if 0 - //CPU reset will reset memtroller ??? - asm volatile ("jmp __cpu_reset" - : /* outputs */ - : "a"(bist) /* inputs */ - : /* clobbers */ - ); -#endif - fallback_image: return bist; } -- Jason W. Schildt LinuxBIOS Software Engineer Linux Networx From jschildt at lnxi.com Sat Sep 3 00:03:31 2005 From: jschildt at lnxi.com (jason schildt) Date: Fri, 02 Sep 2005 16:03:31 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-12/16 Message-ID: DESCRIPTION: ------------------------------------------------- ## lnxi-patch-12 ## (20)files src/mainboard/{all_opteron_boards}/auto.c /Iwill/DK8S2/auto.c: /Iwill/DK8X/auto.c: /arima/hdama/auto.c: /newisys/khepri/auto.c: /amd/quartet/auto.c: /amd/serenade/auto.c: /amd/solo/auto.c: /ibm/e326/auto.c: /ibm/e325/auto.c: /island/aruma/auto.c: /tyan/s2880/auto.c: /tyan/s2881/auto.c: /tyan/s2882/auto.c: /tyan/s2891/auto.c: /tyan/s4880/auto.c: /tyan/s2892/auto.c: /tyan/s2875/auto.c: /tyan/s4882/auto.c: /tyan/s2885/auto.c: /tyan/s2895/auto.c: Substituded: k8_init_and_stop_secondaries() for old k8 Preamble. DIFFSTAT: ------------------------------------------------- Iwill/DK8S2/auto.c | 16 +-------- Iwill/DK8X/auto.c | 15 +-------- amd/quartet/auto.c | 17 +--------- amd/serenade/auto.c | 16 +-------- amd/solo/auto.c | 20 +----------- arima/hdama/auto.c | 24 ++++---------- ibm/e325/auto.c | 17 +--------- ibm/e326/auto.c | 17 +--------- island/aruma/auto.c | 55 +++++++++------------------------ newisys/khepri/auto.c | 17 +--------- tyan/s2875/auto.c | 50 +----------------------------- tyan/s2880/auto.c | 45 +-------------------------- tyan/s2881/auto.c | 43 +------------------------- tyan/s2882/auto.c | 45 +-------------------------- tyan/s2885/auto.c | 77 +--------------------------------------------- tyan/s2891/auto.c | 53 +++----------------------------- tyan/s2892/auto.c | 54 ++------------------------------ tyan/s2895/auto.c | 82 +------------------------------------------------- tyan/s4880/auto.c | 50 +----------------------------- tyan/s4882/auto.c | 74 +-------------------------------------------- 20 files changed, 68 insertions(+), 719 deletions(-) PATCH: ------------------------------------------------- Index: Iwill/DK8S2/auto.c =================================================================== --- Iwill/DK8S2/auto.c (revision 1105) +++ Iwill/DK8S2/auto.c (working copy) @@ -23,7 +23,9 @@ #include "superio/winbond/w83627hf/w83627hf_early_serial.c" #include "cpu/amd/mtrr/amd_earlymtrr.c" #include "cpu/x86/bist.h" +#include "cpu/amd/dualcore/dualcore.c" + #define SERIAL_DEV PNP_DEV(0x2e, W83627HF_SP1) static void hard_reset(void) @@ -161,19 +163,7 @@ unsigned nodeid; if (bist == 0) { - /* Skip this if there was a built in self test failure */ - amd_early_mtrr_init(); - enable_lapic(); - init_timer(); - - /* Has this cpu already booted? */ - if (cpu_init_detected(nodeid)) { - asm volatile ("jmp __cpu_reset"); - } - distinguish_cpu_resets(nodeid); - if (!boot_cpu()) { - stop_this_cpu(); - } + k8_init_and_stop_secondaries(); } /* Setup the console */ w83627hf_enable_serial(SERIAL_DEV, TTYS0_BASE); Index: Iwill/DK8X/auto.c =================================================================== --- Iwill/DK8X/auto.c (revision 1105) +++ Iwill/DK8X/auto.c (working copy) @@ -20,9 +20,11 @@ #include "northbridge/amd/amdk8/reset_test.c" #include "northbridge/amd/amdk8/debug.c" #include "northbridge/amd/amdk8/cpu_rev.c" + #include "superio/NSC/pc87360/pc87360_early_serial.c" #include "cpu/amd/mtrr/amd_earlymtrr.c" #include "cpu/x86/bist.h" +#include "cpu/amd/dualcore/dualcore.c" #define SERIAL_DEV PNP_DEV(0x2e, PC87360_SP1) @@ -163,18 +165,7 @@ unsigned nodeid; if (bist == 0) { - /* Skip this if there was a built in self test failure */ - amd_early_mtrr_init(); - enable_lapic(); - init_timer(); - /* Has this cpu already booted? */ - if (cpu_init_detected(nodeid)) { - asm volatile ("jmp __cpu_reset"); - } - distinguish_cpu_resets(nodeid); - if (!boot_cpu()) { - stop_this_cpu(); - } + k8_init_and_stop_secondaries(); } /* Setup the console */ pc87360_enable_serial(SERIAL_DEV, TTYS0_BASE); Index: arima/hdama/auto.c =================================================================== --- arima/hdama/auto.c (revision 1105) +++ arima/hdama/auto.c (working copy) @@ -22,6 +22,7 @@ #include "superio/NSC/pc87360/pc87360_early_serial.c" #include "cpu/amd/mtrr/amd_earlymtrr.c" #include "cpu/x86/bist.h" +#include "cpu/amd/dualcore/dualcore.c" #define SERIAL_DEV PNP_DEV(0x2e, PC87360_SP1) @@ -135,7 +136,7 @@ }; if (maxnodes > 2) { - print_debug("this mainboard is only designed for 2 cpus\r\n"); + print_spew("this mainboard is only designed for 2 cpus\r\n"); maxnodes = 2; } @@ -165,6 +166,8 @@ #define FIRST_CPU 1 #define SECOND_CPU 1 #define TOTAL_CPUS (FIRST_CPU + SECOND_CPU) + + static void main(unsigned long bist) { static const struct mem_controller cpu[] = { @@ -194,21 +197,7 @@ int needs_reset; if (bist == 0) { - unsigned nodeid; - /* Skip this if there was a built in self test failure */ - amd_early_mtrr_init(); - enable_lapic(); - init_timer(); - nodeid = lapicid() & 0xf; - - /* Has this cpu already booted? */ - if (cpu_init_detected(nodeid)) { - asm volatile ("jmp __cpu_reset"); - } - distinguish_cpu_resets(nodeid); - if (!boot_cpu()) { - stop_this_cpu(); - } + k8_init_and_stop_secondaries(); } /* Setup the console */ pc87360_enable_serial(SERIAL_DEV, TTYS0_BASE); @@ -235,12 +224,13 @@ memreset_setup(); sdram_initialize(sizeof(cpu)/sizeof(cpu[0]), cpu); - + #if 0 dump_pci_devices(); #endif #if 0 dump_pci_device(PCI_DEV(0, 0x18, 2)); + dump_pci_device(PCI_DEV(0, 0x18, 3)); #endif #if 0 Index: newisys/khepri/auto.c =================================================================== --- newisys/khepri/auto.c (revision 1105) +++ newisys/khepri/auto.c (working copy) @@ -23,6 +23,7 @@ #include "superio/NSC/pc87360/pc87360_early_serial.c" #include "cpu/amd/mtrr/amd_earlymtrr.c" #include "cpu/x86/bist.h" +#include "cpu/amd/dualcore/dualcore.c" #define SERIAL_DEV PNP_DEV(0x2e, PC87360_SP1) @@ -111,21 +112,7 @@ unsigned nodeid; if (bist == 0) { - /* Skip this if there was a built in self test failure */ - amd_early_mtrr_init(); - enable_lapic(); - init_timer(); - - nodeid = lapicid() & 0xf; - - /* Has this cpu already booted? */ - if (cpu_init_detected(nodeid)) { - asm volatile ("jmp __cpu_reset"); - } - distinguish_cpu_resets(nodeid); - if (!boot_cpu()) { - stop_this_cpu(); - } + k8_init_and_stop_secondaries(); } /* Setup the console */ pc87360_enable_serial(SERIAL_DEV, TTYS0_BASE); Index: amd/quartet/auto.c =================================================================== --- amd/quartet/auto.c (revision 1105) +++ amd/quartet/auto.c (working copy) @@ -26,6 +26,7 @@ #include "superio/NSC/pc87360/pc87360_early_serial.c" #include "cpu/amd/mtrr/amd_earlymtrr.c" #include "cpu/x86/bist.h" +#include "cpu/amd/dualcore/dualcore.c" #define SERIAL_DEV PNP_DEV(0x2e, PC87360_SP1) @@ -212,21 +213,7 @@ unsigned nodeid; if (bist == 0) { - /* Skip this if there was a built in self test failure */ - amd_early_mtrr_init(); - enable_lapic(); - init_timer(); - nodeid = lapicid() & 0xf; - /* Has this cpu already booted? */ - if (cpu_init_detected(nodeid)) { - asm volatile ("jmp __cpu_reset"); - } - - distinguish_cpu_resets(nodeid); - - if (!boot_cpu()) { - stop_this_cpu(); - } + k8_init_and_stop_secondaries(); } /* Setup the console */ pc87360_enable_serial(SERIAL_DEV, TTYS0_BASE); Index: amd/serenade/auto.c =================================================================== --- amd/serenade/auto.c (revision 1105) +++ amd/serenade/auto.c (working copy) @@ -25,6 +25,7 @@ #include "superio/winbond/w83627hf/w83627hf_early_serial.c" #include "cpu/amd/mtrr/amd_earlymtrr.c" #include "cpu/x86/bist.h" +#include "cpu/amd/dualcore/dualcore.c" #define SERIAL_DEV PNP_DEV(0x2e, W83627HF_SP1) @@ -163,20 +164,7 @@ int needs_reset; unsigned nodeid; if (bist == 0) { - /* Skip this if there was a built in self test failure */ - amd_early_mtrr_init(); - enable_lapic(); - init_timer(); - nodeid = lapicid() & 0xf; - /* Has this cpu already booted? */ - if (cpu_init_detected(nodeid)) { - asm volatile ("jmp __cpu_reset"); - } - - distinguish_cpu_resets(nodeid); - if (!boot_cpu()) { - stop_this_cpu(); - } + k8_init_and_stop_secondaries(); } /* Setup the console */ w83627hf_enable_serial(SERIAL_DEV, TTYS0_BASE); Index: amd/solo/auto.c =================================================================== --- amd/solo/auto.c (revision 1105) +++ amd/solo/auto.c (working copy) @@ -23,6 +23,7 @@ #include "superio/NSC/pc87360/pc87360_early_serial.c" #include "cpu/amd/mtrr/amd_earlymtrr.c" #include "cpu/x86/bist.h" +#include "cpu/amd/dualcore/dualcore.c" #define SERIAL_DEV PNP_DEV(0x2e, PC87360_SP1) @@ -111,24 +112,7 @@ unsigned nodeid; if (bist == 0) { - /* Skip this if there was a built in self test failure */ - amd_early_mtrr_init(); - - enable_lapic(); - init_timer(); - - nodeid = lapicid() & 0xf; - - if (cpu_init_detected(nodeid)) { - asm volatile ("jmp __cpu_reset"); - } - - distinguish_cpu_resets(nodeid); - - if (!boot_cpu()) { - /* This LinuxBIOS image is built for UP only */ - stop_this_cpu(); - } + k8_init_and_stop_secondaries(); } /* Setup the console */ Index: ibm/e325/auto.c =================================================================== --- ibm/e325/auto.c (revision 1105) +++ ibm/e325/auto.c (working copy) @@ -25,6 +25,7 @@ #include "superio/NSC/pc87366/pc87366_early_serial.c" #include "cpu/amd/mtrr/amd_earlymtrr.c" #include "cpu/x86/bist.h" +#include "cpu/amd/dualcore/dualcore.c" #define SERIAL_DEV PNP_DEV(0x2e, PC87366_SP1) @@ -161,21 +162,7 @@ unsigned nodeid; if (bist == 0) { - /* Skip this if there was a built in self test failure */ - amd_early_mtrr_init(); - enable_lapic(); - init_timer(); - - nodeid = lapicid() & 0xf; - - /* Has this cpu already booted? */ - if (cpu_init_detected(nodeid)) { - asm volatile ("jmp __cpu_reset"); - } - distinguish_cpu_resets(nodeid); - if (!boot_cpu()) { - stop_this_cpu(); - } + k8_init_and_stop_secondaries(); } /* Setup the console */ pc87366_enable_serial(SERIAL_DEV, TTYS0_BASE); Index: ibm/e326/auto.c =================================================================== --- ibm/e326/auto.c (revision 1105) +++ ibm/e326/auto.c (working copy) @@ -25,6 +25,7 @@ #include "superio/NSC/pc87366/pc87366_early_serial.c" #include "cpu/amd/mtrr/amd_earlymtrr.c" #include "cpu/x86/bist.h" +#include "cpu/amd/dualcore/dualcore.c" #define SERIAL_DEV PNP_DEV(0x2e, PC87366_SP1) @@ -161,21 +162,7 @@ unsigned nodeid; if (bist == 0) { - /* Skip this if there was a built in self test failure */ - amd_early_mtrr_init(); - enable_lapic(); - init_timer(); - - nodeid = lapicid() & 0xf; - - /* Has this cpu already booted? */ - if (cpu_init_detected(nodeid)) { - asm volatile ("jmp __cpu_reset"); - } - distinguish_cpu_resets(nodeid); - if (!boot_cpu()) { - stop_this_cpu(); - } + k8_init_and_stop_secondaries(); } /* Setup the console */ pc87366_enable_serial(SERIAL_DEV, TTYS0_BASE); Index: island/aruma/auto.c =================================================================== --- island/aruma/auto.c (revision 1105) +++ island/aruma/auto.c (working copy) @@ -25,6 +25,7 @@ #include "superio/winbond/w83627hf/w83627hf_early_serial.c" #include "cpu/amd/mtrr/amd_earlymtrr.c" #include "cpu/x86/bist.h" +#include "cpu/amd/dualcore/dualcore.c" #define SERIAL_DEV PNP_DEV(0x2e, W83627HF_SP1) @@ -128,31 +129,7 @@ int needs_reset; if (bist == 0) { - unsigned nodeid; - - /* Skip this if there was a built in self test failure */ - amd_early_mtrr_init(); - enable_lapic(); - init_timer(); - - nodeid=lapicid() & 0xf; - - -#if ENABLE_APIC_EXT_ID == 1 - enable_apic_ext_id(nodeid); - if(nodeid != 0) { - /* CPU apicid is from 0x10 */ - lapic_write(LAPIC_ID, ( lapic_read(LAPIC_ID) - | (APIC_ID_OFFSET<<24) ) ); - } -#endif - if (cpu_init_detected(nodeid)) { - asm volatile ("jmp __cpu_reset"); - } - distinguish_cpu_resets(nodeid); - if (!boot_cpu()) { - stop_this_cpu(); - } + k8_init_and_stop_secondaries(); } /* Setup the console */ w83627hf_enable_serial(SERIAL_DEV, TTYS0_BASE); @@ -173,20 +150,20 @@ print_pci_devices(); #endif -#if (ALLOW_HT_OVERCLOCKING==1) && (USE_FALLBACK_IMAGE==0) - if(read_option(CMOS_VSTART_amdk8_1GHz, CMOS_VLEN_amdk8_1GHz, 0)) - { - print_debug("AMDK8 allowed at 1GHz\r\n"); - } else { - print_debug("AMDK8 allowed at 800Hz only\r\n"); - } - if(read_option(CMOS_VSTART_amd8131_800MHz, CMOS_VLEN_amd8131_800MHz, 0)) - { - print_debug("AMD8131 allowed at 800MHz\r\n"); - } else { - print_debug("AMD8131 allowed at 600Hz only\r\n"); - } -#endif +//#if (ALLOW_HT_OVERCLOCKING==1) && (USE_FALLBACK_IMAGE==0) +// if(read_option(CMOS_VSTART_amdk8_1GHz, CMOS_VLEN_amdk8_1GHz, 0)) +// { +// print_debug("AMDK8 allowed at 1GHz\r\n"); +// } else { +// print_debug("AMDK8 allowed at 800Hz only\r\n"); +// } +// if(read_option(CMOS_VSTART_amd8131_800MHz, CMOS_VLEN_amd8131_800MHz, 0)) +// { +// print_debug("AMD8131 allowed at 800MHz\r\n"); +// } else { +// print_debug("AMD8131 allowed at 600Hz only\r\n"); +// } +//#endif if (needs_reset) { print_info("HyperT reset -\r\n"); soft_reset(); Index: tyan/s2880/auto.c =================================================================== --- tyan/s2880/auto.c (revision 1105) +++ tyan/s2880/auto.c (working copy) @@ -24,6 +24,7 @@ #include "superio/winbond/w83627hf/w83627hf_early_serial.c" #include "cpu/amd/mtrr/amd_earlymtrr.c" #include "cpu/x86/bist.h" +#include "cpu/amd/dualcore/dualcore.c" #define SERIAL_DEV PNP_DEV(0x2e, W83627HF_SP1) @@ -149,46 +150,8 @@ }; int needs_reset; -#if CONFIG_LOGICAL_CPUS==1 - struct node_core_id id; -#else - unsigned nodeid; -#endif - if (bist == 0) { - /* Skip this if there was a built in self test failure */ - amd_early_mtrr_init(); - -#if CONFIG_LOGICAL_CPUS==1 - set_apicid_cpuid_lo(); -#endif - - enable_lapic(); - init_timer(); - -#if CONFIG_LOGICAL_CPUS==1 - id = get_node_core_id_x(); - if(id.coreid == 0) { - if (cpu_init_detected(id.nodeid)) { - asm volatile ("jmp __cpu_reset"); - } - distinguish_cpu_resets(id.nodeid); - } -#else - nodeid = lapicid(); - if (cpu_init_detected(nodeid)) { - asm volatile ("jmp __cpu_reset"); - } - distinguish_cpu_resets(nodeid); -#endif - - if (!boot_cpu() -#if CONFIG_LOGICAL_CPUS==1 - || (id.coreid != 0) -#endif - ) { - stop_this_cpu(); // it will stop all cores except core0 of cpu0 - } + k8_init_and_stop_secondaries(); } w83627hf_enable_serial(SERIAL_DEV, TTYS0_BASE); @@ -201,10 +164,6 @@ setup_default_resource_map(); needs_reset = setup_coherent_ht_domain(); -#if CONFIG_LOGICAL_CPUS==1 - start_other_cores(); -#endif - needs_reset |= ht_setup_chain(PCI_DEV(0, 0x18, 0), 0x80); if (needs_reset) { print_info("ht reset -\r\n"); Index: tyan/s2881/auto.c =================================================================== --- tyan/s2881/auto.c (revision 1105) +++ tyan/s2881/auto.c (working copy) @@ -24,6 +24,7 @@ #include "superio/winbond/w83627hf/w83627hf_early_serial.c" #include "cpu/amd/mtrr/amd_earlymtrr.c" #include "cpu/x86/bist.h" +#include "cpu/amd/dualcore/dualcore.c" #define SERIAL_DEV PNP_DEV(0x2e, W83627HF_SP1) @@ -114,11 +115,6 @@ /* tyan does not want the default */ #include "resourcemap.c" -#if CONFIG_LOGICAL_CPUS==1 -#define SET_NB_CFG_54 1 -#include "cpu/amd/dualcore/dualcore.c" -#endif - #define FIRST_CPU 1 #define SECOND_CPU 1 #define TOTAL_CPUS (FIRST_CPU + SECOND_CPU) @@ -156,39 +152,7 @@ #endif if (bist == 0) { - /* Skip this if there was a built in self test failure */ - amd_early_mtrr_init(); - -#if CONFIG_LOGICAL_CPUS==1 - set_apicid_cpuid_lo(); -#endif - - enable_lapic(); - init_timer(); - -#if CONFIG_LOGICAL_CPUS==1 - id = get_node_core_id_x(); - if(id.coreid == 0) { - if (cpu_init_detected(id.nodeid)) { - asm volatile ("jmp __cpu_reset"); - } - distinguish_cpu_resets(id.nodeid); - } -#else - nodeid = lapicid(); - if (cpu_init_detected(nodeid)) { - asm volatile ("jmp __cpu_reset"); - } - distinguish_cpu_resets(nodeid); -#endif - - if (!boot_cpu() -#if CONFIG_LOGICAL_CPUS==1 - || (id.coreid != 0) -#endif - ) { - stop_this_cpu(); // it will stop all cores except core0 of cpu0 - } + k8_init_and_stop_secondaries(); } w83627hf_enable_serial(SERIAL_DEV, TTYS0_BASE); @@ -200,9 +164,6 @@ setup_s2881_resource_map(); needs_reset = setup_coherent_ht_domain(); -#if CONFIG_LOGICAL_CPUS==1 - start_other_cores(); -#endif // automatically set that for you, but you might meet tight space needs_reset |= ht_setup_chains_x(); if (needs_reset) { Index: tyan/s2882/auto.c =================================================================== --- tyan/s2882/auto.c (revision 1105) +++ tyan/s2882/auto.c (working copy) @@ -24,6 +24,7 @@ #include "superio/winbond/w83627hf/w83627hf_early_serial.c" #include "cpu/amd/mtrr/amd_earlymtrr.c" #include "cpu/x86/bist.h" +#include "cpu/amd/dualcore/dualcore.c" #define SERIAL_DEV PNP_DEV(0x2e, W83627HF_SP1) @@ -113,11 +114,6 @@ #include "northbridge/amd/amdk8/coherent_ht.c" #include "sdram/generic_sdram.c" -#if CONFIG_LOGICAL_CPUS==1 -#define SET_NB_CFG_54 1 -#include "cpu/amd/dualcore/dualcore.c" -#endif - #define FIRST_CPU 1 #define SECOND_CPU 1 #define TOTAL_CPUS (FIRST_CPU + SECOND_CPU) @@ -160,41 +156,9 @@ #endif if (bist == 0) { - /* Skip this if there was a built in self test failure */ - amd_early_mtrr_init(); + k8_init_and_stop_secondaries(); + } -#if CONFIG_LOGICAL_CPUS==1 - set_apicid_cpuid_lo(); -#endif - - enable_lapic(); - init_timer(); - -#if CONFIG_LOGICAL_CPUS==1 - id = get_node_core_id_x(); - if(id.coreid == 0) { - if (cpu_init_detected(id.nodeid)) { - asm volatile ("jmp __cpu_reset"); - } - distinguish_cpu_resets(id.nodeid); - } -#else - nodeid = lapicid(); - if (cpu_init_detected(nodeid)) { - asm volatile ("jmp __cpu_reset"); - } - distinguish_cpu_resets(nodeid); -#endif - - if (!boot_cpu() -#if CONFIG_LOGICAL_CPUS==1 - || (id.coreid != 0) -#endif - ) { - stop_this_cpu(); // it will stop all cores except core0 of cpu0 - } - } - w83627hf_enable_serial(SERIAL_DEV, TTYS0_BASE); uart_init(); console_init(); @@ -204,9 +168,6 @@ setup_default_resource_map(); needs_reset = setup_coherent_ht_domain(); -#if CONFIG_LOGICAL_CPUS==1 - start_other_cores(); -#endif needs_reset |= ht_setup_chains_x(); if (needs_reset) { print_info("ht reset -\r\n"); Index: tyan/s2891/auto.c =================================================================== --- tyan/s2891/auto.c (revision 1105) +++ tyan/s2891/auto.c (working copy) @@ -26,6 +26,7 @@ #include "cpu/amd/mtrr/amd_earlymtrr.c" #include "cpu/x86/bist.h" +#include "cpu/amd/dualcore/dualcore.c" #include "northbridge/amd/amdk8/setup_resource_map.c" @@ -77,11 +78,6 @@ /* tyan does not want the default */ #include "resourcemap.c" -#if CONFIG_LOGICAL_CPUS==1 -#define SET_NB_CFG_54 1 -#include "cpu/amd/dualcore/dualcore.c" -#endif - #define FIRST_CPU 1 #define SECOND_CPU 1 #define TOTAL_CPUS (FIRST_CPU + SECOND_CPU) @@ -125,45 +121,10 @@ #endif if (bist == 0) { - /* Skip this if there was a built in self test failure */ - amd_early_mtrr_init(); - -#if CONFIG_LOGICAL_CPUS==1 - set_apicid_cpuid_lo(); -#endif - - enable_lapic(); - init_timer(); - - -#if CONFIG_LOGICAL_CPUS==1 - id = get_node_core_id_x(); - if(id.coreid == 0) { - if (cpu_init_detected(id.nodeid)) { - asm volatile ("jmp __cpu_reset"); - } - distinguish_cpu_resets(id.nodeid); - } -#else - nodeid = lapicid(); - if (cpu_init_detected(nodeid)) { - asm volatile ("jmp __cpu_reset"); - } - distinguish_cpu_resets(nodeid); -#endif - - post_code(0x31); - - if (!boot_cpu() -#if CONFIG_LOGICAL_CPUS==1 - || (id.coreid != 0) -#endif - ) { - stop_this_cpu(); // it will stop all cores except core0 of cpu0 - } + k8_init_and_stop_secondaries(); } - post_code(0x32); + // post_code(0x32); w83627hf_enable_serial(SERIAL_DEV, TTYS0_BASE); uart_init(); @@ -175,13 +136,9 @@ setup_s2891_resource_map(); needs_reset = setup_coherent_ht_domain(); + + needs_reset |= ht_setup_chains_x(); -#if CONFIG_LOGICAL_CPUS==1 - // It is said that we should start core1 after all core0 launched - start_other_cores(); -#endif - needs_reset |= ht_setup_chains_x(); - needs_reset |= ck804_early_setup_x(); if (needs_reset) { Index: tyan/s4880/auto.c =================================================================== --- tyan/s4880/auto.c (revision 1105) +++ tyan/s4880/auto.c (working copy) @@ -24,6 +24,7 @@ #include "superio/winbond/w83627hf/w83627hf_early_serial.c" #include "cpu/amd/mtrr/amd_earlymtrr.c" #include "cpu/x86/bist.h" +#include "cpu/amd/dualcore/dualcore.c" #define SERIAL_DEV PNP_DEV(0x2e, W83627HF_SP1) @@ -125,11 +126,6 @@ /* tyan does not want the default */ #include "resourcemap.c" -#if CONFIG_LOGICAL_CPUS==1 -#define SET_NB_CFG_54 1 -#include "cpu/amd/dualcore/dualcore.c" -#endif - #define FIRST_CPU 1 #define SECOND_CPU 1 @@ -202,47 +198,9 @@ }; int i; int needs_reset; -#if CONFIG_LOGICAL_CPUS==1 - struct node_core_id id; -#else - unsigned nodeid; -#endif if (bist == 0) { - /* Skip this if there was a built in self test failure */ - amd_early_mtrr_init(); - -#if CONFIG_LOGICAL_CPUS==1 - set_apicid_cpuid_lo(); -#endif - - enable_lapic(); - init_timer(); - -#if CONFIG_LOGICAL_CPUS==1 - id = get_node_core_id_x(); - if(id.coreid == 0) { - if (cpu_init_detected(id.nodeid)) { - asm volatile ("jmp __cpu_reset"); - } - distinguish_cpu_resets(id.nodeid); -// start_other_core(id.nodeid); - } -#else - nodeid = lapicid(); - if (cpu_init_detected(nodeid)) { - asm volatile ("jmp __cpu_reset"); - } - distinguish_cpu_resets(nodeid); -#endif - - if (!boot_cpu() -#if CONFIG_LOGICAL_CPUS==1 - || (id.coreid != 0) -#endif - ) { - stop_this_cpu(); // it will stop all cores except core0 of cpu0 - } + k8_init_and_stop_secondaries(); } w83627hf_enable_serial(SERIAL_DEV, TTYS0_BASE); @@ -256,10 +214,6 @@ needs_reset = setup_coherent_ht_domain(); -#if CONFIG_LOGICAL_CPUS==1 - start_other_cores(); -#endif - needs_reset |= ht_setup_chains_x(); if (needs_reset) { Index: tyan/s2892/auto.c =================================================================== --- tyan/s2892/auto.c (revision 1105) +++ tyan/s2892/auto.c (working copy) @@ -26,6 +26,7 @@ #include "cpu/amd/mtrr/amd_earlymtrr.c" #include "cpu/x86/bist.h" +#include "cpu/amd/dualcore/dualcore.c" #include "northbridge/amd/amdk8/setup_resource_map.c" @@ -76,11 +77,6 @@ /* tyan does not want the default */ #include "resourcemap.c" -#if CONFIG_LOGICAL_CPUS==1 -#define SET_NB_CFG_54 1 -#include "cpu/amd/dualcore/dualcore.c" -#endif - #define FIRST_CPU 1 #define SECOND_CPU 1 #define TOTAL_CPUS (FIRST_CPU + SECOND_CPU) @@ -125,47 +121,9 @@ }; int needs_reset; -#if CONFIG_LOGICAL_CPUS==1 - struct node_core_id id; -#else - unsigned nodeid; -#endif if (bist == 0) { - /* Skip this if there was a built in self test failure */ - amd_early_mtrr_init(); - -#if CONFIG_LOGICAL_CPUS==1 - set_apicid_cpuid_lo(); -#endif - - enable_lapic(); - init_timer(); - -#if CONFIG_LOGICAL_CPUS==1 - id = get_node_core_id_x(); - if(id.coreid == 0) { - if (cpu_init_detected(id.nodeid)) { - asm volatile ("jmp __cpu_reset"); - } - distinguish_cpu_resets(id.nodeid); -// start_other_core(id.nodeid); - } -#else - nodeid = lapicid(); - if (cpu_init_detected(nodeid)) { - asm volatile ("jmp __cpu_reset"); - } - distinguish_cpu_resets(nodeid); -#endif - - if (!boot_cpu() -#if CONFIG_LOGICAL_CPUS==1 - || (id.coreid != 0) -#endif - ) { - stop_this_cpu(); // it will stop all cores except core0 of cpu0 - } + k8_init_and_stop_secondaries(); } @@ -179,13 +137,9 @@ setup_s2892_resource_map(); needs_reset = setup_coherent_ht_domain(); + + needs_reset |= ht_setup_chains_x(); -#if CONFIG_LOGICAL_CPUS==1 - // It is said that we should start core1 after all core0 launched - start_other_cores(); -#endif - needs_reset |= ht_setup_chains_x(); - needs_reset |= ck804_early_setup_x(); if (needs_reset) { Index: tyan/s2875/auto.c =================================================================== --- tyan/s2875/auto.c (revision 1105) +++ tyan/s2875/auto.c (working copy) @@ -24,6 +24,7 @@ #include "superio/winbond/w83627hf/w83627hf_early_serial.c" #include "cpu/amd/mtrr/amd_earlymtrr.c" #include "cpu/x86/bist.h" +#include "cpu/amd/dualcore/dualcore.c" #define SERIAL_DEV PNP_DEV(0x2e, W83627HF_SP1) @@ -112,11 +113,6 @@ #include "sdram/generic_sdram.c" #include "northbridge/amd/amdk8/resourcemap.c" -#if CONFIG_LOGICAL_CPUS==1 -#define SET_NB_CFG_54 1 -#include "cpu/amd/dualcore/dualcore.c" -#endif - #define FIRST_CPU 1 #define SECOND_CPU 1 #define TOTAL_CPUS (FIRST_CPU + SECOND_CPU) @@ -149,47 +145,8 @@ int needs_reset; -#if CONFIG_LOGICAL_CPUS==1 - struct node_core_id id; -#else - unsigned nodeid; -#endif - if (bist == 0) { - /* Skip this if there was a built in self test failure */ - amd_early_mtrr_init(); - -#if CONFIG_LOGICAL_CPUS==1 - set_apicid_cpuid_lo(); -#endif - - enable_lapic(); - init_timer(); - -#if CONFIG_LOGICAL_CPUS==1 - id = get_node_core_id_x(); - if(id.coreid == 0) { - if (cpu_init_detected(id.nodeid)) { - asm volatile ("jmp __cpu_reset"); - } - distinguish_cpu_resets(id.nodeid); -// start_other_core(id.nodeid); - } -#else - nodeid = lapicid(); - if (cpu_init_detected(nodeid)) { - asm volatile ("jmp __cpu_reset"); - } - distinguish_cpu_resets(nodeid); -#endif - - if (!boot_cpu() -#if CONFIG_LOGICAL_CPUS==1 - || (id.coreid != 0) -#endif - ) { - stop_this_cpu(); // it will stop all cores except core0 of cpu0 - } + k8_init_and_stop_secondaries(); } w83627hf_enable_serial(SERIAL_DEV, TTYS0_BASE); @@ -202,9 +159,6 @@ setup_default_resource_map(); needs_reset = setup_coherent_ht_domain(); -#if CONFIG_LOGICAL_CPUS==1 - start_other_cores(); -#endif needs_reset |= ht_setup_chain(PCI_DEV(0, 0x18, 0), 0x80); if (needs_reset) { print_info("ht reset -\r\n"); Index: tyan/s4882/auto.c =================================================================== --- tyan/s4882/auto.c (revision 1105) +++ tyan/s4882/auto.c (working copy) @@ -23,6 +23,7 @@ #include "superio/winbond/w83627hf/w83627hf_early_serial.c" #include "cpu/amd/mtrr/amd_earlymtrr.c" #include "cpu/x86/bist.h" +#include "cpu/amd/dualcore/dualcore.c" #define SERIAL_DEV PNP_DEV(0x2e, W83627HF_SP1) @@ -129,13 +130,6 @@ /* tyan does not want the default */ #include "resourcemap.c" -#if CONFIG_LOGICAL_CPUS==1 -#define SET_NB_CFG_54 1 -#include "cpu/amd/dualcore/dualcore.c" -#else -#include "cpu/amd/model_fxx/node_id.c" -#endif - #define FIRST_CPU 1 #define SECOND_CPU 1 @@ -208,68 +202,9 @@ }; int i; int needs_reset; -#if CONFIG_LOGICAL_CPUS==1 - struct node_core_id id; -#else - unsigned nodeid; -#endif if (bist == 0) { - /* Skip this if there was a built in self test failure */ - amd_early_mtrr_init(); - -#if CONFIG_LOGICAL_CPUS==1 - set_apicid_cpuid_lo(); - - id = get_node_core_id_x(); // that is initid - #if ENABLE_APIC_EXT_ID == 1 - if(id.coreid == 0) { - enable_apic_ext_id(id.nodeid); - } - #endif -#else - nodeid = get_node_id(); - #if ENABLE_APIC_EXT_ID == 1 - enable_apic_ext_id(nodeid); - #endif -#endif - - enable_lapic(); - init_timer(); - -#if CONFIG_LOGICAL_CPUS==1 - #if ENABLE_APIC_EXT_ID == 1 - #if LIFT_BSP_APIC_ID == 0 - if( id.nodeid != 0 ) //all except cores in node0 - #endif - lapic_write(LAPIC_ID, ( lapic_read(LAPIC_ID) | (APIC_ID_OFFSET<<24) ) ); - #endif - if(id.coreid == 0) { - if (cpu_init_detected(id.nodeid)) { - asm volatile ("jmp __cpu_reset"); - } - distinguish_cpu_resets(id.nodeid); - } -#else - #if ENABLE_APIC_EXT_ID == 1 - #if LIFT_BSP_APIC_ID == 0 - if(nodeid != 0) - #endif - lapic_write(LAPIC_ID, ( lapic_read(LAPIC_ID) | (APIC_ID_OFFSET<<24) ) ); // CPU apicid is from 0x10 - #endif - if (cpu_init_detected(nodeid)) { - asm volatile ("jmp __cpu_reset"); - } - distinguish_cpu_resets(nodeid); -#endif - - if (!boot_cpu() -#if CONFIG_LOGICAL_CPUS==1 - || (id.coreid != 0) -#endif - ) { - stop_this_cpu(); // it will stop all cores except core0 of cpu0 - } + k8_init_and_stop_secondaries(); } w83627hf_enable_serial(SERIAL_DEV, TTYS0_BASE); @@ -283,11 +218,6 @@ needs_reset = setup_coherent_ht_domain(); -#if CONFIG_LOGICAL_CPUS==1 - // It is said that we should start core1 after all core0 launched - start_other_cores(); -#endif - needs_reset |= ht_setup_chains_x(); if (needs_reset) { print_info("ht reset -\r\n"); Index: tyan/s2885/auto.c =================================================================== --- tyan/s2885/auto.c (revision 1105) +++ tyan/s2885/auto.c (working copy) @@ -23,6 +23,7 @@ #include "superio/winbond/w83627hf/w83627hf_early_serial.c" #include "cpu/amd/mtrr/amd_earlymtrr.c" #include "cpu/x86/bist.h" +#include "cpu/amd/dualcore/dualcore.c" #define SERIAL_DEV PNP_DEV(0x2e, W83627HF_SP1) @@ -121,13 +122,6 @@ /* tyan does not want the default */ #include "resourcemap.c" -#if CONFIG_LOGICAL_CPUS==1 -#define SET_NB_CFG_54 1 -#include "cpu/amd/dualcore/dualcore.c" -#else -#include "cpu/amd/model_fxx/node_id.c" -#endif - #define FIRST_CPU 1 #define SECOND_CPU 1 #define TOTAL_CPUS (FIRST_CPU + SECOND_CPU) @@ -160,72 +154,9 @@ }; int needs_reset; -#if CONFIG_LOGICAL_CPUS==1 - struct node_core_id id; -#else - unsigned nodeid; -#endif if (bist == 0) { - /* Skip this if there was a built in self test failure */ - amd_early_mtrr_init(); - -#if CONFIG_LOGICAL_CPUS==1 - set_apicid_cpuid_lo(); - - id = get_node_core_id_x(); // that is initid - #if ENABLE_APIC_EXT_ID == 1 - if(id.coreid == 0) { - enable_apic_ext_id(id.nodeid); - } - #endif -#else - nodeid = get_node_id(); - #if ENABLE_APIC_EXT_ID == 1 - enable_apic_ext_id(nodeid); - #endif -#endif - - enable_lapic(); - init_timer(); - -#if CONFIG_LOGICAL_CPUS==1 - #if ENABLE_APIC_EXT_ID == 1 - #if LIFT_BSP_APIC_ID == 0 - if( id.nodeid != 0 ) //all except cores in node0 - #endif - lapic_write(LAPIC_ID, ( lapic_read(LAPIC_ID) | (APIC_ID_OFFSET<<24) ) ); - #endif - - if(id.coreid == 0) { - if (cpu_init_detected(id.nodeid)) { - asm volatile ("jmp __cpu_reset"); - } - distinguish_cpu_resets(id.nodeid); - } - -#else - #if ENABLE_APIC_EXT_ID == 1 - #if LIFT_BSP_APIC_ID == 0 - if(nodeid != 0) - #endif - lapic_write(LAPIC_ID, ( lapic_read(LAPIC_ID) | (APIC_ID_OFFSET<<24) ) ); // CPU apicid is from 0x10 - - #endif - - if (cpu_init_detected(nodeid)) { - asm volatile ("jmp __cpu_reset"); - } - distinguish_cpu_resets(nodeid); -#endif - - if (!boot_cpu() -#if CONFIG_LOGICAL_CPUS==1 - || (id.coreid != 0) -#endif - ) { - stop_this_cpu(); // it will stop all cores except core0 of cpu0 - } + k8_init_and_stop_secondaries(); } w83627hf_enable_serial(SERIAL_DEV, TTYS0_BASE); @@ -238,10 +169,6 @@ setup_s2885_resource_map(); needs_reset = setup_coherent_ht_domain(); -#if CONFIG_LOGICAL_CPUS==1 - start_other_cores(); -#endif - // automatically set that for you, but you might meet tight space needs_reset |= ht_setup_chains_x(); Index: tyan/s2895/auto.c =================================================================== --- tyan/s2895/auto.c (revision 1105) +++ tyan/s2895/auto.c (working copy) @@ -28,6 +28,7 @@ #include "cpu/amd/mtrr/amd_earlymtrr.c" #include "cpu/x86/bist.h" +#include "cpu/amd/dualcore/dualcore.c" #include "superio/smsc/lpc47b397/lpc47b397_early_gpio.c" @@ -106,12 +107,6 @@ /* tyan does not want the default */ #include "resourcemap.c" -#if CONFIG_LOGICAL_CPUS==1 -#define SET_NB_CFG_54 1 -#include "cpu/amd/dualcore/dualcore.c" -#else -#include "cpu/amd/model_fxx/node_id.c" -#endif #define FIRST_CPU 1 #define SECOND_CPU 1 @@ -163,79 +158,12 @@ }; int needs_reset; -#if CONFIG_LOGICAL_CPUS==1 - struct node_core_id id; -#else - unsigned nodeid; -#endif if (bist == 0) { - /* Skip this if there was a built in self test failure */ - amd_early_mtrr_init(); - -#if CONFIG_LOGICAL_CPUS==1 - set_apicid_cpuid_lo(); - - id = get_node_core_id_x(); // that is initid - #if ENABLE_APIC_EXT_ID == 1 - if(id.coreid == 0) { - enable_apic_ext_id(id.nodeid); - } - #endif -#else - nodeid = get_node_id(); - #if ENABLE_APIC_EXT_ID == 1 - enable_apic_ext_id(nodeid); - #endif -#endif - - enable_lapic(); - init_timer(); - - post_code(0x30); - -#if CONFIG_LOGICAL_CPUS==1 - #if ENABLE_APIC_EXT_ID == 1 - #if LIFT_BSP_APIC_ID == 0 - if( id.nodeid != 0 ) //all except cores in node0 - #endif - lapic_write(LAPIC_ID, ( lapic_read(LAPIC_ID) | (APIC_ID_OFFSET<<24) ) ); - #endif - - if(id.coreid == 0) { - if (cpu_init_detected(id.nodeid)) { - asm volatile ("jmp __cpu_reset"); - } - distinguish_cpu_resets(id.nodeid); - } - -#else - #if ENABLE_APIC_EXT_ID == 1 - #if LIFT_BSP_APIC_ID == 0 - if(nodeid != 0) - #endif - lapic_write(LAPIC_ID, ( lapic_read(LAPIC_ID) | (APIC_ID_OFFSET<<24) ) ); // CPU apicid is from 0x10 - - #endif - - if (cpu_init_detected(nodeid)) { - asm volatile ("jmp __cpu_reset"); - } - distinguish_cpu_resets(nodeid); -#endif - - post_code(0x31); - - if (!boot_cpu() -#if CONFIG_LOGICAL_CPUS==1 - || (id.coreid != 0) -#endif - ) { - stop_this_cpu(); // it will stop all cores except core0 of cpu0 - } + k8_init_and_stop_secondaries(); } - post_code(0x32); + // post_code(0x32); lpc47b397_enable_serial(SERIAL_DEV, TTYS0_BASE); uart_init(); @@ -249,10 +177,6 @@ setup_s2895_resource_map(); needs_reset = setup_coherent_ht_domain(); -#if CONFIG_LOGICAL_CPUS==1 - // It is said that we should start core1 after all core0 launched - start_other_cores(); -#endif needs_reset |= ht_setup_chains_x(); -- Jason W. Schildt LinuxBIOS Software Engineer Linux Networx From jschildt at lnxi.com Sat Sep 3 00:03:29 2005 From: jschildt at lnxi.com (jason schildt) Date: Fri, 02 Sep 2005 16:03:29 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-10/16 Message-ID: DESCRIPTION: ------------------------------------- ## lnxi-patch-10 ## src/northbridge/amd/amdk8/cpu_rev.c Testing for ranges of CPUs instead of exact matches. DIFFSTAT: ------------------------------------- cpu_rev.c | 33 ++++++--------------------------- 1 files changed, 6 insertions(+), 27 deletions(-) PATCH: ------------------------------------- Index: northbridge/amd/amdk8/cpu_rev.c =================================================================== --- northbridge/amd/amdk8/cpu_rev.c (revision 1105) +++ northbridge/amd/amdk8/cpu_rev.c (working copy) @@ -3,44 +3,23 @@ { return (cpuid_eax(1) & 0xfffef) == 0x0f00; } -//AMD_D0_SUPPORT -static int is_cpu_pre_d0(void) -{ - return (cpuid_eax(1) & 0xfff0f) < 0x10f00; -} -static int is_cpu_d0(void) +static int is_cpu_pre_b3(void) { - return (cpuid_eax(1) & 0xfff0f) == 0x10f00; + return (cpuid_eax(1) & 0xfffef) < 0x0f41; } -//AMD_E0_SUPPORT -static int is_cpu_pre_e0(void) -{ - return (cpuid_eax(1) & 0xfff0f) < 0x20f00; -} - -static int is_cpu_e0(void) -{ - return (cpuid_eax(1) & 0xfff00) == 0x20f00; -} - static int is_cpu_pre_c0(void) { return (cpuid_eax(1) & 0xfffef) < 0x0f48; } -static int is_cpu_c0(void) +static int is_cpu_pre_d0(void) { - return (cpuid_eax(1) & 0xfffef) == 0x0f48; + return (cpuid_eax(1) & 0xfff0f) < 0x10000; } -static int is_cpu_pre_b3(void) +static int is_cpu_pre_e0(void) { - return (cpuid_eax(1) & 0xfffef) < 0x0f41; + return (cpuid_eax(1) & 0xfff0f) < 0x20f00; } - -static int is_cpu_b3(void) -{ - return (cpuid_eax(1) & 0xfffef) == 0x0f41; -} -- Jason W. Schildt LinuxBIOS Software Engineer Linux Networx From jschildt at lnxi.com Sat Sep 3 00:03:31 2005 From: jschildt at lnxi.com (jason schildt) Date: Fri, 02 Sep 2005 16:03:31 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-16/16 Message-ID: DESCRIPTION: ---------------------------------------- ## lnxi-patch-16 ## targets/.../Config.lb Increased ROM_IMAGE_SIZE to avoid size overlaps amd/serenade Iwill/dk8s2 newisys/khepri tyan/s2881 tyan/s2882 tyan/s2885 tyan/s2892 tyan/s2895 util/abuild/abuild.sh increased the hardcoded ROM_IMAGE_SIZE to 0x18000 for Fallback and Normal DIFFSTAT: ---------------------------------------- ../util/abuild/abuild.sh | 4 ++-- Iwill/dk8s2/Config.lb | 3 ++- amd/serenade/Config.lb | 4 ++-- newisys/khepri/Config.lb | 4 ++-- tyan/s2881/Config.lb | 4 ++-- tyan/s2882/Config.lb | 4 ++-- tyan/s2885/Config.lb | 4 ++-- tyan/s2892/Config.lb | 6 ++---- tyan/s2895/Config.lb | 6 ++---- 9 files changed, 18 insertions(+), 21 deletions(-) PATCH: ---------------------------------------- Index: amd/serenade/Config.lb =================================================================== --- amd/serenade/Config.lb (revision 1105) +++ amd/serenade/Config.lb (working copy) @@ -5,14 +5,14 @@ romimage "normal" option USE_FALLBACK_IMAGE=0 - option ROM_IMAGE_SIZE=0x10000 + option ROM_IMAGE_SIZE=0x14000 option LINUXBIOS_EXTRA_VERSION=".0-Normal" payload /home/ollie/work/filo-0.4.1/filo.elf end romimage "fallback" option USE_FALLBACK_IMAGE=1 - option ROM_IMAGE_SIZE=0x10000 + option ROM_IMAGE_SIZE=0x14000 option LINUXBIOS_EXTRA_VERSION=".0-Fallback" payload /home/ollie/work/filo-0.4.1/filo.elf end Index: Iwill/dk8s2/Config.lb =================================================================== --- Iwill/dk8s2/Config.lb (revision 1122) +++ Iwill/dk8s2/Config.lb (working copy) @@ -64,7 +64,8 @@ option FALLBACK_SIZE=131072 ## ROM_IMAGE_SIZE is the amount of space to allow linuxBIOS to occupy. -option ROM_IMAGE_SIZE=65536 +#option ROM_IMAGE_SIZE=66536 +option ROM_IMAGE_SIZE=0x12000 ### Index: newisys/khepri/Config.lb =================================================================== --- newisys/khepri/Config.lb (revision 1122) +++ newisys/khepri/Config.lb (working copy) @@ -30,14 +30,14 @@ romimage "normal" option USE_FALLBACK_IMAGE=0 - option ROM_IMAGE_SIZE=0x10000 + option ROM_IMAGE_SIZE=0x14000 option LINUXBIOS_EXTRA_VERSION="-Khepri-Normal" payload ../../../payloads/tg3--ide_disk.zelf end romimage "fallback" option USE_FALLBACK_IMAGE=1 - option ROM_IMAGE_SIZE=0x10000 + option ROM_IMAGE_SIZE=0x14000 option LINUXBIOS_EXTRA_VERSION="-Khepri-Fallback" payload ../../../payloads/tg3--ide_disk.zelf end Index: tyan/s2881/Config.lb =================================================================== --- tyan/s2881/Config.lb (revision 1122) +++ tyan/s2881/Config.lb (working copy) @@ -16,7 +16,7 @@ option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x11800 # option ROM_IMAGE_SIZE=0x13000 - option ROM_IMAGE_SIZE=0x16000 + option ROM_IMAGE_SIZE=0x18000 option XIP_ROM_SIZE=0x20000 option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" # payload ../../../payloads/tg3--ide_disk.zelf @@ -36,7 +36,7 @@ option USE_FALLBACK_IMAGE=1 # option ROM_IMAGE_SIZE=0x11800 # option ROM_IMAGE_SIZE=0x13000 - option ROM_IMAGE_SIZE=0x16000 + option ROM_IMAGE_SIZE=0x18000 option XIP_ROM_SIZE=0x20000 option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" # payload ../../../payloads/tg3--ide_disk.zelf Index: tyan/s2882/Config.lb =================================================================== --- tyan/s2882/Config.lb (revision 1122) +++ tyan/s2882/Config.lb (working copy) @@ -15,7 +15,7 @@ # option ROM_SIZE = 458752 option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x11800 - option ROM_IMAGE_SIZE=0x16000 + option ROM_IMAGE_SIZE=0x18000 option XIP_ROM_SIZE=0x20000 option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" # payload ../../../payloads/tg3--ide_disk.zelf @@ -32,7 +32,7 @@ romimage "fallback" option USE_FALLBACK_IMAGE=1 # option ROM_IMAGE_SIZE=0x11800 - option ROM_IMAGE_SIZE=0x16000 + option ROM_IMAGE_SIZE=0x18000 option XIP_ROM_SIZE=0x20000 option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" # payload ../../../payloads/tg3--ide_disk.zelf Index: tyan/s2885/Config.lb =================================================================== --- tyan/s2885/Config.lb (revision 1105) +++ tyan/s2885/Config.lb (working copy) @@ -16,7 +16,7 @@ option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x13800 # option ROM_IMAGE_SIZE=0x17800 - option ROM_IMAGE_SIZE=0x16200 + option ROM_IMAGE_SIZE=0x18000 option XIP_ROM_SIZE=0x20000 option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" # payload ../../../payloads/tg3--ide_disk.zelf @@ -39,7 +39,7 @@ option USE_FALLBACK_IMAGE=1 # option ROM_IMAGE_SIZE=0x13800 # option ROM_IMAGE_SIZE=0x17800 - option ROM_IMAGE_SIZE=0x16200 + option ROM_IMAGE_SIZE=0x18000 option XIP_ROM_SIZE=0x20000 option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" # payload ../../../payloads/tg3--ide_disk.zelf Index: tyan/s2892/Config.lb =================================================================== --- tyan/s2892/Config.lb (revision 1105) +++ tyan/s2892/Config.lb (working copy) @@ -16,8 +16,7 @@ option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x11800 # option ROM_IMAGE_SIZE=0x13800 - option ROM_IMAGE_SIZE=0x16380 -# option ROM_IMAGE_SIZE=0x17800 + option ROM_IMAGE_SIZE=0x17000 option XIP_ROM_SIZE=0x20000 option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" # payload ../../../payloads/tg3--ide_disk.zelf @@ -37,8 +36,7 @@ option USE_FALLBACK_IMAGE=1 # option ROM_IMAGE_SIZE=0x11800 # option ROM_IMAGE_SIZE=0x13800 - option ROM_IMAGE_SIZE=0x16380 -# option ROM_IMAGE_SIZE=0x17800 + option ROM_IMAGE_SIZE=0x17000 option XIP_ROM_SIZE=0x20000 option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" # payload ../../../payloads/tg3--ide_disk.zelf Index: tyan/s2895/Config.lb =================================================================== --- tyan/s2895/Config.lb (revision 1105) +++ tyan/s2895/Config.lb (working copy) @@ -18,8 +18,7 @@ option USE_FALLBACK_IMAGE=0 # option ROM_IMAGE_SIZE=0x11800 # option ROM_IMAGE_SIZE=0x13800 - option ROM_IMAGE_SIZE=0x15000 -# option ROM_IMAGE_SIZE=0x17800 + option ROM_IMAGE_SIZE=0x17000 option XIP_ROM_SIZE=0x20000 option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal" # payload ../../../payloads/tg3--ide_disk.zelf @@ -46,8 +45,7 @@ option USE_FALLBACK_IMAGE=1 # option ROM_IMAGE_SIZE=0x11800 # option ROM_IMAGE_SIZE=0x13800 - option ROM_IMAGE_SIZE=0x15000 -# option ROM_IMAGE_SIZE=0x17800 + option ROM_IMAGE_SIZE=0x17000 option XIP_ROM_SIZE=0x20000 option LINUXBIOS_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback" # payload ../../../payloads/tg3--ide_disk.zelf Index: ../util/abuild/abuild.sh =================================================================== --- ../util/abuild/abuild.sh (revision 1105) +++ ../util/abuild/abuild.sh (working copy) @@ -82,14 +82,14 @@ cat < Any reason for you disabling Cache as RAM for Tyan MB? YH -----Original Message----- From: linuxbios-bounces at openbios.org [mailto:linuxbios-bounces at openbios.org] On Behalf Of jason schildt Sent: Friday, September 02, 2005 3:04 PM To: linuxbios at openbios.org Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-15/16 DESCRIPTION: ------------------------------------------------ ## lnxi-patch-15 ## src/mainboard/.../Options.lb Disabled cache_as_ram: USE_CACHE_RAM CONFIG_USE_INIT tyan/s2881/Options.lb tyan/s2882/Options.lb tyan/s2891/Options.lb tyan/s4880/Options.lb tyan/s2892/Options.lb tyan/s2875/Options.lb tyan/s4882/Options.lb tyan/s2885/Options.lb tyan/s2895/Options.lb DIFFSTAT: ------------------------------------------------ s2875/Options.lb | 4 ++-- s2881/Options.lb | 4 ++-- s2882/Options.lb | 4 ++-- s2885/Options.lb | 4 ++-- s2891/Options.lb | 4 ++-- s2892/Options.lb | 4 ++-- s2895/Options.lb | 4 ++-- s4880/Options.lb | 4 ++-- s4882/Options.lb | 4 ++-- 9 files changed, 18 insertions(+), 18 deletions(-) PATCH: ------------------------------------------------ Index: s2881/Options.lb =================================================================== --- s2881/Options.lb (revision 1105) +++ s2881/Options.lb (working copy) @@ -130,10 +130,10 @@ ## ## enable CACHE_AS_RAM specifics ## -default USE_DCACHE_RAM=1 +default USE_DCACHE_RAM=0 default DCACHE_RAM_BASE=0xcf000 default DCACHE_RAM_SIZE=0x1000 -default CONFIG_USE_INIT=1 +default CONFIG_USE_INIT=0 ## ## Build code to setup a generic IOAPIC Index: s2882/Options.lb =================================================================== --- s2882/Options.lb (revision 1105) +++ s2882/Options.lb (working copy) @@ -130,10 +130,10 @@ ## ## enable CACHE_AS_RAM specifics ## -default USE_DCACHE_RAM=1 +default USE_DCACHE_RAM=0 default DCACHE_RAM_BASE=0xcf000 default DCACHE_RAM_SIZE=0x1000 -default CONFIG_USE_INIT=1 +default CONFIG_USE_INIT=0 ## ## Build code to setup a generic IOAPIC Index: s2891/Options.lb =================================================================== --- s2891/Options.lb (revision 1105) +++ s2891/Options.lb (working copy) @@ -139,10 +139,10 @@ ## ## enable CACHE_AS_RAM specifics ## -default USE_DCACHE_RAM=1 +default USE_DCACHE_RAM=0 default DCACHE_RAM_BASE=0xcf000 default DCACHE_RAM_SIZE=0x1000 -default CONFIG_USE_INIT=1 +default CONFIG_USE_INIT=0 ## Index: s4880/Options.lb =================================================================== --- s4880/Options.lb (revision 1105) +++ s4880/Options.lb (working copy) @@ -130,10 +130,10 @@ ## ## enable CACHE_AS_RAM specifics ## -default USE_DCACHE_RAM=1 +default USE_DCACHE_RAM=0 default DCACHE_RAM_BASE=0xcf000 default DCACHE_RAM_SIZE=0x1000 -default CONFIG_USE_INIT=1 +default CONFIG_USE_INIT=0 ## ## Build code to setup a generic IOAPIC Index: s2892/Options.lb =================================================================== --- s2892/Options.lb (revision 1105) +++ s2892/Options.lb (working copy) @@ -139,10 +139,10 @@ ## ## enable CACHE_AS_RAM specifics ## -default USE_DCACHE_RAM=1 +default USE_DCACHE_RAM=0 default DCACHE_RAM_BASE=0xcf000 default DCACHE_RAM_SIZE=0x1000 -default CONFIG_USE_INIT=1 +default CONFIG_USE_INIT=0 ## Index: s2875/Options.lb =================================================================== --- s2875/Options.lb (revision 1105) +++ s2875/Options.lb (working copy) @@ -130,10 +130,10 @@ ## ## enable CACHE_AS_RAM specifics ## -default USE_DCACHE_RAM=1 +default USE_DCACHE_RAM=0 default DCACHE_RAM_BASE=0xcf000 default DCACHE_RAM_SIZE=0x1000 -default CONFIG_USE_INIT=1 +default CONFIG_USE_INIT=0 ## ## Build code to setup a generic IOAPIC Index: s4882/Options.lb =================================================================== --- s4882/Options.lb (revision 1105) +++ s4882/Options.lb (working copy) @@ -130,10 +130,10 @@ ## ## enable CACHE_AS_RAM specifics ## -default USE_DCACHE_RAM=1 +default USE_DCACHE_RAM=0 default DCACHE_RAM_BASE=0xcf000 default DCACHE_RAM_SIZE=0x1000 -default CONFIG_USE_INIT=1 +default CONFIG_USE_INIT=0 ## ## Build code to setup a generic IOAPIC Index: s2885/Options.lb =================================================================== --- s2885/Options.lb (revision 1105) +++ s2885/Options.lb (working copy) @@ -130,10 +130,10 @@ ## ## enable CACHE_AS_RAM specifics ## -default USE_DCACHE_RAM=1 +default USE_DCACHE_RAM=0 default DCACHE_RAM_BASE=0xcf000 default DCACHE_RAM_SIZE=0x1000 -default CONFIG_USE_INIT=1 +default CONFIG_USE_INIT=0 ## ## Build code to setup a generic IOAPIC Index: s2895/Options.lb =================================================================== --- s2895/Options.lb (revision 1105) +++ s2895/Options.lb (working copy) @@ -136,10 +136,10 @@ ## ## enable CACHE_AS_RAM specifics ## -default USE_DCACHE_RAM=1 +default USE_DCACHE_RAM=0 default DCACHE_RAM_BASE=0xcf000 default DCACHE_RAM_SIZE=0x1000 -default CONFIG_USE_INIT=1 +default CONFIG_USE_INIT=0 ## ## Build code to setup a generic IOAPIC -- Jason W. Schildt LinuxBIOS Software Engineer Linux Networx -- LinuxBIOS mailing list LinuxBIOS at openbios.org http://www.openbios.org/mailman/listinfo/linuxbios From yinghai.lu at amd.com Sat Sep 3 00:31:21 2005 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Fri, 2 Sep 2005 15:31:21 -0700 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-11/16 Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E060FD@ssvlexmb2.amd.com> Before cache as ram working, I used fixed size to replace unsigned to make sure romcc can compile my in_coherent.c Do you have own internal version ROMCC that make use unsigned well....? YH -----Original Message----- From: linuxbios-bounces at openbios.org [mailto:linuxbios-bounces at openbios.org] On Behalf Of jason schildt Sent: Friday, September 02, 2005 3:03 PM To: linuxbios at openbios.org Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-11/16 DESCRIPTION: ------------------------------------------------ ## lnxi-patch-11 ## src/northbridge/amd/amdk8/incoherent_ht.c Removed K8_HT_FREQ_1G test as we can now compile this with romcc. Bug fix added to ht_optimize_link() To ignore status bits when we read the link freq. Comment added that suggests s/uint8_t/unsigned/g that could save code generated by romcc. DIFFSTAT: ------------------------------------------------ incoherent_ht.c | 22 ++++++++++++---------- 1 files changed, 12 insertions(+), 10 deletions(-) PATCH: ------------------------------------------------ Index: northbridge/amd/amdk8/incoherent_ht.c =================================================================== --- northbridge/amd/amdk8/incoherent_ht.c (revision 1105) +++ northbridge/amd/amdk8/incoherent_ht.c (working copy) @@ -1,15 +1,16 @@ /* This should be done by Eric 2004.12 yhlu add multi ht chain dynamically support + */ #include #include #include -#ifndef K8_HT_FREQ_1G_SUPPORT - #define K8_HT_FREQ_1G_SUPPORT 0 -#endif - +/* We can reduce the size of code generated by romcc by + * changing all of the fixed size types that live in registers + * into simple unsigned variables. (ie s/uint8_t/unsigned/g) + */ #ifndef K8_SCAN_PCI_BUS #define K8_SCAN_PCI_BUS 0 #endif @@ -130,21 +131,20 @@ /* AMD 8131 Errata 48 */ if (id == (PCI_VENDOR_ID_AMD | (PCI_DEVICE_ID_AMD_8131_PCIX << 16))) { freq_cap &= ~(1 << HT_FREQ_800Mhz); - return freq_cap; } /* AMD 8151 Errata 23 */ if (id == (PCI_VENDOR_ID_AMD | (PCI_DEVICE_ID_AMD_8151_SYSCTRL << 16))) { freq_cap &= ~(1 << HT_FREQ_800Mhz); - return freq_cap; } /* AMD K8 Unsupported 1Ghz? */ if (id == (PCI_VENDOR_ID_AMD | (0x1100 << 16))) { - #if K8_HT_FREQ_1G_SUPPORT == 1 - if (is_cpu_pre_e0()) // CK804 support 1G? - #endif - freq_cap &= ~(1 << HT_FREQ_1000Mhz); + /* Supported starting with E0 */ + device_t dev_2 = PCI_DEV(0,0x18,2); + if(pci_read_config32(dev_2,0x9c) < 0x20f00) { + freq_cap &= ~(1 << HT_FREQ_1000Mhz); + } } return freq_cap; @@ -199,8 +199,10 @@ /* See if I am changing the link freqency */ old_freq = pci_read_config8(dev1, pos1 + LINK_FREQ(offs1)); + old_freq &= 0x0f; needs_reset |= old_freq != freq; old_freq = pci_read_config8(dev2, pos2 + LINK_FREQ(offs2)); + old_freq &= 0x0f; needs_reset |= old_freq != freq; /* Set the Calulcated link frequency */ -- Jason W. Schildt LinuxBIOS Software Engineer Linux Networx -- LinuxBIOS mailing list LinuxBIOS at openbios.org http://www.openbios.org/mailman/listinfo/linuxbios From yinghai.lu at amd.com Sat Sep 3 00:32:47 2005 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Fri, 2 Sep 2005 15:32:47 -0700 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-01/16 Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E060FE@ssvlexmb2.amd.com> Actually amd8111_enable is not needed, it will be called from enable_dev ....at first. YH -----Original Message----- From: linuxbios-bounces at openbios.org [mailto:linuxbios-bounces at openbios.org] On Behalf Of jason schildt Sent: Friday, September 02, 2005 3:04 PM To: linuxbios at openbios.org Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-01/16 ## lnxi-patch-1 ## - (2)files src/southbridge/amd/amd8111/amd8111_acpi.c // amd8111_enable is commented out in public tree, but enabled in // hdama. resolution: copied over for merge DIFFSTAT --------------------------------------------------------- amd8111_acpi.c | 5 +++-- amd8111_pci.c | 1 + 2 files changed, 4 insertions(+), 2 deletions(-) PATCH --------------------------------------------------------- Index: southbridge/amd/amd8111/amd8111_pci.c =================================================================== --- southbridge/amd/amd8111/amd8111_pci.c (revision 1105) +++ southbridge/amd/amd8111/amd8111_pci.c (working copy) @@ -55,6 +55,7 @@ .enable_resources = pci_bus_enable_resources, .init = pci_init, .scan_bus = pci_scan_bridge, + /* PCI Subordinate bus reset is not implemented */ .ops_pci = &lops_pci, }; Index: southbridge/amd/amd8111/amd8111_acpi.c =================================================================== --- southbridge/amd/amd8111/amd8111_acpi.c (revision 1105) +++ southbridge/amd/amd8111/amd8111_acpi.c (working copy) @@ -97,6 +97,7 @@ #endif + /* power after power fail */ on = MAINBOARD_POWER_ON_AFTER_POWER_FAIL; get_option(&on, "power_on_after_fail"); byte = pci_read_config8(dev, PREVIOUS_POWER_STATE); @@ -106,7 +107,7 @@ } pci_write_config8(dev, PREVIOUS_POWER_STATE, byte); printk_info("set power %s after power fail\n", on?"on":"off"); - + /* Throttle the CPU speed down for testing */ on = SLOW_CPU_OFF; get_option(&on, "slow_cpu"); @@ -177,7 +178,7 @@ .enable_resources = acpi_enable_resources, .init = acpi_init, .scan_bus = scan_static_bus, -// .enable = amd8111_enable, + .enable = amd8111_enable, .ops_pci = &lops_pci, .ops_smbus_bus = &lops_smbus_bus, }; Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ -- LinuxBIOS mailing list LinuxBIOS at openbios.org http://www.openbios.org/mailman/listinfo/linuxbios From yinghai.lu at amd.com Sat Sep 3 00:34:02 2005 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Fri, 2 Sep 2005 15:34:02 -0700 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch02/16 Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E060FF@ssvlexmb2.amd.com> Why usb2? Amd8111 usb2 already be disabled, and can not be used .... YH -----Original Message----- From: linuxbios-bounces at openbios.org [mailto:linuxbios-bounces at openbios.org] On Behalf Of jason schildt Sent: Friday, September 02, 2005 3:03 PM To: linuxbios at openbios.org Subject: [LinuxBIOS] LNXI Merge: lnxi-patch02/16 DESCRIPTION: --------------------------------------------------------- ## lnxi-patch-2 ## - (3)files src/southbridge/amd/amd8111/amd8111_lpc.c powermanagment removed. copied to public tree src/southbridge/amd/amd8111/Config.lb src/southbridge/amd/amd8111/amd8111_usb.c uncommented amd8111_enable DIFFSTAT: --------------------------------------------------------- Config.lb | 9 ++++----- amd8111_lpc.c | 12 ++++-------- amd8111_usb.c | 2 +- 3 files changed, 9 insertions(+), 14 deletions(-) PATCH: --------------------------------------------------------- Index: amd8111_lpc.c =================================================================== --- amd8111_lpc.c (revision 1105) +++ amd8111_lpc.c (working copy) @@ -84,7 +84,7 @@ return; } printk_spew("for IRQ, reg 0x%08x value 0x%08x 0x%08x\n", - a->reg, a->value_low, a->value_high); + a->reg, a->value_low, a->value_high); } } @@ -113,13 +113,9 @@ byte = pci_read_config8(dev, 0x46); pci_write_config8(dev, 0x46, byte | (1<<0)); - /* power after power fail */ + /* Enable 5Mib Rom window */ byte = pci_read_config8(dev, 0x43); - if (pwr_on) { - byte &= ~(1<<6); - } else { - byte |= (1<<6); - } + byte |= 0xC0; pci_write_config8(dev, 0x43, byte); /* Enable Port 92 fast reset */ @@ -179,7 +175,7 @@ static void lpci_set_subsystem(device_t dev, unsigned vendor, unsigned device) { pci_write_config32(dev, 0x70, - ((device & 0xffff) << 16) | (vendor & 0xffff)); + ((device & 0xffff) << 16) | (vendor & 0xffff)); } static struct pci_operations lops_pci = { Index: Config.lb =================================================================== --- Config.lb (revision 1105) +++ Config.lb (working copy) @@ -1,12 +1,11 @@ config chip.h driver amd8111.o -#driver amd8111_usb.o +driver amd8111_usb.o driver amd8111_lpc.o driver amd8111_ide.o driver amd8111_acpi.o -#driver amd8111_usb2.o -#driver amd8111_ac97.o -#driver amd8111_nic.o +driver amd8111_usb2.o +driver amd8111_ac97.o +driver amd8111_nic.o driver amd8111_pci.o driver amd8111_smbus.o -object amd8111_reset.o Index: amd8111_usb.c =================================================================== --- amd8111_usb.c (revision 1105) +++ amd8111_usb.c (working copy) @@ -26,7 +26,7 @@ .enable_resources = pci_dev_enable_resources, .init = 0, .scan_bus = scan_static_bus, -// .enable = amd8111_enable, + .enable = amd8111_enable, .ops_pci = &lops_pci, }; -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ -- LinuxBIOS mailing list LinuxBIOS at openbios.org http://www.openbios.org/mailman/listinfo/linuxbios From yinghailu at gmail.com Sat Sep 3 03:09:05 2005 From: yinghailu at gmail.com (yhlu) Date: Fri, 2 Sep 2005 18:09:05 -0700 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-14/16 In-Reply-To: References: Message-ID: <2ea3fae1050902180972f37a5f@mail.gmail.com> use max_lapicid() + 1 as apicid_base is not good. esp for apic id lifting. for 8 way dual core system, max_lapicid() will be 0x0f with lifting, and with lifting it will be 0x1f. YH On 9/2/05, jason schildt wrote: > > DESCRIPTION: > ---------------------------------------------- > ## lnxi-patch-14 ## > > src/mainboard/arima/hdama/mptable.c > Removed: max_apicid() renamed it to max_lapicid() and moved it into > generic code > /cpu/x86/lapic/lapic.c (See next) > > src/cpu/x86/lapic/lapic.c > Added: generic max_lapicid() to replace get_apicid_base() > > src/mainboard/.../mptable.c > Replaced: get_apicid_base() with max_lapicid() > tyan/s2850/mptable.c > tyan/s2881/mptable.c > tyan/s2882/mptable.c > tyan/s2891/mptable.c > tyan/s4880/mptable.c > tyan/s2892/mptable.c > tyan/s2875/mptable.c > tyan/s4882/mptable.c > tyan/s2885/mptable.c > tyan/s2895/mptable.c > > > DIFFSTAT: > ---------------------------------------------- > ../cpu/x86/lapic/lapic.c | 24 +++++ > arima/hdama/mptable.c | 198 > ++++++++++++++++++++++++++++++++++++----------- > tyan/s2850/mptable.c | 6 - > tyan/s2875/mptable.c | 6 - > tyan/s2881/mptable.c | 6 - > tyan/s2882/mptable.c | 6 - > tyan/s2885/mptable.c | 7 - > tyan/s2891/mptable.c | 6 - > tyan/s2892/mptable.c | 6 - > tyan/s2895/mptable.c | 6 - > tyan/s4880/mptable.c | 6 - > tyan/s4882/mptable.c | 2 > 12 files changed, 187 insertions(+), 92 deletions(-) > > > PATCH: > ---------------------------------------------- > > Index: tyan/s2850/mptable.c > =================================================================== > --- tyan/s2850/mptable.c (revision 1105) > +++ tyan/s2850/mptable.c (working copy) > @@ -107,11 +107,7 @@ > > > /*I/O APICs: APIC ID Version State Address*/ > -#if CONFIG_LOGICAL_CPUS==1 > - apicid_base = get_apicid_base(1); > -#else > - apicid_base = CONFIG_MAX_PHYSICAL_CPUS; > -#endif > + apicid_base = max_lapicid() + 1; > apicid_8111 = apicid_base+0; > > smp_write_ioapic(mc, apicid_8111, 0x11, 0xfec00000); > Index: tyan/s2875/mptable.c > =================================================================== > --- tyan/s2875/mptable.c (revision 1105) > +++ tyan/s2875/mptable.c (working copy) > @@ -123,11 +123,7 @@ > smp_write_bus(mc, bus_isa, "ISA "); > > /*I/O APICs: APIC ID Version State Address*/ > -#if CONFIG_LOGICAL_CPUS==1 > - apicid_base = get_apicid_base(1); > -#else > - apicid_base = CONFIG_MAX_PHYSICAL_CPUS; > -#endif > + apicid_base = max_lapicid() + 1; > apicid_8111 = apicid_base+0; > smp_write_ioapic(mc, apicid_8111, 0x11, 0xfec00000); > > Index: tyan/s2881/mptable.c > =================================================================== > --- tyan/s2881/mptable.c (revision 1105) > +++ tyan/s2881/mptable.c (working copy) > @@ -136,11 +136,7 @@ > > > /*I/O APICs: APIC ID Version State Address*/ > -#if CONFIG_LOGICAL_CPUS > - apicid_base = get_apicid_base(3); > -#else > - apicid_base = CONFIG_MAX_PHYSICAL_CPUS; > -#endif > + apicid_base = max_lapicid() + 1; > apicid_8111 = apicid_base+0; > apicid_8131_1 = apicid_base+1; > apicid_8131_2 = apicid_base+2; > Index: tyan/s2882/mptable.c > =================================================================== > --- tyan/s2882/mptable.c (revision 1105) > +++ tyan/s2882/mptable.c (working copy) > @@ -134,11 +134,7 @@ > > > /*I/O APICs: APIC ID Version State Address*/ > -#if CONFIG_LOGICAL_CPUS==1 > - apicid_base = get_apicid_base(3); > -#else > - apicid_base = CONFIG_MAX_PHYSICAL_CPUS; > -#endif > + apicid_base = max_lapicid() + 1; > apicid_8111 = apicid_base+0; > apicid_8131_1 = apicid_base+1; > apicid_8131_2 = apicid_base+2; > Index: tyan/s2885/mptable.c > =================================================================== > --- tyan/s2885/mptable.c (revision 1105) > +++ tyan/s2885/mptable.c (working copy) > @@ -158,14 +158,11 @@ > smp_write_bus(mc, bus_isa, "ISA "); > > /*I/O APICs: APIC ID Version State Address*/ > -#if CONFIG_LOGICAL_CPUS==1 > - apicid_base = get_apicid_base(3); > -#else > - apicid_base = CONFIG_MAX_PHYSICAL_CPUS; > -#endif > + apicid_base = max_lapicid() + 1; > apicid_8111 = apicid_base+0; > apicid_8131_1 = apicid_base+1; > apicid_8131_2 = apicid_base+2; > + > smp_write_ioapic(mc, apicid_8111, 0x11, 0xfec00000); //8111 > { > device_t dev; > Index: tyan/s2891/mptable.c > =================================================================== > --- tyan/s2891/mptable.c (revision 1105) > +++ tyan/s2891/mptable.c (working copy) > @@ -204,11 +204,7 @@ > smp_write_bus(mc, bus_isa, "ISA "); > > /*I/O APICs: APIC ID Version State Address*/ > -#if CONFIG_LOGICAL_CPUS==1 > - apicid_base = get_apicid_base(3); > -#else > - apicid_base = CONFIG_MAX_PHYSICAL_CPUS; > -#endif > + apicid_base = max_lapicid() + 1; > apicid_ck804 = apicid_base; > apicid_8131_1 = apicid_base+1; > apicid_8131_2 = apicid_base+2; > Index: tyan/s2892/mptable.c > =================================================================== > --- tyan/s2892/mptable.c (revision 1105) > +++ tyan/s2892/mptable.c (working copy) > @@ -204,11 +204,7 @@ > smp_write_bus(mc, bus_isa, "ISA "); > > /*I/O APICs: APIC ID Version State Address*/ > -#if CONFIG_LOGICAL_CPUS==1 > - apicid_base = get_apicid_base(3); > -#else > - apicid_base = CONFIG_MAX_PHYSICAL_CPUS; > -#endif > + apicid_base = max_lapicid() + 1; > apicid_ck804 = apicid_base; > apicid_8131_1 = apicid_base+1; > apicid_8131_2 = apicid_base+2; > Index: tyan/s2895/mptable.c > =================================================================== > --- tyan/s2895/mptable.c (revision 1105) > +++ tyan/s2895/mptable.c (working copy) > @@ -284,11 +284,7 @@ > smp_write_bus(mc, bus_isa, "ISA "); > > /*I/O APICs: APIC ID Version State Address*/ > -#if CONFIG_LOGICAL_CPUS==1 > - apicid_base = get_apicid_base(4); > -#else > - apicid_base = CONFIG_MAX_PHYSICAL_CPUS; > -#endif > + apicid_base = max_lapicid() + 1; > apicid_ck804 = apicid_base; > apicid_8131_1 = apicid_base+1; > apicid_8131_2 = apicid_base+2; > Index: tyan/s4880/mptable.c > =================================================================== > --- tyan/s4880/mptable.c (revision 1105) > +++ tyan/s4880/mptable.c (working copy) > @@ -135,11 +135,7 @@ > > > /*I/O APICs: APIC ID Version State Address*/ > -#if CONFIG_LOGICAL_CPUS==1 > - apicid_base = get_apicid_base(3); > -#else > - apicid_base = CONFIG_MAX_PHYSICAL_CPUS; > -#endif > + apicid_base = max_lapicid() + 1; > apicid_8111 = apicid_base+0; > apicid_8131_1 = apicid_base+1; > apicid_8131_2 = apicid_base+2; > Index: tyan/s4882/mptable.c > =================================================================== > --- tyan/s4882/mptable.c (revision 1105) > +++ tyan/s4882/mptable.c (working copy) > @@ -94,7 +94,7 @@ > > /*I/O APICs: APIC ID Version State Address*/ > #if CONFIG_LOGICAL_CPUS==1 > - apicid_base = get_apicid_base(3); > + apicid_base = max_lapicid() + 1; > #else > apicid_base = CONFIG_MAX_PHYSICAL_CPUS; > #endif > Index: ../cpu/x86/lapic/lapic.c > =================================================================== > --- ../cpu/x86/lapic/lapic.c (revision 1105) > +++ ../cpu/x86/lapic/lapic.c (working copy) > @@ -3,6 +3,8 @@ > #include > #include > > +#include > + > void setup_lapic(void) > { > /* this is so interrupts work. This is very limited scope -- > @@ -70,3 +72,25 @@ > printk_info("done.\n"); > post_code(0x9b); > } > + > +unsigned max_lapicid(void) > +{ > + /* Walk through the device tree and find the > + maximum local apic id. > + We use this when assigning apic ids to the > + IOAPICs. > + */ > + > + unsigned max_lapicid; > + device_t dev; > + max_lapicid = 0; > + for(dev = all_devices; dev; dev = dev->next) { > + if (dev->path.type != DEVICE_PATH_APIC) > + continue; > + if (dev->path.u.apic.apic_id > max_lapicid) { > + max_lapicid = dev->path.u.apic.apic_id; > + } > + } > + return max_lapicid; > +} > + > Index: arima/hdama/mptable.c > =================================================================== > --- arima/hdama/mptable.c (revision 1105) > +++ arima/hdama/mptable.c (working copy) > @@ -3,7 +3,61 @@ > #include > #include > #include > +#include > +#include > +#include > > +#define HT_INIT_CONTROL 0x6c > +#define HTIC_BIOSR_Detect (1<<5) > + > +/* If we assume a symmetric processor configuration we can > + * get all of the information we need to write the processor > + * entry from the bootstrap processor. > + * Plus I don't think linux really even cares. > + * Having the proper apicid's in the table so the non-bootstrap > + * processors can be woken up should be enough. > + */ > +void smp_write_processors_inorder(struct mp_config_table *mc) > +{ > + int boot_apic_id; > + int order_id; > + unsigned apic_version; > + unsigned cpu_features; > + unsigned cpu_feature_flags; > + struct cpuid_result result; > + device_t cpu; > + > + boot_apic_id = lapicid(); > + apic_version = lapic_read(LAPIC_LVR) & 0xff; > + result = cpuid(1); > + cpu_features = result.eax; > + cpu_feature_flags = result.edx; > + /* order the output of the cpus to fix a bug in kernel 6 11 */ > + for(order_id = 0;order_id <256; order_id++) { > + for(cpu = all_devices; cpu; cpu = cpu->next) { > + unsigned long cpu_flag; > + if ((cpu->path.type != DEVICE_PATH_APIC) || > + (cpu->bus->dev->path.type != > DEVICE_PATH_APIC_CLUSTER)) > + { > + continue; > + } > + if (!cpu->enabled) { > + continue; > + } > + cpu_flag = MPC_CPU_ENABLED; > + if (boot_apic_id == cpu->path.u.apic.apic_id) { > + cpu_flag = MPC_CPU_ENABLED | > MPC_CPU_BOOTPROCESSOR; > + } > + if(cpu->path.u.apic.apic_id == order_id) { > + smp_write_processor(mc, > + cpu->path.u.apic.apic_id, apic_version, > + cpu_flag, cpu_features, cpu_feature_flags); > + break; > + } > + } > + } > +} > + > static unsigned node_link_to_bus(unsigned node, unsigned link) > { > device_t dev; > @@ -50,6 +104,10 @@ > unsigned char bus_8131_1; > unsigned char bus_8131_2; > unsigned char bus_8111_1; > + unsigned apicid_base; > + unsigned apicid_8111; > + unsigned apicid_8131_1; > + unsigned apicid_8131_2; > > mc = (void *)(((char *)v) + SMP_FLOATING_TABLE_LEN); > memset(mc, 0, sizeof(*mc)); > @@ -68,8 +126,12 @@ > mc->mpe_checksum = 0; > mc->reserved = 0; > > - smp_write_processors(mc); > + smp_write_processors_inorder(mc); > > + apicid_base = max_lapicid() + 1; > + apicid_8111 = apicid_base; > + apicid_8131_1 = apicid_base + 1; > + apicid_8131_2 = apicid_base + 2; > { > device_t dev; > > @@ -124,7 +186,7 @@ > smp_write_bus(mc, bus_isa, "ISA "); > > /* IOAPIC handling */ > - smp_write_ioapic(mc, 2, 0x11, 0xfec00000); > + smp_write_ioapic(mc, apicid_8111, 0x11, 0xfec00000); > { > device_t dev; > struct resource *res; > @@ -133,7 +195,7 @@ > if (dev) { > res = find_resource(dev, PCI_BASE_ADDRESS_0); > if (res) { > - smp_write_ioapic(mc, 0x03, 0x11, res->base); > + smp_write_ioapic(mc, apicid_8131_1, 0x11, res->base); > } > } > /* 8131 apic 4 */ > @@ -141,44 +203,44 @@ > if (dev) { > res = find_resource(dev, PCI_BASE_ADDRESS_0); > if (res) { > - smp_write_ioapic(mc, 0x04, 0x11, res->base); > + smp_write_ioapic(mc, apicid_8131_2, 0x11, res->base); > } > } > } > > /* ISA backward compatibility interrupts */ > smp_write_intsrc(mc, mp_ExtINT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, > - bus_isa, 0x00, 0x02, 0x00); > + bus_isa, 0x00, apicid_8111, 0x00); > smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, > - bus_isa, 0x01, 0x02, 0x01); > + bus_isa, 0x01, apicid_8111, 0x01); > smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, > - bus_isa, 0x00, 0x02, 0x02); > + bus_isa, 0x00, apicid_8111, 0x02); > smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, > - bus_isa, 0x03, 0x02, 0x03); > + bus_isa, 0x03, apicid_8111, 0x03); > smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, > - bus_isa, 0x04, 0x02, 0x04); > + bus_isa, 0x04, apicid_8111, 0x04); > smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, > - bus_isa, 0x05, 0x02, 0x05); > + bus_isa, 0x05, apicid_8111, 0x05); > smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, > - bus_isa, 0x06, 0x02, 0x06); > + bus_isa, 0x06, apicid_8111, 0x06); > smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, > - bus_isa, 0x07, 0x02, 0x07); > + bus_isa, 0x07, apicid_8111, 0x07); > smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, > - bus_isa, 0x08, 0x02, 0x08); > + bus_isa, 0x08, apicid_8111, 0x08); > smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, > - bus_isa, 0x09, 0x02, 0x09); > + bus_isa, 0x09, apicid_8111, 0x09); > smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, > - bus_isa, 0x0a, 0x02, 0x0a); > + bus_isa, 0x0a, apicid_8111, 0x0a); > smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, > - bus_isa, 0x0b, 0x02, 0x0b); > + bus_isa, 0x0b, apicid_8111, 0x0b); > smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, > - bus_isa, 0x0c, 0x02, 0x0c); > + bus_isa, 0x0c, apicid_8111, 0x0c); > smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, > - bus_isa, 0x0d, 0x02, 0x0d); > + bus_isa, 0x0d, apicid_8111, 0x0d); > smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, > - bus_isa, 0x0e, 0x02, 0x0e); > + bus_isa, 0x0e, apicid_8111, 0x0e); > smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, > - bus_isa, 0x0f, 0x02, 0x0f); > + bus_isa, 0x0f, apicid_8111, 0x0f); > > /* Standard local interrupt assignments */ > smp_write_lintsrc(mc, mp_ExtINT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, > @@ -188,46 +250,48 @@ > > /* PCI Ints: Type Trigger > Polarity Bus ID PCIDEVNUM|IRQ APIC ID PIN# */ > /* On board nics */ > - smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x03<<2)|0, > 0x02, 0x13); > - smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x04<<2)|0, > 0x02, 0x13); > + smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x03<<2)|0, > apicid_8111, 0x13); > + smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x04<<2)|0, > apicid_8111, 0x13); > + /* On board SATA */ > + smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x05<<2)|0, > apicid_8111, 0x11); > > /* PCI Slot 1 */ > - smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x01<<2)|0, > 0x02, 0x11); > - smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x01<<2)|1, > 0x02, 0x12); > - smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x01<<2)|2, > 0x02, 0x13); > - smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x01<<2)|3, > 0x02, 0x10); > + smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x01<<2)|0, > apicid_8111, 0x11); > + smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x01<<2)|1, > apicid_8111, 0x12); > + smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x01<<2)|2, > apicid_8111, 0x13); > + smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x01<<2)|3, > apicid_8111, 0x10); > > /* PCI Slot 2 */ > - smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x02<<2)|0, > 0x02, 0x12); > - smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x02<<2)|1, > 0x02, 0x13); > - smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x02<<2)|2, > 0x02, 0x10); > - smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x02<<2)|3, > 0x02, 0x11); > + smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x02<<2)|0, > apicid_8111, 0x12); > + smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x02<<2)|1, > apicid_8111, 0x13); > + smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x02<<2)|2, > apicid_8111, 0x10); > + smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_2, (0x02<<2)|3, > apicid_8111, 0x11); > > /* PCI Slot 3 */ > - smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x01<<2)|0, > 0x02, 0x11); > - smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x01<<2)|1, > 0x02, 0x12); > - smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x01<<2)|2, > 0x02, 0x13); > - smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x01<<2)|3, > 0x02, 0x10); > + smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x01<<2)|0, > apicid_8111, 0x11); > + smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x01<<2)|1, > apicid_8111, 0x12); > + smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x01<<2)|2, > apicid_8111, 0x13); > + smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x01<<2)|3, > apicid_8111, 0x10); > > /* PCI Slot 4 */ > - smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x02<<2)|0, > 0x02, 0x12); > - smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x02<<2)|1, > 0x02, 0x13); > - smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x02<<2)|2, > 0x02, 0x10); > - smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x02<<2)|3, > 0x02, 0x11); > + smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x02<<2)|0, > apicid_8111, 0x12); > + smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x02<<2)|1, > apicid_8111, 0x13); > + smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x02<<2)|2, > apicid_8111, 0x10); > + smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x02<<2)|3, > apicid_8111, 0x11); > > /* PCI Slot 5 */ > #warning "FIXME get the irqs right, it's just hacked to work for now" > - smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x05<<2)|0, > 0x02, 0x11); > - smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x05<<2)|1, > 0x02, 0x12); > - smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x05<<2)|2, > 0x02, 0x13); > - smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x05<<2)|3, > 0x02, 0x10); > + smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x05<<2)|0, > apicid_8111, 0x11); > + smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x05<<2)|1, > apicid_8111, 0x12); > + smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x05<<2)|2, > apicid_8111, 0x13); > + smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x05<<2)|3, > apicid_8111, 0x10); > > /* PCI Slot 6 */ > #warning "FIXME get the irqs right, it's just hacked to work for now" > - smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x04<<2)|0, > 0x02, 0x10); > - smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x04<<2)|1, > 0x02, 0x11); > - smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x04<<2)|2, > 0x02, 0x12); > - smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x04<<2)|3, > 0x02, 0x13); > + smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x04<<2)|0, > apicid_8111, 0x10); > + smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x04<<2)|1, > apicid_8111, 0x11); > + smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x04<<2)|2, > apicid_8111, 0x12); > + smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8111_1, (0x04<<2)|3, > apicid_8111, 0x13); > > /* There is no extension information... */ > > @@ -239,9 +303,51 @@ > return smp_next_mpe_entry(mc); > } > > +void reboot_if_hotswap(void) > +{ > + /* Hack patch work around for hot swap enable 33mhz problem */ > + device_t dev; > + uint32_t data; > + unsigned long htic; > + int reset; > + int i; > + > + reset = 0; > + printk_debug("Looking for bad PCIX MHz input\n"); > + dev = dev_find_slot(1, PCI_DEVFN(0x02,0)); > + data = pci_read_config32(dev, 0xa0); > + if(!(((data>>16)&0x03)==0x03)) { > + reset=1; > + printk_debug("Bad PCIX MHz - Reset\n"); > + } > + printk_debug("Looking for bad Hot Swap Enable\n"); > + dev = dev_find_slot(1, PCI_DEVFN(0x01,0)); > + data = pci_read_config32(dev, 0x48); > + if(data & 0x0c) { > + reset=1; > + printk_debug("Bad Hot Swap start - Reset\n"); > + } > + if(reset) { > + /* enable cf9 */ > + dev = dev_find_slot(node_link_to_bus(0, 0), PCI_DEVFN(0x04,3)); > + pci_write_config8(dev, 0x41, 0xf1); > + /* reset */ > + dev = dev_find_slot(0, PCI_DEVFN(0x18,0)); > + htic = pci_read_config32(dev, HT_INIT_CONTROL); > + htic &= ~HTIC_BIOSR_Detect; > + pci_write_config32(dev, HT_INIT_CONTROL, htic); > + outb(0x0e, 0x0cf9); > + } > + else { > + printk_debug("OK 133MHz & Hot Swap is off\n"); > + } > +} > + > unsigned long write_smp_table(unsigned long addr) > { > void *v; > + reboot_if_hotswap(); > + > v = smp_write_floating_table(addr); > return (unsigned long)smp_write_config_table(v); > } > > > > -- > Jason W. Schildt > LinuxBIOS Software Engineer > Linux Networx > > -- > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yinghailu at gmail.com Sat Sep 3 03:10:40 2005 From: yinghailu at gmail.com (yhlu) Date: Fri, 2 Sep 2005 18:10:40 -0700 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-10/16 In-Reply-To: References: Message-ID: <2ea3fae1050902181065c422d2@mail.gmail.com> D0 ? YH On 9/2/05, jason schildt wrote: > > DESCRIPTION: > ------------------------------------- > > ## lnxi-patch-10 ## > src/northbridge/amd/amdk8/cpu_rev.c > Testing for ranges of CPUs instead of exact matches. > > > DIFFSTAT: > ------------------------------------- > cpu_rev.c | 33 ++++++--------------------------- > 1 files changed, 6 insertions(+), 27 deletions(-) > > > > PATCH: > ------------------------------------- > Index: northbridge/amd/amdk8/cpu_rev.c > =================================================================== > --- northbridge/amd/amdk8/cpu_rev.c (revision 1105) > +++ northbridge/amd/amdk8/cpu_rev.c (working copy) > @@ -3,44 +3,23 @@ > { > return (cpuid_eax(1) & 0xfffef) == 0x0f00; > } > -//AMD_D0_SUPPORT > -static int is_cpu_pre_d0(void) > -{ > - return (cpuid_eax(1) & 0xfff0f) < 0x10f00; > -} > > -static int is_cpu_d0(void) > +static int is_cpu_pre_b3(void) > { > - return (cpuid_eax(1) & 0xfff0f) == 0x10f00; > + return (cpuid_eax(1) & 0xfffef) < 0x0f41; > } > > -//AMD_E0_SUPPORT > -static int is_cpu_pre_e0(void) > -{ > - return (cpuid_eax(1) & 0xfff0f) < 0x20f00; > -} > - > -static int is_cpu_e0(void) > -{ > - return (cpuid_eax(1) & 0xfff00) == 0x20f00; > -} > - > static int is_cpu_pre_c0(void) > { > return (cpuid_eax(1) & 0xfffef) < 0x0f48; > } > > -static int is_cpu_c0(void) > +static int is_cpu_pre_d0(void) > { > - return (cpuid_eax(1) & 0xfffef) == 0x0f48; > + return (cpuid_eax(1) & 0xfff0f) < 0x10000; > } > > -static int is_cpu_pre_b3(void) > +static int is_cpu_pre_e0(void) > { > - return (cpuid_eax(1) & 0xfffef) < 0x0f41; > + return (cpuid_eax(1) & 0xfff0f) < 0x20f00; > } > - > -static int is_cpu_b3(void) > -{ > - return (cpuid_eax(1) & 0xfffef) == 0x0f41; > -} > > > > > -- > Jason W. Schildt > LinuxBIOS Software Engineer > Linux Networx > > -- > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yinghailu at gmail.com Sat Sep 3 03:26:34 2005 From: yinghailu at gmail.com (yhlu) Date: Fri, 2 Sep 2005 18:26:34 -0700 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-04/16 In-Reply-To: References: Message-ID: <2ea3fae10509021826444ac558@mail.gmail.com> again about cpu_bus creation for all core1. I prefer to create enry to that in scan_cpu_bus in northbridge.c 1. you don't to reorder that in write_smp_processors 2. for 8 way or four way system, We need to set CPU_INIT_SERIAL=0, to init ecc for ap the same time, then with amd_sibling_init create entry for core1 in node nodex, could conflit access with cpu_initli....in node0/core0. esp for the last core1 could be missed to init, because before nodex/core0 add the core1 to the cpu bus, node0/core0 already finish the start cpu bus. YH On 9/2/05, jason schildt wrote: > > DESCRIPTION: > -------------------------------------------- > ## lnxi-patch-4 Big Dual Core Changes ## - (8)files > > src/include/cpu/amd/dualcore.h > Code Cleanup. > > src/cpu/amd/model_fxx/model_fxx_init.c > Code cleanup: > config guards in header. > dynamic memory hoisting instead of hard coding. > cpu ranges instead of exact cpu matching. > naming change (dev -> cpu) > > > src/cpu/amd/dualcore/dualcore.c > Remove chunk with these function calls #if'd out: > get_core_num_in_bsp() # Not used. > set_apicid_cpuid_lo() # Used in Tyan Opteron boards. > real_start_other_core() # Not used. > start_other_core() # Not used. > get_nodes() # Not used. > start_other_cores() # Used in Tyan Opteron Boards. > > src/cpu/amd/dualcore/amd_sibling.c > Make amd_sibling_init work and generalize get_node_core_id. > > src/cpu/amd/dualcore/dualcore_id.c > Optimized struct node_core_id so that it fits in 1 register with romcc. > > src/northbridge/amd/amdk8/coherent_ht.c > Dualcore cleanup work: > Added startup_othercores() > only look at low nibble to see link freq. > > src/northbridge/amd/amdk8/amdk8.h > Added e0 register > > src/northbridge/amd/amdk8/northbridge.c > Added dynamic memory hoisting - hoist_memory() > included 2.6.11/12 kernel bug fix > Cleaned up cpu_bus_scan() > > src/northbridge/amd/amdk8/raminit.c > factored out set_dimm_map() from set_dimm_size() > added e_step_cpu() > This function holds the logic only needed for e-step. > removed hardcoded memory hole - set_e0_mem_hole() > > DIFFSTAT: > -------------------------------------------- > > cpu/amd/dualcore/amd_sibling.c | 180 +++++++++++------------------- > cpu/amd/dualcore/dualcore.c | 127 ++++++++------------- > cpu/amd/dualcore/dualcore_id.c | 4 > cpu/amd/model_fxx/model_fxx_init.c | 98 +++++----------- > include/cpu/amd/dualcore.h | 9 - > northbridge/amd/amdk8/amdk8.h | 1 > northbridge/amd/amdk8/coherent_ht.c | 89 +++++++------- > northbridge/amd/amdk8/northbridge.c | 215 > ++++++++++++------------------------ > northbridge/amd/amdk8/raminit.c | 154 ++++++++++++------------- > 9 files changed, 346 insertions(+), 531 deletions(-) > > PATCH: > -------------------------------------------- > > > Index: src/include/cpu/amd/dualcore.h > =================================================================== > --- src/include/cpu/amd/dualcore.h (revision 1105) > +++ src/include/cpu/amd/dualcore.h (working copy) > @@ -2,18 +2,13 @@ > #define CPU_AMD_DUALCORE_H > > struct device; > -void amd_sibling_init(struct device *cpu); > > -int is_e0_later_in_bsp(int nodeid); > -unsigned int read_nb_cfg_54(void); > - > struct node_core_id { > unsigned nodeid; > unsigned coreid; > }; > > -// it can be used to get unitid and coreid it running only > -struct node_core_id get_node_core_id(unsigned int nb_cfg_54); > -unsigned get_apicid_base(unsigned ioapic_num); > +void amd_sibling_init(struct device *cpu, struct node_core_id id); > +struct node_core_id get_node_core_id(void); > > #endif /* CPU_AMD_DUALCORE_H */ > Index: src/cpu/amd/model_fxx/model_fxx_init.c > =================================================================== > --- src/cpu/amd/model_fxx/model_fxx_init.c (revision 1105) > +++ src/cpu/amd/model_fxx/model_fxx_init.c (working copy) > @@ -21,10 +21,7 @@ > #include > #include > #include > - > -#if CONFIG_LOGICAL_CPUS==1 > #include > -#endif > > #include "model_fxx_msr.h" > > @@ -152,9 +149,6 @@ > static void init_ecc_memory(unsigned node_id) > { > unsigned long startk, begink, endk; > -#if K8_E0_MEM_HOLE_SIZEK != 0 > - unsigned long hole_startk = 0, hole_endk = 0; > -#endif > unsigned long basek; > struct mtrr_state mtrr_state; > device_t f1_dev, f2_dev, f3_dev; > @@ -199,25 +193,13 @@ > startk = (pci_read_config32(f1_dev, 0x40 + (node_id*8)) & 0xffff0000) >> > 2; > endk = ((pci_read_config32(f1_dev, 0x44 + (node_id*8)) & 0xffff0000) > >> 2) + 0x4000; > > -#if K8_E0_MEM_HOLE_SIZEK != 0 > - if (!is_cpu_pre_e0()) { > - uint32_t val; > - val = pci_read_config32(f1_dev, 0xf0); > - if((val & 1)==1) { > - hole_startk = ((val & (0xff<<24)) >> 10); > - hole_endk = ((val & (0xff<<8))<<(16-10)) - startk; > - hole_endk += hole_startk; > - } > - } > -#endif > - > > /* Don't start too early */ > begink = startk; > if (begink < CONFIG_LB_MEM_TOPK) { > begink = CONFIG_LB_MEM_TOPK; > } > - printk_debug("Clearing memory %uK - %uK: ", startk, endk); > + printk_debug("Clearing memory %uK - %uK: ", begink, endk); > > /* Save the normal state */ > save_mtrr_state(&mtrr_state); > @@ -234,9 +216,6 @@ > unsigned long size; > void *addr; > > -#if K8_E0_MEM_HOLE_SIZEK != 0 > - if ((basek >= hole_startk) && (basek < hole_endk)) continue; > -#endif > /* Report every 64M */ > if ((basek % (64*1024)) == 0) { > /* Restore the normal state */ > @@ -340,6 +319,7 @@ > > /* Erratum 91 prefetch miss is handled in the kernel */ > > + > /* Erratum 106 ... */ > msr = rdmsr_amd(LS_CFG_MSR); > msr.lo |= 1 << 25; > @@ -350,7 +330,7 @@ > msr.hi |= 1 << (43 - 32); > wrmsr_amd(BU_CFG_MSR, msr); > > - if(is_cpu_d0()) { > + if (is_cpu_pre_e0() && !is_cpu_pre_d0()) { > /* Erratum 110 ...*/ > msr = rdmsr_amd(CPU_ID_HYPER_EXT_FEATURES); > msr.hi |=1; > @@ -362,26 +342,34 @@ > msr = rdmsr_amd(CPU_ID_EXT_FEATURES_MSR); > msr.hi |=1; > wrmsr_amd(CPU_ID_EXT_FEATURES_MSR, msr); > + > + /* Erratum 113 ... */ > + msr = rdmsr_amd(BU_CFG_MSR); > + msr.hi |= (1 << 16); > + wrmsr_amd(BU_CFG_MSR, msr); > } > > /* Erratum 122 */ > - msr = rdmsr(HWCR_MSR); > - msr.lo |= 1 << 6; > - wrmsr(HWCR_MSR, msr); > + if (!is_cpu_pre_c0()) { > + msr = rdmsr(HWCR_MSR); > + msr.lo |= 1 << 6; > + wrmsr(HWCR_MSR, msr); > + } > + > + /* Erratum 123? dual core deadlock? */ > > + /* Erratum 131 */ > + msr = rdmsr(NB_CFG_MSR); > + msr.lo |= 1 << 20; > + wrmsr(NB_CFG_MSR, msr); > + > } > > -void model_fxx_init(device_t dev) > +void model_fxx_init(device_t cpu) > { > unsigned long i; > msr_t msr; > -#if CONFIG_LOGICAL_CPUS > struct node_core_id id; > - unsigned siblings; > - id.coreid=0; > -#else > - unsigned nodeid; > -#endif > > /* Turn on caching if we haven't already */ > x86_enable_cache(); > @@ -404,43 +392,18 @@ > /* Enable the local cpu apics */ > setup_lapic(); > > -#if CONFIG_LOGICAL_CPUS == 1 > - siblings = cpuid_ecx(0x80000008) & 0xff; > + /* Find our node and core */ > + id = get_node_core_id(); > > - id = get_node_core_id(read_nb_cfg_54()); // pre e0 nb_cfg_54 can not be > set > - > - if(siblings>0) { > - msr = rdmsr_amd(CPU_ID_FEATURES_MSR); > - msr.lo |= 1 << 28; > - wrmsr_amd(CPU_ID_FEATURES_MSR, msr); > - > - msr = rdmsr_amd(LOGICAL_CPUS_NUM_MSR); > - msr.lo = (siblings+1)<<16; > - wrmsr_amd(LOGICAL_CPUS_NUM_MSR, msr); > - > - msr = rdmsr_amd(CPU_ID_EXT_FEATURES_MSR); > - msr.hi |= 1<<(33-32); > - wrmsr_amd(CPU_ID_EXT_FEATURES_MSR, msr); > - } > - > - > - /* Is this a bad location? In particular can another node prefecth > + /* Is this a bad location? In particular can another node prefetch > * data from this node before we have initialized it? > */ > - if (id.coreid == 0) init_ecc_memory(id.nodeid); // only do it for core 0 > -#else > - /* Is this a bad location? In particular can another node prefecth > - * data from this node before we have initialized it? > - */ > - nodeid = lapicid() & 0xf; > - init_ecc_memory(nodeid); > -#endif > + if (id.coreid == 0) { > + init_ecc_memory(id.nodeid); // only do it for core 0 > + } > > -#if CONFIG_LOGICAL_CPUS==1 > - /* Start up my cpu siblings */ > -// if(id.coreid==0) amd_sibling_init(dev); // Don't need core1 is > already be put in the CPU BUS in bus_cpu_scan > -#endif > - > + /* Deal with sibling cpus */ > + amd_sibling_init(cpu, id); > } > > static struct device_operations cpu_dev_ops = { > @@ -451,7 +414,7 @@ > { X86_VENDOR_AMD, 0xf51 }, /* SH7-B3 */ > { X86_VENDOR_AMD, 0xf58 }, /* SH7-C0 */ > { X86_VENDOR_AMD, 0xf48 }, > -#if 1 > + > { X86_VENDOR_AMD, 0xf5A }, /* SH7-CG */ > { X86_VENDOR_AMD, 0xf4A }, > { X86_VENDOR_AMD, 0xf7A }, > @@ -483,7 +446,6 @@ > { X86_VENDOR_AMD, 0x20fc2 }, > { X86_VENDOR_AMD, 0x20f12 }, /* JH-E6 */ > { X86_VENDOR_AMD, 0x20f32 }, > -#endif > > { 0, 0 }, > }; > Index: src/cpu/amd/dualcore/dualcore.c > =================================================================== > --- src/cpu/amd/dualcore/dualcore.c (revision 1105) > +++ src/cpu/amd/dualcore/dualcore.c (working copy) > @@ -1,99 +1,68 @@ > /* 2004.12 yhlu add dual core support */ > > - > -#ifndef SET_NB_CFG_54 > -#define SET_NB_CFG_54 1 > -#endif > - > #include "cpu/amd/dualcore/dualcore_id.c" > > -static inline unsigned get_core_num_in_bsp(unsigned nodeid) > +static void do_k8_init_and_stop_secondaries(void) > { > - return ((pci_read_config32(PCI_DEV(0, 0x18+nodeid, 3), 0xe8)>>12) > & 3); > -} > - > -static inline > -#if SET_NB_CFG_54 == 1 > - uint8_t > -#else > - void > -#endif > - set_apicid_cpuid_lo(void) { > -#if SET_NB_CFG_54 > - //for pre_e0, even we set nb_cfg_54, but it will still be 0 > - //for e0 later you should use get_node_id(read_nb_cfg_54()) even for > single core cpu > - //get siblings via cpuid(0x80000008) ecx[7:0] > - #if CONFIG_MAX_PHYSICAL_CPUS != 8 > - if( get_core_num_in_bsp(0) == 0) { > - /*first node only has one core, pre_e0 > - all e0 single core installed don't need enable lo too, > - So if mixing e0 single core and dual core, > - don't put single core in first socket */ > - return 0; > - } > - #endif > + struct node_core_id id; > + device_t dev; > + unsigned apicid; > + unsigned max_siblings; > + msr_t msr; > > - if(read_option(CMOS_VSTART_dual_core, CMOS_VLEN_dual_core, 0) != 0) > { // disable dual_core > - return 0; > - } > + /* Skip this if there was a built in self test failure */ > > - // set the NB_CFG[54]=1; why the OS will be happy with that ??? > - msr_t msr; > - msr = rdmsr(NB_CFG_MSR); > - msr.hi |= (1<<(54-32)); // InitApicIdCpuIdLo > - wrmsr(NB_CFG_MSR, msr); > + if (is_cpu_pre_e0()) { > + id.nodeid = lapicid() & 0x7; > + id.coreid = 0; > + } else { > + /* Which cpu are we on? */ > + id = get_node_core_id_x(); > > - return 1; > + /* Set NB_CFG_MSR > + * Linux expect the core to be in the least signficant bits. > + */ > + msr = rdmsr(NB_CFG_MSR); > + msr.hi |= (1<<(54-32)); // InitApicIdCpuIdLo > + wrmsr(NB_CFG_MSR, msr); > + } > > -#endif > + /* For now assume all cpus have the same number of siblings */ > + max_siblings = (cpuid_ecx(0x80000008) & 0xff) + 1; > > -} > + /* Set the lapicid */ > + lapic_write(LAPIC_ID,((id.nodeid*max_siblings) + id.coreid) << 24); > > -static inline void real_start_other_core(unsigned nodeid) > -{ > - uint32_t dword; > - // set PCI_DEV(0, 0x18+nodeid, 3), 0x44 bit 27 to redirect all MC4 > accesses and error logging to core0 > - dword = pci_read_config32(PCI_DEV(0, 0x18+nodeid, 3), 0x44); > - dword |= 1<<27; // NbMcaToMstCpuEn bit > - pci_write_config32(PCI_DEV(0, 0x18+nodeid, 3), 0x44, dword); > - // set PCI_DEV(0, 0x18+nodeid, 0), 0x68 bit 5 to start core1 > - dword = pci_read_config32(PCI_DEV(0, 0x18+nodeid, 0), 0x68); > - dword |= 1<<5; > - pci_write_config32(PCI_DEV(0, 0x18+nodeid, 0), 0x68, dword); > + /* Remember the cpuid */ > + if (id.coreid == 0) { > + dev = PCI_DEV(0, 0x18 + id.nodeid, 2); > + pci_write_config32(dev, 0x9c, cpuid_eax(1)); > + } > + > + /* Maybe call distinguish_cpu_resets only on the last core? */ > + distinguish_cpu_resets(id.nodeid); > + if (!boot_cpu()) { > + stop_this_cpu(); > + } > } > > -//it is running on core0 of every node > -static inline void start_other_core(unsigned nodeid) { > - > - if(read_option(CMOS_VSTART_dual_core, CMOS_VLEN_dual_core, 0) != > 0) { // disable dual_core > - return; > - } > - > - if( get_core_num() >0) { // defined in dualcore_id.c > - real_start_other_core(nodeid); > - } > -} > - > -static inline unsigned get_nodes(void) > +static void k8_init_and_stop_secondaries(void) > { > - return ((pci_read_config32(PCI_DEV(0, 0x18, 0), 0x60)>>4) & 7) + 1; > -} > + /* This doesn't work with Cache As Ram because it messes with > + the MTRR state, which breaks the init detection. > + do_k8_init_and_stop_secondaries should be usable by CAR code. > + */ > > -//it is running on core0 of node0 > -static inline void start_other_cores(void) { > - unsigned nodes; > - unsigned nodeid; > + int init_detected; > > - if(read_option(CMOS_VSTART_dual_core, CMOS_VLEN_dual_core, 0) != > 0) { // disable dual_core > - return; > - } > + init_detected = early_mtrr_init_detected(); > + amd_early_mtrr_init(); > > - nodes = get_nodes(); > - > - for(nodeid=0; nodeid - if( get_core_num_in_bsp(nodeid) > 0) { > - real_start_other_core(nodeid); > - } > + enable_lapic(); > + init_timer(); > + if (init_detected) { > + asm volatile ("jmp __cpu_reset"); > } > > + do_k8_init_and_stop_secondaries(); > } > Index: src/cpu/amd/dualcore/amd_sibling.c > =================================================================== > --- src/cpu/amd/dualcore/amd_sibling.c (revision 1105) > +++ src/cpu/amd/dualcore/amd_sibling.c (working copy) > @@ -1,4 +1,5 @@ > /* 2004.12 yhlu add dual core support */ > +/* 24 June 2005 Cleaned up dual core support Eric Biederman */ > > #include > #include > @@ -14,59 +15,87 @@ > > static int first_time = 1; > static int disable_siblings = !CONFIG_LOGICAL_CPUS; > +void amd_sibling_init(device_t cpu, struct node_core_id id) > +{ > + unsigned long i; > + unsigned siblings, max_siblings; > > + /* On the bootstrap processor see if I want sibling cpus enabled */ > + if (first_time) { > + first_time = 0; > + get_option(&disable_siblings, "dual_core"); > + } > > -int is_e0_later_in_bsp(int nodeid) > -{ > - uint32_t val; > - uint32_t val_old; > - int e0_later; > - if(nodeid==0) { // we don't need to do that for node 0 in core0/node0 > - return !is_cpu_pre_e0(); > + siblings = cpuid_ecx(0x80000008) & 0xff; > + printk_debug("%d Sibling Cores found\n", siblings); > + > + /* For now assume all cpus have the same number of siblings */ > + max_siblings = siblings + 1; > + > + /* Wishlist? make dual cores look like hyperthreading */ > + > + /* See if I am a sibling cpu */ > + if (disable_siblings && (id.coreid != 0)) { > + cpu->enabled = 0; > } > - // d0 will be treated as e0 with this methods, but the d0 nb_cfg_54 > always 0 > - device_t dev; > - dev = dev_find_slot(0, PCI_DEVFN(0x18+nodeid,2)); > - if(!dev) return 0; > - val_old = pci_read_config32(dev, 0x80); > - val = val_old; > - val |= (1<<3); > - pci_write_config32(dev, 0x80, val); > - val = pci_read_config32(dev, 0x80); > - e0_later = !!(val & (1<<3)); > - if(e0_later) { // pre_e0 bit 3 always be 0 and can not be changed > - pci_write_config32(dev, 0x80, val_old); // restore it > + > + if (id.coreid == 0) { > + /* On the primary cpu find the siblings */ > + for (i = 1; i <= siblings; i++) { > + struct device_path cpu_path; > + device_t new; > + /* Build the cpu device path */ > + cpu_path.type = DEVICE_PATH_APIC; > + cpu_path.u.apic.apic_id = > + (id.nodeid*max_siblings) + i; > + new = alloc_dev(cpu->bus, &cpu_path); > + if (!new) { > + continue; > + } > + /* Report what I have done */ > + printk_debug("CPU: %s %s\n", > + dev_path(new), new->enabled?"enabled":"disabled"); > + } > } > - > - return e0_later; > } > > -unsigned int read_nb_cfg_54(void) > +struct node_core_id get_node_core_id(void) > { > - msr_t msr; > - msr = rdmsr(NB_CFG_MSR); > - return ( ( msr.hi >> (54-32)) & 1); > -} > - > -struct node_core_id get_node_core_id(unsigned int nb_cfg_54) { > struct node_core_id id; > - // get the apicid via cpuid(1) ebx[27:24] > - if(nb_cfg_54) { > - // when NB_CFG[54] is set, nodid = ebx[27:25], coreid = > ebx[24] > - id.coreid = (cpuid_ebx(1) >> 24) & 0xf; > - id.nodeid = (id.coreid>>1); > - id.coreid &= 1; > - } else { // single core should be here too > + unsigned siblings; > + /* Get the apicid at reset */ > + id.nodeid = (cpuid_ebx(1) >> 24) & 0xff; > + id.coreid = 0; > + /* Find out how many siblings we have */ > + siblings = cpuid_ecx(0x80000008) & 0xff; > + if (siblings) { > + unsigned bits; > + msr_t msr; > + bits = 0; > + while ((1 << bits) <= siblings) > + bits++; > + > + msr = rdmsr(NB_CFG_MSR); > + if ((msr.hi >> (54-32)) & 1) { > + // when NB_CFG[54] is set, nodeid = ebx[27:25], coreid = ebx[24] > + id.coreid = id.nodeid & ((1 << bits) - 1); > + id.nodeid >>= bits; > + } else { > // when NB_CFG[54] is clear, nodeid = ebx[26:24], coreid > = ebx[27] > - id.nodeid = (cpuid_ebx(1) >> 24) & 0xf; > - id.coreid = (id.nodeid>>3); > - id.nodeid &= 7; > + id.coreid = id.nodeid >> 3; > + id.nodeid &= 7; > + } > + } else { > + if (!is_cpu_pre_e0()) { > + id.nodeid >>= 1; > + } > } > - return id; > + return id; > +} > > > -} > > +#if 0 > static int get_max_siblings(int nodes) > { > device_t dev; > @@ -169,76 +198,5 @@ > > return apicid_base; > } > -#if 0 > -void amd_sibling_init(device_t cpu) > -{ > - unsigned i, siblings; > - struct cpuid_result result; > - unsigned nb_cfg_54; > - struct node_core_id id; > > - /* On the bootstrap processor see if I want sibling cpus enabled */ > - if (first_time) { > - first_time = 0; > - get_option(&disable_siblings, "dual_core"); > - } > - result = cpuid(0x80000008); > - /* See how many sibling cpus we have */ > - /* Is dualcore supported */ > - siblings = (result.ecx & 0xff); > - if ( siblings < 1) { > - return; > - } > - > -#if 1 > - printk_debug("CPU: %u %d siblings\n", > - cpu->path.u.apic.apic_id, > - siblings); > #endif > - > - nb_cfg_54 = read_nb_cfg_54(); > -#if 1 > - id = get_node_core_id(nb_cfg_54); // pre e0 nb_cfg_54 can not be set > - > - /* See if I am a sibling cpu */ > - //if ((cpu->path.u.apic.apic_id>>(nb_cfg_54?0:3)) & siblings ) { // > siblings = 1, 3, 7, 15,.... > - //if ( ( (cpu->path.u.apic.apic_id>>(nb_cfg_54?0:3)) % (siblings+1) ) != > 0 ) { > - if(id.coreid != 0) { > - if (disable_siblings) { > - cpu->enabled = 0; > - } > - return; > - } > -#endif > - > - /* I am the primary cpu start up my siblings */ > - > - for(i = 1; i <= siblings; i++) { > - struct device_path cpu_path; > - device_t new; > - /* Build the cpu device path */ > - cpu_path.type = DEVICE_PATH_APIC; > - cpu_path.u.apic.apic_id = cpu->path.u.apic.apic_id + i * > (nb_cfg_54?1:8); > - > - /* See if I can find the cpu */ > - new = find_dev_path(cpu->bus, &cpu_path); > - /* Allocate the new cpu device structure */ > - if(!new) { > - new = alloc_dev(cpu->bus, &cpu_path); > - new->enabled = 1; > - new->initialized = 0; > - } > - > -#if 1 > - printk_debug("CPU: %u has sibling %u\n", > - cpu->path.u.apic.apic_id, > - new->path.u.apic.apic_id); > -#endif > - /* Start the new cpu */ > - if(new->enabled && !new->initialized) > - start_cpu(new); > - } > - > -} > -#endif > - > Index: src/cpu/amd/dualcore/dualcore_id.c > =================================================================== > --- src/cpu/amd/dualcore/dualcore_id.c (revision 1105) > +++ src/cpu/amd/dualcore/dualcore_id.c (working copy) > @@ -11,8 +11,8 @@ > } > > struct node_core_id { > - unsigned nodeid; > - unsigned coreid; > + unsigned nodeid:8; > + unsigned coreid:8; > }; > > static inline struct node_core_id get_node_core_id(unsigned nb_cfg_54) { > Index: src/northbridge/amd/amdk8/coherent_ht.c > =================================================================== > --- src/northbridge/amd/amdk8/coherent_ht.c (revision 1105) > +++ src/northbridge/amd/amdk8/coherent_ht.c (working copy) > @@ -155,23 +155,6 @@ > > } > > -#ifndef ENABLE_APIC_EXT_ID > -#define ENABLE_APIC_EXT_ID 0 > -#endif > - > -static void enable_apic_ext_id(u8 node) > -{ > -#if ENABLE_APIC_EXT_ID==1 > -#warning "FIXME Is the right place to enable apic ext id here?" > - > - u32 val; > - > - val = pci_read_config32(NODE_HT(node), 0x68); > - val |= (HTTC_APIC_EXT_SPUR | HTTC_APIC_EXT_ID | > HTTC_APIC_EXT_BRD_CST); > - pci_write_config32(NODE_HT(node), 0x68, val); > -#endif > -} > - > static void enable_routing(u8 node) > { > u32 val; > @@ -292,20 +275,18 @@ > return 1; > } > > -static uint16_t read_freq_cap(device_t dev, uint8_t pos) > +static unsigned read_freq_cap(device_t dev, unsigned pos) > { > /* Handle bugs in valid hypertransport frequency reporting */ > - uint16_t freq_cap; > + unsigned freq_cap; > uint32_t id; > > freq_cap = pci_read_config16(dev, pos); > freq_cap &= ~(1 << HT_FREQ_VENDOR); /* Ignore Vendor HT frequencies */ > > -#if K8_HT_FREQ_1G_SUPPORT == 1 > if (!is_cpu_pre_e0()) { > return freq_cap; > } > -#endif > > id = pci_read_config32(dev, 0); > > @@ -339,8 +320,10 @@ > > /* See if I am changing the link freqency */ > old_freq = pci_read_config8(node1, link1 + PCI_HT_CAP_HOST_FREQ); > + old_freq &= 0x0f; > needs_reset |= old_freq != freq; > old_freq = pci_read_config8(node2, link2 + PCI_HT_CAP_HOST_FREQ); > + old_freq &= 0x0f; > needs_reset |= old_freq != freq; > > /* Set the Calulcated link frequency */ > @@ -382,7 +365,6 @@ > > /* Set node2's widths */ > pci_write_config8(node2, link2 + PCI_HT_CAP_HOST_WIDTH + 1, width); > - > return needs_reset; > } > > @@ -1625,9 +1607,9 @@ > } > #endif /* CONFIG_MAX_PHYSICAL_CPUS > 1 */ > > +static unsigned count_cpus(unsigned nodes) > +{ > #if CONFIG_LOGICAL_CPUS==1 > -static unsigned verify_dualcore(unsigned nodes) > -{ > unsigned node, totalcpus, tmp; > > totalcpus = 0; > @@ -1637,25 +1619,21 @@ > } > > return totalcpus; > +#else > + return nodes; > +#endif > > } > -#endif > > static void coherent_ht_finalize(unsigned nodes) > { > + unsigned total_cpus; > + unsigned cpu_node_count; > unsigned node; > int rev_a0; > -#if CONFIG_LOGICAL_CPUS==1 > - unsigned total_cpus; > + total_cpus = count_cpus(nodes); > + cpu_node_count = ((total_cpus -1)<<16)|((nodes - 1) << 4); > > - if(read_option(CMOS_VSTART_dual_core, CMOS_VLEN_dual_core, 0) == 0) { /* > dual_core */ > - total_cpus = verify_dualcore(nodes); > - } > - else { > - total_cpus = nodes; > - } > -#endif > - > /* set up cpu count and node count and enable Limit > * Config Space Range for all available CPUs. > * Also clear non coherent hypertransport bus range > @@ -1672,11 +1650,7 @@ > /* Set the Total CPU and Node count in the system */ > val = pci_read_config32(dev, 0x60); > val &= (~0x000F0070); > -#if CONFIG_LOGICAL_CPUS==1 > - val |= ((total_cpus-1)<<16)|((nodes-1)<<4); > -#else > - val |= ((nodes-1)<<16)|((nodes-1)<<4); > -#endif > + val |= cpu_node_count; > pci_write_config32(dev, 0x60, val); > > /* Only respond to real cpu pci configuration cycles > @@ -1786,6 +1760,33 @@ > return needs_reset; > } > > +static void startup_other_cores(unsigned nodes) > +{ > + unsigned node; > + for(node = 0; node < nodes; node++) { > + device_t dev; > + unsigned siblings; > + dev = NODE_MC(node); > + siblings = (pci_read_config32(dev, 0xe8) >> 12) & 0x3; > + > + if (siblings) { > + device_t dev_f0; > + unsigned val; > + /* Redirect all MC4 accesses and error logging to core0 */ > + val = pci_read_config32(dev, 0x44); > + val |= (1 << 27); //NbMcaToMstCpuEn bit > + pci_write_config32(dev, 0x44, val); > + > + dev_f0 = NODE_HT(node); > + /* Enable extended apic id's and second core */ > + val = pci_read_config32(dev_f0, 0x68); > + val |= (1 << 18) | (1 << 17) | ( 1 << 5); > + pci_write_config32(dev_f0, 0x68, val); > + } > + } > +} > + > + > static int setup_coherent_ht_domain(void) > { > struct setup_smp_result result; > @@ -1799,15 +1800,15 @@ > enable_bsp_routing(); > > #if CONFIG_MAX_PHYSICAL_CPUS > 1 > - result = setup_smp(); > - result.nodes = verify_mp_capabilities(result.nodes); > - clear_dead_routes(result.nodes); > + result = setup_smp(); > #endif > - > + result.nodes = verify_mp_capabilities(result.nodes); > + clear_dead_routes(result.nodes); > if (result.nodes == 1) { > setup_uniprocessor(); > } > coherent_ht_finalize(result.nodes); > + startup_other_cores(result.nodes); > result.needs_reset = apply_cpu_errata_fixes(result.nodes, > result.needs_reset); > result.needs_reset = optimize_link_read_pointers(result.nodes, > result.needs_reset); > return result.needs_reset; > Index: src/northbridge/amd/amdk8/amdk8.h > =================================================================== > --- src/northbridge/amd/amdk8/amdk8.h (revision 1105) > +++ src/northbridge/amd/amdk8/amdk8.h (working copy) > @@ -136,6 +136,7 @@ > #define DCL_DisInRcvrs (1<<24) > #define DCL_BypMax_SHIFT 25 > #define DCL_En2T (1<<28) > +#define DCL_UpperCSMap (1<<29) > #define DRAM_CONFIG_HIGH 0x94 > #define DCH_ASYNC_LAT_SHIFT 0 > #define DCH_ASYNC_LAT_MASK 0xf > Index: src/northbridge/amd/amdk8/northbridge.c > =================================================================== > --- src/northbridge/amd/amdk8/northbridge.c (revision 1105) > +++ src/northbridge/amd/amdk8/northbridge.c (working copy) > @@ -17,9 +17,9 @@ > #include > > #include > +#include > > #if CONFIG_LOGICAL_CPUS==1 > -#include > #include > #endif > > @@ -27,11 +27,8 @@ > #include "root_complex/chip.h" > #include "northbridge.h" > #include "amdk8.h" > +#include "cpu_rev.c" > > -#if K8_E0_MEM_HOLE_SIZEK != 0 > -#include "./cpu_rev.c" > -#endif > - > #define FX_DEVS 8 > static device_t __f0_dev[FX_DEVS]; > static device_t __f1_dev[FX_DEVS]; > @@ -640,6 +637,41 @@ > return tolm; > } > > +static uint32_t hoist_memory(unsigned long mmio_basek, int i) > +{ > + int ii; > + uint32_t carry_over; > + device_t dev; > + uint32_t base, limit; > + uint32_t basek; > + uint32_t hoist; > + > + carry_over = (4*1024*1024) - mmio_basek; > + for(ii=7;ii>i;ii--) { > + > + base = f1_read_config32(0x40 + (ii << 3)); > + limit = f1_read_config32(0x44 + (ii << 3)); > + if ((base & ((1<<1)|(1<<0))) != ((1<<1)|(1<<0))) { > + continue; > + } > + f1_write_config32(0x44 + (ii << 3),limit + (carry_over << 2)); > + f1_write_config32(0x40 + (ii << 3),base + (carry_over << 2)); > + } > + limit = f1_read_config32(0x44 + (i << 3)); > + f1_write_config32(0x44 + (i << 3),limit + (carry_over << 2)); > + dev = __f1_dev[i]; > + base = pci_read_config32(dev, 0x40 + (i << 3)); > + basek = (pci_read_config32(dev, 0x40 + (i << 3)) & 0xffff0000) >> 2; > + hoist = /* hole start address */ > + ((mmio_basek << 10) & 0xff000000) + > + /* hole address to memory controller address */ > + (((basek + carry_over) >> 6) & 0x0000ff00) + > + /* enable */ > + 1; > + pci_write_config32(dev, 0xf0, hoist); > + return carry_over; > +} > + > static void pci_domain_set_resources(device_t dev) > { > unsigned long mmio_basek; > @@ -648,41 +680,23 @@ > > pci_tolm = find_pci_tolm(&dev->link[0]); > > + /* Work around for NUMA bug in all kernels before 2.6.13. > + If pci memory hole is too small, the kernel memory to NUMA > + node mapping will fail to initialize and system will run in > + non-NUMA mode. > + */ > + if(pci_tolm > 0xf8000000) pci_tolm = 0xf8000000; > + > #warning "FIXME handle interleaved nodes" > mmio_basek = pci_tolm >> 10; > /* Round mmio_basek to something the processor can support */ > mmio_basek &= ~((1 << 6) -1); > > -#if 1 > -#warning "FIXME improve mtrr.c so we don't use up all of the mtrrs with a > 64M MMIO hole" > - /* Round the mmio hold to 64M */ > - mmio_basek &= ~((64*1024) - 1); > -#endif > - > -#if K8_E0_MEM_HOLE_SIZEK != 0 > - if (!is_cpu_pre_e0()) > - for (i = 0; i < 8; i++) { > - uint32_t base; > - base = f1_read_config32(0x40 + (i << 3)); > - if ((base & ((1<<1)|(1<<0))) != ((1<<1)|(1<<0))) { > - continue; > - } > - > - base = pci_read_config32(__f1_dev[i], 0xf0); > - if((base & 1)==0) continue; > - base &= 0xff<<24; > - base >>= 10; > - if (mmio_basek > base) { > - mmio_basek = base; > - } > - break; // only one hole > - } > -#endif > - > idx = 10; > for(i = 0; i < 8; i++) { > uint32_t base, limit; > unsigned basek, limitk, sizek; > + > base = f1_read_config32(0x40 + (i << 3)); > limit = f1_read_config32(0x44 + (i << 3)); > if ((base & ((1<<1)|(1<<0))) != ((1<<1)|(1<<0))) { > @@ -708,6 +722,9 @@ > pre_sizek = mmio_basek - basek; > ram_resource(dev, idx++, basek, pre_sizek); > sizek -= pre_sizek; > + if(! is_cpu_pre_e0() ) { > + sizek += hoist_memory(mmio_basek,i); > + } > basek = mmio_basek; > } > if ((basek + sizek) <= 4*1024*1024) { > @@ -767,55 +784,21 @@ > .ops_pci_bus = &pci_cf8_conf1, > }; > > -#define APIC_ID_OFFSET 0x10 > - > static unsigned int cpu_bus_scan(device_t dev, unsigned int max) > { > struct bus *cpu_bus; > device_t dev_mc; > - int bsp_apic_id; > - int apic_id_offset; > + unsigned max_siblings; > int i,j; > - unsigned nb_cfg_54; > - int enable_apic_ext_id; > - unsigned siblings; > -#if CONFIG_LOGICAL_CPUS == 1 > - int e0_later_single_core; > - int disable_siblings; > -#endif > > - nb_cfg_54 = 0; > - enable_apic_ext_id = 0; > - siblings = 0; > - > - /* Find the bootstrap processors apicid */ > - bsp_apic_id = lapicid(); > - > - /* See if I will enable extended ids' */ > - apic_id_offset = bsp_apic_id; > - > -#if CONFIG_LOGICAL_CPUS == 1 > - disable_siblings = !CONFIG_LOGICAL_CPUS; > - get_option(&disable_siblings, "dual_core"); > - > - // for pre_e0, nb_cfg_54 can not be set, ( even set, when you read it > still be 0) > - // How can I get the nb_cfg_54 of every node' nb_cfg_54 in bsp??? and > differ d0 and e0 single core > - > - nb_cfg_54 = read_nb_cfg_54(); > -#endif > dev_mc = dev_find_slot(0, PCI_DEVFN(0x18, 0)); > if (!dev_mc) { > die("0:18.0 not found?"); > } > - if (pci_read_config32(dev_mc, 0x68) & > (HTTC_APIC_EXT_ID|HTTC_APIC_EXT_BRD_CST)) > - { > - enable_apic_ext_id = 1; > - if (apic_id_offset == 0) { > - /* bsp apic id is not changed */ > - apic_id_offset = APIC_ID_OFFSET; > - } > - } > > + /* For now assume all cpus have the same number of siblings */ > + max_siblings = (cpuid_ecx(0x80000008) & 0xff) + 1; > + > /* Find which cpus are present */ > cpu_bus = &dev->link[0]; > for(i = 0; i < 8; i++) { > @@ -834,82 +817,36 @@ > PCI_DEVFN(0x18 + i, j)); > } > } > + > + /* Build the cpu device path */ > + cpu_path.type = DEVICE_PATH_APIC; > + cpu_path.u.apic.apic_id = i*max_siblings; > > -#if CONFIG_LOGICAL_CPUS == 1 > - e0_later_single_core = 0; > - if ((!disable_siblings) && dev && dev->enabled) { > - j = (pci_read_config32(dev, 0xe8) >> 12) & 3; // dev is func 3 > - printk_debug(" %s siblings=%d\r\n", dev_path(dev), j); > + /* See if I can find the cpu */ > + cpu = find_dev_path(cpu_bus, &cpu_path); > > - if(nb_cfg_54) { > - // For e0 single core if nb_cfg_54 is set, apicid will be 0, 2, 4.... > - // ----> you can mixed single core e0 and dual core e0 at any > sequence > - // That is the typical case > - > - if(j == 0 ){ > - e0_later_single_core = is_e0_later_in_bsp(i); > // single core > - } else { > - e0_later_single_core = 0; > - } > - if(e0_later_single_core) { > - printk_debug("\tFound e0 single core\r\n"); > - j=1; > - } > - > - if(siblings > j ) { > - //actually we can't be here, because d0 nb_cfg_54 can not be set > - //even worse is_e0_later_in_bsp() can not find out if it is d0 or e0 > - > - die("When NB_CFG_54 is set, if you want to mix e0 (single core and > dual core) and single core(pre e0) CPUs, you need to put all the single > core (pre e0) CPUs before all the (e0 single or dual core) CPUs\r\n"); > - } > - else { > - siblings = j; > - } > - } else { > - siblings = j; > - } > - } > -#endif > -#if CONFIG_LOGICAL_CPUS==1 > - for (j = 0; j <= (e0_later_single_core?0:siblings); j++ ) > { > -#else > - for (j = 0; j <= siblings; j++ ) { > -#endif > - /* Build the cpu device path */ > - cpu_path.type = DEVICE_PATH_APIC; > - cpu_path.u.apic.apic_id = i * (nb_cfg_54?(siblings+1):1) + j * > (nb_cfg_54?1:8); > - > - /* See if I can find the cpu */ > - cpu = find_dev_path(cpu_bus, &cpu_path); > - > - /* Enable the cpu if I have the processor */ > - if (dev && dev->enabled) { > - if (!cpu) { > - cpu = alloc_dev(cpu_bus, &cpu_path); > - } > - if (cpu) { > - cpu->enabled = 1; > - } > + /* Enable the cpu if I have the processor */ > + if (dev && dev->enabled) { > + if (!cpu) { > + cpu = alloc_dev(cpu_bus, &cpu_path); > } > - > - /* Disable the cpu if I don't have the processor */ > - if (cpu && (!dev || !dev->enabled)) { > - cpu->enabled = 0; > - } > - > - /* Report what I have done */ > if (cpu) { > - if(enable_apic_ext_id) { > - > if(cpu->path.u.apic.apic_id core0 > - > if( (cpu->path.u.apic.apic_id > siblings) || (bsp_apic_id!=0) ) > - > cpu->path.u.apic.apic_id += apic_id_offset; > - } > - } > - printk_debug("CPU: %s %s\n", > - dev_path(cpu), cpu->enabled?"enabled":"disabled"); > + cpu->enabled = 1; > } > - } //j > + } > + > + /* Disable the cpu if I don't have the processor */ > + if (cpu && (!dev || !dev->enabled)) { > + cpu->enabled = 0; > + } > + > + /* Report what I have done */ > + if (cpu) { > + printk_debug("CPU: %s %s\n", > + dev_path(cpu), cpu->enabled?"enabled":"disabled"); > + } > } > + > return max; > } > > Index: src/northbridge/amd/amdk8/raminit.c > =================================================================== > --- src/northbridge/amd/amdk8/raminit.c (revision 1105) > +++ src/northbridge/amd/amdk8/raminit.c (working copy) > @@ -585,6 +585,16 @@ > > } > > +static void e_step_cpu(const struct mem_controller *ctrl) > +{ > + uint32_t dcl,data32; > + > + /* set bit 29 (upper cs map) of function 2 offset 0x90 */ > + dcl = pci_read_config32(ctrl->f2, DRAM_CONFIG_LOW); > + dcl |= DCL_UpperCSMap; > + pci_write_config32(ctrl->f2, DRAM_CONFIG_LOW, dcl); > +} > + > static int is_dual_channel(const struct mem_controller *ctrl) > { > uint32_t dcl; > @@ -714,28 +724,14 @@ > return sz; > } > > -static const unsigned cs_map_aa[15] = { > - /* (row=12, col=8)(14, 12) ---> (0, 0) (2, 4) */ > - 0, 1, 3, 6, 0, > - 0, 2, 4, 7, 9, > - 0, 0, 5, 8,10, > -}; > - > static void set_dimm_size(const struct mem_controller *ctrl, struct > dimm_size sz, unsigned index) > { > - uint32_t base0, base1, map; > + uint32_t base0, base1; > uint32_t dch; > > if (sz.side1 != sz.side2) { > sz.side2 = 0; > } > - map = pci_read_config32(ctrl->f2, DRAM_BANK_ADDR_MAP); > - map &= ~(0xf << (index * 4)); > -#if K8_4RANK_DIMM_SUPPORT == 1 > - if(sz.rank == 4) { > - map &= ~(0xf << ( (index + 2) * 4)); > - } > -#endif > > /* For each base register. > * Place the dimm size in 32 MB quantities in the bits 31 - 21. > @@ -747,22 +743,6 @@ > > /* Make certain side1 of the dimm is at least 32MB */ > if (sz.side1 >= (25 +3)) { > - if(is_cpu_pre_d0()) { > - map |= (sz.side1 - (25 + 3)) << (index *4); > -#if K8_4RANK_DIMM_SUPPORT == 1 > - if(sz.rank == 4) { > - map |= (sz.side1 - (25 + 3)) << ( (index + 2) * > 4); > - } > -#endif > - } > - else { > - map |= cs_map_aa[(sz.rows - 12) * 5 + (sz.col - 8) ] << (index*4); > -#if K8_4RANK_DIMM_SUPPORT == 1 > - if(sz.rank == 4) { > - map |= cs_map_aa[(sz.rows - 12) * 5 + (sz.col - > 8) ] << ( (index + 2) * 4); > - } > -#endif > - } > base0 = (1 << ((sz.side1 - (25 + 3)) + 21)) | 1; > } > > @@ -791,8 +771,6 @@ > } > #endif > > - pci_write_config32(ctrl->f2, DRAM_BANK_ADDR_MAP, map); > - > /* Enable the memory clocks for this DIMM */ > if (base0) { > dch = pci_read_config32(ctrl->f2, DRAM_CONFIG_HIGH); > @@ -806,6 +784,52 @@ > } > } > > + > +static void set_dimm_map(const struct mem_controller *ctrl, > + struct dimm_size sz, unsigned index) > +{ > + static const unsigned cs_map_aa[15] = { > + /* (row=12, col=8)(14, 12) ---> (0, 0) (2, 4) */ > + 0, 1, 3, 6, 0, > + 0, 2, 4, 7, 9, > + 0, 0, 5, 8,10, > + }; > + uint32_t map; > + int row,col; > + > + map = pci_read_config32(ctrl->f2, DRAM_BANK_ADDR_MAP); > + map &= ~(0xf << (index * 4)); > + > +#if K8_4RANK_DIMM_SUPPORT == 1 > + if(sz.rank == 4) { > + map &= ~(0xf << ( (index + 2) * 4)); > + } > +#endif > + > + if (is_cpu_pre_d0()) { > + map |= (sz.side1 - (25 + 3)) << (index *4); > +#if K8_4RANK_DIMM_SUPPORT == 1 > + if(sz.rank == 4) { > + map |= (sz.side1 - (25 + 3)) << ( (index + 2) * > 4); > + } > +#endif > + } else { > + unsigned val; > + val = cs_map_aa[(sz.rows - 12) * 5 + (sz.col - 8) ]; > + if(val == 0) { > + print_err("Invalid Column or Row count\r\n"); > + val = 7; > + } > + map |= val << (index*4); > +#if K8_4RANK_DIMM_SUPPORT == 1 > + if(sz.rank == 4) { > + map |= val << ( (index + 2) * 4); > + } > +#endif > + } > + pci_write_config32(ctrl->f2, DRAM_BANK_ADDR_MAP, map); > +} > + > static long spd_set_ram_size(const struct mem_controller *ctrl, long > dimm_mask) > { > int i; > @@ -820,6 +844,7 @@ > return -1; /* Report SPD error */ > } > set_dimm_size(ctrl, sz, i); > + set_dimm_map(ctrl, sz, i); > } > return dimm_mask; > } > @@ -865,6 +890,13 @@ > print_spew_hex32(tom_k); > print_spew(" KB\r\n"); > > +#if 0 > + /* Report the amount of memory. */ > + print_debug("RAM: 0x"); > + print_debug_hex32(tom_k); > + print_debug(" KB\r\n"); > +#endif > + > /* Now set top of memory */ > msr_t msr; > msr.lo = (tom_k & 0x003fffff) << 10; > @@ -971,7 +1003,7 @@ > if(is_dual_channel(ctrl)) { > /* Also we run out of address mask bits if we try and > interleave 8 4GB dimms */ > if ((bits == 3) && (common_size == (1 << (32 - 3)))) { > -// print_debug("8 4GB chip selects cannot be > interleaved\r\n"); > + print_spew("8 4GB chip selects cannot be > interleaved\r\n"); > return 0; > } > csbase_inc <<=1; > @@ -981,7 +1013,7 @@ > csbase_inc = csbase_low_d0[common_cs_mode]; > if(is_dual_channel(ctrl)) { > if( (bits==3) && (common_cs_mode > 8)) { > -// print_debug("8 cs_mode>8 chip selects cannot > be interleaved\r\n"); > + print_spew("8 cs_mode>8 chip selects cannot be > interleaved\r\n"); > return 0; > } > csbase_inc <<=1; > @@ -1100,25 +1132,6 @@ > return end_k; > } > > -#if K8_E0_MEM_HOLE_SIZEK != 0 > -#define K8_E0_MEM_HOLE_LIMITK 4*1024*1024 > -#define K8_E0_MEM_HOLE_BASEK (K8_E0_MEM_HOLE_LIMITK - > K8_E0_MEM_HOLE_SIZEK ) > - > -static void set_e0_mem_hole(const struct mem_controller *ctrl, unsigned > base_k) > -{ > - /* Route the addresses to the controller node */ > - unsigned val; > - > - val = pci_read_config32(ctrl->f1,0xf0); > - > - val &= 0x00ff00fe; > - val = (K8_E0_MEM_HOLE_BASEK << 10) | > ((K8_E0_MEM_HOLE_SIZEK+base_k)>>(16-10)) | 1; > - > - pci_write_config32(ctrl->f1, 0xf0, val); > -} > - > -#endif > - > static void order_dimms(const struct mem_controller *ctrl) > { > unsigned long tom_k, base_k; > @@ -1135,14 +1148,6 @@ > /* Compute the memory base address */ > base_k = memory_end_k(ctrl, ctrl->node_id); > tom_k += base_k; > -#if K8_E0_MEM_HOLE_SIZEK != 0 > - if(!is_cpu_pre_e0()) { > - /* See if I need to check the range cover hole */ > - if ((base_k <= K8_E0_MEM_HOLE_BASEK) && (tom_k > > K8_E0_MEM_HOLE_BASEK)) { > - tom_k += K8_E0_MEM_HOLE_SIZEK; > - } > - } > -#endif > route_dram_accesses(ctrl, base_k, tom_k); > set_top_mem(tom_k); > } > @@ -2145,12 +2150,11 @@ > struct spd_set_memclk_result result; > const struct mem_param *param; > long dimm_mask; > -#if 1 > + > if (!controller_present(ctrl)) { > -// print_debug("No memory controller present\r\n"); > + print_debug("No memory controller present\r\n"); > return; > } > -#endif > hw_enable_ecc(ctrl); > activate_spd_rom(ctrl); > dimm_mask = spd_detect_dimms(ctrl); > @@ -2176,6 +2180,10 @@ > if (dimm_mask < 0) > goto hw_spd_err; > order_dimms(ctrl); > + if( !is_cpu_pre_e0() ) { > + print_debug("E step CPU\r\n"); > + e_step_cpu(ctrl); > + } > return; > hw_spd_err: > /* Unrecoverable error reading SPD data */ > @@ -2280,22 +2288,6 @@ > } while(((dcl & DCL_MemClrStatus) == 0) || ((dcl & DCL_DramEnable) == > 0) ); > } > > - // init e0 mem hole here > -#if K8_E0_MEM_HOLE_SIZEK != 0 > - if (!is_cpu_pre_e0()) { > - uint32_t base, limit; > - unsigned base_k, limit_k; > - base = pci_read_config32(ctrl->f1, 0x40 + (i << > 3)); > - limit = pci_read_config32(ctrl->f1, 0x44 + (i << > 3)); > - base_k = (base & 0xffff0000) >> 2; > - limit_k = ((limit + 0x00010000) & 0xffff0000) >> > 2; > - if ((base_k <= K8_E0_MEM_HOLE_BASEK) && (limit_k > > K8_E0_MEM_HOLE_BASEK)) { > - set_e0_mem_hole(ctrl+i, base_k); > - } > - } > - > -#endif > - > print_debug(" done\r\n"); > } > > > > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > > -- > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hamish at prodigi.ch Sat Sep 3 18:41:55 2005 From: hamish at prodigi.ch (Hamish Guthrie) Date: Sat, 03 Sep 2005 18:41:55 +0200 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-06/16 In-Reply-To: References: Message-ID: <4319D253.4080008@prodigi.ch> I would like to apologise for my previous tirade, but I have fixed this problem a few times in the past and the SMP guys just ignore UNDERSTANDING THE CODE!!! In any event, the patch is crap! Hamish jason schildt wrote: > DESCRIPTION: > ---------------------------------------------- > > ## lnxi-patch-6 ## > src/cpu/x86/tsc/delay_tsc.c > cpu_relax() gets called unconditionally. > > > DIFFSTAT: > ---------------------------------------------- > delay_tsc.c | 4 ---- > 1 files changed, 4 deletions(-) > > > > PATCH: > ---------------------------------------------- > > Index: delay_tsc.c > =================================================================== > --- delay_tsc.c (revision 1105) > +++ delay_tsc.c (working copy) > @@ -159,11 +159,7 @@ > count = rdtscll(); > stop = clocks + count; > while(stop > count) { > -#ifdef CONFIG_SMP > -#if CONFIG_SMP == 1 > cpu_relax(); > -#endif > -#endif > count = rdtscll(); > } > } > > -- > > Jason W. Schildt > LinuxBIOS Software Engineer > Linux Networx > From hamish at prodigi.ch Sat Sep 3 18:43:15 2005 From: hamish at prodigi.ch (Hamish Guthrie) Date: Sat, 03 Sep 2005 18:43:15 +0200 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-06/16 In-Reply-To: References: Message-ID: <4319D2A3.3060305@prodigi.ch> This patch is CRAP!!!! This unconditionally breaks tsc usage for single-processor systems. PLEASE leave the original code as it was - it is generic code for both SMP and uni-processor environments. The code as it is does not break your SMP code, so why break our uni-processor code????? Thanks Hamish jason schildt wrote: > DESCRIPTION: > ---------------------------------------------- > > ## lnxi-patch-6 ## > src/cpu/x86/tsc/delay_tsc.c > cpu_relax() gets called unconditionally. > > > DIFFSTAT: > ---------------------------------------------- > delay_tsc.c | 4 ---- > 1 files changed, 4 deletions(-) > > > > PATCH: > ---------------------------------------------- > > Index: delay_tsc.c > =================================================================== > --- delay_tsc.c (revision 1105) > +++ delay_tsc.c (working copy) > @@ -159,11 +159,7 @@ > count = rdtscll(); > stop = clocks + count; > while(stop > count) { > -#ifdef CONFIG_SMP > -#if CONFIG_SMP == 1 > cpu_relax(); > -#endif > -#endif > count = rdtscll(); > } > } > > -- > > Jason W. Schildt > LinuxBIOS Software Engineer > Linux Networx > From halbmond at macnews.de Sat Sep 3 19:40:23 2005 From: halbmond at macnews.de (Angel) Date: Sat, 3 Sep 2005 19:40:23 +0200 Subject: [LinuxBIOS] RE: Does LinuxBIOS support the Mac Mini? In-Reply-To: <20050826141120.GA24803@openbios.org> References: <20050826141120.GA24803@openbios.org> Message-ID: The output of "lspci -vvv" is: Script started on Sam 03 Sep 2005 16:51:10 CEST lspci -vvv OUTPUT: 0000:00:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 AGP Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- 0000:00:10.0 VGA compatible controller: ATI Technologies Inc: Unknown device 5962 (rev 01) (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc: Unknown device 5962 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- 0001:10:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 PCI Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- 0001:10:1b.1 USB Controller: NEC Corporation USB (rev 43) (prog-if 10 [OHCI]) Subsystem: NEC Corporation USB Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- 0001:10:1b.2 USB Controller: NEC Corporation USB 2.0 (rev 04) (prog-if 20 [EHCI]) Subsystem: NEC Corporation USB 2.0 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- 0002:20:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 Internal PCI Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- 0002:20:0f.0 Ethernet controller: Apple Computer Inc. UniNorth 2 GMAC (Sun GEM) (rev 80) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=slow >TAbort- SERR- * Angel [050826 16:00]: >> http://e-www.motorola.com/webapp/sps/site/prod_summary.jsp?code=MPC107 >> ) this chipset seems to be only suitable for older CPU up to the >> MPC7410. I couldn't find any information about the chipset used in the >> Mac Mini. > > Can you send the output of "lspci -vvv" running on Linux on a Mac Mini? > > Stefan > > From fboudra at uxp.fr Tue Sep 6 09:07:16 2005 From: fboudra at uxp.fr (Fathi BOUDRA) Date: Tue, 6 Sep 2005 09:07:16 +0200 Subject: [LinuxBIOS] [LinuxbiosV1] Starting the real time clock on STPC Elite Message-ID: <200509060907.17173.fboudra@uxp.fr> hi, Using Linuxbios V1 on a STPC Elite motherboard, the date and time were not kept. It seems to be that this thread is related to the same problem : http://www.linuxbios.org/pipermail/linuxbios/2002-December/001393.html Could someone using the STPC Elite confirm the problem ? Or suggest a solution to resolved it ? Cheers, Fathi From stepan at openbios.org Tue Sep 6 12:08:50 2005 From: stepan at openbios.org (Stefan Reinauer) Date: Tue, 6 Sep 2005 12:08:50 +0200 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-11/16 In-Reply-To: References: Message-ID: <20050906100850.GA2391@openbios.org> * jason schildt [050903 00:03]: > +/* We can reduce the size of code generated by romcc by > + * changing all of the fixed size types that live in registers > + * into simple unsigned variables. (ie s/uint8_t/unsigned/g) > + */ Why is this? I would consider specifying an 8bit type to be more space-safing than using some generic untyped integer value. If not this should be fixed in romcc.. > /* AMD K8 Unsupported 1Ghz? */ > if (id == (PCI_VENDOR_ID_AMD | (0x1100 << 16))) { > - if (is_cpu_pre_e0()) // CK804 support 1G? > + device_t dev_2 = PCI_DEV(0,0x18,2); > + if(pci_read_config32(dev_2,0x9c) < 0x20f00) { The function call looks a lot more readable here. How much is the gain of manual inlining here? Stefan From jschildt at lnxi.com Tue Sep 6 16:18:19 2005 From: jschildt at lnxi.com (Jason Schildt) Date: Tue, 6 Sep 2005 08:18:19 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-11/16 In-Reply-To: <20050906100850.GA2391@openbios.org> References: <20050906100850.GA2391@openbios.org> Message-ID: <20050906141819.GA761@zoot.lnxi.com> On Tue, Sep 06, 2005 at 12:08:50PM +0200, Stefan Reinauer wrote: > * jason schildt [050903 00:03]: > > +/* We can reduce the size of code generated by romcc by > > + * changing all of the fixed size types that live in registers > > + * into simple unsigned variables. (ie s/uint8_t/unsigned/g) > > + */ > > Why is this? I would consider specifying an 8bit type to be more > space-safing than using some generic untyped integer value. If not this > should be fixed in romcc.. You're right in your thinking, but at this time ROMCC converts it to an unsigned anyway and winds up producing more code doing so. So in the end the space saving measure costs more in code size produced by ROMCC. > > > /* AMD K8 Unsupported 1Ghz? */ > > if (id == (PCI_VENDOR_ID_AMD | (0x1100 << 16))) { > > - if (is_cpu_pre_e0()) // CK804 support 1G? > > > + device_t dev_2 = PCI_DEV(0,0x18,2); > > + if(pci_read_config32(dev_2,0x9c) < 0x20f00) { > > The function call looks a lot more readable here. How much is the gain > of manual inlining here? > > Stefan > > -- > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios -- Jason W. Schildt LinuxBIOS Software Engineer Linux Networx From yinghai.lu at amd.com Tue Sep 6 18:48:26 2005 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 6 Sep 2005 09:48:26 -0700 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-11/16 Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06103@ssvlexmb2.amd.com> I remember that if changed that to unsigned, for four ways system it will not be compiled by ROMCC. YH -----Original Message----- From: linuxbios-bounces at openbios.org [mailto:linuxbios-bounces at openbios.org] On Behalf Of Jason Schildt Sent: Tuesday, September 06, 2005 7:18 AM To: Stefan Reinauer Cc: linuxbios at openbios.org Subject: Re: [LinuxBIOS] LNXI Merge: lnxi-patch-11/16 On Tue, Sep 06, 2005 at 12:08:50PM +0200, Stefan Reinauer wrote: > * jason schildt [050903 00:03]: > > +/* We can reduce the size of code generated by romcc by > > + * changing all of the fixed size types that live in registers > > + * into simple unsigned variables. (ie s/uint8_t/unsigned/g) > > + */ > > Why is this? I would consider specifying an 8bit type to be more > space-safing than using some generic untyped integer value. If not this > should be fixed in romcc.. You're right in your thinking, but at this time ROMCC converts it to an unsigned anyway and winds up producing more code doing so. So in the end the space saving measure costs more in code size produced by ROMCC. > > > /* AMD K8 Unsupported 1Ghz? */ > > if (id == (PCI_VENDOR_ID_AMD | (0x1100 << 16))) { > > - if (is_cpu_pre_e0()) // CK804 support 1G? > > > + device_t dev_2 = PCI_DEV(0,0x18,2); > > + if(pci_read_config32(dev_2,0x9c) < 0x20f00) { > > The function call looks a lot more readable here. How much is the gain > of manual inlining here? > > Stefan > > -- > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios -- Jason W. Schildt LinuxBIOS Software Engineer Linux Networx -- LinuxBIOS mailing list LinuxBIOS at openbios.org http://www.openbios.org/mailman/listinfo/linuxbios From jschildt at lnxi.com Tue Sep 6 19:47:43 2005 From: jschildt at lnxi.com (Jason Schildt) Date: Tue, 6 Sep 2005 11:47:43 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-15/16 In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4201E060FC@ssvlexmb2.amd.com> References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E060FC@ssvlexmb2.amd.com> Message-ID: <20050906174743.GA17854@zoot.lnxi.com> On Fri, Sep 02, 2005 at 03:26:56PM -0700, Lu, Yinghai wrote: > Any reason for you disabling Cache as RAM for Tyan MB? At this point the only way we could get all of the Opteron type boards to build was to temporarily disable CAR. The CAR implimentation was riddled with #IFDEFs and in some cases multiple layers of nested #IFDEFs that made the code very difficult to manage. The CAR issue is definitely something that needs to be discussed at the LinuxBIOS Summit in October with everyone involved coming to an agreement on how it should work. At the very least, CAR should be tested on all of the affected boards before commiting them to the repository. We simply want things to work reliably. If you want to enable CAR for a board that has been tested and is known to work, then it is a local decision. But by default we need something that is stable and manageable for everyone. --jason-- > > YH > > > > -----Original Message----- > From: linuxbios-bounces at openbios.org > [mailto:linuxbios-bounces at openbios.org] On Behalf Of jason schildt > Sent: Friday, September 02, 2005 3:04 PM > To: linuxbios at openbios.org > Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-15/16 > > DESCRIPTION: > ------------------------------------------------ > > ## lnxi-patch-15 ## > src/mainboard/.../Options.lb > Disabled cache_as_ram: USE_CACHE_RAM CONFIG_USE_INIT > tyan/s2881/Options.lb > tyan/s2882/Options.lb > tyan/s2891/Options.lb > tyan/s4880/Options.lb > tyan/s2892/Options.lb > tyan/s2875/Options.lb > tyan/s4882/Options.lb > tyan/s2885/Options.lb > tyan/s2895/Options.lb > > > DIFFSTAT: > ------------------------------------------------ > > s2875/Options.lb | 4 ++-- > s2881/Options.lb | 4 ++-- > s2882/Options.lb | 4 ++-- > s2885/Options.lb | 4 ++-- > s2891/Options.lb | 4 ++-- > s2892/Options.lb | 4 ++-- > s2895/Options.lb | 4 ++-- > s4880/Options.lb | 4 ++-- > s4882/Options.lb | 4 ++-- > 9 files changed, 18 insertions(+), 18 deletions(-) > > > > PATCH: > ------------------------------------------------ > > Index: s2881/Options.lb > =================================================================== > --- s2881/Options.lb (revision 1105) > +++ s2881/Options.lb (working copy) > @@ -130,10 +130,10 @@ > ## > ## enable CACHE_AS_RAM specifics > ## > -default USE_DCACHE_RAM=1 > +default USE_DCACHE_RAM=0 > default DCACHE_RAM_BASE=0xcf000 > default DCACHE_RAM_SIZE=0x1000 > -default CONFIG_USE_INIT=1 > +default CONFIG_USE_INIT=0 > > ## > ## Build code to setup a generic IOAPIC > Index: s2882/Options.lb > =================================================================== > --- s2882/Options.lb (revision 1105) > +++ s2882/Options.lb (working copy) > @@ -130,10 +130,10 @@ > ## > ## enable CACHE_AS_RAM specifics > ## > -default USE_DCACHE_RAM=1 > +default USE_DCACHE_RAM=0 > default DCACHE_RAM_BASE=0xcf000 > default DCACHE_RAM_SIZE=0x1000 > -default CONFIG_USE_INIT=1 > +default CONFIG_USE_INIT=0 > > ## > ## Build code to setup a generic IOAPIC > Index: s2891/Options.lb > =================================================================== > --- s2891/Options.lb (revision 1105) > +++ s2891/Options.lb (working copy) > @@ -139,10 +139,10 @@ > ## > ## enable CACHE_AS_RAM specifics > ## > -default USE_DCACHE_RAM=1 > +default USE_DCACHE_RAM=0 > default DCACHE_RAM_BASE=0xcf000 > default DCACHE_RAM_SIZE=0x1000 > -default CONFIG_USE_INIT=1 > +default CONFIG_USE_INIT=0 > > > ## > Index: s4880/Options.lb > =================================================================== > --- s4880/Options.lb (revision 1105) > +++ s4880/Options.lb (working copy) > @@ -130,10 +130,10 @@ > ## > ## enable CACHE_AS_RAM specifics > ## > -default USE_DCACHE_RAM=1 > +default USE_DCACHE_RAM=0 > default DCACHE_RAM_BASE=0xcf000 > default DCACHE_RAM_SIZE=0x1000 > -default CONFIG_USE_INIT=1 > +default CONFIG_USE_INIT=0 > > ## > ## Build code to setup a generic IOAPIC > Index: s2892/Options.lb > =================================================================== > --- s2892/Options.lb (revision 1105) > +++ s2892/Options.lb (working copy) > @@ -139,10 +139,10 @@ > ## > ## enable CACHE_AS_RAM specifics > ## > -default USE_DCACHE_RAM=1 > +default USE_DCACHE_RAM=0 > default DCACHE_RAM_BASE=0xcf000 > default DCACHE_RAM_SIZE=0x1000 > -default CONFIG_USE_INIT=1 > +default CONFIG_USE_INIT=0 > > > ## > Index: s2875/Options.lb > =================================================================== > --- s2875/Options.lb (revision 1105) > +++ s2875/Options.lb (working copy) > @@ -130,10 +130,10 @@ > ## > ## enable CACHE_AS_RAM specifics > ## > -default USE_DCACHE_RAM=1 > +default USE_DCACHE_RAM=0 > default DCACHE_RAM_BASE=0xcf000 > default DCACHE_RAM_SIZE=0x1000 > -default CONFIG_USE_INIT=1 > +default CONFIG_USE_INIT=0 > > ## > ## Build code to setup a generic IOAPIC > Index: s4882/Options.lb > =================================================================== > --- s4882/Options.lb (revision 1105) > +++ s4882/Options.lb (working copy) > @@ -130,10 +130,10 @@ > ## > ## enable CACHE_AS_RAM specifics > ## > -default USE_DCACHE_RAM=1 > +default USE_DCACHE_RAM=0 > default DCACHE_RAM_BASE=0xcf000 > default DCACHE_RAM_SIZE=0x1000 > -default CONFIG_USE_INIT=1 > +default CONFIG_USE_INIT=0 > > ## > ## Build code to setup a generic IOAPIC > Index: s2885/Options.lb > =================================================================== > --- s2885/Options.lb (revision 1105) > +++ s2885/Options.lb (working copy) > @@ -130,10 +130,10 @@ > ## > ## enable CACHE_AS_RAM specifics > ## > -default USE_DCACHE_RAM=1 > +default USE_DCACHE_RAM=0 > default DCACHE_RAM_BASE=0xcf000 > default DCACHE_RAM_SIZE=0x1000 > -default CONFIG_USE_INIT=1 > +default CONFIG_USE_INIT=0 > > ## > ## Build code to setup a generic IOAPIC > Index: s2895/Options.lb > =================================================================== > --- s2895/Options.lb (revision 1105) > +++ s2895/Options.lb (working copy) > @@ -136,10 +136,10 @@ > ## > ## enable CACHE_AS_RAM specifics > ## > -default USE_DCACHE_RAM=1 > +default USE_DCACHE_RAM=0 > default DCACHE_RAM_BASE=0xcf000 > default DCACHE_RAM_SIZE=0x1000 > -default CONFIG_USE_INIT=1 > +default CONFIG_USE_INIT=0 > > ## > ## Build code to setup a generic IOAPIC > > > > -- > Jason W. Schildt > LinuxBIOS Software Engineer > Linux Networx > > -- > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > > -- Jason W. Schildt LinuxBIOS Software Engineer Linux Networx From yinghai.lu at amd.com Tue Sep 6 19:56:36 2005 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 6 Sep 2005 10:56:36 -0700 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-15/16 Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06106@ssvlexmb2.amd.com> I think CAR for AMD Opteron MB esp Tyan MBs are validated. I don't understand the #ifdef cause problem.... And I didn't enable that on other MB that I can test. Also I didn't enable dual support for other MB too. You should know some MB don't support dual core because VRM problem...., you could burn out the MB... So you could enable the dual core support for the MB that is not validated or talk to HW engineers of the MB vendors.... YH -----Original Message----- From: Jason Schildt [mailto:jschildt at lnxi.com] Sent: Tuesday, September 06, 2005 10:48 AM To: Lu, Yinghai Cc: linuxbios at openbios.org Subject: Re: [LinuxBIOS] LNXI Merge: lnxi-patch-15/16 On Fri, Sep 02, 2005 at 03:26:56PM -0700, Lu, Yinghai wrote: > Any reason for you disabling Cache as RAM for Tyan MB? At this point the only way we could get all of the Opteron type boards to build was to temporarily disable CAR. The CAR implimentation was riddled with #IFDEFs and in some cases multiple layers of nested #IFDEFs that made the code very difficult to manage. The CAR issue is definitely something that needs to be discussed at the LinuxBIOS Summit in October with everyone involved coming to an agreement on how it should work. At the very least, CAR should be tested on all of the affected boards before commiting them to the repository. We simply want things to work reliably. If you want to enable CAR for a board that has been tested and is known to work, then it is a local decision. But by default we need something that is stable and manageable for everyone. --jason-- > > YH > > > > -----Original Message----- > From: linuxbios-bounces at openbios.org > [mailto:linuxbios-bounces at openbios.org] On Behalf Of jason schildt > Sent: Friday, September 02, 2005 3:04 PM > To: linuxbios at openbios.org > Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-15/16 > > DESCRIPTION: > ------------------------------------------------ > > ## lnxi-patch-15 ## > src/mainboard/.../Options.lb > Disabled cache_as_ram: USE_CACHE_RAM CONFIG_USE_INIT > tyan/s2881/Options.lb > tyan/s2882/Options.lb > tyan/s2891/Options.lb > tyan/s4880/Options.lb > tyan/s2892/Options.lb > tyan/s2875/Options.lb > tyan/s4882/Options.lb > tyan/s2885/Options.lb > tyan/s2895/Options.lb > > > DIFFSTAT: > ------------------------------------------------ > > s2875/Options.lb | 4 ++-- > s2881/Options.lb | 4 ++-- > s2882/Options.lb | 4 ++-- > s2885/Options.lb | 4 ++-- > s2891/Options.lb | 4 ++-- > s2892/Options.lb | 4 ++-- > s2895/Options.lb | 4 ++-- > s4880/Options.lb | 4 ++-- > s4882/Options.lb | 4 ++-- > 9 files changed, 18 insertions(+), 18 deletions(-) > > > > PATCH: > ------------------------------------------------ > > Index: s2881/Options.lb > =================================================================== > --- s2881/Options.lb (revision 1105) > +++ s2881/Options.lb (working copy) > @@ -130,10 +130,10 @@ > ## > ## enable CACHE_AS_RAM specifics > ## > -default USE_DCACHE_RAM=1 > +default USE_DCACHE_RAM=0 > default DCACHE_RAM_BASE=0xcf000 > default DCACHE_RAM_SIZE=0x1000 > -default CONFIG_USE_INIT=1 > +default CONFIG_USE_INIT=0 > > ## > ## Build code to setup a generic IOAPIC > Index: s2882/Options.lb > =================================================================== > --- s2882/Options.lb (revision 1105) > +++ s2882/Options.lb (working copy) > @@ -130,10 +130,10 @@ > ## > ## enable CACHE_AS_RAM specifics > ## > -default USE_DCACHE_RAM=1 > +default USE_DCACHE_RAM=0 > default DCACHE_RAM_BASE=0xcf000 > default DCACHE_RAM_SIZE=0x1000 > -default CONFIG_USE_INIT=1 > +default CONFIG_USE_INIT=0 > > ## > ## Build code to setup a generic IOAPIC > Index: s2891/Options.lb > =================================================================== > --- s2891/Options.lb (revision 1105) > +++ s2891/Options.lb (working copy) > @@ -139,10 +139,10 @@ > ## > ## enable CACHE_AS_RAM specifics > ## > -default USE_DCACHE_RAM=1 > +default USE_DCACHE_RAM=0 > default DCACHE_RAM_BASE=0xcf000 > default DCACHE_RAM_SIZE=0x1000 > -default CONFIG_USE_INIT=1 > +default CONFIG_USE_INIT=0 > > > ## > Index: s4880/Options.lb > =================================================================== > --- s4880/Options.lb (revision 1105) > +++ s4880/Options.lb (working copy) > @@ -130,10 +130,10 @@ > ## > ## enable CACHE_AS_RAM specifics > ## > -default USE_DCACHE_RAM=1 > +default USE_DCACHE_RAM=0 > default DCACHE_RAM_BASE=0xcf000 > default DCACHE_RAM_SIZE=0x1000 > -default CONFIG_USE_INIT=1 > +default CONFIG_USE_INIT=0 > > ## > ## Build code to setup a generic IOAPIC > Index: s2892/Options.lb > =================================================================== > --- s2892/Options.lb (revision 1105) > +++ s2892/Options.lb (working copy) > @@ -139,10 +139,10 @@ > ## > ## enable CACHE_AS_RAM specifics > ## > -default USE_DCACHE_RAM=1 > +default USE_DCACHE_RAM=0 > default DCACHE_RAM_BASE=0xcf000 > default DCACHE_RAM_SIZE=0x1000 > -default CONFIG_USE_INIT=1 > +default CONFIG_USE_INIT=0 > > > ## > Index: s2875/Options.lb > =================================================================== > --- s2875/Options.lb (revision 1105) > +++ s2875/Options.lb (working copy) > @@ -130,10 +130,10 @@ > ## > ## enable CACHE_AS_RAM specifics > ## > -default USE_DCACHE_RAM=1 > +default USE_DCACHE_RAM=0 > default DCACHE_RAM_BASE=0xcf000 > default DCACHE_RAM_SIZE=0x1000 > -default CONFIG_USE_INIT=1 > +default CONFIG_USE_INIT=0 > > ## > ## Build code to setup a generic IOAPIC > Index: s4882/Options.lb > =================================================================== > --- s4882/Options.lb (revision 1105) > +++ s4882/Options.lb (working copy) > @@ -130,10 +130,10 @@ > ## > ## enable CACHE_AS_RAM specifics > ## > -default USE_DCACHE_RAM=1 > +default USE_DCACHE_RAM=0 > default DCACHE_RAM_BASE=0xcf000 > default DCACHE_RAM_SIZE=0x1000 > -default CONFIG_USE_INIT=1 > +default CONFIG_USE_INIT=0 > > ## > ## Build code to setup a generic IOAPIC > Index: s2885/Options.lb > =================================================================== > --- s2885/Options.lb (revision 1105) > +++ s2885/Options.lb (working copy) > @@ -130,10 +130,10 @@ > ## > ## enable CACHE_AS_RAM specifics > ## > -default USE_DCACHE_RAM=1 > +default USE_DCACHE_RAM=0 > default DCACHE_RAM_BASE=0xcf000 > default DCACHE_RAM_SIZE=0x1000 > -default CONFIG_USE_INIT=1 > +default CONFIG_USE_INIT=0 > > ## > ## Build code to setup a generic IOAPIC > Index: s2895/Options.lb > =================================================================== > --- s2895/Options.lb (revision 1105) > +++ s2895/Options.lb (working copy) > @@ -136,10 +136,10 @@ > ## > ## enable CACHE_AS_RAM specifics > ## > -default USE_DCACHE_RAM=1 > +default USE_DCACHE_RAM=0 > default DCACHE_RAM_BASE=0xcf000 > default DCACHE_RAM_SIZE=0x1000 > -default CONFIG_USE_INIT=1 > +default CONFIG_USE_INIT=0 > > ## > ## Build code to setup a generic IOAPIC > > > > -- > Jason W. Schildt > LinuxBIOS Software Engineer > Linux Networx > > -- > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > > -- Jason W. Schildt LinuxBIOS Software Engineer Linux Networx From ebiederman at lnxi.com Tue Sep 6 21:13:20 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue, 06 Sep 2005 13:13:20 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-01/16 In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4201E060FE@ssvlexmb2.amd.com> (Yinghai Lu's message of "Fri, 2 Sep 2005 15:32:47 -0700") References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E060FE@ssvlexmb2.amd.com> Message-ID: "Lu, Yinghai" writes: > Actually amd8111_enable is not needed, it will be called from enable_dev > ....at first. Largely that is true but only if the device is listed in the static device tree Config.lb You can't do much except enable the device if it isn't listed but not calling amd8111_enable serves no real purpose either. Eric From ebiederman at lnxi.com Tue Sep 6 21:18:25 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue, 06 Sep 2005 13:18:25 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-06/16 In-Reply-To: <4319D253.4080008@prodigi.ch> (Hamish Guthrie's message of "Sat, 03 Sep 2005 18:41:55 +0200") References: <4319D253.4080008@prodigi.ch> Message-ID: Hamish Guthrie writes: > I would like to apologise for my previous tirade, but I have fixed this problem > a few times in the past and the SMP guys just ignore UNDERSTANDING THE CODE!!! That is part of the point of the code review. So we can work out the issues. In general it is much better to have something like cpu_relax conditionalized in the header than in the calling code. As it is the code is hard to read and it is not at all obvious why. As I recall cpu_relax simply expands to rep; nop which should be safe on any cpu. > In any event, the patch is crap! How so? The point is to communicate and if there is something non-obvious we need in a comment in the code so people do not forget what is going on. Eric From ebiederman at lnxi.com Tue Sep 6 21:26:46 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue, 06 Sep 2005 13:26:46 -0600 Subject: [LinuxBIOS] LNXI merge: lnxi-patch-00/16 In-Reply-To: <20050902204424.GC30635@zoot.lnxi.com> (Jason Schildt's message of "Fri, 2 Sep 2005 14:44:24 -0600") References: <20050902204424.GC30635@zoot.lnxi.com> Message-ID: Jason Schildt writes: > All, > > I've taken the ill-fated merge attempt from a few weeks ago and have > reworked it into 16 smaller, logical patches. I've also made certain > that in the end, when all patches are applied all of the touched boards > will build. > > Each patch I submit will consist of a brief description of what was > changed and why, as well as a diffstat and the patch itself. As a bit of constructive criticism, the why the change was missing on quite a few of the diffs. With the why missing it is hard for other people to understand the problem and comment effectively. Eric From ebiederman at lnxi.com Tue Sep 6 21:43:00 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue, 06 Sep 2005 13:43:00 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-11/16 In-Reply-To: <20050906100850.GA2391@openbios.org> (Stefan Reinauer's message of "Tue, 6 Sep 2005 12:08:50 +0200") References: <20050906100850.GA2391@openbios.org> Message-ID: Stefan Reinauer writes: > * jason schildt [050903 00:03]: >> +/* We can reduce the size of code generated by romcc by >> + * changing all of the fixed size types that live in registers >> + * into simple unsigned variables. (ie s/uint8_t/unsigned/g) >> + */ > > Why is this? I would consider specifying an 8bit type to be more > space-safing than using some generic untyped integer value. If not this > should be fixed in romcc.. This is a fundamental limit, especially on 32bit x86 with it's non-symmetric registers. romcc allocates registers and registers are not 8 bits. Therefore it requires an extra operation to mask the register value to be 8 bits, after the operation. Theoretically it could help by allowing use of registers such as %ah but the problem is that you cannot perform a register to register between register combinations like %esi, %ah and it gets even worse when you include the mmx and sse registers. So %ah is essentially unusable. Since using smaller values does not increase the numbers of registers you can use and using smaller registers requires an extra mask step. Using smaller values increases the code size. The comment was added to document this fact so we can revisit this later, if it becomes important. Hopefully this begins dispelling the myth that sub word sized quantities are more efficient to use. If you are really into register savings bit-fields can help. Especially when you have more than 2 values in a register. You have to pack and unpack the values but if you don't have them all unpacked simultaneously it can help. A sub word type is only slightly better than a bit-field in that you can use the register directly. But it still requires maintenance work to keep from having anything more than a sign bit in the registers high bits. >> /* AMD K8 Unsupported 1Ghz? */ >> if (id == (PCI_VENDOR_ID_AMD | (0x1100 << 16))) { >> - if (is_cpu_pre_e0()) // CK804 support 1G? > >> + device_t dev_2 = PCI_DEV(0,0x18,2); >> + if(pci_read_config32(dev_2,0x9c) < 0x20f00) { > > The function call looks a lot more readable here. How much is the gain > of manual inlining here? 100% The call actually works. cpuid requires 4 registers and we don't have that many to spare at this point in the code. What this bit does is read a cached copy of the cpu rev from a scratch register in pci configuration space. Probably the clearest thing to have would be a set of functions that perform this test. Something like is_cached_cpu_pre_e0(). Almost as good was be a good comment. Eric From ebiederman at lnxi.com Tue Sep 6 21:46:18 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue, 06 Sep 2005 13:46:18 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-10/16 In-Reply-To: <2ea3fae1050902181065c422d2@mail.gmail.com> (yinghailu@gmail.com's message of "Fri, 2 Sep 2005 18:10:40 -0700") References: <2ea3fae1050902181065c422d2@mail.gmail.com> Message-ID: yhlu writes: > D0 ? The thinking here is that cpu versions test should be done against ranges instead of exact matches. So only the is_cpu_pre_xxx versions remain in cpu_rev.c d0 is likely the one rev where an exact match would work but it is a dangerous habit to get into. Ranges can be much more easily extended into the future as we see new processor variants. Eric From ebiederman at lnxi.com Tue Sep 6 22:05:28 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue, 06 Sep 2005 14:05:28 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-11/16 In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4201E060FD@ssvlexmb2.amd.com> (Yinghai Lu's message of "Fri, 2 Sep 2005 15:31:21 -0700") References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E060FD@ssvlexmb2.amd.com> Message-ID: "Lu, Yinghai" writes: > Before cache as ram working, I used fixed size to replace unsigned to > make sure romcc can compile my in_coherent.c To the best of my knowledge this is based on a myth of how romcc works. Explanation already sent. > Do you have own internal version ROMCC that make use unsigned well....? No special internal version. Occasionally minor bug fixes that haven't propagated up, but I don't think there are any more outstanding romcc patches right now. > I remember that if changed that to unsigned, for four ways system it > will not be compiled by ROMCC. Without seeing the output I cannot comment on why it failed for you. I recall making and testing that change without problems. It is fascinating that a comment about how to reduce code size has generated more discussion than most of the actual code changes. Eric From ebiederman at lnxi.com Tue Sep 6 22:08:03 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue, 06 Sep 2005 14:08:03 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch02/16 In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4201E060FF@ssvlexmb2.amd.com> (Yinghai Lu's message of "Fri, 2 Sep 2005 15:34:02 -0700") References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E060FF@ssvlexmb2.amd.com> Message-ID: "Lu, Yinghai" writes: > Why usb2? > > Amd8111 usb2 already be disabled, and can not be used .... That seems to match my recollections. In which case the code should be modified to always disable usb2 unconditionally with an appropriate comment. Simply not compiling the code is confusing and appears to be a board specific hack in generic code. Eric From ebiederman at lnxi.com Tue Sep 6 22:12:46 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue, 06 Sep 2005 14:12:46 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-14/16 In-Reply-To: <2ea3fae1050902180972f37a5f@mail.gmail.com> (yinghailu@gmail.com's message of "Fri, 2 Sep 2005 18:09:05 -0700") References: <2ea3fae1050902180972f37a5f@mail.gmail.com> Message-ID: yhlu writes: > use max_lapicid() + 1 as apicid_base is not good. > > esp for apic id lifting. > > for 8 way dual core system, max_lapicid() will be 0x0f with lifting, and with > lifting it will be 0x1f. The x86 standard is now is tuples of (nodeid, coreid) which means on k8 based systems the cpu apicids will always be densly packed. I haven't seen the reference but I have been assured that is the way things are working. I believe it was Richard Breuner assured me of this In addition in the code cleanups that have been us only use the (nodeid, coreid) as supporting multiple form simultaneously is both confusing, and creates code that is hard to maintain. Eric From ebiederman at lnxi.com Tue Sep 6 22:25:47 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue, 06 Sep 2005 14:25:47 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-15/16 In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06106@ssvlexmb2.amd.com> (Yinghai Lu's message of "Tue, 6 Sep 2005 10:56:36 -0700") References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06106@ssvlexmb2.amd.com> Message-ID: "Lu, Yinghai" writes: > I think CAR for AMD Opteron MB esp Tyan MBs are validated. > > I don't understand the #ifdef cause problem.... > > And I didn't enable that on other MB that I can test. > > Also I didn't enable dual support for other MB too. > > You should know some MB don't support dual core because VRM problem...., > you could burn out the MB... > > So you could enable the dual core support for the MB that is not > validated or talk to HW engineers of the MB vendors.... Agreed. And we have not. CONFIG_MAX_SIBLINGS is not defined. A better explanation is that we had fundamental code cleanups that conflict with the current CAR implementation. In particular look at k8_init_and_stop_secondaries() from patch 4/16. It dramatically reduces the code duplication in auto.c by factoring out a common function. It was felt that maintainable code was preferable to an optional feature. The problem is that our method of detecting an init in early_mtrr_init_detected() while general purpose doesn't work if you have already played with the mttrs as the CAR code does. So either a new technique init detection is needed or we need to pass in a flag. It should only be a few days work to fix the CAR code, to work with the greatly simplified code base. There was also a practical concern with the CAR in that you cannot test changes to it except by flashing fallback which is contrary to the spirit of fallback/normal image separation. Again all minor practical problems, and not a criticism on the technique itself. Eric From ebiederman at lnxi.com Tue Sep 6 22:30:47 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue, 06 Sep 2005 14:30:47 -0600 Subject: [LinuxBIOS] LNXI merge: lnxi-patch-00/16 In-Reply-To: <20050902204424.GC30635@zoot.lnxi.com> (Jason Schildt's message of "Fri, 2 Sep 2005 14:44:24 -0600") References: <20050902204424.GC30635@zoot.lnxi.com> Message-ID: Jason Schildt writes: > All, > > I've taken the ill-fated merge attempt from a few weeks ago and have > reworked it into 16 smaller, logical patches. I've also made certain > that in the end, when all patches are applied all of the touched boards > will build. > > Each patch I submit will consist of a brief description of what was > changed and why, as well as a diffstat and the patch itself. > > I'll start submitting the diffs for review. Next time please include in the subject a very brief summary of what the patch is doing not just the patch count. Something like: [PATCH 4/16] Dual core and E0 changes. [PATCH 13/16] auto.c and failover.c changes. Some kind of logical name for each patchset, so they can be thought of and referred to more easily. Eric From yinghai.lu at amd.com Tue Sep 6 22:31:03 2005 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 6 Sep 2005 13:31:03 -0700 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-14/16 Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06108@ssvlexmb2.amd.com> I didn't catch you. For 8 ways dual core system. Lapicid will be 0x10-0x1f, so 0 will be used by ioapic. YH -----Original Message----- From: linuxbios-bounces at openbios.org [mailto:linuxbios-bounces at openbios.org] On Behalf Of ebiederman at lnxi.com Sent: Tuesday, September 06, 2005 1:13 PM To: yhlu Cc: linuxbios at openbios.org Subject: Re: [LinuxBIOS] LNXI Merge: lnxi-patch-14/16 yhlu writes: > use max_lapicid() + 1 as apicid_base is not good. > > esp for apic id lifting. > > for 8 way dual core system, max_lapicid() will be 0x0f with lifting, and with > lifting it will be 0x1f. The x86 standard is now is tuples of (nodeid, coreid) which means on k8 based systems the cpu apicids will always be densly packed. I haven't seen the reference but I have been assured that is the way things are working. I believe it was Richard Breuner assured me of this In addition in the code cleanups that have been us only use the (nodeid, coreid) as supporting multiple form simultaneously is both confusing, and creates code that is hard to maintain. Eric -- LinuxBIOS mailing list LinuxBIOS at openbios.org http://www.openbios.org/mailman/listinfo/linuxbios From ebiederman at lnxi.com Tue Sep 6 22:35:04 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue, 06 Sep 2005 14:35:04 -0600 Subject: [LinuxBIOS] mmx problems on VIA EPIA-SP resolved In-Reply-To: <1125610127.1831.30.camel@Doug> (Doug Bell's message of "Thu, 01 Sep 2005 14:28:47 -0700") References: <1125610127.1831.30.camel@Doug> Message-ID: Doug Bell writes: > We are working on VIA EPIA-SP with C3-2 processsor and have resolved > problems related to the use of the mmx as seen in the > auto.inc. The code was hanging unless we used -mno-mmx in Config.lb. Ok. Likely an issue that romcc gets confused about which instructions are part of the mmx,sse1, and sse2 extension. As the implementation filters by the registers used than by the instructions. > We then modified /src/cpu/via/model_centaur_init.c cpu_table[] to > include > {X86_VENDOR_CENTAUR, 0698}, // VIA C3 Nehemiah Sounds reasonable. > If anyone else is doing work on this board please let us know! Our code > isn't far enough along to check in. A branch might work. Eric From yinghai.lu at amd.com Tue Sep 6 22:41:05 2005 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 6 Sep 2005 13:41:05 -0700 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-15/16 Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06109@ssvlexmb2.amd.com> >There was also a practical concern with the CAR in that you cannot >test changes to it except by flashing fallback which is contrary to >the spirit of fallback/normal image separation. I never tried out by change option use cmos_util to get boot normal to fallback. I mean if I change option in CMOS from fallack to normal. The system will always in normal, until I clear the CMOS. YH From yinghai.lu at amd.com Tue Sep 6 22:50:00 2005 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 6 Sep 2005 13:50:00 -0700 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-15/16 Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0610A@ssvlexmb2.amd.com> I tried to make cache_as_ram_auto.c more smaller, the problem is I can not use jmp __cpu_reset, and I need use goto cpu_reset_x YH -----Original Message----- From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] Sent: Tuesday, September 06, 2005 1:26 PM To: Lu, Yinghai Cc: Jason Schildt; linuxbios at openbios.org Subject: Re: [LinuxBIOS] LNXI Merge: lnxi-patch-15/16 "Lu, Yinghai" writes: > I think CAR for AMD Opteron MB esp Tyan MBs are validated. > > I don't understand the #ifdef cause problem.... > > And I didn't enable that on other MB that I can test. > > Also I didn't enable dual support for other MB too. > > You should know some MB don't support dual core because VRM problem...., > you could burn out the MB... > > So you could enable the dual core support for the MB that is not > validated or talk to HW engineers of the MB vendors.... Agreed. And we have not. CONFIG_MAX_SIBLINGS is not defined. A better explanation is that we had fundamental code cleanups that conflict with the current CAR implementation. In particular look at k8_init_and_stop_secondaries() from patch 4/16. It dramatically reduces the code duplication in auto.c by factoring out a common function. It was felt that maintainable code was preferable to an optional feature. The problem is that our method of detecting an init in early_mtrr_init_detected() while general purpose doesn't work if you have already played with the mttrs as the CAR code does. So either a new technique init detection is needed or we need to pass in a flag. It should only be a few days work to fix the CAR code, to work with the greatly simplified code base. There was also a practical concern with the CAR in that you cannot test changes to it except by flashing fallback which is contrary to the spirit of fallback/normal image separation. Again all minor practical problems, and not a criticism on the technique itself. Eric From hamish at prodigi.ch Wed Sep 7 00:06:28 2005 From: hamish at prodigi.ch (Hamish Guthrie) Date: Wed, 07 Sep 2005 00:06:28 +0200 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-06/16 In-Reply-To: References: <4319D253.4080008@prodigi.ch> Message-ID: <431E12E4.9050009@prodigi.ch> Eric, I totally agree that constructive criticism is in order. Please look at the original version of the code I submitted a few months ago, shortly after the cpu_relax issue first came into being: void udelay(unsigned us) { unsigned long long count; unsigned long long stop; unsigned long long clocks; init_timer(); clocks = us; clocks *= clocks_per_usec; count = rdtscll(); stop = clocks + count; while(stop > count) { #ifdef CONFIG_SMP #if CONFIG_SMP == 1 cpu_relax(); #endif #endif count = rdtscll(); } } There was also a comment in the commit of that modification explaining exactly why it should be bracketed in the #ifdef CONFIG_SMP. I would also guess that anyone reading that code should actually think that there may be a reason, however daft it may seem, for someone to go to the trouble of bracketing the cpu_relax statement in such a way. Maybe I should add the following comment to the code, in order for it to be more explicit: /* The cpu_relax function call is specific to the SMP environment, if * code is compiled without the CONFIG_SMP define, and the cpu_relax * call is encountered, the resulting code will break. Please, therefore * do not remove the enclosing defines because cpu_relax is an SMP * specific function. */ I will not, however add this to the code, I would expect the people who added the cpu_relax function to be considerate enough as to maybe bracket their function call in #ifdef CONFIG_SMP so as to not break the uniprocessor code. I do not want to harp on ad infinitum on this, but, there are a number of people in the embedded space using LinuxBIOS, and generally there are very few SMP devices in the embedded space. I would also just like to ask how many devices are out there using LinuxBIOS with SMP? I am sure that I could multiply that number by 10 000 to get to the number of embedded uniprocessor devices using LinuxBIOS. Right now, I am in the process of rolling out some replacement firmware for some 120 000 devices previously running WinCE, which are now running Linux with LinuxBIOS as the loader. Do we need to get to the worst-case scenario and fork LinuxBIOS for uniprocessor/SMP> - I would like to think not. Hamish Eric W. Biederman wrote: > Hamish Guthrie writes: > > >>I would like to apologise for my previous tirade, but I have fixed this problem >>a few times in the past and the SMP guys just ignore UNDERSTANDING THE CODE!!! > > > That is part of the point of the code review. So we can work out the issues. > > In general it is much better to have something like cpu_relax conditionalized > in the header than in the calling code. As it is the code is hard to read > and it is not at all obvious why. As I recall cpu_relax simply expands > to rep; nop which should be safe on any cpu. > > >>In any event, the patch is crap! > > > How so? > > The point is to communicate and if there is something non-obvious we need > in a comment in the code so people do not forget what is going on. > > Eric > > From yinghai.lu at amd.com Wed Sep 7 00:32:53 2005 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 6 Sep 2005 15:32:53 -0700 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-06/16 Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0610D@ssvlexmb2.amd.com> This is first time for Jason to commit change for LNXI. So please don't worry about it. Sometime ago, someone total busted the tree, and it still be recoverd.... You can always challenge other's code if you are right. That is open source so it could reach more better code.... Regards Yinghai Lu From yinghai.lu at amd.com Wed Sep 7 00:44:21 2005 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 6 Sep 2005 15:44:21 -0700 Subject: [LinuxBIOS] topics for linuxbios summit Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0610E@ssvlexmb2.amd.com> Any thing that we need to prepare? 1. dual core: cpu scan in northbridge.c or amd_sibling_init... 2. Cache as RAM.... 3. ACPI: how to create DSDT ( Config.lb + scan to produce AMI directly?) Only support _PRT at first step? 4. ACPI: SRAT scan pci conf? 5. Open Firmware support in Kernel for i386 and x86_64 6. OpenEFI or FreeEFI as payload for LinuxBIOS....? 7. USB ROM eumluator in Linux.... 8. Serverworks chipset: Who and how? 9. CK804 support etc...., Steven from Bench? 10. K8 E0 memhole support in raminit.c or northbridge.c? Regards Yinghai Lu From ebiederman at lnxi.com Wed Sep 7 03:28:29 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue, 06 Sep 2005 19:28:29 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-06/16 In-Reply-To: <431E12E4.9050009@prodigi.ch> (Hamish Guthrie's message of "Wed, 07 Sep 2005 00:06:28 +0200") References: <4319D253.4080008@prodigi.ch> <431E12E4.9050009@prodigi.ch> Message-ID: Hamish Guthrie writes: > Eric, > > I totally agree that constructive criticism is in order. Please look at the > original version of the code I submitted a few months ago, shortly after the > cpu_relax issue first came into being: Thank you. > I do not want to harp on ad infinitum on this, but, there are a number of people > in the embedded space using LinuxBIOS, and generally there are very few SMP > devices in the embedded space. I would also just like to ask how many devices > are out there using LinuxBIOS with SMP? With dual cores becoming the path to performance you can't make a new system that isn't SMP. From the cluster side most interesting commodity are dual processor SMP. > I am sure that I could multiply that > number by 10 000 to get to the number of embedded uniprocessor devices using > LinuxBIOS. Right now, I am in the process of rolling out some replacement > firmware for some 120 000 devices previously running WinCE, which are now > running Linux with LinuxBIOS as the loader. Cool. I like the thought of 100 million devices running LinuxBIOS :) > Do we need to get to the worst-case scenario and fork LinuxBIOS for > uniprocessor/SMP> - I would like to think not. Agreed. My impression is usually the SMP/Desktop work uses the same hardware as the embedded systems but a couple of years sooner. There is also the challenge that a lot of embedded systems are single shot deals many times embedded developers don't have a long term interest in the free software project they work with. So my impression is that in a 5 years or so we will start seeing multi core embedded systems. The most maintainable fix for something like cpu_relax() is to have one definition that compiles SMP and another definition that works non-smp. #ifdef CONFIG_SMP static inline void cpu_relax(void) { __asm__ __volatile__ ("rep ; nop"); } #else static inline void cpu_relax(void) { /* do nothing */ } #endif Although in this particular case I don't know it even makes sense to bracket cpu_relax(); My point being that putting the #ifdef code in header files or in the definition of the function being called it is frequently more maintainable, than having it in the inline body of the function. Then so long as calling cpu_relax() is a reasonable thing to do you don't have to worry about it in that code. For this particular piece of code cpu_relax() largely overkill because we don't do much on secondary processors. With the growing developer base the conflicts between different developers have become a problem, this is not isolated to embedded work/SMP work conflicting. Getting a functioning code review and release process in place is one of the things we need to talk about at the LinuxBIOS summit. I know Jason tested the build on a least one uniprocessor system but that may not have tested this code path. Jason before committing will you please double check that cpu_relax() has a definition of CONFIG_SMP is 0 or not set? Eric From ebiederman at lnxi.com Wed Sep 7 03:31:28 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue, 06 Sep 2005 19:31:28 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-14/16 In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06108@ssvlexmb2.amd.com> (Yinghai Lu's message of "Tue, 6 Sep 2005 13:31:03 -0700") References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06108@ssvlexmb2.amd.com> Message-ID: "Lu, Yinghai" writes: > I didn't catch you. > > For 8 ways dual core system. Lapicid will be 0x10-0x1f, so 0 will be > used by ioapic. With the set of changes apicids will be 0x0-0x0f with 8way dual cores. If that is not sensible we can change the generic code as all of the apicid assignment is now in generic code. Eric From ebiederman at lnxi.com Wed Sep 7 03:33:52 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue, 06 Sep 2005 19:33:52 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-15/16 In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06109@ssvlexmb2.amd.com> (Yinghai Lu's message of "Tue, 6 Sep 2005 13:41:05 -0700") References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06109@ssvlexmb2.amd.com> Message-ID: "Lu, Yinghai" writes: >>There was also a practical concern with the CAR in that you cannot >>test changes to it except by flashing fallback which is contrary to >>the spirit of fallback/normal image separation. > > I never tried out by change option use cmos_util to get boot normal to > fallback. > > I mean if I change option in CMOS from fallack to normal. The system > will always in normal, until I clear the CMOS. Unless there the systems does not boot as far as ElfBoot. In which case after 3 failures the system will go to fallback. Most of our development and definitely most of deployments don't have a rom emulator. So it is important for testing that as little code as possible goes into make the decision of which rom image to boot. Eric From ebiederman at lnxi.com Wed Sep 7 03:43:06 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue, 06 Sep 2005 19:43:06 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-15/16 In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0610A@ssvlexmb2.amd.com> (Yinghai Lu's message of "Tue, 6 Sep 2005 13:50:00 -0700") References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0610A@ssvlexmb2.amd.com> Message-ID: "Lu, Yinghai" writes: > I tried to make cache_as_ram_auto.c more smaller, the problem is > I can not use jmp __cpu_reset, and I need use goto cpu_reset_x The practical problem was not how much the code had to do (except for failover.c) but instead how little of that code was in common functions, and instead was per-motherboard. Implementing on one motherboard while experimenting is fine but when you go multi-board too much cut and paste is dangerous. The first round of dual core and cache as ram code feels like an old style adventure game: You have now entered a twisty maze of ifdefs. Eric From ebiederman at lnxi.com Wed Sep 7 03:49:28 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue, 06 Sep 2005 19:49:28 -0600 Subject: [LinuxBIOS] Re: topics for linuxbios summit In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0610E@ssvlexmb2.amd.com> (Yinghai Lu's message of "Tue, 6 Sep 2005 15:44:21 -0700") References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0610E@ssvlexmb2.amd.com> Message-ID: "Lu, Yinghai" writes: > Any thing that we need to prepare? > > 1. dual core: cpu scan in northbridge.c or amd_sibling_init... > 2. Cache as RAM.... > 3. ACPI: how to create DSDT ( Config.lb + scan to produce AMI directly?) > Only support _PRT at first step? > 4. ACPI: SRAT scan pci conf? > 5. Open Firmware support in Kernel for i386 and x86_64 > 6. OpenEFI or FreeEFI as payload for LinuxBIOS....? Before we generate ACPI or anything else we need to move the relevant information into the internal device tree. > 7. USB ROM eumluator in Linux.... > 8. Serverworks chipset: Who and how? > 9. CK804 support etc...., Steven from Bench? > 10. K8 E0 memhole support in raminit.c or northbridge.c? Worth discussing. But this has always been very successfully handled in northbridge.c on Intel chipsets and it works equally well on AMD chipsets. The implementation should be in patch 4/16. 11. LinuxBIOS Maintenance. How can we do better? Eric From rminnich at lanl.gov Wed Sep 7 04:25:20 2005 From: rminnich at lanl.gov (Ronald G Minnich) Date: Tue, 06 Sep 2005 20:25:20 -0600 Subject: [LinuxBIOS] [Fwd: Re: LACIS 2005: LinuxBIOS Summit registrations (fwd)] Message-ID: <431E4F90.2040706@lanl.gov> if you're coming, you had best register. We have fewer registrations than we hoped for ... note that we're going to have a pretty good vendor presence, and also will be describing new developments in linuxbios. thanks ron From windex at windex.org Wed Sep 7 05:43:41 2005 From: windex at windex.org (windex) Date: Tue, 06 Sep 2005 22:43:41 -0500 Subject: [LinuxBIOS] I'm alive.. Message-ID: <431E61ED.6000509@windex.org> HI folks, Just a quick note that I'm still alive. If I have some time, I'll try to start contributing to the wiki again. I was reminded of what was going on by someone who hunted me down over MSN via my personal site (from my users page). The company I was working for had some financial problems, which led to me being very busy for awhile, then practically doing nothing, then canned for lack of resources. If anyone has any interest in providing some financial support for me to spend time working on documentation again, I'd be willing to listen. :) Otherwise, I'm trying to run my own company and pick up customers and that's taking nearly all of my free time at the moment. I'm back on the mailing list now, though, and hope to have my mortage payment covered in a stable way soon enough to get back to helping out. Talk to you guys later, Justin (jdarby @ linuxbios.org wiki) From yinghailu at gmail.com Wed Sep 7 05:47:03 2005 From: yinghailu at gmail.com (yhlu) Date: Tue, 6 Sep 2005 20:47:03 -0700 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-15/16 In-Reply-To: References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0610A@ssvlexmb2.amd.com> Message-ID: <2ea3fae1050906204725d323cf@mail.gmail.com> I agree. The cache_as_ram_auto.c should be the same to all Opteron MB except for 1 spd rom related. 2 superio related Other thing is need to consider apic id lifting. So i consider change that to #include "auto_1.c" int someting spd and superio related #include "auto_2.c" YH On 9/6/05, Eric W. Biederman wrote: > > "Lu, Yinghai" writes: > > > I tried to make cache_as_ram_auto.c more smaller, the problem is > > I can not use jmp __cpu_reset, and I need use goto cpu_reset_x > > The practical problem was not how much the code had to do > (except for failover.c) but instead how little of that code > was in common functions, and instead was per-motherboard. > Implementing on one motherboard while experimenting is fine but when > you go multi-board too much cut and paste is dangerous. > > The first round of dual core and cache as ram code feels > like an old style adventure game: > > You have now entered a twisty maze of ifdefs. > > Eric > > -- > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yinghailu at gmail.com Wed Sep 7 05:52:35 2005 From: yinghailu at gmail.com (yhlu) Date: Tue, 6 Sep 2005 20:52:35 -0700 Subject: [LinuxBIOS] [Fwd: Re: LACIS 2005: LinuxBIOS Summit registrations (fwd)] In-Reply-To: <431E4F90.2040706@lanl.gov> References: <431E4F90.2040706@lanl.gov> Message-ID: <2ea3fae105090620522f654bc0@mail.gmail.com> I have registered. I guess Eric and jason and Tom and Dave will be there too. benchmark.com guy should be there too, So We can discuss ck804 ..... I wonder if Stefan will be there. YH On 9/6/05, Ronald G Minnich wrote: > > if you're coming, you had best register. We have fewer registrations > than we hoped for ... > > > note that we're going to have a pretty good vendor presence, and also > will be describing new developments in linuxbios. > > thanks > > ron > > -- > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yinghailu at gmail.com Wed Sep 7 06:04:29 2005 From: yinghailu at gmail.com (yhlu) Date: Tue, 6 Sep 2005 21:04:29 -0700 Subject: [LinuxBIOS] Re: topics for linuxbios summit In-Reply-To: References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0610E@ssvlexmb2.amd.com> Message-ID: <2ea3fae1050906210417a72b6e@mail.gmail.com> On 9/6/05, Eric W. Biederman wrote: > > "Lu, Yinghai" writes: > > > Any thing that we need to prepare? > > > > 1. dual core: cpu scan in northbridge.c or amd_sibling_init... > > 2. Cache as RAM.... > > 3. ACPI: how to create DSDT ( Config.lb + scan to > produce AMI directly?) > > Only support _PRT at first step? > > 4. ACPI: SRAT scan pci conf? > > 5. Open Firmware support in Kernel for i386 and x86_64 > > 6. OpenEFI or FreeEFI as payload for LinuxBIOS....? > > Before we generate ACPI or anything else we need to move the relevant > information > into the internal device tree. YH: Good point, But I worry that we make LinuxBIOS more complicated. > 7. USB ROM eumluator in Linux.... > > 8. Serverworks chipset: Who and how? > > 9. CK804 support etc...., Steven from Bench? > > 10. K8 E0 memhole support in raminit.c or northbridge.c? > > Worth discussing. But this has always been very successfully handled > in northbridge.c on Intel chipsets and it works equally well on > AMD chipsets. The implementation should be in patch 4/16. YH: That is good feature. Please consider to add several option in CMOS for that 0: auto 1: 512M, 2:1G, 3: 2G----------> need 2 bits 11. LinuxBIOS Maintenance. How can we do better? YH: I agree we need a. one process for coordination such as chipset support. and share source code before publish ( three parties NDA?) c. one process for source code release control..., stable tag... b. move back the list and public source tree to US. Eric > > > -- > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yinghailu at gmail.com Wed Sep 7 06:10:16 2005 From: yinghailu at gmail.com (yhlu) Date: Tue, 6 Sep 2005 21:10:16 -0700 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-14/16 In-Reply-To: References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06108@ssvlexmb2.amd.com> Message-ID: <2ea3fae105090621105972be54@mail.gmail.com> at such case We need to enable 8 bit ext apic id mode for Opteron. So Opteron could use 0x10 above. and leave 0-0x0f to the device that can not support 8 bit apic id. I'm considering to align apic id lifting to the way that Norma BIOS does. YH On 9/6/05, Eric W. Biederman wrote: > > "Lu, Yinghai" writes: > > > I didn't catch you. > > > > For 8 ways dual core system. Lapicid will be 0x10-0x1f, so 0 will be > > used by ioapic. > > With the set of changes apicids will be 0x0-0x0f with 8way dual cores. > If that is not sensible we can change the generic code as all of > the apicid assignment is now in generic code. > > Eric > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stepan at openbios.org Wed Sep 7 10:30:53 2005 From: stepan at openbios.org (Stefan Reinauer) Date: Wed, 7 Sep 2005 10:30:53 +0200 Subject: [LinuxBIOS] Re: topics for linuxbios summit In-Reply-To: <2ea3fae1050906210417a72b6e@mail.gmail.com> References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0610E@ssvlexmb2.amd.com> <2ea3fae1050906210417a72b6e@mail.gmail.com> Message-ID: <20050907083053.GA13143@openbios.org> * yhlu [050907 06:04]: > > Before we generate ACPI or anything else we need to move the relevant > > information > > into the internal device tree. > > YH: Good point, But I worry that we make LinuxBIOS more complicated. No, the information has to be reorganized. Currently pirq and mptables have to be hand crafted, and this is the complicated thing. Instead the abstract information should be put to the configuration filess, if it can not be probed. > 11. LinuxBIOS Maintenance. How can we do better? > YH: I agree we need > b. move back the list and public source tree to US. what's wrong with the status quo? Stefan From ebiederman at lnxi.com Wed Sep 7 17:39:31 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed, 07 Sep 2005 09:39:31 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-14/16 In-Reply-To: <2ea3fae105090621105972be54@mail.gmail.com> (yinghailu@gmail.com's message of "Tue, 6 Sep 2005 21:10:16 -0700") References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06108@ssvlexmb2.amd.com> <2ea3fae105090621105972be54@mail.gmail.com> Message-ID: yhlu writes: > at such case We need to enable 8 bit ext apic id mode for Opteron. So Opteron > could use 0x10 above. > and leave 0-0x0f to the device that can not support 8 bit apic id. > > I'm considering to align apic id lifting to the way that Norma BIOS does. Are io-apics limited to apic ids 0x0-0x0f as well? My memory says to me the limit should be 0x0-0xff... Eric From ebiederman at lnxi.com Wed Sep 7 17:41:53 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed, 07 Sep 2005 09:41:53 -0600 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-15/16 In-Reply-To: <2ea3fae1050906204725d323cf@mail.gmail.com> (yinghailu@gmail.com's message of "Tue, 6 Sep 2005 20:47:03 -0700") References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0610A@ssvlexmb2.amd.com> <2ea3fae1050906204725d323cf@mail.gmail.com> Message-ID: yhlu writes: > I agree. > > The cache_as_ram_auto.c should be the same to all Opteron MB except for > 1 spd rom related. > 2 superio related > > Other thing is need to consider apic id lifting. > > So i consider change that to > > #include "auto_1.c" > int someting spd and superio related > #include "auto_2.c" Boards can get weird and wonderful when their designers are creative. So I would like to keep this as a matter of common subroutines we can call, rather than magic includes. The practical difference is minimal, but common subroutines are much more readable. Eric From ebiederman at lnxi.com Wed Sep 7 17:48:27 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Wed, 07 Sep 2005 09:48:27 -0600 Subject: [LinuxBIOS] Re: topics for linuxbios summit In-Reply-To: <20050907083053.GA13143@openbios.org> (Stefan Reinauer's message of "Wed, 7 Sep 2005 10:30:53 +0200") References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0610E@ssvlexmb2.amd.com> <2ea3fae1050906210417a72b6e@mail.gmail.com> <20050907083053.GA13143@openbios.org> Message-ID: Stefan Reinauer writes: > * yhlu [050907 06:04]: >> 11. LinuxBIOS Maintenance. How can we do better? >> YH: I agree we need > >> b. move back the list and public source tree to US. > > what's wrong with the status quo? I don't see a problem with the servers right now. Does anyone have any specific problems with the servers? Eric From yinghai.lu at amd.com Wed Sep 7 17:51:25 2005 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Wed, 7 Sep 2005 08:51:25 -0700 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-14/16 Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E08A92@ssvlexmb2.amd.com> >Are io-apics limited to apic ids 0x0-0x0f as well? > >My memory says to me the limit should be 0x0-0xff... before enable ext_apic_id, Opteron only can use 4 bit for apic id, So only 16 apic id. After enable ext_apic_id in every opteron, it will use 8 bit for apic id, So we got 256 apic id. Then CPU can use 0x10 above apic id. some io apic device only support 4 bit apic id, So We can leave 0x0-0xf to them. that is for AMD, it is said that intel's from p4 has 256 for default. I cut and paste something for you from Kernel list. > - 1: 82489DX -- communication using a five-wire inter-APIC bus, 8-bit > physical ID, 32-bit logical ID, etc., > > - 2: Pentium-style -- communication using a three-wire inter-APIC bus, > 4-bit physical ID, 8-bit logical ID, etc., > > - 3: P4-style -- communication using the system bus, 8-bit physical ID, > 8-bit logical ID, etc. >According to what AMD told us, all K8 CPUs support 8-bit APIC IDs >("extended APIC IDs" in their speak), but they are only enabled >"when both ApicExtId and ApicExtBrdCst in the HyperTransport Transaction >Control Register are set". YH -------------- next part -------------- An HTML attachment was scrubbed... URL: From yinghai.lu at amd.com Wed Sep 7 17:51:58 2005 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Wed, 7 Sep 2005 08:51:58 -0700 Subject: [LinuxBIOS] Re: topics for linuxbios summit Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E08A94@ssvlexmb2.amd.com> Did you notice that our list can not searched by google now? YH -----Original Message----- From: Stefan Reinauer [mailto:stepan at openbios.org] Sent: Wed 9/7/2005 1:30 AM To: Eric W. Biederman; linuxbios at openbios.org; Lu, Yinghai Subject: Re: [LinuxBIOS] Re: topics for linuxbios summit * yhlu [050907 06:04]: > > Before we generate ACPI or anything else we need to move the relevant > > information > > into the internal device tree. > > YH: Good point, But I worry that we make LinuxBIOS more complicated. No, the information has to be reorganized. Currently pirq and mptables have to be hand crafted, and this is the complicated thing. Instead the abstract information should be put to the configuration filess, if it can not be probed. > 11. LinuxBIOS Maintenance. How can we do better? > YH: I agree we need > b. move back the list and public source tree to US. what's wrong with the status quo? Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From yinghai.lu at amd.com Wed Sep 7 18:09:12 2005 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Wed, 7 Sep 2005 09:09:12 -0700 Subject: [LinuxBIOS] Re: topics for linuxbios summit Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E08A96@ssvlexmb2.amd.com> eric> > Before we generate ACPI or anything else we need to move the relevant eric> > information eric> > into the internal device tree. eric> > YH: Good point, But I worry that we make LinuxBIOS more complicated. Stepan: No, the information has to be reorganized. Currently pirq and mptables Stepan: have to be hand crafted, and this is the complicated thing. Instead the Stepan: abstract information should be put to the configuration filess, if it Stepan: can not be probed. YH: I suggest to add 1. one node id to ram_resource, so the index will be (idx<<8 | nodeid), So I can re-use ram_resource in pci_domain for SRAT creating. 2. for apci_cluster_id, will add two fields core_id and node_id, ( instantiate it when cpu_init)... 3. pci device: add pci_irq_routing, and pci_possiable_resource ( for apci _PRT and _PRS...) how about ioapci in the internal tree? YH -------------- next part -------------- An HTML attachment was scrubbed... URL: From stepan at openbios.org Wed Sep 7 18:34:46 2005 From: stepan at openbios.org (Stefan Reinauer) Date: Wed, 7 Sep 2005 18:34:46 +0200 Subject: [LinuxBIOS] Re: topics for linuxbios summit In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4201E08A94@ssvlexmb2.amd.com> References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E08A94@ssvlexmb2.amd.com> Message-ID: <20050907163446.GA31491@openbios.org> * Lu, Yinghai [050907 17:51]: > Did you notice that our list can not searched by google now? Actually no. It works fine here.. For example: http://www.google.com/search?q=%22BIOS+Saver+RD1%22 Google indeed prefers .org over .de domains, but that is no problem since the nameserver entry is linuxbios.org not linuxbios.de. Regards, Stefan From petekarl at student.chalmers.se Wed Sep 7 19:30:08 2005 From: petekarl at student.chalmers.se (Peter Karlsson) Date: Wed, 7 Sep 2005 19:30:08 +0200 (MEST) Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-06/16 In-Reply-To: References: <4319D253.4080008@prodigi.ch> <431E12E4.9050009@prodigi.ch> Message-ID: On Tue, 6 Sep 2005, Eric W. Biederman wrote: > My impression is usually the SMP/Desktop work uses the same hardware as > the embedded systems but a couple of years sooner. There is also the challenge > that a lot of embedded systems are single shot deals many times embedded > developers don't have a long term interest in the free software project > they work with. So my impression is that in a 5 years or so we will start > seeing multi core embedded systems. http://www.embedded.com/showArticle.jhtml?articleID=169600382 Best regards Peter K From yinghai.lu at amd.com Wed Sep 7 20:11:44 2005 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Wed, 7 Sep 2005 11:11:44 -0700 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-14/16 Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06119@ssvlexmb2.amd.com> 8111 and 8131 only have 4 bit apic id. YH -----Original Message----- From: linuxbios-bounces at openbios.org [mailto:linuxbios-bounces at openbios.org] On Behalf Of ebiederman at lnxi.com Sent: Wednesday, September 07, 2005 8:40 AM To: yhlu Cc: linuxbios at openbios.org; Lu, Yinghai Subject: Re: [LinuxBIOS] LNXI Merge: lnxi-patch-14/16 yhlu writes: > at such case We need to enable 8 bit ext apic id mode for Opteron. So Opteron > could use 0x10 above. > and leave 0-0x0f to the device that can not support 8 bit apic id. > > I'm considering to align apic id lifting to the way that Norma BIOS does. Are io-apics limited to apic ids 0x0-0x0f as well? My memory says to me the limit should be 0x0-0xff... Eric -- LinuxBIOS mailing list LinuxBIOS at openbios.org http://www.openbios.org/mailman/listinfo/linuxbios From rminnich at lanl.gov Wed Sep 7 20:56:04 2005 From: rminnich at lanl.gov (Ronald G Minnich) Date: Wed, 07 Sep 2005 12:56:04 -0600 Subject: [LinuxBIOS] FYI on the linuxbios summit: Richard Bruner, AMD Fellow, will lead off Message-ID: <431F37C4.90606@lanl.gov> We're going to have the privelege of hearing from Richard Bruner of AMD for the first hour-long talk at the linuxbios summit. Hope to see you all there. ron From dbell at nxtv.com Wed Sep 7 20:59:04 2005 From: dbell at nxtv.com (Doug Bell) Date: Wed, 07 Sep 2005 11:59:04 -0700 Subject: [LinuxBIOS] serial debug messages workaround Message-ID: <1126119545.20753.5.camel@Doug> We're working on bringing up linuxbios on the epia-sp. We found the serial output is locking up strangely in a busy wait within src/pc80/serial.c: static void uart_tx_byte(unsigned char data) { uart_wait_to_tx_byte(); // this one causes trouble outb(data, TTYS0_BASE + UART_TBR); /* Make certain the data clears the fifos */ uart_wait_until_sent(); } If the uart_wait_to_tx_byte() call is removed, there is no lockup on serial output. The lockup on serial output always occurs in the same place, based on whatever would be printed. It's not random at all across reboots, however it is fairly random as regards code changes. That is, if you have a loop that prints stuff out, then try to print out some other stuff, somewhere along the line it will lock up during printing. Where it locks up is always the same place in the serial output stream, provided the code remains unchainged. The uart is inside the VT1211 superio device. Does anyone have any clue as to why this is locking up. As a workaround we've just commented out the uart_wait_to_tx_byte() for now, but that's nonstandard and might break other things. We are not yet checking in any code. Thanks for any advice/ideas. From yinghai.lu at amd.com Thu Sep 8 01:46:24 2005 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Wed, 7 Sep 2005 16:46:24 -0700 Subject: [LinuxBIOS] node id and core id in internal tree Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06122@ssvlexmb2.amd.com> Eric, It seems that cpu_path and cpu_bus_path in include/device/path.h are not used. So what do you prefer struct apic_path { unsigned apic_id; unsigned node id; unsigned core_id; } Or struct cpu_path { unsigned id; unsigned apic_id; unsigned node_id; unsigned core_id; } YH ________________________________ From: linuxbios-bounces at openbios.org [mailto:linuxbios-bounces at openbios.org] On Behalf Of Lu, Yinghai Sent: Wednesday, September 07, 2005 9:09 AM To: Stefan Reinauer; Eric W. Biederman; linuxbios at openbios.org Subject: RE: [LinuxBIOS] Re: topics for linuxbios summit eric> > Before we generate ACPI or anything else we need to move the relevant eric> > information eric> > into the internal device tree. eric> > YH: Good point, But I worry that we make LinuxBIOS more complicated. Stepan: No, the information has to be reorganized. Currently pirq and mptables Stepan: have to be hand crafted, and this is the complicated thing. Instead the Stepan: abstract information should be put to the configuration filess, if it Stepan: can not be probed. YH: I suggest to add 1. one node id to ram_resource, so the index will be (idx<<8 | nodeid), So I can re-use ram_resource in pci_domain for SRAT creating. 2. for apci_cluster_id, will add two fields core_id and node_id, ( instantiate it when cpu_init)... 3. pci device: add pci_irq_routing, and pci_possiable_resource ( for apci _PRT and _PRS...) how about ioapci in the internal tree? YH -------------- next part -------------- An HTML attachment was scrubbed... URL: From Narahari.Narasimhaiah at honeywell.com Thu Sep 8 17:02:49 2005 From: Narahari.Narasimhaiah at honeywell.com (Narahari, Narasimhaiah (IE10)) Date: Thu, 8 Sep 2005 08:02:49 -0700 Subject: [LinuxBIOS] VGA Message-ID: <77ED2BF75D59D1439F90412CC5B10974241F216D@ie10-sahara.hiso.honeywell.com> Hi everyone, I have a small question to ask, I am trying to boot windows 2000 on SC2200 Geode based board. I have downloaded Linuxbiosv1 from the cvs repository. And my doubt is, What are the requirements other than generating VGABIOS and TESTBIOS (i386 emulation) for bringing up VGA on Linuxbiosv1? With regards, narahari -------------- next part -------------- An HTML attachment was scrubbed... URL: From smithbone at gmail.com Thu Sep 8 17:32:40 2005 From: smithbone at gmail.com (Richard Smith) Date: Thu, 8 Sep 2005 10:32:40 -0500 Subject: [LinuxBIOS] VGA In-Reply-To: <77ED2BF75D59D1439F90412CC5B10974241F216D@ie10-sahara.hiso.honeywell.com> References: <77ED2BF75D59D1439F90412CC5B10974241F216D@ie10-sahara.hiso.honeywell.com> Message-ID: <8a0c367805090808327b32ed02@mail.gmail.com> On 9/8/05, Narahari, Narasimhaiah (IE10) wrote: > Hi everyone, > > I have a small question to ask, > I am trying to boot windows 2000 on SC2200 Geode based board. I have > downloaded Linuxbiosv1 from the cvs repository. And my doubt is, > > What are the requirements other than generating VGABIOS and TESTBIOS (i386 > emulation) for bringing up VGA on Linuxbiosv1? Lots. VGA is troublesome in V1. First off you have to decide what method you are going to use other than running testbios directly on the command line there are 2 more 1. You instruct linuxbios to attempt to switch to realmode call the bios and then return to normal. 2. You boot ADLO as a payload and let it run the VGABios. For option 1 you will have to search the mail archives. There are some options you have to enable. For option 2 you need to read the ADLO payload documentation on the wiki. -- Richard A. Smith From stepan at openbios.org Thu Sep 8 17:56:12 2005 From: stepan at openbios.org (Stefan Reinauer) Date: Thu, 8 Sep 2005 17:56:12 +0200 Subject: [LinuxBIOS] VGA In-Reply-To: <8a0c367805090808327b32ed02@mail.gmail.com> References: <77ED2BF75D59D1439F90412CC5B10974241F216D@ie10-sahara.hiso.honeywell.com> <8a0c367805090808327b32ed02@mail.gmail.com> Message-ID: <20050908155612.GA17944@openbios.org> * Richard Smith [050908 17:32]: > On 9/8/05, Narahari, Narasimhaiah (IE10) > wrote: > > I have a small question to ask, > > I am trying to boot windows 2000 on SC2200 Geode based board. I have > > downloaded Linuxbiosv1 from the cvs repository. And my doubt is, > > > > What are the requirements other than generating VGABIOS and TESTBIOS (i386 > > emulation) for bringing up VGA on Linuxbiosv1? > > Lots. VGA is troublesome in V1. [..] In addition you have to run the VSA code on geode systems to get VGA for Windows flavors. Stefan From steve at digidescorp.com Thu Sep 8 22:05:34 2005 From: steve at digidescorp.com (Steven J. Magnani) Date: Thu, 8 Sep 2005 15:05:34 -0500 Subject: [LinuxBIOS] PATCH: cygwin compilation of LinuxBIOS Message-ID: <000001c5b4b0$ac2ef710$6ffea8c0@banana> I'm starting to merge my source tree into the mainline. Ultimately this will include support for Intel's E7501 Xeon development kit, including the ICH3-S southbridge and the SMSC LPC47B272 Super I/O chips. Where my changes touch existing code, I'm sending out patches for review first. Constructive comments welcomed! One point about cygwin (cross-)compilation, for the record: both cmos.options and util/newconfig/config.g must be in UNIX (\n) format. The build fails if they are in DOS (\r\n) format. If you download the source with something like TortoiseSVN, text files arrive in DOS format and these particular files need to be run through dos2unix. --Steve PATCH: Modifications for building LinuxBIOS under cygwin. Remove unnecessary #include that prevents build_opt_tbl from cross-compiling with gcc 3.4.3. Add wildcards to 'clean' rules so executables ending in .exe get deleted. Added nrv2b to the list of files that are cleaned. --- util/options/build_opt_tbl.c.orig 2005-09-08 13:36:06.156250000 -0500 +++ util/options/build_opt_tbl.c 2005-09-08 14:17:28.875000000 -0500 @@ -1,6 +1,5 @@ #include #include -#include #include #include #include --- src/config/Config.lb.orig 2005-09-08 14:41:03.953125000 -0500 +++ src/config/Config.lb 2005-09-08 14:36:47.734375000 -0500 @@ -153,9 +153,9 @@ action "rm -f linuxbios" action "rm -f ldscript.ld" action "rm -f a.out *.s *.l *.o *.E *.inc" - action "rm -f TAGS tags romcc" - action "rm -f docipl buildrom chips.c *chip.c linuxbios_ram* linuxbios_pay*" - action "rm -f build_opt_tbl option_table.c crt0.S" + action "rm -f TAGS tags romcc*" + action "rm -f docipl buildrom* chips.c *chip.c linuxbios_ram* linuxbios_pay*" + action "rm -f build_opt_tbl* nrv2b* option_table.c crt0.S" end # do standard config files that the user need not specify From steve at digidescorp.com Thu Sep 8 22:12:37 2005 From: steve at digidescorp.com (Steven J. Magnani) Date: Thu, 8 Sep 2005 15:12:37 -0500 Subject: [LinuxBIOS] RE: CMOS options questions Message-ID: <000101c5b4b1$abb11f10$6ffea8c0@banana> See http://openbios.org/pipermail/linuxbios/2005-August/012255.html for an explanation of the issue that spawned this patch. I've run out of time for a complete solution, so as a compromise I propose a patch that prevents LB from modifying CMOS when HAVE_OPTION_TABLE = 0: PATCH: Don't write to CMOS when HAVE_OPTION_TABLE = 0. This allows single-image (normal) LinuxBIOS to co-exist with factory BIOSs whose CMOS usage is incompatible (i.e. Intel XE7501DevKit). --- src/pc80/mc146818rtc.c.orig 2005-09-08 13:35:36.312500000 -0500 +++ src/pc80/mc146818rtc.c 2005-09-08 14:10:06.187500000 -0500 @@ -127,6 +127,8 @@ int cmos_invalid, checksum_invalid; printk_debug("RTC Init\n"); + +#if HAVE_OPTION_TABLE /* See if there has been a CMOS power problem. */ x = CMOS_READ(RTC_VALID); cmos_invalid = !(x & RTC_VRT); @@ -160,19 +162,25 @@ } #endif } +#endif + + /* Setup the real time clock */ + CMOS_WRITE(RTC_CONTROL_DEFAULT, RTC_CONTROL); + /* Setup the frequency it operates at */ + CMOS_WRITE(RTC_FREQ_SELECT_DEFAULT, RTC_FREQ_SELECT); + +#if HAVE_OPTION_TABLE /* See if there is a LB CMOS checksum error */ checksum_invalid = !rtc_checksum_valid(LB_CKS_RANGE_START, LB_CKS_RANGE_END,LB_CKS_LOC); if(checksum_invalid) printk_debug("Invalid CMOS LB checksum\n"); - /* Setup the real time clock */ - CMOS_WRITE(RTC_CONTROL_DEFAULT, RTC_CONTROL); - /* Setup the frequency it operates at */ - CMOS_WRITE(RTC_FREQ_SELECT_DEFAULT, RTC_FREQ_SELECT); /* Make certain we have a valid checksum */ rtc_set_checksum(PC_CKS_RANGE_START, PC_CKS_RANGE_END,PC_CKS_LOC); +#endif + /* Clear any pending interrupts */ (void) CMOS_READ(RTC_INTR_FLAGS); } ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!" #include From steve at digidescorp.com Thu Sep 8 22:15:59 2005 From: steve at digidescorp.com (Steven J. Magnani) Date: Thu, 8 Sep 2005 15:15:59 -0500 Subject: [LinuxBIOS] PATCH: correct arguments to pnp_set_drq Message-ID: <000201c5b4b2$245ab570$6ffea8c0@banana> This patch corrects an apparent bug in the definition of pnp_set_drq(). See http://openbios.org/pipermail/linuxbios/2005-May/011605.html for a description of the issue. PATCH: BUG FIX: arguments to pnp_set_drq are transposed --- src/devices/pnp_device.c.orig 2005-09-08 13:34:52.859375000 -0500 +++ src/devices/pnp_device.c 2005-09-08 13:40:16.671875000 -0500 @@ -52,7 +52,7 @@ pnp_write_config(dev, index, irq); } -void pnp_set_drq(device_t dev, unsigned drq, unsigned index) +void pnp_set_drq(device_t dev, unsigned index, unsigned drq) { /* Index == 0x74 */ pnp_write_config(dev, index, drq & 0xff); ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!" #include From yinghai.lu at amd.com Thu Sep 8 22:40:37 2005 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Thu, 8 Sep 2005 13:40:37 -0700 Subject: [LinuxBIOS] PATCH: correct arguments to pnp_set_drq Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06128@ssvlexmb2.amd.com> Good, maybe this is reason why floppy have problem in Kernel.... YH -----Original Message----- From: linuxbios-bounces at openbios.org [mailto:linuxbios-bounces at openbios.org] On Behalf Of Steven J. Magnani Sent: Thursday, September 08, 2005 1:16 PM To: linuxbios at openbios.org Subject: [LinuxBIOS] PATCH: correct arguments to pnp_set_drq This patch corrects an apparent bug in the definition of pnp_set_drq(). See http://openbios.org/pipermail/linuxbios/2005-May/011605.html for a description of the issue. PATCH: BUG FIX: arguments to pnp_set_drq are transposed --- src/devices/pnp_device.c.orig 2005-09-08 13:34:52.859375000 -0500 +++ src/devices/pnp_device.c 2005-09-08 13:40:16.671875000 -0500 @@ -52,7 +52,7 @@ pnp_write_config(dev, index, irq); } -void pnp_set_drq(device_t dev, unsigned drq, unsigned index) +void pnp_set_drq(device_t dev, unsigned index, unsigned drq) { /* Index == 0x74 */ pnp_write_config(dev, index, drq & 0xff); ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!" #include -- LinuxBIOS mailing list LinuxBIOS at openbios.org http://www.openbios.org/mailman/listinfo/linuxbios From steve at digidescorp.com Fri Sep 9 16:50:07 2005 From: steve at digidescorp.com (Steven J. Magnani) Date: Fri, 9 Sep 2005 09:50:07 -0500 Subject: [LinuxBIOS] PATCH: nested spinlock hang when initializing x86 sibling CPUs Message-ID: <000a01c5b54d$c59df5a0$6ffea8c0@banana> This patch resolves the issue identified in http://openbios.org/pipermail/linuxbios/2005-July/011903.html. Changes: * Remove spinlock bracketing of cpu_initialize() call * Drop SERIAL_CPU_INIT option * (Unrelated) Attempt more descriptive comments for various config options PATCH: --- src/cpu/x86/lapic/lapic_cpu_init.c.orig 2005-09-09 09:29:25.156250000 -0500 +++ src/cpu/x86/lapic/lapic_cpu_init.c 2005-09-09 09:31:59.109375000 -0500 @@ -230,17 +230,16 @@ void secondary_cpu_init(void) { atomic_inc(&active_cpus); -#if SERIAL_CPU_INIT == 1 - #if CONFIG_MAX_CPUS>2 - spin_lock(&start_cpu_lock); - #endif -#endif + + // NOTE: The call to cpu_initialize() used to be bracketed by + // calls to lock and unlock the start_cpu_lock spin lock. + // These were removed to resolve a hang due to nested spin locking + // when secondary CPUs go to initialize their siblings. + // See http://openbios.org/pipermail/linuxbios/2005-July/011903.html. + // It's possible that some other form of concurrency control + // is needed at this level. cpu_initialize(); -#if SERIAL_CPU_INIT == 1 - #if CONFIG_MAX_CPUS>2 - spin_unlock(&start_cpu_lock); - #endif -#endif + atomic_dec(&active_cpus); stop_this_cpu(); } @@ -265,11 +264,9 @@ printk_err("CPU %u would not start!\n", cpu->path.u.apic.apic_id); } -#if SERIAL_CPU_INIT == 1 #if CONFIG_MAX_CPUS>2 udelay(10); #endif -#endif } /* Now loop until the other cpus have finished initializing */ --- src/config/Options.lb.orig 2005-09-09 09:36:27.562500000 -0500 +++ src/config/Options.lb 2005-09-09 09:35:17.125000000 -0500 @@ -188,37 +188,37 @@ default 65536 format "0x%x" export used - comment "Default fallback image size" + comment "ROM_SECTION_SIZE to use for the fallback build." end define ROM_SIZE default none format "0x%x" export used - comment "Size of your ROM" + comment "Total number of bytes allocated for normal and fallback LinuxBIOS images and payloads. Note that the fallback image goes at the end of the ROM, and the normal image at the beginning." end define ROM_IMAGE_SIZE default 65535 format "0x%x" export always - comment "Default image size" + comment "Maximum number of bytes allowed for a LinuxBIOS image. Does not include the payload." end define ROM_SECTION_SIZE default {FALLBACK_SIZE} format "0x%x" export used - comment "Default rom section size" + comment "Default rom section size. Normally, this is calculated in mainboard Config.lb and varies between the normal and fallback builds." end define ROM_SECTION_OFFSET default {ROM_SIZE - FALLBACK_SIZE} format "0x%x" export used - comment "Default rom section offset" + comment "Number of bytes from the beginning of the ROM to the start of the section containing this build (normal or fallback). Normally, this is calculated in mainboard Config.lb." end define PAYLOAD_SIZE default {ROM_SECTION_SIZE - ROM_IMAGE_SIZE} format "0x%x" export always - comment "Default payload size" + comment "Maximum number of bytes allowed for a payload. Normally, this is calculated as above." end define _ROMBASE default {PAYLOAD_SIZE} @@ -479,7 +479,7 @@ export used comment "System clock frequency in MHz" end - + ############################################### # SMP options ############################################### @@ -509,11 +509,6 @@ export used comment "Define to build an MP table" end -define SERIAL_CPU_INIT - default 1 - export always - comment "Serialize CPU init" -end ############################################### # Boot options @@ -533,7 +528,7 @@ default {0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1} format "0x%x" export always - comment "ROM stream start location" + comment "Memory address of this (normal or fallback) build's payload in ROM. Normally, this is calculated as above." end define CONFIG_FS_STREAM default 0 --- src/mainboard/tyan/s2735/Options.lb.orig 2005-09-08 13:35:22.453125000 -0500 +++ src/mainboard/tyan/s2735/Options.lb 2005-09-09 09:21:21.531250000 -0500 @@ -8,7 +8,6 @@ uses CONFIG_MAX_CPUS uses CONFIG_MAX_PHYSICAL_CPUS uses CONFIG_LOGICAL_CPUS -uses SERIAL_CPU_INIT uses CONFIG_IOAPIC uses CONFIG_SMP uses FALLBACK_SIZE @@ -127,8 +126,6 @@ default CONFIG_MAX_PHYSICAL_CPUS=2 default CONFIG_LOGICAL_CPUS=1 -default SERIAL_CPU_INIT=0 - #BTEXT Console #default CONFIG_CONSOLE_BTEXT=1 ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!" #include From steve at digidescorp.com Fri Sep 9 16:57:04 2005 From: steve at digidescorp.com (Steven J. Magnani) Date: Fri, 9 Sep 2005 09:57:04 -0500 Subject: [LinuxBIOS] PATCH: relocate GDT before invoking payload Message-ID: <000b01c5b54e$c1239ba0$6ffea8c0@banana> I posted this patch previously; see http://openbios.org/pipermail/linuxbios/2005-August/012063.html for the original issue. Here's another chance to comment before I commit it. PATCH: --- src/arch/i386/boot/tables.c.orig 2005-09-08 13:35:39.125000000 -0500 +++ src/arch/i386/boot/tables.c 2005-08-16 16:17:41.766000000 -0500 @@ -7,6 +7,32 @@ #include #include "linuxbios_table.h" +// Global Descriptor Table, defined in c_start.S +extern uint8_t gdt; +extern uint8_t gdt_end; + +/* i386 lgdt argument */ +struct gdtarg { + unsigned short limit; + unsigned int base; +} __attribute__((packed)); + +// Copy GDT to new location and reload it +// 2003-07 by SONE Takeshi +// Ported from Etherboot to LinuxBIOS 2005-08 by Steve Magnani +void move_gdt(unsigned long newgdt) +{ + uint16_t num_gdt_bytes = &gdt_end - &gdt; + struct gdtarg gdtarg; + + printk_debug("Moving GDT to %#lx...", newgdt); + memcpy((void*)newgdt, &gdt, num_gdt_bytes); + gdtarg.base = newgdt; + gdtarg.limit = num_gdt_bytes - 1; + __asm__ __volatile__ ("lgdt %0\n\t" : : "m" (gdtarg)); + printk_debug("ok\n"); +} + struct lb_memory *write_tables(void) { unsigned long low_table_start, low_table_end; @@ -45,6 +71,10 @@ low_table_end = 0x500; } + // Relocate the GDT to reserved memory, so it won't get clobbered + move_gdt(low_table_end); + low_table_end += &gdt_end - &gdt; + /* The linuxbios table must be in 0-4K or 960K-1M */ write_linuxbios_table( low_table_start, low_table_end, ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!" #include From smithbone at gmail.com Fri Sep 9 17:30:54 2005 From: smithbone at gmail.com (Richard Smith) Date: Fri, 9 Sep 2005 10:30:54 -0500 Subject: [LinuxBIOS] PATCH: nested spinlock hang when initializing x86 sibling CPUs In-Reply-To: <000a01c5b54d$c59df5a0$6ffea8c0@banana> References: <000a01c5b54d$c59df5a0$6ffea8c0@banana> Message-ID: <8a0c3678050909083011249be2@mail.gmail.com> On 9/9/05, Steven J. Magnani wrote: > This patch resolves the issue identified in > http://openbios.org/pipermail/linuxbios/2005-July/011903.html. Does LinuxBIOS need a bug tracker? That might make references like this a little easier rather than haveing to prowl through the mailing archive for the right thread. -- Richard A. Smith From yinghailu at gmail.com Fri Sep 9 18:00:42 2005 From: yinghailu at gmail.com (yhlu) Date: Fri, 9 Sep 2005 09:00:42 -0700 Subject: [LinuxBIOS] PATCH: nested spinlock hang when initializing x86 sibling CPUs In-Reply-To: <000a01c5b54d$c59df5a0$6ffea8c0@banana> References: <000a01c5b54d$c59df5a0$6ffea8c0@banana> Message-ID: <2ea3fae105090909005bd753c4@mail.gmail.com> You need to keep SERIAL_CPU_INIT. reason is for AMD K8 cpu_init regarding init_ecc there maybe some conflict on console. You can disable it by set it to 0. YH On 9/9/05, Steven J. Magnani wrote: > > This patch resolves the issue identified in > http://openbios.org/pipermail/linuxbios/2005-July/011903.html. > > Changes: > * Remove spinlock bracketing of cpu_initialize() call > * Drop SERIAL_CPU_INIT option > * (Unrelated) Attempt more descriptive comments for various config > options > > PATCH: > > --- src/cpu/x86/lapic/lapic_cpu_init.c.orig 2005-09-09 > 09:29:25.156250000 -0500 > +++ src/cpu/x86/lapic/lapic_cpu_init.c 2005-09-09 09:31:59.109375000 > -0500 > @@ -230,17 +230,16 @@ > void secondary_cpu_init(void) > { > atomic_inc(&active_cpus); > -#if SERIAL_CPU_INIT == 1 > - #if CONFIG_MAX_CPUS>2 > - spin_lock(&start_cpu_lock); > - #endif > -#endif > + > + // NOTE: The call to cpu_initialize() used to be bracketed by > + // calls to lock and unlock the start_cpu_lock spin lock. > + // These were removed to resolve a hang due to nested spin > locking > + // when secondary CPUs go to initialize their siblings. > + // See > http://openbios.org/pipermail/linuxbios/2005-July/011903.html. > + // It's possible that some other form of concurrency > control > + // is needed at this level. > cpu_initialize(); > -#if SERIAL_CPU_INIT == 1 > - #if CONFIG_MAX_CPUS>2 > - spin_unlock(&start_cpu_lock); > - #endif > -#endif > + > atomic_dec(&active_cpus); > stop_this_cpu(); > } > @@ -265,11 +264,9 @@ > printk_err("CPU %u would not start!\n", > cpu->path.u.apic.apic_id); > } > -#if SERIAL_CPU_INIT == 1 > #if CONFIG_MAX_CPUS>2 > udelay(10); > #endif > -#endif > } > > /* Now loop until the other cpus have finished initializing */ > --- src/config/Options.lb.orig 2005-09-09 09:36:27.562500000 -0500 > +++ src/config/Options.lb 2005-09-09 09:35:17.125000000 -0500 > @@ -188,37 +188,37 @@ > default 65536 > format "0x%x" > export used > - comment "Default fallback image size" > + comment "ROM_SECTION_SIZE to use for the fallback build." > end > define ROM_SIZE > default none > format "0x%x" > export used > - comment "Size of your ROM" > + comment "Total number of bytes allocated for normal and fallback > LinuxBIOS images and payloads. Note that the fallback image goes at the > end of the ROM, and the normal image at the beginning." > end > define ROM_IMAGE_SIZE > default 65535 > format "0x%x" > export always > - comment "Default image size" > + comment "Maximum number of bytes allowed for a LinuxBIOS image. > Does not include the payload." > end > define ROM_SECTION_SIZE > default {FALLBACK_SIZE} > format "0x%x" > export used > - comment "Default rom section size" > + comment "Default rom section size. Normally, this is calculated > in mainboard Config.lb and varies between the normal > and fallback > builds." > end > define ROM_SECTION_OFFSET > default {ROM_SIZE - FALLBACK_SIZE} > format "0x%x" > export used > - comment "Default rom section offset" > + comment "Number of bytes from the beginning of the ROM to the > start of the section containing this build (normal or fallback). > Normally, this is calculated in mainboard Config.lb ." > end > define PAYLOAD_SIZE > default {ROM_SECTION_SIZE - ROM_IMAGE_SIZE} > format "0x%x" > export always > - comment "Default payload size" > + comment "Maximum number of bytes allowed for a payload. > Normally, this is calculated as above." > end > define _ROMBASE > default {PAYLOAD_SIZE} > @@ -479,7 +479,7 @@ > export used > comment "System clock frequency in MHz" > end > - > + > ############################################### > # SMP options > ############################################### > @@ -509,11 +509,6 @@ > export used > comment "Define to build an MP table" > end > -define SERIAL_CPU_INIT > - default 1 > - export always > - comment "Serialize CPU init" > -end > > ############################################### > # Boot options > @@ -533,7 +528,7 @@ > default {0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1} > format "0x%x" > export always > - comment "ROM stream start location" > + comment "Memory address of this (normal or fallback) build's > payload in ROM. Normally, this is calculated as above." > end > define CONFIG_FS_STREAM > default 0 > > > --- src/mainboard/tyan/s2735/Options.lb.orig 2005-09-08 > 13:35:22.453125000 -0500 > +++ src/mainboard/tyan/s2735/Options.lb 2005-09-09 09:21:21.531250000 > -0500 > @@ -8,7 +8,6 @@ > uses CONFIG_MAX_CPUS > uses CONFIG_MAX_PHYSICAL_CPUS > uses CONFIG_LOGICAL_CPUS > -uses SERIAL_CPU_INIT > uses CONFIG_IOAPIC > uses CONFIG_SMP > uses FALLBACK_SIZE > @@ -127,8 +126,6 @@ > default CONFIG_MAX_PHYSICAL_CPUS=2 > default CONFIG_LOGICAL_CPUS=1 > > -default SERIAL_CPU_INIT=0 > - > #BTEXT Console > #default CONFIG_CONSOLE_BTEXT=1 > > ------------------------------------------------------------------------ > Steven J. Magnani "I claim this network for MARS! > www.digidescorp.com Earthling, return my > space modulator!" > > #include > > > > > > > -- > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yinghailu at gmail.com Fri Sep 9 18:03:17 2005 From: yinghailu at gmail.com (yhlu) Date: Fri, 9 Sep 2005 09:03:17 -0700 Subject: [LinuxBIOS] PATCH: relocate GDT before invoking payload In-Reply-To: <000b01c5b54e$c1239ba0$6ffea8c0@banana> References: <000b01c5b54e$c1239ba0$6ffea8c0@banana> Message-ID: <2ea3fae105090909037de51de8@mail.gmail.com> why? The payload will have its own GDT. YH On 9/9/05, Steven J. Magnani wrote: > > I posted this patch previously; see > http://openbios.org/pipermail/linuxbios/2005-August/012063.html for the > original issue. > > Here's another chance to comment before I commit it. > > PATCH: > > --- src/arch/i386/boot/tables.c.orig 2005-09-08 13:35:39.125000000 > -0500 > +++ src/arch/i386/boot/tables.c 2005-08-16 16:17:41.766000000 -0500 > @@ -7,6 +7,32 @@ > #include > #include "linuxbios_table.h" > > +// Global Descriptor Table, defined in c_start.S > +extern uint8_t gdt; > +extern uint8_t gdt_end; > + > +/* i386 lgdt argument */ > +struct gdtarg { > + unsigned short limit; > + unsigned int base; > +} __attribute__((packed)); > + > +// Copy GDT to new location and reload it > +// 2003-07 by SONE Takeshi > +// Ported from Etherboot to LinuxBIOS 2005-08 by Steve Magnani > +void move_gdt(unsigned long newgdt) > +{ > + uint16_t num_gdt_bytes = &gdt_end - &gdt; > + struct gdtarg gdtarg; > + > + printk_debug("Moving GDT to %#lx...", newgdt); > + memcpy((void*)newgdt, &gdt, num_gdt_bytes); > + gdtarg.base = newgdt; > + gdtarg.limit = num_gdt_bytes - 1; > + __asm__ __volatile__ ("lgdt %0\n\t" : : "m" (gdtarg)); > + printk_debug("ok\n"); > +} > + > struct lb_memory *write_tables(void) > { > unsigned long low_table_start, low_table_end; > @@ -45,6 +71,10 @@ > low_table_end = 0x500; > } > > + // Relocate the GDT to reserved memory, so it won't get > clobbered > + move_gdt(low_table_end); > + low_table_end += &gdt_end - &gdt; > + > /* The linuxbios table must be in 0-4K or 960K-1M */ > write_linuxbios_table( > low_table_start, low_table_end, > > ------------------------------------------------------------------------ > Steven J. Magnani "I claim this network for MARS! > www.digidescorp.com Earthling, return my > space modulator!" > > #include > > > > > -- > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at digidescorp.com Fri Sep 9 18:34:56 2005 From: steve at digidescorp.com (Steven J. Magnani) Date: Fri, 9 Sep 2005 11:34:56 -0500 Subject: [LinuxBIOS] PATCH: relocate GDT before invoking payload In-Reply-To: <2ea3fae105090909037de51de8@mail.gmail.com> Message-ID: <001801c5b55c$6d0ca0d0$6ffea8c0@banana> QNX Neutrino doesn't set up its own GDT right away. Its startup code has some defensive logic that attempts to put the system into a known state. This causes an exception when booted from LinuxBIOS, if its GDT got trashed when elfboot() loaded the Neutrino image. See the hyperlink below for more discussion. The fix seems straightforward, and the increased amount of "table" memory very modest. Do you object to this patch? Steve -----Original Message----- From: yhlu [mailto:yinghailu at gmail.com] Sent: Friday, September 09, 2005 10:03 AM To: Steven J. Magnani Cc: linuxbios at openbios.org Subject: Re: [LinuxBIOS] PATCH: relocate GDT before invoking payload why? The payload will have its own GDT. YH On 9/9/05, Steven J. Magnani wrote: I posted this patch previously; see http://openbios.org/pipermail/linuxbios/2005-August/012063.html for the original issue. Here's another chance to comment before I commit it. PATCH: --- src/arch/i386/boot/tables.c.orig 2005-09-08 13:35:39.125000000 -0500 +++ src/arch/i386/boot/tables.c 2005-08-16 16:17:41.766000000 -0500 @@ -7,6 +7,32 @@ #include #include "linuxbios_table.h" +// Global Descriptor Table, defined in c_start.S +extern uint8_t gdt; +extern uint8_t gdt_end; + +/* i386 lgdt argument */ +struct gdtarg { + unsigned short limit; + unsigned int base; +} __attribute__((packed)); + +// Copy GDT to new location and reload it +// 2003-07 by SONE Takeshi +// Ported from Etherboot to LinuxBIOS 2005-08 by Steve Magnani +void move_gdt(unsigned long newgdt) +{ + uint16_t num_gdt_bytes = &gdt_end - &gdt; + struct gdtarg gdtarg; + + printk_debug("Moving GDT to %#lx...", newgdt); + memcpy((void*)newgdt, &gdt, num_gdt_bytes); + gdtarg.base = newgdt; + gdtarg.limit = num_gdt_bytes - 1; + __asm__ __volatile__ ("lgdt %0\n\t" : : "m" (gdtarg)); + printk_debug("ok\n"); +} + struct lb_memory *write_tables(void) { unsigned long low_table_start, low_table_end; @@ -45,6 +71,10 @@ low_table_end = 0x500; } + // Relocate the GDT to reserved memory, so it won't get clobbered + move_gdt(low_table_end); + low_table_end += &gdt_end - &gdt; + /* The linuxbios table must be in 0-4K or 960K-1M */ write_linuxbios_table( low_table_start, low_table_end, ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!" #include -- LinuxBIOS mailing list LinuxBIOS at openbios.org http://www.openbios.org/mailman/listinfo/linuxbios -------------- next part -------------- An HTML attachment was scrubbed... URL: From yinghai.lu at amd.com Fri Sep 9 18:49:36 2005 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Fri, 9 Sep 2005 09:49:36 -0700 Subject: [LinuxBIOS] PATCH: relocate GDT before invoking payload Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0612D@ssvlexmb2.amd.com> I'm ok with this patch. YH ________________________________ From: linuxbios-bounces at openbios.org [mailto:linuxbios-bounces at openbios.org] On Behalf Of Steven J. Magnani Sent: Friday, September 09, 2005 9:35 AM To: yinghailu at gmail.com Cc: linuxbios at openbios.org Subject: RE: [LinuxBIOS] PATCH: relocate GDT before invoking payload QNX Neutrino doesn't set up its own GDT right away. Its startup code has some defensive logic that attempts to put the system into a known state. This causes an exception when booted from LinuxBIOS, if its GDT got trashed when elfboot() loaded the Neutrino image. See the hyperlink below for more discussion. The fix seems straightforward, and the increased amount of "table" memory very modest. Do you object to this patch? Steve -----Original Message----- From: yhlu [mailto:yinghailu at gmail.com] Sent: Friday, September 09, 2005 10:03 AM To: Steven J. Magnani Cc: linuxbios at openbios.org Subject: Re: [LinuxBIOS] PATCH: relocate GDT before invoking payload why? The payload will have its own GDT. YH On 9/9/05, Steven J. Magnani wrote: I posted this patch previously; see http://openbios.org/pipermail/linuxbios/2005-August/012063.html for the original issue. Here's another chance to comment before I commit it. PATCH: --- src/arch/i386/boot/tables.c.orig 2005-09-08 13:35:39.125000000 -0500 +++ src/arch/i386/boot/tables.c 2005-08-16 16:17:41.766000000 -0500 @@ -7,6 +7,32 @@ #include #include "linuxbios_table.h" +// Global Descriptor Table, defined in c_start.S +extern uint8_t gdt; +extern uint8_t gdt_end; + +/* i386 lgdt argument */ +struct gdtarg { + unsigned short limit; + unsigned int base; +} __attribute__((packed)); + +// Copy GDT to new location and reload it +// 2003-07 by SONE Takeshi +// Ported from Etherboot to LinuxBIOS 2005-08 by Steve Magnani +void move_gdt(unsigned long newgdt) +{ + uint16_t num_gdt_bytes = &gdt_end - &gdt; + struct gdtarg gdtarg; + + printk_debug("Moving GDT to %#lx...", newgdt); + memcpy((void*)newgdt, &gdt, num_gdt_bytes); + gdtarg.base = newgdt; + gdtarg.limit = num_gdt_bytes - 1; + __asm__ __volatile__ ("lgdt %0\n\t" : : "m" (gdtarg)); + printk_debug("ok\n"); +} + struct lb_memory *write_tables(void) { unsigned long low_table_start, low_table_end; @@ -45,6 +71,10 @@ low_table_end = 0x500; } + // Relocate the GDT to reserved memory, so it won't get clobbered + move_gdt(low_table_end); + low_table_end += &gdt_end - &gdt; + /* The linuxbios table must be in 0-4K or 960K-1M */ write_linuxbios_table( low_table_start, low_table_end, ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!" #include -- LinuxBIOS mailing list LinuxBIOS at openbios.org http://www.openbios.org/mailman/listinfo/linuxbios -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at digidescorp.com Fri Sep 9 18:51:10 2005 From: steve at digidescorp.com (Steven J. Magnani) Date: Fri, 9 Sep 2005 11:51:10 -0500 Subject: [LinuxBIOS] PATCH: nested spinlock hang when initializing x86 sibling CPUs In-Reply-To: <2ea3fae105090909005bd753c4@mail.gmail.com> Message-ID: <001d01c5b55e$ae223d80$6ffea8c0@banana> Based on the mainboard config files I see, it looks like the only purpose of SERIAL_CPU_INIT is to work around the nested spinlock issue with Intel hyperthreaded CPUs. I don't think this is the best solution to the problem. To me, 'SERIAL_CPU_INIT' implies a free choice - I can choose whether my CPUs are initialized serially or concurrently, and either choice is acceptable. But that's not the way it works; making the wrong choice on Intel systems causes the system to hang. I think a better solution will do away with SERIAL_CPU_INIT, but might keep the spinlock bracket around cpu_initialize(). The question is how to reconcile the differences between AMD and Intel SMP startup. Can you provide any suggestions from the AMD viewpoint? Steve -----Original Message----- From: yhlu [mailto:yinghailu at gmail.com] Sent: Friday, September 09, 2005 10:01 AM To: Steven J. Magnani Cc: linuxbios at openbios.org Subject: Re: [LinuxBIOS] PATCH: nested spinlock hang when initializing x86 sibling CPUs You need to keep SERIAL_CPU_INIT. reason is for AMD K8 cpu_init regarding init_ecc there maybe some conflict on console. You can disable it by set it to 0. YH On 9/9/05, Steven J. Magnani wrote: This patch resolves the issue identified in http://openbios.org/pipermail/linuxbios/2005-July/011903.html. Changes: * Remove spinlock bracketing of cpu_initialize() call * Drop SERIAL_CPU_INIT option * (Unrelated) Attempt more descriptive comments for various config options PATCH: --- src/cpu/x86/lapic/lapic_cpu_init.c.orig 2005-09-09 09:29:25.156250000 -0500 +++ src/cpu/x86/lapic/lapic_cpu_init.c 2005-09-09 09:31:59.109375000 -0500 @@ -230,17 +230,16 @@ void secondary_cpu_init(void) { atomic_inc(&active_cpus); -#if SERIAL_CPU_INIT == 1 - #if CONFIG_MAX_CPUS>2 - spin_lock(&start_cpu_lock); - #endif -#endif + + // NOTE: The call to cpu_initialize() used to be bracketed by + // calls to lock and unlock the start_cpu_lock spin lock. + // These were removed to resolve a hang due to nested spin locking + // when secondary CPUs go to initialize their siblings. + // See http://openbios.org/pipermail/linuxbios/2005-July/011903.html. + // It's possible that some other form of concurrency control + // is needed at this level. cpu_initialize(); -#if SERIAL_CPU_INIT == 1 - #if CONFIG_MAX_CPUS>2 - spin_unlock(&start_cpu_lock); - #endif -#endif + atomic_dec(&active_cpus); stop_this_cpu(); } @@ -265,11 +264,9 @@ printk_err("CPU %u would not start!\n", cpu->path.u.apic.apic_id); } -#if SERIAL_CPU_INIT == 1 #if CONFIG_MAX_CPUS>2 udelay(10); #endif -#endif } /* Now loop until the other cpus have finished initializing */ --- src/config/Options.lb.orig 2005-09-09 09:36:27.562500000 -0500 +++ src/config/Options.lb 2005-09-09 09:35:17.125000000 -0500 @@ -188,37 +188,37 @@ default 65536 format "0x%x" export used - comment "Default fallback image size" + comment "ROM_SECTION_SIZE to use for the fallback build." end define ROM_SIZE default none format "0x%x" export used - comment "Size of your ROM" + comment "Total number of bytes allocated for normal and fallback LinuxBIOS images and payloads. Note that the fallback image goes at the end of the ROM, and the normal image at the beginning." end define ROM_IMAGE_SIZE default 65535 format "0x%x" export always - comment "Default image size" + comment "Maximum number of bytes allowed for a LinuxBIOS image. Does not include the payload." end define ROM_SECTION_SIZE default {FALLBACK_SIZE} format "0x%x" export used - comment "Default rom section size" + comment "Default rom section size. Normally, this is calculated in mainboard Config.lb and varies between the normal and fallback builds." end define ROM_SECTION_OFFSET default {ROM_SIZE - FALLBACK_SIZE} format "0x%x" export used - comment "Default rom section offset" + comment "Number of bytes from the beginning of the ROM to the start of the section containing this build (normal or fallback). Normally, this is calculated in mainboard Config.lb." end define PAYLOAD_SIZE default {ROM_SECTION_SIZE - ROM_IMAGE_SIZE} format "0x%x" export always - comment "Default payload size" + comment "Maximum number of bytes allowed for a payload. Normally, this is calculated as above." end define _ROMBASE default {PAYLOAD_SIZE} @@ -479,7 +479,7 @@ export used comment "System clock frequency in MHz" end - + ############################################### # SMP options ############################################### @@ -509,11 +509,6 @@ export used comment "Define to build an MP table" end -define SERIAL_CPU_INIT - default 1 - export always - comment "Serialize CPU init" -end ############################################### # Boot options @@ -533,7 +528,7 @@ default {0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1} format "0x%x" export always - comment "ROM stream start location" + comment "Memory address of this (normal or fallback) build's payload in ROM. Normally, this is calculated as above." end define CONFIG_FS_STREAM default 0 --- src/mainboard/tyan/s2735/Options.lb.orig 2005-09-08 13:35:22.453125000 -0500 +++ src/mainboard/tyan/s2735/Options.lb 2005-09-09 09:21:21.531250000 -0500 @@ -8,7 +8,6 @@ uses CONFIG_MAX_CPUS uses CONFIG_MAX_PHYSICAL_CPUS uses CONFIG_LOGICAL_CPUS -uses SERIAL_CPU_INIT uses CONFIG_IOAPIC uses CONFIG_SMP uses FALLBACK_SIZE @@ -127,8 +126,6 @@ default CONFIG_MAX_PHYSICAL_CPUS=2 default CONFIG_LOGICAL_CPUS=1 -default SERIAL_CPU_INIT=0 - #BTEXT Console #default CONFIG_CONSOLE_BTEXT=1 ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!" #include -- LinuxBIOS mailing list LinuxBIOS at openbios.org http://www.openbios.org/mailman/listinfo/linuxbios -------------- next part -------------- An HTML attachment was scrubbed... URL: From yinghai.lu at amd.com Fri Sep 9 19:09:16 2005 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Fri, 9 Sep 2005 10:09:16 -0700 Subject: [LinuxBIOS] PATCH: nested spinlock hang when initializing x86 sibling CPUs Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0612E@ssvlexmb2.amd.com> This has nothing to do with AMD or intel. For AMD four ways single core system, or two way dual core system. If you need to set SERIAL_CPU_INIT = 0 , you may need to set loglevel to 7 instead of 8. For 8 ways Opteron system, if you set SERIAL_CPU_INIT=0, the mem on node1-node7, will be init_ecc at the same time to reduce init time from 7x to 1.1x. If intel has NUMA support, there will be the same. But if you need debug info or better output message format, you need to set SERIAL_CPU_INIT = 1. YH ________________________________ From: linuxbios-bounces at openbios.org [mailto:linuxbios-bounces at openbios.org] On Behalf Of Steven J. Magnani Sent: Friday, September 09, 2005 9:51 AM To: yinghailu at gmail.com Cc: linuxbios at openbios.org Subject: RE: [LinuxBIOS] PATCH: nested spinlock hang when initializing x86 sibling CPUs Based on the mainboard config files I see, it looks like the only purpose of SERIAL_CPU_INIT is to work around the nested spinlock issue with Intel hyperthreaded CPUs. I don't think this is the best solution to the problem. To me, 'SERIAL_CPU_INIT' implies a free choice - I can choose whether my CPUs are initialized serially or concurrently, and either choice is acceptable. But that's not the way it works; making the wrong choice on Intel systems causes the system to hang. I think a better solution will do away with SERIAL_CPU_INIT, but might keep the spinlock bracket around cpu_initialize(). The question is how to reconcile the differences between AMD and Intel SMP startup. Can you provide any suggestions from the AMD viewpoint? Steve -----Original Message----- From: yhlu [mailto:yinghailu at gmail.com] Sent: Friday, September 09, 2005 10:01 AM To: Steven J. Magnani Cc: linuxbios at openbios.org Subject: Re: [LinuxBIOS] PATCH: nested spinlock hang when initializing x86 sibling CPUs You need to keep SERIAL_CPU_INIT. reason is for AMD K8 cpu_init regarding init_ecc there maybe some conflict on console. You can disable it by set it to 0. YH On 9/9/05, Steven J. Magnani wrote: This patch resolves the issue identified in http://openbios.org/pipermail/linuxbios/2005-July/011903.html. Changes: * Remove spinlock bracketing of cpu_initialize() call * Drop SERIAL_CPU_INIT option * (Unrelated) Attempt more descriptive comments for various config options PATCH: --- src/cpu/x86/lapic/lapic_cpu_init.c.orig 2005-09-09 09:29:25.156250000 -0500 +++ src/cpu/x86/lapic/lapic_cpu_init.c 2005-09-09 09:31:59.109375000 -0500 @@ -230,17 +230,16 @@ void secondary_cpu_init(void) { atomic_inc(&active_cpus); -#if SERIAL_CPU_INIT == 1 - #if CONFIG_MAX_CPUS>2 - spin_lock(&start_cpu_lock); - #endif -#endif + + // NOTE: The call to cpu_initialize() used to be bracketed by + // calls to lock and unlock the start_cpu_lock spin lock. + // These were removed to resolve a hang due to nested spin locking + // when secondary CPUs go to initialize their siblings. + // See http://openbios.org/pipermail/linuxbios/2005-July/011903.html. + // It's possible that some other form of concurrency control + // is needed at this level. cpu_initialize(); -#if SERIAL_CPU_INIT == 1 - #if CONFIG_MAX_CPUS>2 - spin_unlock(&start_cpu_lock); - #endif -#endif + atomic_dec(&active_cpus); stop_this_cpu(); } @@ -265,11 +264,9 @@ printk_err("CPU %u would not start!\n", cpu->path.u.apic.apic_id); } -#if SERIAL_CPU_INIT == 1 #if CONFIG_MAX_CPUS>2 udelay(10); #endif -#endif } /* Now loop until the other cpus have finished initializing */ --- src/config/Options.lb.orig 2005-09-09 09:36:27.562500000 -0500 +++ src/config/Options.lb 2005-09-09 09:35:17.125000000 -0500 @@ -188,37 +188,37 @@ default 65536 format "0x%x" export used - comment "Default fallback image size" + comment "ROM_SECTION_SIZE to use for the fallback build." end define ROM_SIZE default none format "0x%x" export used - comment "Size of your ROM" + comment "Total number of bytes allocated for normal and fallback LinuxBIOS images and payloads. Note that the fallback image goes at the end of the ROM, and the normal image at the beginning." end define ROM_IMAGE_SIZE default 65535 format "0x%x" export always - comment "Default image size" + comment "Maximum number of bytes allowed for a LinuxBIOS image. Does not include the payload." end define ROM_SECTION_SIZE default {FALLBACK_SIZE} format "0x%x" export used - comment "Default rom section size" + comment "Default rom section size. Normally, this is calculated in mainboard Config.lb and varies between the normal and fallback builds." end define ROM_SECTION_OFFSET default {ROM_SIZE - FALLBACK_SIZE} format "0x%x" export used - comment "Default rom section offset" + comment "Number of bytes from the beginning of the ROM to the start of the section containing this build (normal or fallback). Normally, this is calculated in mainboard Config.lb." end define PAYLOAD_SIZE default {ROM_SECTION_SIZE - ROM_IMAGE_SIZE} format "0x%x" export always - comment "Default payload size" + comment "Maximum number of bytes allowed for a payload. Normally, this is calculated as above." end define _ROMBASE default {PAYLOAD_SIZE} @@ -479,7 +479,7 @@ export used comment "System clock frequency in MHz" end - + ############################################### # SMP options ############################################### @@ -509,11 +509,6 @@ export used comment "Define to build an MP table" end -define SERIAL_CPU_INIT - default 1 - export always - comment "Serialize CPU init" -end ############################################### # Boot options @@ -533,7 +528,7 @@ default {0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1} format "0x%x" export always - comment "ROM stream start location" + comment "Memory address of this (normal or fallback) build's payload in ROM. Normally, this is calculated as above." end define CONFIG_FS_STREAM default 0 --- src/mainboard/tyan/s2735/Options.lb.orig 2005-09-08 13:35:22.453125000 -0500 +++ src/mainboard/tyan/s2735/Options.lb 2005-09-09 09:21:21.531250000 -0500 @@ -8,7 +8,6 @@ uses CONFIG_MAX_CPUS uses CONFIG_MAX_PHYSICAL_CPUS uses CONFIG_LOGICAL_CPUS -uses SERIAL_CPU_INIT uses CONFIG_IOAPIC uses CONFIG_SMP uses FALLBACK_SIZE @@ -127,8 +126,6 @@ default CONFIG_MAX_PHYSICAL_CPUS=2 default CONFIG_LOGICAL_CPUS=1 -default SERIAL_CPU_INIT=0 - #BTEXT Console #default CONFIG_CONSOLE_BTEXT=1 ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!" #include -- LinuxBIOS mailing list LinuxBIOS at openbios.org http://www.openbios.org/mailman/listinfo/linuxbios -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at digidescorp.com Fri Sep 9 20:58:52 2005 From: steve at digidescorp.com (Steven J. Magnani) Date: Fri, 9 Sep 2005 13:58:52 -0500 Subject: [LinuxBIOS] PATCH: nested spinlock hang when initializing x86 sibling CPUs In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0612E@ssvlexmb2.amd.com> Message-ID: <003501c5b570$88aa3d70$6ffea8c0@banana> > This has nothing to do with AMD or intel. I disagree. The Tyan s2735 is the only board that sets SERIAL_CPU_INIT to 0. Why? That board happens to be a sister to the boards I'm working with, which have problems with nested spinlocking. This is not an issue of interleaving debug output; the board hangs when initializing the sibling of the 2nd CPU. I am thinking that the underlying problem is that the start_cpu_lock is being used in places (secondary_cpu_init) where a different lock is called for. The AMD code seems to start secondary/sibling CPUs quite differently than the Intel code. Without some idea of the call sequence for starting up AMD secondary/sibling CPUs it's difficult to know what the effects of switching to a different lock would be. If someone could sketch out something for AMD like I put together for Intel when I first encountered this issue (http://openbios.org/pipermail/linuxbios/2005-July/011903.html) it might be easier for us to reach some kind of consensus. ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!" #include From steve at digidescorp.com Fri Sep 9 21:59:16 2005 From: steve at digidescorp.com (Steven J. Magnani) Date: Fri, 9 Sep 2005 14:59:16 -0500 Subject: [LinuxBIOS] PATCH: nested spinlock hang when initializing x86 sibling CPUs Message-ID: <003601c5b578$f88cfee0$6ffea8c0@banana> Here is a revised patch which works in the Intel world. Let me know if this causes any problems in the AMD world. I'm still planning on making the comment changes to src/config/Options.lb, unless someone thinks I've made things more confusing. PATCH: --- src/cpu/x86/lapic/lapic_cpu_init.c.orig 2005-09-09 09:29:25.156250000 -0500 +++ src/cpu/x86/lapic/lapic_cpu_init.c 2005-09-09 14:54:51.218750000 -0500 @@ -227,20 +227,26 @@ } /* C entry point of secondary cpus */ + +// secondary_cpu_lock is used to serialize initialization of secondary CPUs +// This can be used to avoid interleaved debugging messages. + +static spinlock_t secondary_cpu_lock = SPIN_LOCK_UNLOCKED; + void secondary_cpu_init(void) { atomic_inc(&active_cpus); + #if SERIAL_CPU_INIT == 1 - #if CONFIG_MAX_CPUS>2 - spin_lock(&start_cpu_lock); - #endif + spin_lock(&secondary_cpu_lock); #endif + cpu_initialize(); + #if SERIAL_CPU_INIT == 1 - #if CONFIG_MAX_CPUS>2 - spin_unlock(&start_cpu_lock); - #endif + spin_unlock(&secondary_cpu_lock); #endif + atomic_dec(&active_cpus); stop_this_cpu(); } ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!" #include From yinghai.lu at amd.com Fri Sep 9 22:10:48 2005 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Fri, 9 Sep 2005 13:10:48 -0700 Subject: [LinuxBIOS] PATCH: nested spinlock hang when initializing x86 sibling CPUs Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06130@ssvlexmb2.amd.com> Please do not touch SERIAL_CPU_INIT. That doesn't hurt. YH -----Original Message----- From: Steven J. Magnani [mailto:steve at digidescorp.com] Sent: Friday, September 09, 2005 12:59 PM To: Lu, Yinghai; yinghailu at gmail.com Cc: linuxbios at openbios.org Subject: RE: [LinuxBIOS] PATCH: nested spinlock hang when initializing x86 sibling CPUs Here is a revised patch which works in the Intel world. Let me know if this causes any problems in the AMD world. I'm still planning on making the comment changes to src/config/Options.lb, unless someone thinks I've made things more confusing. PATCH: --- src/cpu/x86/lapic/lapic_cpu_init.c.orig 2005-09-09 09:29:25.156250000 -0500 +++ src/cpu/x86/lapic/lapic_cpu_init.c 2005-09-09 14:54:51.218750000 -0500 @@ -227,20 +227,26 @@ } /* C entry point of secondary cpus */ + +// secondary_cpu_lock is used to serialize initialization of secondary CPUs +// This can be used to avoid interleaved debugging messages. + +static spinlock_t secondary_cpu_lock = SPIN_LOCK_UNLOCKED; + void secondary_cpu_init(void) { atomic_inc(&active_cpus); + #if SERIAL_CPU_INIT == 1 - #if CONFIG_MAX_CPUS>2 - spin_lock(&start_cpu_lock); - #endif + spin_lock(&secondary_cpu_lock); #endif + cpu_initialize(); + #if SERIAL_CPU_INIT == 1 - #if CONFIG_MAX_CPUS>2 - spin_unlock(&start_cpu_lock); - #endif + spin_unlock(&secondary_cpu_lock); #endif + atomic_dec(&active_cpus); stop_this_cpu(); } ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!" #include From pj at cassens.com Fri Sep 9 22:43:33 2005 From: pj at cassens.com (pj at cassens.com) Date: Fri, 9 Sep 2005 15:43:33 -0500 Subject: [LinuxBIOS] VIA MII help, please Message-ID: <20050909204333.GA2742@cassens.com> Trying to get myself up to date on the linuxbios offerings and have a very specific need to get the VIA MII 6000 to CF boot! I see the wiki page of: http://linuxbios.org/index.php/Supported_Motherboards that says, "Location in source tree: targets/via/epia-mii", but browsing the CVS tree ([LinuxBIOS] / trunk / LinuxBIOSv2 / targets / via) does NOT show "epia-m". Did the mii stuff drop from the linuxbios? HELP please PJ From rminnich at lanl.gov Sat Sep 10 03:01:39 2005 From: rminnich at lanl.gov (Ronald G Minnich) Date: Fri, 09 Sep 2005 19:01:39 -0600 Subject: [LinuxBIOS] Re: LinuxBIOS Summit In-Reply-To: <43220A26.6050207@onelabs.com> References: <1125612431.6731.18.camel@logarithm.lanl.gov> <43220A26.6050207@onelabs.com> Message-ID: <43223073.4050301@lanl.gov> Bari Ari wrote: > > Is workshop #9 "LinuxBIOS Summit (full day)" going to be on just Tuesday > Oct 11? Thank you, Bari, for asking this. The linuxbios summit as currently planned is a 2.5 day affair. I will try to get the web page fixed. ron From russ at ashlandhome.net Sat Sep 10 04:50:03 2005 From: russ at ashlandhome.net (Russell Whitaker) Date: Fri, 9 Sep 2005 19:50:03 -0700 (PDT) Subject: [LinuxBIOS] Re: LinuxBIOS Summit In-Reply-To: <43223073.4050301@lanl.gov> References: <1125612431.6731.18.camel@logarithm.lanl.gov> <43220A26.6050207@onelabs.com> <43223073.4050301@lanl.gov> Message-ID: On Fri, 9 Sep 2005, Ronald G Minnich wrote: > Bari Ari wrote: > >> >> Is workshop #9 "LinuxBIOS Summit (full day)" going to be on just Tuesday >> Oct 11? > > Thank you, Bari, for asking this. The linuxbios summit as currently planned > is a 2.5 day affair. I will try to get the web page fixed. > Will my "one day linuxbios summit registration" be good for the full 2.5 days? Russ From ollie at lanl.gov Mon Sep 12 05:55:19 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Sun, 11 Sep 2005 21:55:19 -0600 Subject: [LinuxBIOS] Re: LinuxBIOS Summit In-Reply-To: References: <1125612431.6731.18.camel@logarithm.lanl.gov> <43220A26.6050207@onelabs.com> <43223073.4050301@lanl.gov> Message-ID: <1126497319.5365.5.camel@logarithm.lanl.gov> On Fri, 2005-09-09 at 19:50 -0700, Russell Whitaker wrote: > > On Fri, 9 Sep 2005, Ronald G Minnich wrote: > > > Bari Ari wrote: > > > >> > >> Is workshop #9 "LinuxBIOS Summit (full day)" going to be on just Tuesday > >> Oct 11? > > > > Thank you, Bari, for asking this. The linuxbios summit as currently planned > > is a 2.5 day affair. I will try to get the web page fixed. > > > Will my "one day linuxbios summit registration" be good for the full > 2.5 days? > sure. > Russ > -- Li-Ta Lo Los Alamos National Lab From steve at digidescorp.com Mon Sep 12 18:39:09 2005 From: steve at digidescorp.com (Steven J. Magnani) Date: Mon, 12 Sep 2005 11:39:09 -0500 Subject: [LinuxBIOS] PATCH: failure/race in secondary CPU startup Message-ID: <000301c5b7b8$83142c50$6ffea8c0@banana> This patch does two things: * Prints a failure message when a sibling CPU fails to start (currently, a message is printed only when a CPU enumerated in Config.lb fails to start). * Detects a race condition that results in secondary CPUs using the wrong CPU info. This can occur if the BSP times out waiting for a secondary CPU to respond, for example if the secondary startup code is modified so that an emulator can be used to debug the secondary CPU. PATCH: --- src/cpu/intel/hyperthreading/intel_sibling.c.orig 2005-09-08 13:35:05.578125000 -0500 +++ src/cpu/intel/hyperthreading/intel_sibling.c 2005-09-12 11:24:20.546875000 -0500 @@ -67,7 +67,11 @@ new->path.u.apic.apic_id); #endif /* Start the new cpu */ - start_cpu(new); + if (!start_cpu(new)) { + /* Record the error in cpu? */ + printk_err("CPU %u would not start!\n", + new->path.u.apic.apic_id); + } } } --- src/arch/i386/lib/cpu.c.orig 2005-09-08 13:35:40.875000000 -0500 +++ src/arch/i386/lib/cpu.c 2005-09-12 11:26:27.375000000 -0500 @@ -231,6 +231,14 @@ die("CPU: missing cpu device structure"); } + // Check that we haven't been passed bad information as the result of a race + // (i.e. BSP timed out while waiting for us to load secondary_stack) + + if (cpu->path.u.apic.apic_id != lapicid()) { + printk_err("CPU #%d Initialization FAILED: APIC ID mismatch (%u != %u)\n", + info->index, cpu->path.u.apic.apic_id, lapicid()); + // return without setting initialized flag + } else { /* Find what type of cpu we are dealing with */ identify_cpu(cpu); printk_debug("CPU: vendor %s device %x\n", @@ -247,6 +255,8 @@ } printk_info("CPU #%d Initialized\n", info->index); + } + return; } ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!" #include From stepan at openbios.org Mon Sep 12 20:13:59 2005 From: stepan at openbios.org (Stefan Reinauer) Date: Mon, 12 Sep 2005 20:13:59 +0200 Subject: [LinuxBIOS] LNXI Merge: lnxi-patch-05/16 In-Reply-To: References: Message-ID: <20050912181359.GA20390@openbios.org> This one looks fine, as the could probably wouldn't even compile without it. * jason schildt [050903 00:03]: > DESCRIPTION: > ------------------------------------------------- > ## lnxi-patch-5 ## > src/superio/NSC/pc87360/superio.c > Bug fix from &pnp_ops to &ops > > > =================================================================== > --- superio/NSC/pc87360/superio.c (revision 1105) > +++ superio/NSC/pc87360/superio.c (working copy) > @@ -66,7 +66,7 @@ > > static void enable_dev(struct device *dev) > { > - pnp_enable_devices(dev, &pnp_ops, > + pnp_enable_devices(dev, &ops, > sizeof(pnp_dev_info)/sizeof(pnp_dev_info[0]), pnp_dev_info); > } From steve at digidescorp.com Mon Sep 12 20:34:40 2005 From: steve at digidescorp.com (Steven J. Magnani) Date: Mon, 12 Sep 2005 13:34:40 -0500 Subject: [LinuxBIOS] PATCH: P64H2 cleanup Message-ID: <000401c5b7c8$a6638790$6ffea8c0@banana> This patch does the following: * Drops hard-coding of P64H2 vendor/subsystem ID * Replaces magic numbers with standard #defined tags * Attempts to improve clarity via comments and variable names * Releases for general use Except for the vendor/subsystem ID, the changes don't affect the operation of the code. PATCH: --- src/southbridge/intel/i82870/p64h2_ioapic.c.orig 2005-09-08 13:34:48.078125000 -0500 +++ src/southbridge/intel/i82870/p64h2_ioapic.c 2005-09-12 13:22:28.671875000 -0500 @@ -4,72 +4,81 @@ #include #include #include +#include #include "82870.h" -static int ioapic_no = 0; +static int num_p64h2_ioapics = 0; static void p64h2_ioapic_enable(device_t dev) { - uint32_t dword; - uint16_t word; - /* We have to enable MEM and Bus Master for IOAPIC */ - word = 0x0146; - pci_write_config16(dev, PCICMD, word); - dword = 0x358015d9; - pci_write_config32(dev, SUBSYS, dword); + uint16_t command = PCI_COMMAND_SERR | PCI_COMMAND_PARITY | PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY; + pci_write_config16(dev, PCI_COMMAND, command); } +//--------------------------------------------------------------------- ------------- +// Function: p64h2_ioapic_init +// Parameters: dev - PCI bus/device/function of P64H2 IOAPIC +// NOTE: There are two IOAPICs per P64H2, at D28:F0 and D30:F0 +// Return Value: None +// Description: Configure one of the IOAPICs in a P64H2. +// Note that a PCI bus scan will detect both IOAPICs, so this function +// will be called twice for each P64H2 in the system. +// static void p64h2_ioapic_init(device_t dev) { - uint32_t dword; - uint16_t word; - int i, addr; + uint32_t memoryBase; + int apic_index, apic_id; - volatile uint32_t *ioapic_a; /* io apic io memory space command address */ - volatile uint32_t *ioapic_d; /* io apic io memory space data address */ + volatile uint32_t* pIndexRegister; /* io apic io memory space command address */ + volatile uint32_t* pWindowRegister; /* io apic io memory space data address */ - i = ioapic_no++; + apic_index = num_p64h2_ioapics; + num_p64h2_ioapics++; - if(i<3) /* io apic address numbers are 3,4,5,&8 */ - addr=i+3; + // A note on IOAPIC addresses: + // 0 and 1 are used for the local APICs of the dual virtual + // (hyper-threaded) CPUs of physical CPU 0 (mainboard/Config.lb). + // 6 and 7 are used for the local APICs of the dual virtual + // (hyper-threaded) CPUs of physical CPU 1 (mainboard/Config.lb). + // 2 is used for the IOAPIC in the 82801 Southbridge (hard-coded in i82801xx_lpc.c) + + // Map APIC index into APIC ID + // IDs 3, 4, 5, and 8+ are available (see above note) + + if (apic_index < 3) + apic_id = apic_index + 3; else - addr=i+5; - /* Read the MBAR address for setting up the io apic in io memory space */ - dword = pci_read_config32(dev, PCI_BASE_ADDRESS_0); - ioapic_a = (uint32_t *) dword; - ioapic_d = ioapic_a +0x04; + apic_id = apic_index + 5; + + ASSERT(apic_id < 16); // ID is only 4 bits + + // Read the MBAR address for setting up the IOAPIC in memory space + // NOTE: this address was assigned during enumeration of the bus + + memoryBase = pci_read_config32(dev, PCI_BASE_ADDRESS_0); + pIndexRegister = (volatile uint32_t*) memoryBase; + pWindowRegister = (volatile uint32_t*)(memoryBase + 0x10); + printk_debug("IOAPIC %d at %02x:%02x.%01x MBAR = %x DataAddr = %x\n", - addr, dev->bus->secondary, - PCI_SLOT(dev->path.u.pci.devfn), PCI_FUNC(dev->path.u.pci.devfn), - ioapic_a, ioapic_d); + apic_id, dev->bus->secondary, PCI_SLOT(dev->path.u.pci.devfn), + PCI_FUNC(dev->path.u.pci.devfn), pIndexRegister, pWindowRegister); -#if 0 - dword = (u32)ioapic_a; - word = 0x8000 + ((dword >>8)&0x0fff); - pci_write_config_word(dev, ABAR, word); -#endif - /* Set up the io apic for the p64h2 - 1461 */ - *ioapic_a=0; - *ioapic_d=(addr<<24); /* Set the address number */ - *ioapic_a=3; - *ioapic_d=1; /* Enable the io apic */ + apic_id <<= 24; // Convert ID to bitmask - /* This code test the setup to see if we really found the io apic */ - *ioapic_a=0; - dword=*ioapic_d; - printk_debug("PCI %d apic id = %x\n",addr,dword); - if(dword!=(addr<<24)) - for(;;); - *ioapic_a=3; - dword=*ioapic_d; - printk_debug("PCI %d apic DT = %x\n",addr,dword); - if(dword!=1) - for(;;); + *pIndexRegister = 0; // Select APIC ID register + *pWindowRegister = (*pWindowRegister & ~(0xF<<24)) | apic_id; // Set the ID + + if ((*pWindowRegister & (0xF<<24)) != apic_id) + die("p64h2_ioapic_init failed"); + *pIndexRegister = 3; // Select Boot Configuration register + *pWindowRegister |= 1; // Use Processor System Bus to deliver interrupts + if (!(*pWindowRegister & 1)) + die("p64h2_ioapic_init failed"); } static struct device_operations ioapic_ops = { --- src/southbridge/intel/i82870/82870.h.orig 2005-09-08 13:34:48.140625000 -0500 +++ src/southbridge/intel/i82870/82870.h 2005-07-25 09:40:35.109375000 -0500 @@ -1,6 +1,4 @@ /* for io apic 1461 */ -#define PCICMD 0x04 -#define SUBSYS 0x2c #define MBAR 0x10 #define ABAR 0x40 @@ -8,3 +6,10 @@ #define MTT 0x042 #define HCCR 0x0f0 #define ACNF 0x0e0 +#define STRP 0x44 // Strap status register + +#define STRP_EN133 0x0001 // 133 MHz-capable (Px_133EN) +#define STRP_HPCAP 0x0002 // Hot-plug capable (Hx_SLOT zero/nonzero) + +#define ACNF_SYNCPH 0x0010 // PCI(-X) input clock is synchronous to hub input clock + --- src/include/assert.h.orig 1969-12-31 18:00:00.000000000 -0600 +++ src/include/assert.h 2005-07-11 11:03:54.000000000 -0500 @@ -0,0 +1,59 @@ +/* + * $Header: /home/cvs/BIR/ca-cpu/freebios/src/include/assert.h,v 1.1 2005/07/11 16:03:54 smagnani Exp $ + * + * assert.h: Debugging macros + * + * Copyright (C) 2005 Digital Design Corporation + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + * $Log: assert.h,v $ + * Revision 1.1 2005/07/11 16:03:54 smagnani + * Initial revision. + * + * + */ + +#ifndef __ASSERT_H_DEFINED +#define __ASSERT_H_DEFINED + +// ROMCC doesn't support __FILE__ or __LINE__ :^{ + +#if DEBUG +#ifdef __ROMCC__ +#define ASSERT(x) { if (!(x)) die("ASSERT failure!\r\n"); } +#else +#define ASSERT(x) { \ + if (!(x)) \ + { \ + printk_emerg("ASSERT failure: file '%s', line %d\n", __FILE__, __LINE__); \ + die(""); \ + } \ + } +#endif // __ROMCC__ +#else // !DEBUG +#define ASSERT(x) { } +#endif + +#ifdef __ROMCC__ +#define BUG() { die("BUG encountered: system halted\r\n"); } +#else +#define BUG() { \ + printk_emerg("BUG: file '%s', line %d\n", __FILE__, __LINE__); \ + die(""); \ + } +#endif + +#endif // __ASSERT_H_DEFINED ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!" #include From jschildt at lnxi.com Mon Sep 12 21:18:16 2005 From: jschildt at lnxi.com (jason schildt) Date: Mon, 12 Sep 2005 13:18:16 -0600 Subject: [LinuxBIOS] LNXI Merge: modification to lnxi-patch-06/16 Message-ID: DESCRIPTION: ---------------------------------------------- ## lnxi-patch-6 ## src/include/smp/spinlock.h src/cpu/x86/tsc/delay_tsc.c cpu_relax() gets called unconditionally. DIFFSTAT: ----------------------------------------------- cpu/x86/tsc/delay_tsc.c | 4 ---- include/smp/spinlock.h | 1 + 2 files changed, 1 insertion(+), 4 deletions(-) PATCH: ----------------------------------------------- Index: lnxi-merge/src/include/smp/spinlock.h =================================================================== --- lnxi-merge/src/include/smp/spinlock.h (revision 1105) +++ lnxi-merge/src/include/smp/spinlock.h (working copy) @@ -19,6 +19,7 @@ #define spin_unlock_wait(lock) do {} while(0) #define spin_lock(lock) do {} while(0) #define spin_unlock(lock) do {} while(0) +#define cpu_relax() do {} while(0) #endif #endif /* SMP_SPINLOCK_H */ Index: lnxi-merge/src/cpu/x86/tsc/delay_tsc.c =================================================================== --- lnxi-merge/src/cpu/x86/tsc/delay_tsc.c (revision 1105) +++ lnxi-merge/src/cpu/x86/tsc/delay_tsc.c (working copy) @@ -159,11 +159,7 @@ count = rdtscll(); stop = clocks + count; while(stop > count) { -#ifdef CONFIG_SMP -#if CONFIG_SMP == 1 cpu_relax(); -#endif -#endif count = rdtscll(); } } ----------------------------------------------- --jason-- -- Jason W. Schildt LinuxBIOS Software Engineer Linux Networx From rminnich at lanl.gov Mon Sep 12 22:10:17 2005 From: rminnich at lanl.gov (Ronald G Minnich) Date: Mon, 12 Sep 2005 14:10:17 -0600 Subject: [LinuxBIOS] sc520 Message-ID: <4325E0A9.9080809@lanl.gov> support for the digitallogic sc520 is now in the svn tree. I have built it and it works. open issues - memory size still hardcoded - e100 insmod fails - vga bios fails ron From pj at cassens.com Mon Sep 12 22:40:04 2005 From: pj at cassens.com (pj at cassens.com) Date: Mon, 12 Sep 2005 15:40:04 -0500 Subject: [LinuxBIOS] Via MII BIOS help, can pay! Message-ID: <20050912204004.GA11257@cassens.com> Hello, all! Before messing with my Via MII BIOS, I google'd my heart out and did not find any real specific info. I found many other peeps in the same boat as I am; I need CF boot for this VERY cool MB! In fact, I have committed to already buying qty 130 of them and will buy another qty 130 on my way to a total nearing 900 if I'm lucky. I won't bore you with the project details, But I will say that they are vehicle mounted PC's running Linux (of course). That's all well and good, but we are spending a fair amount on IDE-CF adapters and cables (times qty) AND we have to take the PC apart to put on a new boot image. So, part of the openbios docs indicate that "targets/via/epia-mii" exists for this board. It does not. I am trying to learn as quickly as possible about what I can do with openbios. I am willing to pay for some excelerated work/help in order to help my own cause. The payment could be money to a person or group or in hardware (to make sure it all works of course). I don't know how much is fair. I do know that http://www.esupport.com/ bios guys might be able to do it. That would suck, however... 1. enigineering cost fo $1000+++, 2. not opensource, 3. still have per bios cost nearing IDE-CF adapter cost... So, anyone interested? From talbotx at comcast.net Tue Sep 13 01:59:53 2005 From: talbotx at comcast.net (Adam Talbot) Date: Mon, 12 Sep 2005 16:59:53 -0700 Subject: [LinuxBIOS] Via MII BIOS help, can pay! In-Reply-To: <20050912204004.GA11257@cassens.com> References: <20050912204004.GA11257@cassens.com> Message-ID: <43261679.2000201@comcast.net> First and foremost. The MII and the M are the same. Use the epia-m for your base compile. Last time I checked the M/MII was not running. About a year back the code runs just fine. If this is a must have, just grab one of the old tree's. Stay away from www.esupport.com. Via's fast boot can boot from the CF. You may want to look, into that. Boot time. How fast can you get the system booted. So from power until full GUI? -Adam pj at cassens.com wrote: >Hello, all! Before messing with my Via MII BIOS, I google'd my heart out and did not find any real specific info. I found many other peeps in the same boat as I am; I need CF boot for this VERY cool MB! > >In fact, I have committed to already buying qty 130 of them and will buy another qty 130 on my way to a total nearing 900 if I'm lucky. I won't bore you with the project details, But I will say that they are vehicle mounted PC's running Linux (of course). That's all well and good, but we are spending a fair amount on IDE-CF adapters and cables (times qty) AND we have to take the PC apart to put on a new boot image. > >So, part of the openbios docs indicate that "targets/via/epia-mii" exists for this board. It does not. I am trying to learn as quickly as possible about what I can do with openbios. I am willing to pay for some excelerated work/help in order to help my own cause. The payment could be money to a person or group or in hardware (to make sure it all works of course). I don't know how much is fair. I do know that http://www.esupport.com/ bios guys might be able to do it. That would suck, however... 1. enigineering cost fo $1000+++, 2. not opensource, 3. still have per bios cost nearing IDE-CF adapter cost... > >So, anyone interested? > > > From san at google.com Tue Sep 13 05:22:10 2005 From: san at google.com (San Mehat) Date: Mon, 12 Sep 2005 20:22:10 -0700 Subject: [LinuxBIOS] Section Overlaps & Offset miscalculation Message-ID: <236ccac05091220223e912934@mail.google.com> Greetings, I'm currently trying to build a ck804 based amd bios and am having the following issue: /usr/bin/ld: section .reset [fffdfff0 -> fffdffff] overlaps section .rom [fffd858b -> fffe263f] When i increase 'ROM_IMAGE_SIZE' from 0x10000 to 0x20000 the problem goes away, however it looks like the offsets are being incorrectly computed (the reset vector jump goes off into la-la land). Any ideas?.. thanks -san -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at digidescorp.com Tue Sep 13 17:07:57 2005 From: steve at digidescorp.com (Steven J. Magnani) Date: Tue, 13 Sep 2005 10:07:57 -0500 Subject: [LinuxBIOS] E7501 Raminit rewrite Message-ID: <000f01c5b874$f00b32b0$6ffea8c0@banana> This one ends up being a little more than a "patch". I ended up reorganizing the E7501 raminit code so I could follow it, and fixed some bugs along the way. Significant logical changes: * Added support for "fast" (64-clock) refresh * Added code to support remap window for 3 - 4 GB systems * Fixed premature configuration of true row boundaries that resulted in some sections of DRAM not receiving JEDEC commands (see http://openbios.org/pipermail/linuxbios/2005-June/011752.html). * Redefined RCOMP_MMIO so that RCOMP registers can be configured on systems where A20M# is asserted. * Disabled subsystem (vendor) ID configuration * #ifdef'd out suspicious looking code (see http://openbios.org/pipermail/linuxbios/2005-June/011759.html) * Added optional run-time checking of dual-channel compatibility of installed DIMMs * Move JEDEC SPD and SDRAM definitions into reusable #include files Probably, the rewritten code should be reviewed as if it were new. My hope is that it is now easy enough to follow that this shouldn't be too bad. The original code is, of course, in Subversion. Since I reordered the functions as part of the rewrite, a 'diff' of of the new code against the original won't tell you much. I've attached a reordered copy of the Subversion code that won't compile, but should be a little easier to diff against the new code so you can see what's changed. I will hold off on committing this for awhile to give people time to look at it. I know that radical changes are a pain to review, but IMHO the improvement in maintainability is significant. New files that are part of this 'patch', but not included here (I committed these to Subversion): src/include/spd.h src/include/sdram_mode.h src/include/northbridge/intel/e7501/e7501.h Thanks, Steve ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!" #include -------------- next part -------------- A non-text attachment was scrubbed... Name: raminit-new.c.zip Type: application/octet-stream Size: 31132 bytes Desc: not available URL: From Stephen.Kimball at bench.com Tue Sep 13 17:28:15 2005 From: Stephen.Kimball at bench.com (Stephen.Kimball at bench.com) Date: Tue, 13 Sep 2005 11:28:15 -0400 Subject: [LinuxBIOS] Section Overlaps & Offset miscalculation Message-ID: <30ADB28314F8B744AB478FB5EDA044B30D8109@nh-ex01.bench.com> What motherboard are you using? The first thing to check is the ROMSTRAP table. The CK804 may not allow the board to come out of reset if the ROMSTRAP is not in the proper location. I think it's at 0xFFFFFFE0 defined in ids.inc and it points to "2BIGDOGS" or 0x2B16D065. Steve -----Original Message----- From: linuxbios-bounces at openbios.org [mailto:linuxbios-bounces at openbios.org] On Behalf Of San Mehat Sent: Monday, September 12, 2005 11:22 PM To: linuxbios at openbios.org Subject: [LinuxBIOS] Section Overlaps & Offset miscalculation Greetings, I'm currently trying to build a ck804 based amd bios and am having the following issue: /usr/bin/ld: section .reset [fffdfff0 -> fffdffff] overlaps section .rom [fffd858b -> fffe263f] When i increase 'ROM_IMAGE_SIZE' from 0x10000 to 0x20000 the problem goes away, however it looks like the offsets are being incorrectly computed (the reset vector jump goes off into la-la land). Any ideas?.. thanks -san -------------- next part -------------- An HTML attachment was scrubbed... URL: From yinghai.lu at amd.com Tue Sep 13 18:27:20 2005 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 13 Sep 2005 09:27:20 -0700 Subject: [LinuxBIOS] E7501 Raminit rewrite Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06135@ssvlexmb2.amd.com> It's good to have spd.h there. But the name should be changed for support DDR2...etc. YH -----Original Message----- From: linuxbios-bounces at openbios.org [mailto:linuxbios-bounces at openbios.org] On Behalf Of Steven J. Magnani Sent: Tuesday, September 13, 2005 8:08 AM To: linuxbios at openbios.org Subject: [LinuxBIOS] E7501 Raminit rewrite This one ends up being a little more than a "patch". I ended up reorganizing the E7501 raminit code so I could follow it, and fixed some bugs along the way. Significant logical changes: * Added support for "fast" (64-clock) refresh * Added code to support remap window for 3 - 4 GB systems * Fixed premature configuration of true row boundaries that resulted in some sections of DRAM not receiving JEDEC commands (see http://openbios.org/pipermail/linuxbios/2005-June/011752.html). * Redefined RCOMP_MMIO so that RCOMP registers can be configured on systems where A20M# is asserted. * Disabled subsystem (vendor) ID configuration * #ifdef'd out suspicious looking code (see http://openbios.org/pipermail/linuxbios/2005-June/011759.html) * Added optional run-time checking of dual-channel compatibility of installed DIMMs * Move JEDEC SPD and SDRAM definitions into reusable #include files Probably, the rewritten code should be reviewed as if it were new. My hope is that it is now easy enough to follow that this shouldn't be too bad. The original code is, of course, in Subversion. Since I reordered the functions as part of the rewrite, a 'diff' of of the new code against the original won't tell you much. I've attached a reordered copy of the Subversion code that won't compile, but should be a little easier to diff against the new code so you can see what's changed. I will hold off on committing this for awhile to give people time to look at it. I know that radical changes are a pain to review, but IMHO the improvement in maintainability is significant. New files that are part of this 'patch', but not included here (I committed these to Subversion): src/include/spd.h src/include/sdram_mode.h src/include/northbridge/intel/e7501/e7501.h Thanks, Steve ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!" #include From yinghai.lu at amd.com Tue Sep 13 18:35:35 2005 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Tue, 13 Sep 2005 09:35:35 -0700 Subject: [LinuxBIOS] Section Overlaps & Offset miscalculation Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06136@ssvlexmb2.amd.com> Typically you need set ROM_IMAGE_SIZE to 0x15000 so you can leave some space (24Kbytes) for fallback payload. YH ________________________________ From: linuxbios-bounces at openbios.org [mailto:linuxbios-bounces at openbios.org] On Behalf Of San Mehat Sent: Monday, September 12, 2005 8:22 PM To: linuxbios at openbios.org Subject: [LinuxBIOS] Section Overlaps & Offset miscalculation Greetings, I'm currently trying to build a ck804 based amd bios and am having the following issue: /usr/bin/ld: section .reset [fffdfff0 -> fffdffff] overlaps section .rom [fffd858b -> fffe263f] When i increase 'ROM_IMAGE_SIZE' from 0x10000 to 0x20000 the problem goes away, however it looks like the offsets are being incorrectly computed (the reset vector jump goes off into la-la land). Any ideas?.. thanks -san -------------- next part -------------- An HTML attachment was scrubbed... URL: From ollie at lanl.gov Tue Sep 13 22:25:25 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Tue, 13 Sep 2005 14:25:25 -0600 Subject: [LinuxBIOS] LinuxBIOS Summit: Call for Speaker from Embedded World Message-ID: <1126643126.6399.35.camel@logarithm.lanl.gov> Hi, While we are working on the agenda of LinuxBIOS summit, we found that we desperately need speakers from embedded device world. Current we have no speaker who can stand for them. We would like to hear from people who is currently deploying or trying to deploying LinuxBIOS in their products. What problems did you encounter when using LinuxBIOS? What kind of support do you need from vendors and the developer community? Could you give us a big picture of where and how many LinuxBIOS embedded systems you have deployed out there? People complained about that LinuxBIOS development was too slanted to cluster application. Now it is time for people to hear from you!!! So please, come up and speak!!! -- Li-Ta Lo Los Alamos National Lab From ollie at lanl.gov Tue Sep 13 23:20:33 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Tue, 13 Sep 2005 15:20:33 -0600 Subject: [LinuxBIOS] LinuxBIOS Summit: Draft Schedule Message-ID: <1126646433.6399.69.camel@logarithm.lanl.gov> Hi, We are working on the agenda for LinuxBIOS summit. Here is a draft version. Please give us any suggestion and help you have. We categorized the attendance into three parties, the vendors, the users and the developers. We hope the three parties can each describe their past experience, outstanding problems and future directions such that these three parties can help each other. The first day will be focus on current status report. We are going to have Oct. 11 Vendor Presentation 1. Richard Bruner from AMD will talk about AMD's plan on LinuxBIOS and their roadmap for their products. 2. LNXI will give us their experience on integrating LinuxBIOS in their cluster products. 3. Terra soft will give us their plan of using LinuxBIOS in their PPC 970 products. User Experience Users from Sandia and Los Alamos will talk on their experience of using LinuxBIOS in clusters. Developer Status Report Developers will give presentations and hands-on demo of recent development. Topics includes: 1. Dual Core support for AMD K8 2. Cache As Ram support for Intel and AMD processors. 3. Integrating VGA BIOS support in your LinuxBIOS. On the second day we will focus on making LinuxBIOS more friendly for people of the three parties: Oct. 12 User Friendly 1. User Interface: What kind of default payload and/or user interface are we going to use? Do we want it to be command line or menu style? 2. User's Manual. Developer Friendly 1. KConfig: Josaih England will show us his work on using KConfig to replace the current config tool. 2. Development Model: What is the svn commit and release process? 3. Device Object Model: People still complain about the complexity of the current device model. Can we make it easier to work with? What is the impact of a new config too like #1 on the device model? How are we going to generate PIRQ/ACPI etc. tables? 4. Programmer's Manual. Vendor Friendly 1. We need to discuss the possibility of signing N-party NDA with vendors for their unreleased products. 2. How can we ensure 3rd party that our code is clean and free of legal trouble? 3. Binary blob and EFI/Tiano Interface. How are we going to play nice with Intel? Hackathon If anyone get inspired during the discussion, start implement your idea immediately!! On the third day we will look forward further into the future: Oct. 13 Crazy Ideas 1. FreeFI: Possible name change and official FSF sponsorship. 2. LinuxBIOS as Linux: Ron just doesn't give up his old LinuxBIOS==Linux idea. He will show how he is recycling it. Homework Assignment Hey, you had a good time. It is time to do your homework now. -- Li-Ta Lo Los Alamos National Lab From linuxbios at xdr.com Wed Sep 14 16:35:17 2005 From: linuxbios at xdr.com (Dave Ashley) Date: Wed, 14 Sep 2005 07:35:17 -0700 Subject: [LinuxBIOS] Awakening noop errors Message-ID: <200509141435.j8EEZHc6008043@xdr.com> All, We're working on epia-sp standup and romcc is outputting streams of the following: serial.c:60.51: serial.c:70.29: console.c:6.21: console.c:16.26: console.c:52.36: console.c:72.71: bist.h:11.34: auto.c:175.28: 0x788530 noop Internal compile r warning: awakening noop? serial.c:54.34: serial.c:66.29: console.c:6.21: console.c:16.26: console.c:53.36: console.c:72.71: bist.h:11.34: auto.c:175.28: 0x78b060 noop Internal compile r warning: awakening noop?serial.c:60.51: serial.c:70.29: console.c:6.21: console.c:16.26: console.c:53.36: console.c:72.71: bist.h:11.34: auto.c:175.28: 0x78cfa0 noop Internal compile r warning: awakening noop? serial.c:54.34: serial.c:66.29: console.c:6.21: console.c:16.26: console.c:54.36: console.c:72.71: bist.h:11.34: auto.c:175.28: 0x78fad0 noop Internal compile r warning: awakening noop? What do I do to fix this? -Dave From steve at digidescorp.com Wed Sep 14 19:00:03 2005 From: steve at digidescorp.com (Steven J. Magnani) Date: Wed, 14 Sep 2005 12:00:03 -0500 Subject: [LinuxBIOS] PATCH: ICH bug fixes Message-ID: <002e01c5b94d$c30237d0$6ffea8c0@banana> This patch fixes various LPC bugs in the ICH-4 and ICH-5 code that I noticed while working on the ICH-3: * DMA configuration read only half of the existing bits * 'posted memory write enable' code looks to have been mis-inherited from AMD * NMI/SERR configuration was done in PCI space instead of I/O space * Secondary IDE would be enabled whenever primary IDE was enabled * i82801xx_enable worked incorrectly when called for a PCI device without a corresponding disable bit I don't have any way to test that these do more than compile, although the identical ICH-3 code seems to work OK. The i82801xx_enable functions should be looked at closely since there are differences between the 'CA, 'DBM, and 'ER code. PATCH: --- src/southbridge/intel/i82801er/i82801er_lpc.c.orig 2005-09-08 13:34:49.312500000 -0500 +++ src/southbridge/intel/i82801er/i82801er_lpc.c 2005-09-14 11:07:02.588125000 -0500 @@ -8,9 +8,11 @@ #include #include #include +#include +#include #include "i82801er.h" -void isa_dma_init(void); /* from /pc80/isa-dma.c */ + #define NMI_OFF 0 @@ -52,7 +54,7 @@ { uint16_t word; int i; - word = pci_read_config8(dev, PCI_DMA_CFG); + word = pci_read_config16(dev, PCI_DMA_CFG); word &= ((1 << 10) - (1 << 8)); for(i = 0; i < 8; i++) { if (i == 4) @@ -124,9 +126,15 @@ i82801er_enable_serial_irqs(dev); +#ifdef SUSPICIOUS_LOOKING_CODE + // The ICH-5 datasheet does not mention this configuration register. + // This code may have been inherited (incorrectly) from code for the AMD 766 southbridge, + // which *does* support this functionality. + /* posted memory write enable */ byte = pci_read_config8(dev, 0x46); pci_write_config8(dev, 0x46, byte | (1<<0)); +#endif /* power after power fail */ /* FIXME this doesn't work! */ @@ -145,16 +153,16 @@ #endif /* Set up NMI on errors */ - byte = pci_read_config8(dev, 0x61); - byte |= (1 << 3); /* IOCHK# NMI Enable */ - byte |= (1 << 6); /* PCI SERR# Enable */ - pci_write_config8(dev, 0x61, byte); - byte = pci_read_config8(dev, 0x70); + byte = inb(0x61); + byte &= ~(1 << 3); /* IOCHK# NMI Enable */ + byte &= ~(1 << 2); /* PCI SERR# Enable */ + outb(byte, 0x61); + byte = inb(0x70); nmi_option = NMI_OFF; get_option(&nmi_option, "nmi"); if (nmi_option) { - byte |= (1 << 7); /* set NMI */ - pci_write_config8(dev, 0x70, byte); + byte &= ~(1 << 7); /* set NMI */ + outb(byte, 0x70); } /* Initialize the real time clock */ --- src/southbridge/intel/i82801dbm/i82801dbm_lpc.c.orig 2005-09-08 13:34:50.750000000 -0500 +++ src/southbridge/intel/i82801dbm/i82801dbm_lpc.c 2005-09-14 11:07:20.103750000 -0500 @@ -8,9 +8,11 @@ #include #include #include +#include +#include #include "i82801dbm.h" -void isa_dma_init(void); /* from /pc80/isa-dma.c */ + #define NMI_OFF 0 @@ -52,7 +54,7 @@ { uint16_t word; int i; - word = pci_read_config8(dev, PCI_DMA_CFG); + word = pci_read_config16(dev, PCI_DMA_CFG); word &= ((1 << 10) - (1 << 8)); for(i = 0; i < 8; i++) { if (i == 4) @@ -124,9 +126,15 @@ i82801dbm_enable_serial_irqs(dev); +#ifdef SUSPICIOUS_LOOKING_CODE + // The ICH-4 datasheet does not mention this configuration register. + // This code may have been inherited (incorrectly) from code for the AMD 766 southbridge, + // which *does* support this functionality. + /* posted memory write enable */ byte = pci_read_config8(dev, 0x46); pci_write_config8(dev, 0x46, byte | (1<<0)); +#endif /* power after power fail */ /* FIXME this doesn't work! */ @@ -145,16 +153,16 @@ #endif /* Set up NMI on errors */ - byte = pci_read_config8(dev, 0x61); - byte |= (1 << 3); /* IOCHK# NMI Enable */ - byte |= (1 << 6); /* PCI SERR# Enable */ - pci_write_config8(dev, 0x61, byte); - byte = pci_read_config8(dev, 0x70); + byte = inb(0x61); + byte &= ~(1 << 3); /* IOCHK# NMI Enable */ + byte &= ~(1 << 2); /* PCI SERR# Enable */ + outb(byte, 0x61); + byte = inb(0x70); nmi_option = NMI_OFF; get_option(&nmi_option, "nmi"); if (nmi_option) { - byte |= (1 << 7); /* set NMI */ - pci_write_config8(dev, 0x70, byte); + byte &= ~(1 << 7); /* set NMI */ + outb(byte, 0x70); } /* Initialize the real time clock */ --- src/southbridge/intel/i82801er/i82801er_ide.c.orig 2005-09-14 11:46:49.213125000 -0500 +++ src/southbridge/intel/i82801er/i82801er_ide.c 2005-09-14 11:21:59.916250000 -0500 @@ -26,7 +26,7 @@ word = pci_read_config16(dev, 0x42); word &= ~((1 << 15)); - if (enable_a) { + if (enable_b) { /* Enable secondary ide interface */ word |= (1<<15); printk_debug("IDE1 "); --- src/southbridge/intel/i82801dbm/i82801dbm_ide.c.orig 2005-09-14 11:45:41.197500000 -0500 +++ src/southbridge/intel/i82801dbm/i82801dbm_ide.c 2005-09-14 11:21:10.385000000 -0500 @@ -26,7 +26,7 @@ word = pci_read_config16(dev, 0x42); word &= ~((1 << 15)); - if (enable_a) { + if (enable_b) { /* Enable secondary ide interface */ word |= (1<<15); printk_debug("IDE1 "); --- src/southbridge/intel/i82801er/i82801er.c.orig 2005-09-08 13:34:49.343750000 -0500 +++ src/southbridge/intel/i82801er/i82801er.c 2005-09-14 11:56:26.666250000 -0500 @@ -6,48 +6,58 @@ void i82801er_enable(device_t dev) { - device_t lpc_dev; - unsigned int index; - uint16_t reg_old, reg; - -// all 82801er device ares in bus 0 - unsigned int devfn; - devfn = PCI_DEVFN(0x1f, 0); // lpc - lpc_dev = dev_find_slot(0, devfn); // 0 - if (!lpc_dev ) { - return; - } -#if 0 - if ((lpc_dev->vendor != PCI_VENDOR_ID_INTEL) || - (lpc_dev->device != PCI_DEVICE_ID_INTEL_82801ER_1F0)) { - uint32_t id; - id = pci_read_config32(lpc_dev, PCI_VENDOR_ID); - if (id != (PCI_VENDOR_ID_INTEL | (PCI_DEVICE_ID_INTEL_82801ER_1F0 << 16))) { - return; - } - } -#endif - - index = (dev->path.u.pci.devfn & 7); - if((dev->path.u.pci.devfn & ~0x7)==devfn) { // D=0x1f - if(index==0){ //1f0 - index = 14; - } - } else { // D=0x1d - index += 8; - } - - reg_old = pci_read_config16(lpc_dev, FUNC_DIS); - reg = reg_old; - reg &= ~(1<enabled) { - reg |= (1<path.u.pci.devfn) == 31) { + index = PCI_FUNC(dev->path.u.pci.devfn); + + switch (index) { + case 0: + case 1: + case 2: + case 3: + case 5: + case 6: + bHasDisableBit = 1; + break; + + default: + break; + }; + + if (index == 0) + index = 14; // D31:F0 bit is an exception + + } else if (PCI_SLOT(dev->path.u.pci.devfn) == 29) { + index = 8 + PCI_FUNC(dev->path.u.pci.devfn); + + if ((PCI_FUNC(dev->path.u.pci.devfn) < 4) || (PCI_FUNC(dev->path.u.pci.devfn) == 7)) + bHasDisableBit = 1; + } + + if (bHasDisableBit) { + cur_disable_mask = pci_read_config16(lpc_dev, FUNC_DIS); + new_disable_mask = cur_disable_mask & ~(1<enabled) { + new_disable_mask |= (1<vendor != PCI_VENDOR_ID_INTEL) || - (lpc_dev->device != PCI_DEVICE_ID_INTEL_82801DBM_1F0)) { - uint32_t id; - id = pci_read_config32(lpc_dev, PCI_VENDOR_ID); - if (id != (PCI_VENDOR_ID_INTEL | (PCI_DEVICE_ID_INTEL_82801DBM_1F0 << 16))) { - return; - } - } -#endif - - index = (dev->path.u.pci.devfn & 7); - if((dev->path.u.pci.devfn & ~0x7)==devfn) { // D=0x1f - if(index==0){ //1f0 - index = 14; - } - } else { // D=0x1d - index += 8; - } - - reg_old = pci_read_config16(lpc_dev, FUNC_DIS); - reg = reg_old; - reg &= ~(1<enabled) { - reg |= (1<path.u.pci.devfn) == 31) { + index = PCI_FUNC(dev->path.u.pci.devfn); + + switch (index) { + case 0: + case 1: + case 3: + case 5: + case 6: + bHasDisableBit = 1; + break; + + default: + break; + }; + + if (index == 0) + index = 14; // D31:F0 bit is an exception + + } else if (PCI_SLOT(dev->path.u.pci.devfn) == 29) { + index = 8 + PCI_FUNC(dev->path.u.pci.devfn); + + if ((PCI_FUNC(dev->path.u.pci.devfn) < 3) || (PCI_FUNC(dev->path.u.pci.devfn) == 7)) + bHasDisableBit = 1; + } + + if (bHasDisableBit) { + cur_disable_mask = pci_read_config16(lpc_dev, FUNC_DIS); + new_disable_mask = cur_disable_mask & ~(1<enabled) { + new_disable_mask |= (1< Hey all, I've been making some modifications to the ck804 early smbus code and i'm noticin that romcc appears to be chewing seemingly forever. Any ideas on how to diagnose this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ollie at lanl.gov Wed Sep 14 19:17:59 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Wed, 14 Sep 2005 11:17:59 -0600 Subject: [LinuxBIOS] RomCC chews forever (or seemingly forever) In-Reply-To: <236ccac050914101427e4a119@mail.google.com> References: <236ccac050914101427e4a119@mail.google.com> Message-ID: <1126718279.5267.22.camel@logarithm.lanl.gov> On Wed, 2005-09-14 at 10:14 -0700, San Mehat wrote: > Hey all, > > I've been making some modifications to the ck804 early smbus code and > i'm noticin that romcc appears to be chewing seemingly forever. > Any ideas on how to diagnose this? > I think you are running out of registers. If wait long enough, ROMCC will complain not enough registers. -- Li-Ta Lo Los Alamos National Lab From san at google.com Wed Sep 14 19:30:33 2005 From: san at google.com (San Mehat) Date: Wed, 14 Sep 2005 10:30:33 -0700 Subject: [LinuxBIOS] RomCC chews forever (or seemingly forever) In-Reply-To: <1126718279.5267.22.camel@logarithm.lanl.gov> References: <236ccac050914101427e4a119@mail.google.com> <1126718279.5267.22.camel@logarithm.lanl.gov> Message-ID: <236ccac050914103054f1fe7f@mail.google.com> Thanks for the quick response.. it looks like if you forget to specify a return value the compile can hang forever (ie > 1 hour before i gave up). so something like this: static int blah(int foo, int bar) { int baz = 10 while (baz) { baz-- if (something_else()) return 1; } // ACK!.. no return here } seems to cause things to break. On 9/14/05, Li-Ta Lo wrote: > > On Wed, 2005-09-14 at 10:14 -0700, San Mehat wrote: > > Hey all, > > > > I've been making some modifications to the ck804 early smbus code and > > i'm noticin that romcc appears to be chewing seemingly forever. > > Any ideas on how to diagnose this? > > > > I think you are running out of registers. If wait long enough, ROMCC > will complain not enough registers. > > -- > Li-Ta Lo > Los Alamos National Lab > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at digidescorp.com Wed Sep 14 20:05:32 2005 From: steve at digidescorp.com (Steven J. Magnani) Date: Wed, 14 Sep 2005 13:05:32 -0500 Subject: [LinuxBIOS] APIC IDs for Tyan s2735 Message-ID: <003401c5b956$e96cb9f0$6ffea8c0@banana> YhLu - Can you check the mptable for the S2735? If I'm reading it correctly, APIC ID 8 is being used for the ICH, but it seems from the southbridge code that the ICH is hard-coded to 2. ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!" #include From steve at digidescorp.com Wed Sep 14 20:06:26 2005 From: steve at digidescorp.com (Steven J. Magnani) Date: Wed, 14 Sep 2005 13:06:26 -0500 Subject: [LinuxBIOS] E7501 Raminit rewrite In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06135@ssvlexmb2.amd.com> Message-ID: <003501c5b957$0954e8a0$6ffea8c0@banana> Can you be more specific about the changes you'd like to see? Steve -----Original Message----- From: Lu, Yinghai [mailto:yinghai.lu at amd.com] Sent: Tuesday, September 13, 2005 10:27 AM To: Steven J. Magnani; linuxbios at openbios.org Subject: RE: [LinuxBIOS] E7501 Raminit rewrite It's good to have spd.h there. But the name should be changed for support DDR2...etc. YH -----Original Message----- From: linuxbios-bounces at openbios.org [mailto:linuxbios-bounces at openbios.org] On Behalf Of Steven J. Magnani Sent: Tuesday, September 13, 2005 8:08 AM To: linuxbios at openbios.org Subject: [LinuxBIOS] E7501 Raminit rewrite This one ends up being a little more than a "patch". I ended up reorganizing the E7501 raminit code so I could follow it, and fixed some bugs along the way. Significant logical changes: * Added support for "fast" (64-clock) refresh * Added code to support remap window for 3 - 4 GB systems * Fixed premature configuration of true row boundaries that resulted in some sections of DRAM not receiving JEDEC commands (see http://openbios.org/pipermail/linuxbios/2005-June/011752.html). * Redefined RCOMP_MMIO so that RCOMP registers can be configured on systems where A20M# is asserted. * Disabled subsystem (vendor) ID configuration * #ifdef'd out suspicious looking code (see http://openbios.org/pipermail/linuxbios/2005-June/011759.html) * Added optional run-time checking of dual-channel compatibility of installed DIMMs * Move JEDEC SPD and SDRAM definitions into reusable #include files Probably, the rewritten code should be reviewed as if it were new. My hope is that it is now easy enough to follow that this shouldn't be too bad. The original code is, of course, in Subversion. Since I reordered the functions as part of the rewrite, a 'diff' of of the new code against the original won't tell you much. I've attached a reordered copy of the Subversion code that won't compile, but should be a little easier to diff against the new code so you can see what's changed. I will hold off on committing this for awhile to give people time to look at it. I know that radical changes are a pain to review, but IMHO the improvement in maintainability is significant. New files that are part of this 'patch', but not included here (I committed these to Subversion): src/include/spd.h src/include/sdram_mode.h src/include/northbridge/intel/e7501/e7501.h Thanks, Steve ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!" #include From yinghai.lu at amd.com Wed Sep 14 20:10:42 2005 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Wed, 14 Sep 2005 11:10:42 -0700 Subject: [LinuxBIOS] E7501 Raminit rewrite Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0614C@ssvlexmb2.amd.com> Every define have SPD_DDR_ prefix, or with ddr_spd.h and SPD_ prefix.... YH -----Original Message----- From: Steven J. Magnani [mailto:steve at digidescorp.com] Sent: Wednesday, September 14, 2005 11:06 AM To: Lu, Yinghai; linuxbios at openbios.org Subject: RE: [LinuxBIOS] E7501 Raminit rewrite Can you be more specific about the changes you'd like to see? Steve -----Original Message----- From: Lu, Yinghai [mailto:yinghai.lu at amd.com] Sent: Tuesday, September 13, 2005 10:27 AM To: Steven J. Magnani; linuxbios at openbios.org Subject: RE: [LinuxBIOS] E7501 Raminit rewrite It's good to have spd.h there. But the name should be changed for support DDR2...etc. YH -----Original Message----- From: linuxbios-bounces at openbios.org [mailto:linuxbios-bounces at openbios.org] On Behalf Of Steven J. Magnani Sent: Tuesday, September 13, 2005 8:08 AM To: linuxbios at openbios.org Subject: [LinuxBIOS] E7501 Raminit rewrite This one ends up being a little more than a "patch". I ended up reorganizing the E7501 raminit code so I could follow it, and fixed some bugs along the way. Significant logical changes: * Added support for "fast" (64-clock) refresh * Added code to support remap window for 3 - 4 GB systems * Fixed premature configuration of true row boundaries that resulted in some sections of DRAM not receiving JEDEC commands (see http://openbios.org/pipermail/linuxbios/2005-June/011752.html). * Redefined RCOMP_MMIO so that RCOMP registers can be configured on systems where A20M# is asserted. * Disabled subsystem (vendor) ID configuration * #ifdef'd out suspicious looking code (see http://openbios.org/pipermail/linuxbios/2005-June/011759.html) * Added optional run-time checking of dual-channel compatibility of installed DIMMs * Move JEDEC SPD and SDRAM definitions into reusable #include files Probably, the rewritten code should be reviewed as if it were new. My hope is that it is now easy enough to follow that this shouldn't be too bad. The original code is, of course, in Subversion. Since I reordered the functions as part of the rewrite, a 'diff' of of the new code against the original won't tell you much. I've attached a reordered copy of the Subversion code that won't compile, but should be a little easier to diff against the new code so you can see what's changed. I will hold off on committing this for awhile to give people time to look at it. I know that radical changes are a pain to review, but IMHO the improvement in maintainability is significant. New files that are part of this 'patch', but not included here (I committed these to Subversion): src/include/spd.h src/include/sdram_mode.h src/include/northbridge/intel/e7501/e7501.h Thanks, Steve ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!" #include From yinghai.lu at amd.com Wed Sep 14 20:18:38 2005 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Wed, 14 Sep 2005 11:18:38 -0700 Subject: [LinuxBIOS] APIC IDs for Tyan s2735 Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0614D@ssvlexmb2.amd.com> That is right...that is different to any other E7500 MB. YH -----Original Message----- From: linuxbios-bounces at openbios.org [mailto:linuxbios-bounces at openbios.org] On Behalf Of Steven J. Magnani Sent: Wednesday, September 14, 2005 11:06 AM To: linuxbios at openbios.org Subject: [LinuxBIOS] APIC IDs for Tyan s2735 YhLu - Can you check the mptable for the S2735? If I'm reading it correctly, APIC ID 8 is being used for the ICH, but it seems from the southbridge code that the ICH is hard-coded to 2. ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!" #include -- LinuxBIOS mailing list LinuxBIOS at openbios.org http://www.openbios.org/mailman/listinfo/linuxbios From jcarr at linuxmachines.com Wed Sep 14 20:35:53 2005 From: jcarr at linuxmachines.com (Jeff Carr) Date: Wed, 14 Sep 2005 11:35:53 -0700 Subject: [LinuxBIOS] BIOS Saver discontinued Message-ID: <43286D89.4030309@linuxmachines.com> According to the manufacturer, they are out of the BIOS Saver's and do not plan on manufacturing more. I tried to inquire about what quantity was needed to get them to make more, but didn't hear back from them. This is disappointing. Either the PLCC package was designed to protect the motherboard socket, or it was designed to discourage people from doing bios work. It's horrible. Every time you remove the chip it bends the pins around. It's only a matter of time until the pins break off. Despite being careful with a small screwdriver and even using a PLCC chip puller. Fry's only has one and it's not well designed. I don't fish so I don't have fishing string for that other seemingly troublesome trick. It would be helpful if there was a chip socket that could be pulled straight up with one's fingers. Perhaps there are enough engineers and interest that we could cleverly design such a device (or something else ingenious) and have a bunch of them made? Along the same lines, has anyone tried using different size SST chips? I tried to duplicate the 256KB bios by putting it in a 512KB chip (SST 28SF040A vs 39SF020A). This didn't seem to work (no beep or video but didn't try port 80 parallel card yet). Perhaps someone knows if this should work. Can someone recommend a good place to get a handful of SST 39SF02A PLCC chips for these experiments? Thanks, Jeff From Stephen.Kimball at bench.com Wed Sep 14 20:44:36 2005 From: Stephen.Kimball at bench.com (Stephen.Kimball at bench.com) Date: Wed, 14 Sep 2005 14:44:36 -0400 Subject: [LinuxBIOS] BIOS Saver discontinued Message-ID: <30ADB28314F8B744AB478FB5EDA044B30D3C38@nh-ex01.bench.com> > > Along the same lines, has anyone tried using different size SST chips? I > tried to duplicate the 256KB bios by putting it in a 512KB chip (SST > 28SF040A vs 39SF020A). This didn't seem to work (no beep or video but > didn't try port 80 parallel card yet). Perhaps someone knows if this > should work. Can someone recommend a good place to get a handful of SST > 39SF02A PLCC chips for these experiments? Look for the device data sheet on the SST Web site. If the device is pin compatible, it should work. Usually pin compatible devices have the same first 4 characters and the last 4 describe the capacity. Steve From dfeustel at verizon.net Wed Sep 14 20:55:23 2005 From: dfeustel at verizon.net (Dave Feustel) Date: Wed, 14 Sep 2005 13:55:23 -0500 Subject: [LinuxBIOS] Disk Passwords Message-ID: <200509141355.23321.dfeustel@verizon.net> Does the current Linux Bios support use of disk passwords at bootup as defined in the ATA specs? Thanks, Dave Feustel -- Tired of having to defend against Malware? You know: trojans, viruses, SPYWARE, ADWARE, KEYLOGGERS, rootkits, worms and popups. Then Switch to OpenBSD with a KDE desktop!!! From talbotx at comcast.net Wed Sep 14 21:07:14 2005 From: talbotx at comcast.net (Adam Talbot) Date: Wed, 14 Sep 2005 12:07:14 -0700 Subject: [LinuxBIOS] BIOS Saver discontinued In-Reply-To: <43286D89.4030309@linuxmachines.com> References: <43286D89.4030309@linuxmachines.com> Message-ID: <432874E2.10603@comcast.net> No more BIOS Saver... Hummm. This I may be able to help with. What packages do we want/need? PLCC32 and DIP32? Does that cover 95% of motherboards? I found dental floss works well for pulling the chip. Take two peaces and wrap them around the chip one vertically and one horizontally, tie all four ends together and you have a nice way to pull the chip again and again..... Different size chips. I have a VIA epia-mII that i have been trying to get linuxbios installed on. I am using both the sst 39sf020 (256k) and the sst 39sf040 (512k). The board see's both and is able to boot from both. I did find out that the "stock" bios image will only boot off the 256, when i flash the stock 256k image onto the 512k chip it will not boot. No clue as to why. This could be a function of my programmer, not sure. -Adam Jeff Carr wrote: >According to the manufacturer, they are out of the BIOS Saver's and do >not plan on manufacturing more. I tried to inquire about what quantity >was needed to get them to make more, but didn't hear back from them. > >This is disappointing. Either the PLCC package was designed to protect >the motherboard socket, or it was designed to discourage people from >doing bios work. It's horrible. Every time you remove the chip it bends >the pins around. It's only a matter of time until the pins break off. >Despite being careful with a small screwdriver and even using a PLCC >chip puller. Fry's only has one and it's not well designed. I don't fish >so I don't have fishing string for that other seemingly troublesome trick. > >It would be helpful if there was a chip socket that could be pulled >straight up with one's fingers. Perhaps there are enough engineers and >interest that we could cleverly design such a device (or something else >ingenious) and have a bunch of them made? > >Along the same lines, has anyone tried using different size SST chips? I >tried to duplicate the 256KB bios by putting it in a 512KB chip (SST >28SF040A vs 39SF020A). This didn't seem to work (no beep or video but >didn't try port 80 parallel card yet). Perhaps someone knows if this >should work. Can someone recommend a good place to get a handful of SST >39SF02A PLCC chips for these experiments? > >Thanks, >Jeff > > > From steve at nexpath.com Wed Sep 14 21:21:14 2005 From: steve at nexpath.com (Steve Gehlbach) Date: Wed, 14 Sep 2005 12:21:14 -0700 Subject: [LinuxBIOS] BIOS Saver discontinued In-Reply-To: <43286D89.4030309@linuxmachines.com> References: <43286D89.4030309@linuxmachines.com> Message-ID: <4328782A.1080302@nexpath.com> >Perhaps there are enough engineers and >interest that we could cleverly design such a device (or something else >ingenious) and have a bunch of them made? > > > The best solution I have found is a hole in the board, so you can poke it out. I put one in all of the boards I design, but I have never seen one on a motherboard. All of the pullers I have used eventually bend pins. Have you tried dental flloss? It works pretty well, but you need a puller to get the first one out. Steve From smithbone at gmail.com Wed Sep 14 21:19:49 2005 From: smithbone at gmail.com (Richard Smith) Date: Wed, 14 Sep 2005 14:19:49 -0500 Subject: [LinuxBIOS] BIOS Saver discontinued In-Reply-To: <432874E2.10603@comcast.net> References: <43286D89.4030309@linuxmachines.com> <432874E2.10603@comcast.net> Message-ID: <8a0c3678050914121951016cce@mail.gmail.com> > 256, when i flash the stock 256k image onto the 512k chip it will not > boot. No clue as to why. This could be a function of my programmer, not > sure. Duplicate the image into both of halfs of the 512k chip. Whats probally happening is that the additional address line on the 512k chip is not pulled down on the board so its floating and your chip is selecting addresses in the unprogrammed area of the chip. If you dup the image then it won't matter what the floating address line is doing. That is as long as the line dosn't float into the "undefined" range and cause a latchup. -- Richard A. Smith From jcarr at linuxmachines.com Wed Sep 14 21:47:30 2005 From: jcarr at linuxmachines.com (Jeff Carr) Date: Wed, 14 Sep 2005 12:47:30 -0700 Subject: [LinuxBIOS] BIOS Saver discontinued In-Reply-To: <30ADB28314F8B744AB478FB5EDA044B30D3C38@nh-ex01.bench.com> References: <30ADB28314F8B744AB478FB5EDA044B30D3C38@nh-ex01.bench.com> Message-ID: <43287E52.8050308@linuxmachines.com> On 09/14/2005 11:44 AM, Stephen.Kimball at bench.com wrote: >>tried to duplicate the 256KB bios by putting it in a 512KB chip (SST >>28SF040A vs 39SF020A). This didn't seem to work (no beep or video but >>didn't try port 80 parallel card yet). Perhaps someone knows if this >>should work. Can someone recommend a good place to get a handful of > > SST > >>39SF02A PLCC chips for these experiments? > > > Look for the device data sheet on the SST Web site. If the device is > pin compatible, it should work. Usually pin compatible devices have the > same first 4 characters and the last 4 describe the capacity. That's crazy! The PLCC 32pin connector doesn't have a standard pin layout? Wow; that's really silly. I see now on the datasheets. Pins 1(A18), 2(A16) & 30(A17) can be NC on the 256KB chip. Makes sense. Seems like this chip should work to me; just thought I would ask. I don't understand the memory layout & behavior of the pc bios enough yet to know if this should or shouldn't work yet. Jeff From jcarr at linuxmachines.com Wed Sep 14 21:52:20 2005 From: jcarr at linuxmachines.com (Jeff Carr) Date: Wed, 14 Sep 2005 12:52:20 -0700 Subject: [LinuxBIOS] BIOS Saver discontinued In-Reply-To: <4328782A.1080302@nexpath.com> References: <43286D89.4030309@linuxmachines.com> <4328782A.1080302@nexpath.com> Message-ID: <43287F74.9030904@linuxmachines.com> On 09/14/2005 12:21 PM, Steve Gehlbach wrote: > >> Perhaps there are enough engineers and >> interest that we could cleverly design such a device (or something else >> ingenious) and have a bunch of them made? >> >> >> > The best solution I have found is a hole in the board, so you can poke > it out. I put one in all of the boards I design, but I have never seen > one on a motherboard. All of the pullers I have used eventually bend > pins. Have you tried dental flloss? It works pretty well, but you need > a puller to get the first one out. Ok, ok -- I'll listen to the masses and follow this method. :) Still, I'd rather make an adapter. I've been told that production motherboard PLCC adapters are usally only rated for about 10 insertions. An adapter must be manufactured I think. Perhaps someone has some experience with plastic mold injection adapter design & fabrication. Jeff From jcarr at linuxmachines.com Wed Sep 14 21:53:52 2005 From: jcarr at linuxmachines.com (Jeff Carr) Date: Wed, 14 Sep 2005 12:53:52 -0700 Subject: [LinuxBIOS] BIOS Saver discontinued In-Reply-To: <432874E2.10603@comcast.net> References: <43286D89.4030309@linuxmachines.com> <432874E2.10603@comcast.net> Message-ID: <43287FD0.9070306@linuxmachines.com> On 09/14/2005 12:07 PM, Adam Talbot wrote: > > No more BIOS Saver... Hummm. This I may be able to help with. What > packages do we want/need? PLCC32 and DIP32? Does that cover 95% of > motherboards? I'd say more than half of currently manufactured motherboards are PLCC32. > Different size chips. I have a VIA epia-mII that i have been trying to > get linuxbios installed on. I am using both the sst 39sf020 (256k) and > the sst 39sf040 (512k). The board see's both and is able to boot from > both. I did find out that the "stock" bios image will only boot off the > 256, when i flash the stock 256k image onto the 512k chip it will not > boot. No clue as to why. This could be a function of my programmer, not > sure. Thanks for the feedback; good to know I'm not the only one. Jeff From jcarr at linuxmachines.com Wed Sep 14 21:57:06 2005 From: jcarr at linuxmachines.com (Jeff Carr) Date: Wed, 14 Sep 2005 12:57:06 -0700 Subject: [LinuxBIOS] BIOS Saver discontinued In-Reply-To: <8a0c3678050914121951016cce@mail.gmail.com> References: <43286D89.4030309@linuxmachines.com> <432874E2.10603@comcast.net> <8a0c3678050914121951016cce@mail.gmail.com> Message-ID: <43288092.5000109@linuxmachines.com> On 09/14/2005 12:19 PM, Richard Smith wrote: >>256, when i flash the stock 256k image onto the 512k chip it will not >>boot. No clue as to why. This could be a function of my programmer, not >>sure. > > > Duplicate the image into both of halfs of the 512k chip. Whats > probally happening is that the additional address line on the 512k > chip is not pulled down on the board so its floating and your chip is > selecting addresses in the unprogrammed area of the chip. If you dup > the image then it won't matter what the floating address line is > doing. > > That is as long as the line dosn't float into the "undefined" range > and cause a latchup. Clever. I'll try that now. I think I can reach in and touch Pin 1,2 & 30 with a small wire; then just ground them to the case. (?) Jeff From linuxbios at xdr.com Wed Sep 14 21:56:42 2005 From: linuxbios at xdr.com (Dave Ashley) Date: Wed, 14 Sep 2005 12:56:42 -0700 Subject: [LinuxBIOS] PLCC removal trick Message-ID: <200509141956.j8EJughS009640@xdr.com> I don't know about anyone else but the dental floss idea didn't work at all for me, the floss interferes with the pins. I had this idea on how to remove the chip easily, but I haven't tried it. Just get some strong epoxy and glue onto the top surface of the flashrom something to act as a handle. After it's dry, use that to pull the chip out. JB Weld might work. -Dave From linuxbios at xdr.com Wed Sep 14 22:02:30 2005 From: linuxbios at xdr.com (Dave Ashley) Date: Wed, 14 Sep 2005 13:02:30 -0700 Subject: [LinuxBIOS] Re: serial debug messages workaround Message-ID: <200509142002.j8EK2UcR009688@xdr.com> Doug Bell was having trouble with serial out on epia-sp. I tracked this problem to the cache. If the early_mtrr_init() call isn't done, the problem goes away. Within early_mtrr_init() if the call to enable_cache() is commented out, the problem goes away. Enabling the cache on the c3 Nehemia is causing strange behaviour. This mailing list is pretty much dead as regards actual help, NXTV is working on epia-sp support and we'll be contributing our results back to the project. Some support would be in order. I/NXTV contributed plenty years ago to the epia-m support for V1, as many old timers will attest. -Dave From noodles at earth.li Wed Sep 14 22:13:13 2005 From: noodles at earth.li (Jonathan McDowell) Date: Wed, 14 Sep 2005 21:13:13 +0100 Subject: [LinuxBIOS] Re: serial debug messages workaround In-Reply-To: <200509142002.j8EK2UcR009688@xdr.com> References: <200509142002.j8EK2UcR009688@xdr.com> Message-ID: <20050914201313.GC21646@earth.li> On Wed, Sep 14, 2005 at 01:02:30PM -0700, Dave Ashley wrote: > Doug Bell was having trouble with serial out on epia-sp. > > I tracked this problem to the cache. If the early_mtrr_init() call > isn't done, the problem goes away. Within early_mtrr_init() if the > call to enable_cache() is commented out, the problem goes away. > Enabling the cache on the c3 Nehemia is causing strange behaviour. I committed similar change for EPIA-M earlier today; I'm now getting a lot further with a plain SVN tree on EPIA-M than I have for a long while. J. -- Conscience is the fear of getting | Black Cat Networks Ltd caught. | http://www.blackcatnetworks.co.uk/ | UK Web, domain and email hosting From jcarr at linuxmachines.com Wed Sep 14 22:19:48 2005 From: jcarr at linuxmachines.com (Jeff Carr) Date: Wed, 14 Sep 2005 13:19:48 -0700 Subject: [LinuxBIOS] BIOS Saver discontinued In-Reply-To: <8a0c3678050914121951016cce@mail.gmail.com> References: <43286D89.4030309@linuxmachines.com> <432874E2.10603@comcast.net> <8a0c3678050914121951016cce@mail.gmail.com> Message-ID: <432885E4.1080902@linuxmachines.com> On 09/14/2005 12:19 PM, Richard Smith wrote: >>256, when i flash the stock 256k image onto the 512k chip it will not >>boot. No clue as to why. This could be a function of my programmer, not >>sure. > > > Duplicate the image into both of halfs of the 512k chip. Whats > probally happening is that the additional address line on the 512k > chip is not pulled down on the board so its floating and your chip is > selecting addresses in the unprogrammed area of the chip. If you dup > the image then it won't matter what the floating address line is > doing. > > That is as long as the line dosn't float into the "undefined" range > and cause a latchup. > You are clever. That worked. At least one time anyway. :) Good, I can finally give linuxbios a go. First to try flash & burn now. Jeff From smithbone at gmail.com Wed Sep 14 22:38:56 2005 From: smithbone at gmail.com (Richard Smith) Date: Wed, 14 Sep 2005 15:38:56 -0500 Subject: [LinuxBIOS] PLCC removal trick In-Reply-To: <200509141956.j8EJughS009640@xdr.com> References: <200509141956.j8EJughS009640@xdr.com> Message-ID: <8a0c367805091413381ea7d9ce@mail.gmail.com> On 9/14/05, Dave Ashley wrote: > I don't know about anyone else but the dental floss idea didn't > work at all for me, the floss interferes with the pins. > > I had this idea on how to remove the chip easily, but I > haven't tried it. Just get some strong epoxy and glue > onto the top surface of the flashrom something to > act as a handle. After it's dry, use that to pull the > chip out. > > JB Weld might work. If you are doing that much LB work then you _really_ need and eprom emulator. It will pay for itself in the time you save waiting on the flash to program. Tech Tools has some good ones for about $300 and the 16bit DOS loader programs that they provide in addition to the windows clients will run under DOSEMU fine. (As long as you use the fast parallel port option) The windows clients might run under WINE but I've not tried. Seriously. Get an emulator. You will be happy you did. You will also probally need a DIP to PLCC adapter. So I guess the real total is $500 (depending on the adapter you buy) . Still its totally worth the money. -- Richard A. Smith From linuxbios at xdr.com Wed Sep 14 23:24:31 2005 From: linuxbios at xdr.com (Dave Ashley) Date: Wed, 14 Sep 2005 14:24:31 -0700 Subject: [LinuxBIOS] Re: serial debug messages workaround Message-ID: <200509142124.j8ELOVHT010123@xdr.com> Jon McDowell wrote: >I committed similar change for EPIA-M earlier today; I'm now getting a I looked at V1 epia-m support and found there was a workaround: /* new Via Edens seem to need an early invalidate - before enabling * caches */ invd When I put this code in auto.c (V2) before the early_mtrr_init(): __asm__ volatile (" invd"); all the strange behaviour goes away, and booting is fast again. -Dave From linuxbios at xdr.com Wed Sep 14 23:36:33 2005 From: linuxbios at xdr.com (Dave Ashley) Date: Wed, 14 Sep 2005 14:36:33 -0700 Subject: [LinuxBIOS] Re: serial debug messages workaround Message-ID: <200509142136.j8ELaXIB010194@xdr.com> >When I put this code in auto.c (V2) before the early_mtrr_init(): > __asm__ volatile (" invd"); I spoke too soon, the problem isn't fixed by just doing the invd. -Dave From noodles at earth.li Thu Sep 15 00:10:21 2005 From: noodles at earth.li (Jonathan McDowell) Date: Wed, 14 Sep 2005 23:10:21 +0100 Subject: [LinuxBIOS] Re: serial debug messages workaround In-Reply-To: <200509142136.j8ELaXIB010194@xdr.com> References: <200509142136.j8ELaXIB010194@xdr.com> Message-ID: <20050914221021.GD21646@earth.li> On Wed, Sep 14, 2005 at 02:36:33PM -0700, Dave Ashley wrote: > >When I put this code in auto.c (V2) before the early_mtrr_init(): > > __asm__ volatile (" invd"); > I spoke too soon, the problem isn't fixed by just doing the invd. Yeah, I'd originally tried adding that too but then realised it wasn't needed. J. -- Hi Ho, Hi Ho, it's Hand Grenades | .''`. Debian GNU/Linux Developer I throw! | : :' : Happy to accept PGP signed | `. `' or encrypted mail - RSA + | `- DSA keys on the keyservers. From jcarr at linuxmachines.com Thu Sep 15 03:44:30 2005 From: jcarr at linuxmachines.com (Jeff Carr) Date: Wed, 14 Sep 2005 18:44:30 -0700 Subject: [LinuxBIOS] PLCC removal trick In-Reply-To: <8a0c367805091413381ea7d9ce@mail.gmail.com> References: <200509141956.j8EJughS009640@xdr.com> <8a0c367805091413381ea7d9ce@mail.gmail.com> Message-ID: <4328D1FE.1090302@linuxmachines.com> On 09/14/2005 01:38 PM, Richard Smith wrote: > If you are doing that much LB work then you _really_ need and eprom > emulator. I see from this page: http://www.antratek.nl/EPROM-emulators-e.html > It will pay for itself in the time you save waiting on the > flash to program. More than that I think. How smart are these devices? Can one single step through instructions or dump out the registers on the CPU.(?) > Tech Tools has some good ones for about $300 and the 16bit DOS loader > programs that they provide in addition to the windows clients will run > under DOSEMU fine. Interesting. Do you have some URL's? The FAQ doesn't contain anything like this in it. > (As long as you use the fast parallel port option) > The windows clients might run under WINE but I've not tried. Perhaps you can send some screenshots of the software or email some of the capabilities of using an emulator. Man, if only someone made one that hooked up to gdb, then we would be in business. > Seriously. Get an emulator. You will be happy you did. Perhaps. This is the first I've heard of them so I'd like to see what is out there in the market. > You will also probally need a DIP to PLCC adapter. Right. The adapter size is likely to be a problem. Some boards will not have the space to fit such an adapter. Guess it's back to the making adapters game. Thanks for the pointers, Jeff From jcarr at linuxmachines.com Thu Sep 15 04:01:48 2005 From: jcarr at linuxmachines.com (Jeff Carr) Date: Wed, 14 Sep 2005 19:01:48 -0700 Subject: [LinuxBIOS] PLCC removal trick In-Reply-To: <4328D1FE.1090302@linuxmachines.com> References: <200509141956.j8EJughS009640@xdr.com> <8a0c367805091413381ea7d9ce@mail.gmail.com> <4328D1FE.1090302@linuxmachines.com> Message-ID: <4328D60C.90603@linuxmachines.com> On 09/14/2005 06:44 PM, Jeff Carr wrote: > On 09/14/2005 01:38 PM, Richard Smith wrote: >>Tech Tools has some good ones for about $300 and the 16bit DOS loader > Perhaps you can send some screenshots of the software or email some of > the capabilities of using an emulator. Sorry, I should have googled more first. The manuals are at: http://www.tech-tools.com/romtools.htm Jeff From talbotx at comcast.net Thu Sep 15 04:06:53 2005 From: talbotx at comcast.net (Adam Talbot) Date: Wed, 14 Sep 2005 19:06:53 -0700 Subject: [LinuxBIOS] BIOS Saver discontinued In-Reply-To: <432885E4.1080902@linuxmachines.com> References: <43286D89.4030309@linuxmachines.com> <432874E2.10603@comcast.net> <8a0c3678050914121951016cce@mail.gmail.com> <432885E4.1080902@linuxmachines.com> Message-ID: <4328D73D.2090502@comcast.net> Have you guy's looked at this as a replacement? http://www.loet.de/flasher_en.html -Adam Jeff Carr wrote: >On 09/14/2005 12:19 PM, Richard Smith wrote: > > >>>256, when i flash the stock 256k image onto the 512k chip it will not >>>boot. No clue as to why. This could be a function of my programmer, not >>>sure. >>> >>> >>Duplicate the image into both of halfs of the 512k chip. Whats >>probally happening is that the additional address line on the 512k >>chip is not pulled down on the board so its floating and your chip is >>selecting addresses in the unprogrammed area of the chip. If you dup >>the image then it won't matter what the floating address line is >>doing. >> >>That is as long as the line dosn't float into the "undefined" range >>and cause a latchup. >> >> >> > >You are clever. That worked. At least one time anyway. :) > >Good, I can finally give linuxbios a go. First to try flash & burn now. > >Jeff > > > From jcarr at linuxmachines.com Thu Sep 15 04:50:52 2005 From: jcarr at linuxmachines.com (Jeff Carr) Date: Wed, 14 Sep 2005 19:50:52 -0700 Subject: [LinuxBIOS] BIOS Saver discontinued In-Reply-To: <4328D73D.2090502@comcast.net> References: <43286D89.4030309@linuxmachines.com> <432874E2.10603@comcast.net> <8a0c3678050914121951016cce@mail.gmail.com> <432885E4.1080902@linuxmachines.com> <4328D73D.2090502@comcast.net> Message-ID: <4328E18C.6040105@linuxmachines.com> On 09/14/2005 07:06 PM, Adam Talbot wrote: > Have you guy's looked at this as a replacement? > http://www.loet.de/flasher_en.html No, woulda never found that. I put it in the FAQ. Looks perfect to me. And someone just added kernel 2.6 drivers in March. http://sourceforge.net/projects/ctflasher/ Perfect, thanks a lot. Jeff From linuxbios at xdr.com Thu Sep 15 16:02:20 2005 From: linuxbios at xdr.com (Dave Ashley) Date: Thu, 15 Sep 2005 07:02:20 -0700 Subject: [LinuxBIOS] PLCC removal trick Message-ID: <200509151402.j8FE2Kc2015346@xdr.com> >Sorry, I should have googled more first. The manuals are at: >http://www.tech-tools.com/romtools.htm I looked at the FlexROM III, it appears to emulate just flat 8 or 16 bit devices. PLCC's are more complicated, they frequently make use of an LPC interface that clocks in 4 bits of data at a time (as I recall) to get the address into the chip, then clocks out 4 bits of data at a time. I think an operation is 16 bits at a time. This is all transparent from the system's perspective. However behind the scenes it is a complicated dance. LPC = Low Pin Count -Dave From linuxbios at xdr.com Thu Sep 15 17:17:25 2005 From: linuxbios at xdr.com (Dave Ashley) Date: Thu, 15 Sep 2005 08:17:25 -0700 Subject: [LinuxBIOS] EPIA-M + EPIA-SP V2 cache init Message-ID: <200509151517.j8FFHPIj015642@xdr.com> I've had success in V2 for EPIA-SP by pulling ASM code from V1 and replacing the whole early_mtrr_init() call from V2, with this, placed right at the start of auto.c (see below). The romcc generated code works fast enough, but it really makes a difference when the linux kernel is uncompressed later. I don't really know what is happening though, I'm not an expert on the low level cache setup. There is difference between the V2 early_mtrr_init functionality and what was in V1. __asm__ volatile ( "\n" " invd\n" "earlymtrr_start:\n" " xorl %%eax, %%eax\n" " xorl %%edx, %%edx\n" " movl $fixed_mtrr_msr, %%esi\n" "clear_fixed_var_mtrr:\n" " lodsl (%%esi), %%eax\n" " testl %%eax, %%eax\n" " jz clear_fixed_var_mtrr_out\n" " movl %%eax, %%ecx\n" " xorl %%eax, %%eax\n" " wrmsr\n" " jmp clear_fixed_var_mtrr\n" "clear_fixed_var_mtrr_out:\n" "set_fixed_mtrr:\n" " movl $0x250, %%ecx\n" " rdmsr\n" " movl $0x06060606, %%edx\n" " movl $0x06060606, %%eax\n" " wrmsr\n" " movl $0x258, %%ecx\n" " rdmsr\n" " movl $0x06060606, %%edx\n" " movl $0x06060606, %%eax\n" " wrmsr\n" "set_var_mtrr:\n" " movl $0x200, %%ecx\n" " rdmsr\n" " andl $0xfffffff0, %%edx\n" " orl $0x00000000, %%edx\n" " andl $0x00000f00, %%eax\n" " orl $0x00000006, %%eax\n" " wrmsr\n" " movl $0x201, %%ecx\n" " rdmsr\n" " andl $0xfffffff0, %%edx\n" " orl $0x0000000f, %%edx\n" " andl $0x000007ff, %%eax\n" " orl $0xf0000800, %%eax\n" " wrmsr\n" "enable_mtrr:\n" " movl $0x2ff, %%ecx\n" " xorl %%edx, %%edx\n" " movl $0x00000c00, %%eax\n" " wrmsr\n" " movl %%cr0, %%eax\n" " andl $0x9fffffff,%%eax\n" " movl %%eax, %%cr0\n" " jmp earlymtrr_end\n" "fixed_mtrr_msr:\n" " .long 0x250, 0x258, 0x259\n" " .long 0x268, 0x269, 0x26A\n" " .long 0x26B, 0x26C, 0x26D\n" " .long 0x26E, 0x26F\n" "var_mtrr_msr:\n" " .long 0x200, 0x201, 0x202, 0x203\n" " .long 0x204, 0x205, 0x206, 0x207\n" " .long 0x208, 0x209, 0x20A, 0x20B\n" " .long 0x20C, 0x20D, 0x20E, 0x20F\n" " .long 0x000\n" "earlymtrr_end:\n"); From gfiala at s.netic.de Thu Sep 15 20:06:05 2005 From: gfiala at s.netic.de (Guido Fiala) Date: Thu, 15 Sep 2005 20:06:05 +0200 Subject: [LinuxBIOS] PLCC removal trick In-Reply-To: <200509141956.j8EJughS009640@xdr.com> References: <200509141956.j8EJughS009640@xdr.com> Message-ID: <200509152006.05821.gfiala@s.netic.de> On Wednesday 14 September 2005 21:56, Dave Ashley wrote: > I don't know about anyone else but the dental floss idea didn't > work at all for me, the floss interferes with the pins. > > I had this idea on how to remove the chip easily, but I > haven't tried it. Just get some strong epoxy and glue > onto the top surface of the flashrom something to > act as a handle. After it's dry, use that to pull the > chip out. Instead of epoxy you might use hot-glue (or whats it called), or, even better, "Power Strip" - a removable 2-side-glue flexible tape... From steve at nexpath.com Thu Sep 15 20:40:31 2005 From: steve at nexpath.com (Steve Gehlbach) Date: Thu, 15 Sep 2005 11:40:31 -0700 Subject: [LinuxBIOS] PLCC removal trick In-Reply-To: <200509152006.05821.gfiala@s.netic.de> References: <200509141956.j8EJughS009640@xdr.com> <200509152006.05821.gfiala@s.netic.de> Message-ID: <4329C01F.5000000@nexpath.com> Guido Fiala wrote: >On Wednesday 14 September 2005 21:56, Dave Ashley wrote: > > >>I don't know about anyone else but the dental floss idea didn't >>work at all for me, the floss interferes with the pins. >> >>I had this idea on how to remove the chip easily, but I >>haven't tried it. Just get some strong epoxy and glue >>onto the top surface of the flashrom something to >>act as a handle. After it's dry, use that to pull the >>chip out. >> >> > >Instead of epoxy you might use hot-glue (or whats it called), >or, even better, "Power Strip" - a removable 2-side-glue flexible tape... > > > > It's a good idea, but keep in mind that some programmers (such as my Needhams) have a cover that closes over the chip to program it, so a removal knob might interfere with closing the cover. Maybe the programmer will make contact anyway with the cover open, haven't tried it so I don't know. Steve From jimc at rmtg.com Thu Sep 15 20:48:43 2005 From: jimc at rmtg.com (Jim Cooper) Date: Thu, 15 Sep 2005 12:48:43 -0600 Subject: [LinuxBIOS] PLCC removal trick Message-ID: <7770D1D3403FEB4F9C05C20A923136CCF4B16E@PIONEER.corp.rmtg.com> I have heard of using canned air to blow the solder out and crystallize it, but I don't think I would try this. I use a heat gun and pair of IC tweezers. Whatever you do, add some solder paste so it reflows first. Ideally you should use a tip for the PLCC that concentrates the heat on the legs of the chip and doesn't overheat the chip itself. Take a look at the temp ratings of the chip if you use the heatgun approach. Most chips are only rated to take that kind of heat a little longer than it takes to reflow the solder. -----Original Message----- From: linuxbios-bounces at openbios.org [mailto:linuxbios-bounces at openbios.org] On Behalf Of Steve Gehlbach Sent: Thursday, September 15, 2005 11:41 AM To: Guido Fiala Cc: linuxbios at openbios.org Subject: Re: [LinuxBIOS] PLCC removal trick Guido Fiala wrote: >On Wednesday 14 September 2005 21:56, Dave Ashley wrote: > > >>I don't know about anyone else but the dental floss idea didn't work >>at all for me, the floss interferes with the pins. >> >>I had this idea on how to remove the chip easily, but I haven't tried >>it. Just get some strong epoxy and glue onto the top surface of the >>flashrom something to act as a handle. After it's dry, use that to >>pull the chip out. >> >> > >Instead of epoxy you might use hot-glue (or whats it called), or, even >better, "Power Strip" - a removable 2-side-glue flexible tape... > > > > It's a good idea, but keep in mind that some programmers (such as my Needhams) have a cover that closes over the chip to program it, so a removal knob might interfere with closing the cover. Maybe the programmer will make contact anyway with the cover open, haven't tried it so I don't know. Steve -- LinuxBIOS mailing list LinuxBIOS at openbios.org http://www.openbios.org/mailman/listinfo/linuxbios From Rodney.Kittleson at bench.com Thu Sep 15 21:06:50 2005 From: Rodney.Kittleson at bench.com (Rodney.Kittleson at bench.com) Date: Thu, 15 Sep 2005 14:06:50 -0500 Subject: [LinuxBIOS] PLCC removal trick Message-ID: <2A4A703C1E2835429F547DFFD236B7D103C788@mn-ex1.mn.bench.com> I was looking at the PromJet over a year ago, it runs around $1,500 with the LPC/FWH option. They seem to nickle and dime you with this unit. Base price + LPC/FWH support + 32PLCC adapter + ethernet (Parallel Port is standard). http://www.emutec.com/pjetmain.html Rod > > > >Sorry, I should have googled more first. The manuals are at: > >http://www.tech-tools.com/romtools.htm > > I looked at the FlexROM III, it appears to emulate just flat 8 or 16 > bit devices. PLCC's are more complicated, they frequently make use of > an LPC interface that clocks in 4 bits of data at a time (as I recall) > to get the address into the chip, then clocks out 4 bits of data at a > time. I think an operation is 16 bits at a time. This is all > transparent > from the system's perspective. However behind the scenes it is a > complicated dance. > > LPC = Low Pin Count > > -Dave > > -- > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > From rminnich at lanl.gov Thu Sep 15 23:17:51 2005 From: rminnich at lanl.gov (Ronald G Minnich) Date: Thu, 15 Sep 2005 15:17:51 -0600 Subject: [LinuxBIOS] linuxbios summit confusion Message-ID: <4329E4FF.90507@lanl.gov> folks, the linuxbios summit is oct. 11-13, in spite of what you may have seen on the web page. thanks! ron From linuxbios at xdr.com Thu Sep 15 23:36:50 2005 From: linuxbios at xdr.com (Dave Ashley) Date: Thu, 15 Sep 2005 14:36:50 -0700 Subject: [LinuxBIOS] eth1: Too much work at interrupt, IntrStatus=0x0001. Message-ID: <200509152136.j8FLaoEN018534@xdr.com> We've got epia-sp almost into linux fully, but RTL8139 (eth1) or the VIA 3065 (eth0) don't work properly. Interrupts are occuring as expected on ethernet packets. We're trying to work with the RTL8139 for now which is a card plugged into the epia-sp. It's able to act as a pci bus master. I suspect something about the PCI isn't working, like the card isn't able to dma into host memory or something similiar. Inside linux drivers/net/8139too.c inside function rtl8139_rx_interrupt if ((rx_size > (MAX_ETH_FRAME_SIZE+4)) || (rx_size < 8) || (!(rx_status & RxStatusOK))) { rtl8139_rx_err (rx_status, dev, tp, ioaddr); printk("here2 rx_size = %d\n", rx_size); // (DA) return; } The interrupt service routine is exiting because rx_size is always 0. This is the size of the received packet I think. A similiar problem is occuring in the 3065 ethernet. We're failing to do something within linuxbios that's preventing pci devices from functioning properly. Does anyone have any suggestions? I'm hoping these symptoms are familiar. Thanks-- Dave From linuxbios at xdr.com Fri Sep 16 00:33:36 2005 From: linuxbios at xdr.com (Dave Ashley) Date: Thu, 15 Sep 2005 15:33:36 -0700 Subject: [LinuxBIOS] More epia-sp + ethernet Message-ID: <200509152233.j8FMXawI018851@xdr.com> I switched from the rtl8139 to the rhine VT6102 debugging, since this is actually working well enough for etherboot to successfully get a bootfile. Within linux the via-rhine.c reports when debugging is turned up: eth0: Something Wicked happened! 00000040. This bit (40) represents a PCI Bus Error. Here's our linuxbios/etherboot/kernel output (see below). Any advice appreciated. -Dave LinuxBIOS-1.1.8.0Normal Thu Sep 15 14:55:02 PDT 2005 starting... MISC FIXUP Done Enabling SMBUS Enable skipped ENABLING MAINBOARD DEVICES MAINBOARD ENABLED ENABLING SHADOW RAM SHADOW RAM ENABLED ENABLING SDRAM SETTING NORTHBRIDGE FUNCTION2 REGS djb_replicate_award2_regs starting 00000200 is the cpu controller djb_replicate_award2_regs returning 00:06 11 59 22 06 00 00 02 00 00 00 06 00 00 00 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 00 00 00 00 00 00 00 00 00 00 00 00 40:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50:a8 be ef 88 30 28 00 69 00 30 00 00 00 b2 88 c7 60:ff ff 00 ff ff 00 ff 00 00 00 00 00 00 00 00 00 70:bb cc bb cc 70 08 30 00 00 00 00 00 00 00 00 00 80:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 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:00 00 00 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:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Setting SDRAM registers djb_replicate_award3_regs starting 00000300 is the dram controller djb_replicate_award3_regs returning 00:06 11 59 32 06 00 00 02 00 00 00 06 00 00 00 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 00 00 00 00 00 00 00 00 00 00 00 00 40:01 01 01 01 01 01 01 01 45 00 00 00 00 00 00 00 50:e0 00 00 00 01 0a a5 1a 10 00 00 00 00 00 00 00 60:01 00 00 00 00 99 82 00 85 8f 65 10 00 00 80 00 70:7a 77 3b 3e 94 00 0e 12 13 11 a1 62 00 00 00 00 80:00 00 30 00 00 ff 01 00 00 00 00 00 00 00 00 00 90:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0:00 00 00 00 08 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:00 00 00 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:aa 00 aa 00 99 00 00 00 ee 00 ee 00 10 11 00 00 f0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ENABLING SDRAM 00000200 is the dram function 00000300 is the dram function QUICK CHECKING SDRAM MAIN is DONE Copying LinuxBIOS into ram. Jumping to LinuxBIOS. LinuzBIOS-1.1.8.0Normal Thu Sep 15 14:55:02 PDT 2005 booting... Enumerating buses... Finding PCI configuration type. PCI: Using configuration type 1 PCI_DOMAIN: 0000 enabled PCI: pci_scan_bus for bus 0 PCI: 00:00.0 [1106/0259] enabled PCI: 00:00.1 [1106/1259] enabled PCI: 00:00.2 [1106/2259] enabled PCI: 00:00.3 [1106/3259] enabled PCI: 00:00.4 [1106/4259] enabled PCI: 00:00.7 [1106/7259] enabled PCI: 00:01.0 [1106/b198] enabled PCI: 00:0d.0 [1106/3044] enabled PCI: 00:0f.0 [1106/3149] enabled PCI: 00:0f.1 [1106/0571] enabled PCI: 00:10.0 [1106/3038] enabled PCI: 00:10.1 [1106/3038] enabled PCI: 00:10.2 [1106/3038] enabled PCI: 00:10.3 [1106/3038] enabled PCI: 00:10.4 [1106/3104] enabled PCI: 00:11.0 [1106/3227] enabled PCI: 00:11.5 [1106/3059] enabled PCI: 00:11.6 [1106/3068] enabled PCI: 00:12.0 [1106/3065] enabled PCI: 00:14.0 [10ec/8139] enabled PCI: pci_scan_bus for bus 1 PCI: pci_scan_bus returning with max=01 PCI: pci_scan_bus returning with max=01 done Allocating resources... Reading resources... (DA) pci_bridge_read_bases 1c = f0 (DA) pci_bridge_read_bases 1d = 0 PCI: 00:01.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 1 io PCI: 00:01.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 1 prefmem PCI: 00:01.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 1 mem Done reading resources. Setting resources... ERROR! register 0x5c is not set! ERROR! register 0x5d is not set! I would set ram size to 0x200000 Kbytes PCI: 00:00.0 10 <- [0x00e0000000 - 0x00efffffff] prefmem PCI: 00:0d.0 10 <- [0x00f0004000 - 0x00f00047ff] mem PCI: 00:0d.0 14 <- [0x0000002400 - 0x000000247f] io PCI: 00:0f.0 10 <- [0x0000002820 - 0x0000002827] io PCI: 00:0f.0 14 <- [0x0000002840 - 0x0000002843] io PCI: 00:0f.0 18 <- [0x0000002830 - 0x0000002837] io PCI: 00:0f.0 1c <- [0x0000002850 - 0x0000002853] io PCI: 00:0f.0 20 <- [0x0000002800 - 0x000000280f] io PCI: 00:0f.0 24 <- [0x0000001000 - 0x00000010ff] io PCI: 00:0f.1 20 <- [0x0000002810 - 0x000000281f] io PCI: 00:10.0 20 <- [0x0000002480 - 0x000000249f] io PCI: 00:10.1 20 <- [0x00000024a0 - 0x00000024bf] io PCI: 00:10.2 20 <- [0x00000024c0 - 0x00000024df] io PCI: 00:10.3 20 <- [0x00000024e0 - 0x00000024ff] io PCI: 00:10.4 10 <- [0x00f0005000 - 0x00f00050ff] mem PCI: 00:11.5 10 <- [0x0000001400 - 0x00000014ff] io PCI: 00:11.6 10 <- [0x0000001800 - 0x00000018ff] io PCI: 00:12.0 10 <- [0x0000001c00 - 0x0000001cff] io PCI: 00:12.0 14 <- [0x00f0006000 - 0x00f00060ff] mem PCI: 00:14.0 10 <- [0x0000002000 - 0x00000020ff] io PCI: 00:14.0 14 <- [0x00f0007000 - 0x00f00070ff] mem PCI: 00:14.0 30 <- [0x00f0000000 - 0x00f0003fff] romem Done setting resources. Done allocating resources. Enabling resourcess... PCI: 00:00.0 subsystem <- 00/00 PCI: 00:00.0 cmd <- 146 PCI: 00:00.1 subsystem <- 00/00 PCI: 00:00.1 cmd <- 146 PCI: 00:00.2 cmd <- 146 PCI: 00:00.3 cmd <- 146 PCI: 00:00.4 cmd <- 146 PCI: 00:00.7 cmd <- 146 PCI: 00:01.0 bridge ctrl <- 0003 PCI: 00:01.0 cmd <- 147 PCI: 00:0d.0 cmd <- 1c3 PCI: 00:0f.0 cmd <- 141 PCI: 00:0f.1 cmd <- 1c1 PCI: 00:10.0 cmd <- 141 PCI: 00:10.1 cmd <- 141 PCI: 00:10.2 cmd <- 141 PCI: 00:10.3 cmd <- 141 PCI: 00:10.4 cmd <- 142 PCI: 00:11.0 cmd <- 1c7 PCI: 00:11.5 cmd <- 141 PCI: 00:11.6 cmd <- 141 PCI: 00:12.0 cmd <- 1c3 PCI: 00:14.0 cmd <- 143 done. Initializing devices... Root Device init PCI: 00:00.0 init PCI: 00:00.1 init PCI: 00:00.2 init PCI: 00:00.3 init PCI: 00:00.4 init PCI: 00:00.7 init PCI: 00:0d.0 init PCI: 00:0f.0 init PCI: 00:0f.1 init Enabling VIA IDE. enables in reg 0x40 0x38 enables in reg 0x40 read back as 0x3b enables in reg 0x9 0x8a enables in reg 0x9 read back as 0x8f command in reg 0x4 0x81 command in reg 0x4 reads back as 0x7 PCI: 00:10.0 init Configuring VIA USB 1.1 PCI: 00:10.1 init Configuring VIA USB 1.1 PCI: 00:10.2 init Configuring VIA USB 1.1 PCI: 00:10.3 init Configuring VIA USB 1.1 PCI: 00:10.4 init PCI: 00:11.0 init vt8237 init pci_routing_fixup: dev is 000161b8 setting firewire Assigning IRQ 11 to 0:d.0 Readback = 11 setting usb setting vt8237 setting ethernet Assigning IRQ 10 to 0:12.0 Readback = 10 setting vga setting pci slot Assigning IRQ 11 to 0:14.0 Readback = 11 setting cardbus slot setting riser slot PCI: 00:11.5 init PCI: 00:11.6 init PCI: 00:12.0 init Configuring VIA Rhine LAN PCI: 00:14.0 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 (0x70/0xa0) check_pirq_routing_table() - irq_routing_table located at: 0x000f0000 /code/bootfiles/LinuxBIOSv2/src/arch/i386/boot/pirq_routing.c: 36:check_pirq_routin4 done. Wrote linuxbios table at: 00000500 - 00000b3c checksum 9389 Welcome to elfboot, the open sourced starter. January 2002, Eric Biederman. Version 1.3 23:stream_init() - rom_stream: 0xfff80000 - 0xfffcffff Found ELF candiate at offset 0 New segment addr 0x94000 size 0x7088 offset 0x80 filesize 0x3580 (cleaned up) New segment addr 0x94000 size 0x7088 offset 0x80 filesize 0x3580 Dropping non PT_LOAD segment Loading Segment: addr: 0x0000000000094000 memsz: 0x0000000000007088 filesz: 0x000000000 Clearing Segment: addr: 0x0000000000097580 memsz: 0x0000000000003b08 Jumping to boot code at 0x94000 ROM segment 0x0000 length 0x0000 reloc 0x9400 Etherboot 5.0.10 (GPL) ELF for [VIA 86C100] Probing...[VIA 86C100]Found VIA 6102 ROM address 0x0000 rhine.c v1.0.0 2000-01-07 Enabling Sticky Bit Workaround for Chip_id: 0x0000 IO address 1C00 Ethernet Address: 00:40:63:DE:5A:01 Analyzing Media type,this will take several seconds........CPU 1391 Mhz OK Linespeed=100Mbs Fullduplex The PCI BIOS has not enabled this device! Updating PCI command 0143->0147. pci_bus 00 pci_device_fn 90 Searching for server (BOOTP)... .Me: 172.30.6.88, Server: 172.30.6.100, Gateway 172.30.6.254 Loading 172.30.6.100:bootfile_cn400_dave ...(ELF)... .................................e rhine disable Unknown bootloader class! type=00096f3a data=00000060 Firmware type: LinuxBIOS Linux version 2.4.26 (root at linuxcm) (gcc version 3.2.2) #22 Thu Sep 15 15:14:56 PDT 205 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 0000000000000ba4 (reserved) BIOS-e820: 0000000000000ba4 - 00000000000a0000 (usable) BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved) BIOS-e820: 0000000000100000 - 0000000001b34000 (usable) 27MB LOWMEM available. hm, page 00000000 reserved twice. On node 0 totalpages: 6964 zone(0): 4096 pages. zone(1): 2868 pages. zone(2): 0 pages. Kernel command line: root=/dev/ram console=ttyS0,115200 console=tty0 Initializing CPU#0 Detected 1333.468 MHz processor. Console: colour dummy device 80x25 Calibrating delay loop... 2637.82 BogoMIPS Memory: 24676k/27856k available (1350k kernel code, 2792k reserved, 296k data, 276k in) Dentry cache hash table entries: 4096 (order: 3, 32768 bytes) Inode cache hash table entries: 2048 (order: 2, 16384 bytes) Mount cache hash table entries: 512 (order: 0, 4096 bytes) Buffer cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 8192 (order: 3, 32768 bytes) CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line) CPU: L2 Cache: 64K (32 bytes/line) CPU: Centaur VIA Nehemiah stepping 08 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.40 (20010327) Richard Gooch (rgooch at atnf.csiro.au) mtrr: detected mtrr type: Intel PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) PCI: Using IRQ router VIA [1106/3227] at 00:11.0 Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd Detected PS/2 Mouse Port. pty: 256 Unix98 ptys configured keyboard: Timeout - AT keyboard not present?(ed) keyboard: Timeout - AT keyboard not present?(f4) Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A Real Time Clock Driver v1.10f RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize loop: loaded (max 8 devices) via-rhine.c:v1.10-LK1.1.19 July-12-2003 Written by Donald Becker http://www.scyld.com/network/via-rhine.html via-rhine: Reset succeeded. eth0: VIA VT6102 Rhine-II at 0x1c00, 00:40:63:de:5a:01, IRQ 10. eth0: MII PHY found at address 1, status 0x786d advertising 05e1 Link 45e1. 8139too Fast Ethernet driver 0.9.26 PCI: Found IRQ 11 for device 00:14.0 PCI: Sharing IRQ 11 with 00:0d.0 eth1: RealTek RTL8139 at 0xc2800000, 00:03:70:00:41:3e, IRQ 11 Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx usb.c: registered new driver usbdevfs usb.c: registered new driver hub host/usb-uhci.c: $Revision: 1.275 $ time 15:15:02 Sep 15 2005 host/usb-uhci.c: High bandwidth mode enabled host/usb-uhci.c: v1.275:USB Universal Host Controller Interface driver usb.c: registered new driver hid hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik hid-core.c: USB HID support drivers mice: PS/2 mouse device common for all mice NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 2048 bind 4096) ip_conntrack version 2.1 (217 buckets, 1736 max) - 288 bytes per conntrack ip_tables: (C) 2000-2002 Netfilter core team NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. NET4: Ethernet Bridge 008 for NET4.0 802.1Q VLAN Support v1.8 Ben Greear All bugs added by David S. Miller RAMDISK: Compressed image found at block 0 Freeing initrd memory: 346k freed VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 276k freed nxtvinit:ifconfieth0: Reset succeeded. g eth0 0.0.0.0 eth0: Setting full-duplex based on MII #1 link partner capability of 45e1. 06 11 27 32 c7 00 10 02 00 00 01 06 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 54 7f f0 00 00 00 00 00 0c 20 08 00 04 00 00 08 ff fd 09 00 00 a0 cb 00 03 00 00 01 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 00 00 00 20 84 55 00 f2 30 00 00 01 04 00 00 00 18 00 00 00 01 40 88 b0 c0 0f 00 00 41 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 14 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05 00 00 00 00 00 00 00 00 00 nxtvinit:ash BusyBox v0.60.3 (2005.09.15-18:50+0000) Built-in shell (ash) Enter 'help' for a list of built-in commands. sh: can't access tty; job control turned off # eth0: Something Wicked happened! 00000040. From windrainman at yahoo.com Fri Sep 16 06:29:52 2005 From: windrainman at yahoo.com (Frank Samuel) Date: Thu, 15 Sep 2005 21:29:52 -0700 (PDT) Subject: [LinuxBIOS] A question about compiling linuxBIOS Message-ID: <20050916042952.56981.qmail@web50304.mail.yahoo.com> I am pretty new to LinuxBIOS. I tried building Iwill's dk8s2 motherboard by buildtarget Iwill/dk8s2 cd Iwill/dk8s2 && make Tried on four platforms but met different problems. I feel surprised and would like to ask some questions here. And hope someone can anwer. 1. Do I need to compile it on a machine with IWILL DK8S2 motherboard? 2. Do I need to use a specific kernel version, gcc version? Thanks a lot. Xuehua __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From petekarl at student.chalmers.se Fri Sep 16 10:20:43 2005 From: petekarl at student.chalmers.se (Peter Karlsson) Date: Fri, 16 Sep 2005 10:20:43 +0200 (CEST) Subject: [LinuxBIOS] BIOS Saver discontinued In-Reply-To: <43287F74.9030904@linuxmachines.com> References: <43286D89.4030309@linuxmachines.com> <4328782A.1080302@nexpath.com> <43287F74.9030904@linuxmachines.com> Message-ID: On Wed, 14 Sep 2005, Jeff Carr wrote: > Still, I'd rather make an adapter. I've been told that production > motherboard PLCC adapters are usally only rated for about 10 insertions. > An adapter must be manufactured I think. Perhaps someone has some > experience with plastic mold injection adapter design & fabrication. I have quite good experience with injection moulding, though not with adapters. That should not be a problem though. I've worked with injection moulding within the car industry here in Sweden since '97 (designed injection moulded parts that is). What do you wish to know? Best regards Peter K From stepan at openbios.org Fri Sep 16 10:37:47 2005 From: stepan at openbios.org (Stefan Reinauer) Date: Fri, 16 Sep 2005 10:37:47 +0200 Subject: [LinuxBIOS] A question about compiling linuxBIOS In-Reply-To: <20050916042952.56981.qmail@web50304.mail.yahoo.com> References: <20050916042952.56981.qmail@web50304.mail.yahoo.com> Message-ID: <20050916083747.GA24120@openbios.org> Dear Xuehua, * Frank Samuel [050916 06:29]: > Tried on four platforms but met different problems. I > feel surprised and would like to ask some questions > here. > 1. Do I need to compile it on a machine with IWILL > DK8S2 motherboard? No, any machine with an x86 gcc or cross-gcc will do. > 2. Do I need to use a specific kernel version, gcc > version? Some gcc versions may cause problems, though all newer versions seem to be fine. I'm using some gcc 3.3.5 preversion and it works fine. Could you send a more detailed error description (ie the explicit error line(s) you are seeing. Stefan From hamish at prodigi.ch Fri Sep 16 11:18:19 2005 From: hamish at prodigi.ch (Hamish Guthrie) Date: Fri, 16 Sep 2005 11:18:19 +0200 Subject: [LinuxBIOS] BIOS Saver discontinued In-Reply-To: References: <43286D89.4030309@linuxmachines.com> <4328782A.1080302@nexpath.com> <43287F74.9030904@linuxmachines.com> Message-ID: <432A8DDB.20803@prodigi.ch> I have a really neat set of adapters I picked up in Taiwan a few years ago. The first one is an adapter from PLCC32 to DIL32 - it stands about 2 inches high and slots directly into a PLCC slot. I have put a ZIF socket into that. I also managed to pick up an adapter from DIL to PLCC, and that has a special ZIF PLCC socket. I can try to see if a friend of mine in Taipei can find more of these - I recall paying just a few dollars for both adapters, and they have proved invaluable. Hamish Peter Karlsson wrote: > On Wed, 14 Sep 2005, Jeff Carr wrote: > >> Still, I'd rather make an adapter. I've been told that production >> motherboard PLCC adapters are usally only rated for about 10 insertions. >> An adapter must be manufactured I think. Perhaps someone has some >> experience with plastic mold injection adapter design & fabrication. > > > I have quite good experience with injection moulding, though not with > adapters. That should not be a problem though. I've worked with > injection moulding within the car industry here in Sweden since '97 > (designed injection moulded parts that is). What do you wish to know? > > Best regards > > Peter K > From smithbone at gmail.com Fri Sep 16 15:20:37 2005 From: smithbone at gmail.com (Richard Smith) Date: Fri, 16 Sep 2005 08:20:37 -0500 Subject: [LinuxBIOS] BIOS Saver discontinued In-Reply-To: <432A8DDB.20803@prodigi.ch> References: <43286D89.4030309@linuxmachines.com> <4328782A.1080302@nexpath.com> <43287F74.9030904@linuxmachines.com> <432A8DDB.20803@prodigi.ch> Message-ID: <8a0c36780509160620192806a7@mail.gmail.com> > and that has a special ZIF PLCC socket. I can try to see if a friend of > mine in Taipei can find more of these - I recall paying just a few > dollars for both adapters, and they have proved invaluable. Just a couple of dollars? Wow! Thats awesome. emulation.com normally has stuff like that for a hundred plus dollars. If you find some I'll buy a few. -- Richard A. Smith From hamish at prodigi.ch Fri Sep 16 15:36:30 2005 From: hamish at prodigi.ch (Hamish Guthrie) Date: Fri, 16 Sep 2005 15:36:30 +0200 Subject: [LinuxBIOS] BIOS Saver discontinued In-Reply-To: <8a0c36780509160620192806a7@mail.gmail.com> References: <43286D89.4030309@linuxmachines.com> <4328782A.1080302@nexpath.com> <43287F74.9030904@linuxmachines.com> <432A8DDB.20803@prodigi.ch> <8a0c36780509160620192806a7@mail.gmail.com> Message-ID: <432ACA5E.2000200@prodigi.ch> There is a large mall in Taipei somewhere (my Taiwanese friend knows where), and I went there to have a look around and I just happend to see these adapters, and I was blown away by their prices - if I remember correctly, the PLCC->DIL adapter was about US$5 and the DIL->ZIF PLCC was about $12 - I also picked up about 6 regular DIL32 ZIF sockets for $3 each. I had previously bought these sort of things from emulation and the like, and as you say, their prices are crazy. I have sent an e-mail to my friend in Taipei, and will see what he comes back with. Richard Smith wrote: >>and that has a special ZIF PLCC socket. I can try to see if a friend of >>mine in Taipei can find more of these - I recall paying just a few >>dollars for both adapters, and they have proved invaluable. > > > Just a couple of dollars? Wow! Thats awesome. emulation.com normally > has stuff like that for a hundred plus dollars. If you find some > I'll buy a few. > From hamish at prodigi.ch Fri Sep 16 16:29:03 2005 From: hamish at prodigi.ch (Hamish Guthrie) Date: Fri, 16 Sep 2005 16:29:03 +0200 Subject: [LinuxBIOS] BIOS Saver discontinued In-Reply-To: <432ACA5E.2000200@prodigi.ch> References: <43286D89.4030309@linuxmachines.com> <4328782A.1080302@nexpath.com> <43287F74.9030904@linuxmachines.com> <432A8DDB.20803@prodigi.ch> <8a0c36780509160620192806a7@mail.gmail.com> <432ACA5E.2000200@prodigi.ch> Message-ID: <432AD6AF.8000703@prodigi.ch> I have put 2 photos on a web server http://www.prodigi.ch/adaptor/plccdil.jpg and http://www.prodigi.ch/adaptor/plcczif.jpg The plccdil picture shows the adaptor from PLCC to DIL32, with one of the 32-PIN ZIF sockets I bought plugged into the top of it. The 2nd image is the PLCC ZIF socket - incedentally, it does not show in the picture, but at the bottom it has 32 pins sticking out IN a DIL arrangement which can plug into an EPROM programmer (well into a DIL ZIF socket actually). Hamish Guthrie wrote: > There is a large mall in Taipei somewhere (my Taiwanese friend knows > where), and I went there to have a look around and I just happend to see > these adapters, and I was blown away by their prices - if I remember > correctly, the PLCC->DIL adapter was about US$5 and the DIL->ZIF PLCC > was about $12 - I also picked up about 6 regular DIL32 ZIF sockets for > $3 each. I had previously bought these sort of things from emulation and > the like, and as you say, their prices are crazy. I have sent an e-mail > to my friend in Taipei, and will see what he comes back with. > > Richard Smith wrote: > >>> and that has a special ZIF PLCC socket. I can try to see if a friend of >>> mine in Taipei can find more of these - I recall paying just a few >>> dollars for both adapters, and they have proved invaluable. >> >> >> >> Just a couple of dollars? Wow! Thats awesome. emulation.com normally >> has stuff like that for a hundred plus dollars. If you find some >> I'll buy a few. >> > From smithbone at gmail.com Fri Sep 16 16:34:19 2005 From: smithbone at gmail.com (Richard Smith) Date: Fri, 16 Sep 2005 09:34:19 -0500 Subject: [LinuxBIOS] BIOS Saver discontinued In-Reply-To: <432AD6AF.8000703@prodigi.ch> References: <43286D89.4030309@linuxmachines.com> <4328782A.1080302@nexpath.com> <43287F74.9030904@linuxmachines.com> <432A8DDB.20803@prodigi.ch> <8a0c36780509160620192806a7@mail.gmail.com> <432ACA5E.2000200@prodigi.ch> <432AD6AF.8000703@prodigi.ch> Message-ID: <8a0c36780509160734658fa61@mail.gmail.com> > The plccdil picture shows the adaptor from PLCC to DIL32, with one of > the 32-PIN ZIF sockets I bought plugged into the top of it. > > The 2nd image is the PLCC ZIF socket - incedentally, it does not show in > the picture, but at the bottom it has 32 pins sticking out IN a DIL > arrangement which can plug into an EPROM programmer (well into a DIL ZIF > socket actually). Yep. Looks just like the stuff that I have. -- Richard A. Smith From san at google.com Fri Sep 16 17:33:35 2005 From: san at google.com (San Mehat) Date: Fri, 16 Sep 2005 08:33:35 -0700 Subject: [LinuxBIOS] Building a viable rom *without* the fallback image Message-ID: <236ccac0509160833477b6790@mail.google.com> Hey all, I'm trying to figure out how to do a build a rom which contains *only* the normal image and not the fallback. For my purposes I don't believe I need a fallback image since I'm burning my images to a ROM emulator. The rom in question is only 512k and I need to fit 'other stuff' in there as well. Appreciate it :) -San -------------- next part -------------- An HTML attachment was scrubbed... URL: From stepan at openbios.org Fri Sep 16 17:36:48 2005 From: stepan at openbios.org (Stefan Reinauer) Date: Fri, 16 Sep 2005 17:36:48 +0200 Subject: [LinuxBIOS] Building a viable rom *without* the fallback image In-Reply-To: <236ccac0509160833477b6790@mail.google.com> References: <236ccac0509160833477b6790@mail.google.com> Message-ID: <20050916153648.GA12377@openbios.org> * San Mehat [050916 17:33]: > I'm trying to figure out how to do a build a rom which contains *only* the > normal image and not the fallback. For my purposes I don't believe I need a > fallback image since I'm burning my images to a ROM emulator. The rom in > question is only 512k and I need to fit 'other stuff' in there as well. You have to do it the other way around. The fallback image is mandatory, the normal image is optional. Stefan From smithbone at gmail.com Fri Sep 16 18:00:33 2005 From: smithbone at gmail.com (Richard Smith) Date: Fri, 16 Sep 2005 11:00:33 -0500 Subject: [LinuxBIOS] Building a viable rom *without* the fallback image In-Reply-To: <20050916153648.GA12377@openbios.org> References: <236ccac0509160833477b6790@mail.google.com> <20050916153648.GA12377@openbios.org> Message-ID: <8a0c367805091609007ced30c6@mail.gmail.com> On 9/16/05, Stefan Reinauer wrote: > > fallback image since I'm burning my images to a ROM emulator. The rom in > > question is only 512k and I need to fit 'other stuff' in there as well. > > You have to do it the other way around. The fallback image is mandatory, > the normal image is optional. There really isn't any good documentation on doing this. If you will write up your eventual config and what changes you had to make I'll see that it gets up in the wiki. As Stefan said the "Fallback" image is what you want. Its the first image booted. If I remember correctly you can modify your buildrom statement in your Config.lb to keep from copying the normal image into the generated rom. So changing buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback" to buildrom ./linuxbios.rom ROM_SIZE "fallback" should only include the "fallback" image in the final ROM. However this dosn't mean it will work. *grin* The normal+fallback scheme is wired in pretty deep. You may have to go change the startup files a bit to achieve exactly what you want. -- Richard A. Smith From debra22 at debra22.karoo.co.uk Fri Sep 16 19:02:04 2005 From: debra22 at debra22.karoo.co.uk (Martin Gooderham) Date: Fri, 16 Sep 2005 17:02:04 +0000 Subject: [LinuxBIOS] i think this is right : open/linux bois Message-ID: <432AFA8C.307@debra22.karoo.co.uk> :) do i just compile unknown source and write to /bios From Stephen.Kimball at bench.com Fri Sep 16 18:17:56 2005 From: Stephen.Kimball at bench.com (Stephen.Kimball at bench.com) Date: Fri, 16 Sep 2005 12:17:56 -0400 Subject: [LinuxBIOS] Building a viable rom *without* the fallback image Message-ID: <30ADB28314F8B744AB478FB5EDA044B30D3C3D@nh-ex01.bench.com> You could also look at Steven Magnani 's post: http://www.linuxbios.org/pipermail/linuxbios/2005-August/012263.html He suggests some mainboard Config file changes, which look good. I haven't tried it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From san at google.com Fri Sep 16 18:33:33 2005 From: san at google.com (San Mehat) Date: Fri, 16 Sep 2005 09:33:33 -0700 Subject: [LinuxBIOS] Building a viable rom *without* the fallback image In-Reply-To: <30ADB28314F8B744AB478FB5EDA044B30D3C3D@nh-ex01.bench.com> References: <30ADB28314F8B744AB478FB5EDA044B30D3C3D@nh-ex01.bench.com> Message-ID: <236ccac050916093326771e0d@mail.google.com> Thank you all, I shall try this out... -San On 9/16/05, Stephen.Kimball at bench.com wrote: > > You could also look at Steven Magnani 's post: > > http://www.linuxbios.org/pipermail/linuxbios/2005-August/012263.html > > He suggests some mainboard Config file changes, which look good. I haven't > tried it. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at digidescorp.com Fri Sep 16 18:38:13 2005 From: steve at digidescorp.com (Steven J. Magnani) Date: Fri, 16 Sep 2005 11:38:13 -0500 Subject: [LinuxBIOS] Building a viable rom *without* the fallback image In-Reply-To: <236ccac0509160833477b6790@mail.google.com> Message-ID: <002701c5badd$0b1ebdf0$6ffea8c0@banana> The Intel XE7501DEVKIT code that I checked in earlier this week uses a single image. Have a look at the target and mainboard config files. Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From yinghai.lu at amd.com Fri Sep 16 18:44:09 2005 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Fri, 16 Sep 2005 09:44:09 -0700 Subject: [LinuxBIOS] Building a viable rom *without* the fallback image Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06154@ssvlexmb2.amd.com> You can change the ROM_SIZE in MB Option.lb to make final Normal+Fallback size to 512K. YH ________________________________ From: linuxbios-bounces at openbios.org [mailto:linuxbios-bounces at openbios.org] On Behalf Of San Mehat Sent: Friday, September 16, 2005 8:34 AM To: LinuxBIOS Subject: [LinuxBIOS] Building a viable rom *without* the fallback image Hey all, I'm trying to figure out how to do a build a rom which contains *only* the normal image and not the fallback. For my purposes I don't believe I need a fallback image since I'm burning my images to a ROM emulator. The rom in question is only 512k and I need to fit 'other stuff' in there as well. Appreciate it :) -San -------------- next part -------------- An HTML attachment was scrubbed... URL: From san at google.com Fri Sep 16 18:44:30 2005 From: san at google.com (San Mehat) Date: Fri, 16 Sep 2005 09:44:30 -0700 Subject: [LinuxBIOS] Building a viable rom *without* the fallback image In-Reply-To: <236ccac050916093326771e0d@mail.google.com> References: <30ADB28314F8B744AB478FB5EDA044B30D3C3D@nh-ex01.bench.com> <236ccac050916093326771e0d@mail.google.com> Message-ID: <236ccac0509160944569e30e1@mail.google.com> hmm.. so i commented out the 'normal' section of my target Config.lband changed the buildrom line to only build the fallback image, but the generated rom file is now 131072 bytes instead of the expected 512k. Any ideas? danke ;) -san On 9/16/05, San Mehat wrote: > > Thank you all, > > I shall try this out... > > -San > > > On 9/16/05, Stephen.Kimball at bench.com wrote: > > > > You could also look at Steven Magnani 's post: > > > > http://www.linuxbios.org/pipermail/linuxbios/2005-August/012263.html > > > > He suggests some mainboard Config file changes, which look good. I > > haven't tried it. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yinghai.lu at amd.com Fri Sep 16 19:10:03 2005 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Fri, 16 Sep 2005 10:10:03 -0700 Subject: [LinuxBIOS] Building a viable rom *without* the fallback image Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E06155@ssvlexmb2.amd.com> That is 128k. In the MB Option.lb there ROM_SIZE You can change that to ROM_SIZE=524288 So Fallback will use 128k, and Nomal will use 384k. YH ________________________________ From: linuxbios-bounces at openbios.org [mailto:linuxbios-bounces at openbios.org] On Behalf Of San Mehat Sent: Friday, September 16, 2005 9:45 AM To: Stephen.Kimball at bench.com Cc: linuxbios at openbios.org Subject: Re: [LinuxBIOS] Building a viable rom *without* the fallback image hmm.. so i commented out the 'normal' section of my target Config.lb and changed the buildrom line to only build the fallback image, but the generated rom file is now 131072 bytes instead of the expected 512k. Any ideas? danke ;) -san On 9/16/05, San Mehat wrote: Thank you all, I shall try this out... -San On 9/16/05, Stephen.Kimball at bench.com wrote: You could also look at Steven Magnani 's post: http://www.linuxbios.org/pipermail/linuxbios/2005-August/012263.html He suggests some mainboard Config file changes, which look good. I haven't tried it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From windrainman at yahoo.com Fri Sep 16 21:23:25 2005 From: windrainman at yahoo.com (Frank Samuel) Date: Fri, 16 Sep 2005 12:23:25 -0700 (PDT) Subject: [LinuxBIOS] A question about compiling linuxBIOS In-Reply-To: <20050916083747.GA24120@openbios.org> Message-ID: <20050916192325.76664.qmail@web50315.mail.yahoo.com> Thanks Stefan for the information. I conntinued my complation and get some progress. The problem I met is below: /usr/lib/gcc-lib/i586-suse-linux/3.3.5/../../../../i586-suse-linux/bin/ld: section .reset [00000000fffdfff0 -> 00000000fffdffff] overlaps section .rom [00000000fffd80fc -> 00000000fffe094f] /usr/lib/gcc-lib/i586-suse-linux/3.3.5/../../../../i586-suse-linux/bin/ld: section .id [00000000fffdffd8 -> 00000000fffdffef] overlaps section .rom [00000000fffd80fc -> 00000000fffe094f] /usr/lib/gcc-lib/i586-suse-linux/3.3.5/../../../../i586-suse-linux/bin/ld: linuxbios: section .id lma 0xfffdffd8 overlaps previous sections /usr/lib/gcc-lib/i586-suse-linux/3.3.5/../../../../i586-suse-linux/bin/ld: linuxbios: section .reset lma 0xfffdfff0 overlaps previous sections collect2: ld returned 1 exit status make[1]: *** [linuxbios] Error 1 make[1]: Leaving directory `/home/opt/linuxbios/LinuxBIOSv2-2040/targets/Iwill/dk8s2/dk8s2/normal' make: *** [normal/linuxbios.rom] Error 1 I checked some previous email and find someone met the similar problem for tyan board and the solution is to increase ROM_IMAGE_SIZE. The motherboard I tried is Iwill/dk8s2. After increasing ROM_IMAGE_SIZE from 65536 to 70000, the compilation passed this step. Then I downloaded filo-0.42 and compiled it, put it to the payload directory. I am glad that everything compiles and a linuxbios.rom is build. Then flash_rom is used to flash the image to the IWILL DK8S2 machine. But after doing this and reboot the machine, it never comes up. Is there something wrong with the procedures I performed? Greatly appreciated. Xuehua --- Stefan Reinauer wrote: > Dear Xuehua, > > * Frank Samuel [050916 > 06:29]: > > Tried on four platforms but met different > problems. I > > feel surprised and would like to ask some > questions > > here. > > 1. Do I need to compile it on a machine with IWILL > > DK8S2 motherboard? > > No, any machine with an x86 gcc or cross-gcc will > do. > > > 2. Do I need to use a specific kernel version, gcc > > version? > > Some gcc versions may cause problems, though all > newer > versions seem to be fine. I'm using some gcc 3.3.5 > preversion and it works fine. > > Could you send a more detailed error description (ie > the explicit error > line(s) you are seeing. > > Stefan > > > > > > > > > > -- > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From stepan at openbios.org Fri Sep 16 21:28:57 2005 From: stepan at openbios.org (Stefan Reinauer) Date: Fri, 16 Sep 2005 21:28:57 +0200 Subject: [LinuxBIOS] A question about compiling linuxBIOS In-Reply-To: <20050916192212.76284.qmail@web50303.mail.yahoo.com> References: <20050916083747.GA24120@openbios.org> <20050916192212.76284.qmail@web50303.mail.yahoo.com> Message-ID: <20050916192857.GA26791@openbios.org> * Frank Samuel [050916 21:22]: > Then flash_rom is used to > flash the image to the IWILL DK8S2 machine. But after > doing this and reboot the machine, it never comes up. > Is there something wrong with the procedures I > performed? Greatly appreciated. How big is your flash chip? How big is the image you are burning? Do you have a serial cable attached to the machine and the correct baud rate set? Stefan From ollie at lanl.gov Fri Sep 16 21:54:09 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Fri, 16 Sep 2005 13:54:09 -0600 Subject: [LinuxBIOS] eth1: Too much work at interrupt, IntrStatus=0x0001. In-Reply-To: <200509152136.j8FLaoEN018534@xdr.com> References: <200509152136.j8FLaoEN018534@xdr.com> Message-ID: <1126900450.6666.13.camel@logarithm.lanl.gov> On Thu, 2005-09-15 at 14:36 -0700, Dave Ashley wrote: > We've got epia-sp almost into linux fully, but RTL8139 (eth1) or the > VIA 3065 (eth0) don't work properly. > > Interrupts are occuring as expected on ethernet packets. We're trying to > work with the RTL8139 for now which is a card plugged into the epia-sp. > It's able to act as a pci bus master. I suspect something about the PCI > isn't working, like the card isn't able to dma into host memory or > something similiar. > > Inside linux drivers/net/8139too.c inside function rtl8139_rx_interrupt > if ((rx_size > (MAX_ETH_FRAME_SIZE+4)) || > (rx_size < 8) || > (!(rx_status & RxStatusOK))) { > rtl8139_rx_err (rx_status, dev, tp, ioaddr); > printk("here2 rx_size = %d\n", rx_size); // (DA) > return; > } > > The interrupt service routine is exiting because rx_size is always 0. This > is the size of the received packet I think. > > A similiar problem is occuring in the 3065 ethernet. We're failing to do > something within linuxbios that's preventing pci devices from functioning > properly. > > Does anyone have any suggestions? I'm hoping these symptoms are familiar. Are you sure your DRAM is inited correctly? We had similar problem on EPIA. The kernel boots but it has problem to DMA received packets. -- Li-Ta Lo Los Alamos National Lab From windrainman at yahoo.com Fri Sep 16 22:04:00 2005 From: windrainman at yahoo.com (Frank Samuel) Date: Fri, 16 Sep 2005 13:04:00 -0700 (PDT) Subject: [LinuxBIOS] A question about compiling linuxBIOS In-Reply-To: <20050916192857.GA26791@openbios.org> Message-ID: <20050916200403.98236.qmail@web50307.mail.yahoo.com> Before I get BIOS download from IWILL's website. The .ROM file is 524288 bytes. Is this the flash_chip size? The linuxbios.rom built is 1048576 bytes. I didn't connect the serial cable to the machine. And do you mean set the baute rate in Bios settings? Thanks. Xuehua --- Stefan Reinauer wrote: > * Frank Samuel [050916 > 21:22]: > > Then flash_rom is used to > > flash the image to the IWILL DK8S2 machine. But > after > > doing this and reboot the machine, it never comes > up. > > > Is there something wrong with the procedures I > > performed? Greatly appreciated. > > How big is your flash chip? How big is the image you > are > burning? > > Do you have a serial cable attached to the machine > and > the correct baud rate set? > > Stefan > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From stepan at openbios.org Fri Sep 16 22:08:02 2005 From: stepan at openbios.org (Stefan Reinauer) Date: Fri, 16 Sep 2005 22:08:02 +0200 Subject: [LinuxBIOS] A question about compiling linuxBIOS In-Reply-To: <20050916200403.98236.qmail@web50307.mail.yahoo.com> References: <20050916192857.GA26791@openbios.org> <20050916200403.98236.qmail@web50307.mail.yahoo.com> Message-ID: <20050916200802.GA3620@openbios.org> * Frank Samuel [050916 22:04]: > Before I get BIOS download from IWILL's website. > The .ROM file is 524288 bytes. Is this the flash_chip > size? The linuxbios.rom built is 1048576 bytes. Then you probably flashed half of LinuxBIOS only.. You need to create one that is 512k big if that is the size of your flash chip > I didn't connect the serial cable to the machine. And > do you mean set the baute rate in Bios settings? Connect the board with a serial cable to another machine. you will see lots of output if LinuxBIOS is there. (i think 115200 baud is the default) VGA is still a bit tricky in LinuxBIOS Stefan From linuxbios at xdr.com Fri Sep 16 23:53:16 2005 From: linuxbios at xdr.com (Dave Ashley) Date: Fri, 16 Sep 2005 14:53:16 -0700 Subject: [LinuxBIOS] eth1: Too much work at interrupt, IntrStatus=0x0001. Message-ID: <200509162153.j8GLrGPY028114@xdr.com> Li-Ta Lo wrote: >Are you sure your DRAM is inited correctly? We had similar problem on >EPIA. The kernel boots but it has problem to DMA received packets. Just a couple hours ago we figured this out, it was related to incorrect settings of the VLINK control registers. We copied values from award and now it's stable. Thanks-- Dave From linuxbios at xdr.com Sat Sep 17 00:01:28 2005 From: linuxbios at xdr.com (Dave Ashley) Date: Fri, 16 Sep 2005 15:01:28 -0700 Subject: [LinuxBIOS] EPIA-SP standup progress!!!! Message-ID: <200509162201.j8GM1St5028162@xdr.com> All, We've managed to get into linux on epia-sp using our modified V2 linuxbios source. Next week we'll be cleaning up the code for release back to the project. There were a lot of real puzzlers we had to figure out. Missing pieces include: 1) DDR init not using SPD values, controller settings taken from stock bios and are specific to our particular DDR module 2) Size isn't detected correctly 3) VGA BIOS doesn't exist, however it might not be needed 4) Cache init code taken from V1 epia-m tree, so it's lots of inline ASM which is probably against the ideals (romcc) >From my point of view the worst thing about linuxbios is the crippling lack of documentation. Document this thing better and you'll see more developers jumping on board, I think. -Dave From okajima at digitalinfra.co.jp Sat Sep 17 00:28:21 2005 From: okajima at digitalinfra.co.jp (Jun OKAJIMA) Date: Sat, 17 Sep 2005 07:28:21 +0900 Subject: [LinuxBIOS] BIOS Saver discontinued In-Reply-To: <8a0c36780509160620192806a7@mail.gmail.com> References: <8a0c36780509160620192806a7@mail.gmail.com> Message-ID: <200509162228.AA00339@bbb-jz5c7z9hn9y.digitalinfra.co.jp> >> and that has a special ZIF PLCC socket. I can try to see if a friend of >> mine in Taipei can find more of these - I recall paying just a few >> dollars for both adapters, and they have proved invaluable. > >Just a couple of dollars? Wow! Thats awesome. emulation.com normally >has stuff like that for a hundred plus dollars. If you find some >I'll buy a few. > FYI, See this. http://fab51.com/workshop/bios/dual_bios2.html This guy solders a chip directly to a M/B. Maybe he could not get a socket. --- Okajima. From c.jones at f5.com Sat Sep 17 04:28:38 2005 From: c.jones at f5.com (Clay Jones) Date: Fri, 16 Sep 2005 19:28:38 -0700 Subject: [LinuxBIOS] Building a viable rom *without* the fallback image Message-ID: <7D7AEA925A7F724194B1521C75E622DC011B5F3D@exchfive.olympus.f5net.com> Look at Config.kernelimage.lb in targets/arima/hdama. Clay Jones senior software engineer | c.jones at f5.com | www.f5.com P. 509 343 3500 | F. 509 343 3501 | D. 509 343 3519 F5 Networks | 1322 North Whitman Lane | Liberty Lake, Washington 99019 The Leader in Application Traffic Management Ensuring secure and optimized application delivery for global enterprises ________________________________ From: linuxbios-bounces at openbios.org [mailto:linuxbios-bounces at openbios.org] On Behalf Of Lu, Yinghai Sent: Friday, September 16, 2005 10:10 AM To: San Mehat; Stephen.Kimball at bench.com Cc: linuxbios at openbios.org Subject: RE: [LinuxBIOS] Building a viable rom *without* the fallback image That is 128k. In the MB Option.lb there ROM_SIZE You can change that to ROM_SIZE=524288 So Fallback will use 128k, and Nomal will use 384k. YH ________________________________ From: linuxbios-bounces at openbios.org [mailto:linuxbios-bounces at openbios.org] On Behalf Of San Mehat Sent: Friday, September 16, 2005 9:45 AM To: Stephen.Kimball at bench.com Cc: linuxbios at openbios.org Subject: Re: [LinuxBIOS] Building a viable rom *without* the fallback image hmm.. so i commented out the 'normal' section of my target Config.lb and changed the buildrom line to only build the fallback image, but the generated rom file is now 131072 bytes instead of the expected 512k. Any ideas? danke ;) -san On 9/16/05, San Mehat wrote: Thank you all, I shall try this out... -San On 9/16/05, Stephen.Kimball at bench.com wrote: You could also look at Steven Magnani 's post: http://www.linuxbios.org/pipermail/linuxbios/2005-August/012263.html He suggests some mainboard Config file changes, which look good. I haven't tried it. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 6180 bytes Desc: image001.gif URL: From windrainman at yahoo.com Sat Sep 17 23:13:15 2005 From: windrainman at yahoo.com (Frank Samuel) Date: Sat, 17 Sep 2005 14:13:15 -0700 (PDT) Subject: [LinuxBIOS] A question about compiling linuxBIOS In-Reply-To: <20050916200802.GA3620@openbios.org> Message-ID: <20050917211315.59127.qmail@web50315.mail.yahoo.com> Hi, Stephan, Thanks for the information. By changing the ROM_SIZE in the Config.lb, I get a linuxbios.ROM of 524288 bytes and flashed it to the destination node. After that I connected the null modem cable to another machine, use minicom and configured the serial poart as 115200 8N1, quite and restart the minicom again and then started the machine with linuxbios flashed. But I cannot see any inputs. What could be the problem? Thanks. Xuehua --- Stefan Reinauer wrote: > * Frank Samuel [050916 > 22:04]: > > Before I get BIOS download from IWILL's website. > > The .ROM file is 524288 bytes. Is this the > flash_chip > > size? The linuxbios.rom built is 1048576 bytes. > > Then you probably flashed half of LinuxBIOS only.. > You need to create > one that is 512k big if that is the size of your > flash chip > > > I didn't connect the serial cable to the machine. > And > > do you mean set the baute rate in Bios settings? > > Connect the board with a serial cable to another > machine. you will see > lots of output if LinuxBIOS is there. (i think > 115200 baud is the > default) > VGA is still a bit tricky in LinuxBIOS > > > Stefan > > -- > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From stuge-linuxbios at cdy.org Sun Sep 18 04:59:00 2005 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Sun, 18 Sep 2005 04:59:00 +0200 Subject: [LinuxBIOS] More epia-sp + ethernet In-Reply-To: <200509152233.j8FMXawI018851@xdr.com> References: <200509152233.j8FMXawI018851@xdr.com> Message-ID: <20050918025900.1149.qmail@cdy.org> On Thu, Sep 15, 2005 at 03:33:36PM -0700, Dave Ashley wrote: > Within linux the via-rhine.c reports when debugging is turned up: > eth0: Something Wicked happened! 00000040. > > This bit (40) represents a PCI Bus Error. The data sheet I could find wasn't very helpful, scyld.com/ethercard_drivers.html errata explains the error as: 0040 PCI Bus Error A serious, perhaps unrecoverable error. No other bits set in the interrupt status register either.. Anyone at VIA listening? :) //Peter From stuge-linuxbios at cdy.org Sun Sep 18 05:05:02 2005 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Sun, 18 Sep 2005 05:05:02 +0200 Subject: [LinuxBIOS] PLCC removal trick In-Reply-To: <200509141956.j8EJughS009640@xdr.com> References: <200509141956.j8EJughS009640@xdr.com> Message-ID: <20050918030502.1923.qmail@cdy.org> On Wed, Sep 14, 2005 at 12:56:42PM -0700, Dave Ashley wrote: > I don't know about anyone else but the dental floss idea didn't > work at all for me, the floss interferes with the pins. Try putting the floss diagonally under the chip? //Peter From stuge-linuxbios at cdy.org Sun Sep 18 05:28:56 2005 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Sun, 18 Sep 2005 05:28:56 +0200 Subject: [LinuxBIOS] LPC ROM emulator [was: PLCC removal trick] In-Reply-To: <4328D1FE.1090302@linuxmachines.com> <200509151402.j8FE2Kc2015346@xdr.com> References: <200509141956.j8EJughS009640@xdr.com> <8a0c367805091413381ea7d9ce@mail.gmail.com> <4328D1FE.1090302@linuxmachines.com> <200509151402.j8FE2Kc2015346@xdr.com> Message-ID: <20050918032856.4467.qmail@cdy.org> On Thu, Sep 15, 2005 at 07:02:20AM -0700, Dave Ashley wrote: > I looked at the FlexROM III, it appears to emulate just flat 8 or > 16 bit devices. PLCC's are more complicated, they frequently make > use of an LPC interface that clocks in 4 bits of data at a time (as > I recall) to get the address into the chip, then clocks out 4 bits > of data at a time. I think an operation is 16 bits at a time. This > is all transparent from the system's perspective. However behind > the scenes it is a complicated dance. Cycles are 1, 2, 4 or 128 bytes. Required signals are 4 bit A/D bus, cycle sync, reset and clock. Last two are same as on PCI. LPC is a pretty neat bus. Making an emulator would be fun.. On Wed, Sep 14, 2005 at 06:44:30PM -0700, Jeff Carr wrote: > More than that I think. How smart are these devices? Can one single > step through instructions or dump out the registers on the CPU.(?) I don't think so, it's only a ROM emulator, not a CPU debugger. As for single stepping, that won't work either because the ROM has a (very short) limited response time, it can't just block on reads. > the capabilities of using an emulator. Man, if only someone made > one that hooked up to gdb, then we would be in business. I'm not sure how gdb would work with a ROM emulator, but on the other hand I haven't done too much advanced stuff with gdb. :( > > You will also probally need a DIP to PLCC adapter. > > Right. The adapter size is likely to be a problem. Some boards will > not have the space to fit such an adapter. Guess it's back to the > making adapters game. Try to find one that builds straight up from the socket. I was using something pretty good from ICEtech or similar when last working with BIOS things, it didn't have the DIP size board until about an inch up from the PLCC socket. //Peter From stuge-linuxbios at cdy.org Sun Sep 18 06:00:46 2005 From: stuge-linuxbios at cdy.org (Peter Stuge) Date: Sun, 18 Sep 2005 06:00:46 +0200 Subject: [LinuxBIOS] BIOS Saver discontinued In-Reply-To: <43286D89.4030309@linuxmachines.com> References: <43286D89.4030309@linuxmachines.com> Message-ID: <20050918040046.8074.qmail@cdy.org> On Wed, Sep 14, 2005 at 11:35:53AM -0700, Jeff Carr wrote: > I tried to duplicate the 256KB bios by putting it in a 512KB chip > (SST 28SF040A vs 39SF020A). This didn't seem to work (no beep or > video but didn't try port 80 parallel card yet). Perhaps someone > knows if this should work. Should. 39SF is flash while 28SF is EEPROM, but in practise this just means that 39SF is faster. As long as you can pull A18 low it should work just fine. > Can someone recommend a good place to get a handful of SST 39SF02A > PLCC chips for these experiments? Try contacting your local SST distributor. It's Memec here in Sweden, but I'm not sure if they're exclusive worldwide. If you have a business they're usually happy to sell you down to $150 worth of goods per purchase. //Peter From windrainman at yahoo.com Mon Sep 19 16:56:23 2005 From: windrainman at yahoo.com (Frank Samuel) Date: Mon, 19 Sep 2005 07:56:23 -0700 (PDT) Subject: [LinuxBIOS] A question about compiling linuxBIOS In-Reply-To: <20050917211315.59127.qmail@web50315.mail.yahoo.com> Message-ID: <20050919145624.91619.qmail@web50305.mail.yahoo.com> hi, all, I got some new progress by more experiments. It seems that my serial connection was working. When I reboot the machine by running "reboot", I saw a string of LinuxBIOS $Version Starting... My board is Iwill DK8S2. This seems to be what main() of auto.c prints when it call console_init(). report_bist_failure is also alled. But setup_default_resource_map failed. Don't know why this failed. If I power down the target machine, I can see nothing. I checked the cmos.layout. I saved cmos settings to a file by cmos_to_file and read it via cmos_util, I get a settings file in which baud rate is 1200. This desn't match with the cmos settings of the machine. I am wondering whether cmos.layout is still correct now since iwill motherboard changes structure of cmos settings pretty frequent. Could this be the reason that I cannot see any output of linuxbios after the target machine power up? BTW, how cmos.layout for Iwill is created? by flipping cmos settings and observing the differnces of the binary file or Iwill provides this? Can someone provide some hints? Thanks a lot. Xuehua --- Frank Samuel wrote: > Hi, Stephan, Thanks for the information. > By changing the ROM_SIZE in the Config.lb, I get > a linuxbios.ROM of 524288 bytes and flashed it to > the > destination node. > > After that I connected the null modem cable to > another > machine, use minicom and configured the serial poart > > as 115200 8N1, quite and restart the minicom again > and > then started the machine with linuxbios flashed. But > I > cannot see any inputs. What could be the problem? > > Thanks. > > Xuehua > > --- Stefan Reinauer wrote: > > > * Frank Samuel [050916 > > 22:04]: > > > Before I get BIOS download from IWILL's website. > > > > The .ROM file is 524288 bytes. Is this the > > flash_chip > > > size? The linuxbios.rom built is 1048576 bytes. > > > > Then you probably flashed half of LinuxBIOS only.. > > You need to create > > one that is 512k big if that is the size of your > > flash chip > > > > > I didn't connect the serial cable to the > machine. > > And > > > do you mean set the baute rate in Bios settings? > > > > Connect the board with a serial cable to another > > machine. you will see > > lots of output if LinuxBIOS is there. (i think > > 115200 baud is the > > default) > > VGA is still a bit tricky in LinuxBIOS > > > > > > Stefan > > > > -- > > LinuxBIOS mailing list > > LinuxBIOS at openbios.org > > http://www.openbios.org/mailman/listinfo/linuxbios > > > > > > > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com > > -- > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From cro_marmot at comcast.net Tue Sep 20 07:38:08 2005 From: cro_marmot at comcast.net (David Hendricks) Date: Mon, 19 Sep 2005 23:38:08 -0600 Subject: [LinuxBIOS] i think this is right : open/linux bois In-Reply-To: <432AFA8C.307@debra22.karoo.co.uk> References: <432AFA8C.307@debra22.karoo.co.uk> Message-ID: <20050919233808.12d7803f@sunder> Can you be a little more specific? On Fri, 16 Sep 2005 17:02:04 +0000 Martin Gooderham wrote: > :) do i just compile unknown source and write to /bios > > > > > -- > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios From talbotx at comcast.net Tue Sep 20 08:42:37 2005 From: talbotx at comcast.net (Adam Talbot) Date: Mon, 19 Sep 2005 23:42:37 -0700 Subject: [LinuxBIOS] A free mac mini?? Scam?? In-Reply-To: <4328D73D.2090502@comcast.net> References: <43286D89.4030309@linuxmachines.com> <432874E2.10603@comcast.net> <8a0c3678050914121951016cce@mail.gmail.com> <432885E4.1080902@linuxmachines.com> <4328D73D.2090502@comcast.net> Message-ID: <432FAF5D.4090404@comcast.net> OK, Guys's... is this one real or a scam. I was sucked in?I don?t REALLY have need of a Mac Mini, but I figured ?what the hey??it?s another toy for Linux bios. I went to the website (Link at bottem) and followed the instructions: fill in personal info (name, address, phone, etc?all easy enough information to find on the web anyway), then wade through all the ?optional? offers that you can ignore, then complete one ?offer? which is basically a purchase from some sponsoring companies (I needed print cartridges so I bought a couple for my home printer), then refer a couple of other people to the site. Kinda feels like a pyramid-form-letter kinda thing, but I bought something I needed and stand to possibly get a Mac Mini out of the deal. Not bad. http://minimacs.freepay.com/?r=22580525 -Adam Talbot From justin at street-vision.com Tue Sep 20 13:24:36 2005 From: justin at street-vision.com (Justin Cormack) Date: Tue, 20 Sep 2005 11:24:36 +0000 Subject: [LinuxBIOS] A free mac mini?? Scam?? In-Reply-To: <432FAF5D.4090404@comcast.net> References: <43286D89.4030309@linuxmachines.com> <432874E2.10603@comcast.net> <8a0c3678050914121951016cce@mail.gmail.com> <432885E4.1080902@linuxmachines.com> <4328D73D.2090502@comcast.net> <432FAF5D.4090404@comcast.net> Message-ID: <1127215476.575.5.camel@scrod> On Mon, 2005-09-19 at 23:42 -0700, Adam Talbot wrote: > OK, Guys's... is this one real or a scam. > > I was sucked in?I don?t REALLY have need of a Mac Mini, but I figured > ?what the hey??it?s another toy for Linux bios. I went to the website > (Link at bottem) and followed the instructions: fill in personal info Of course it is a scam. And without any evidence to the contrary I assume your mail is too. Can someone remove it from the archive. Justin From Morales at appro.com Wed Sep 21 02:41:25 2005 From: Morales at appro.com (Edwin Morales) Date: Tue, 20 Sep 2005 17:41:25 -0700 Subject: [LinuxBIOS] Using SATA HDD Message-ID: <4B21D6C08BC8BA4A9530E43C980E58B0471D82@hawk.appro.com> How do you get the SATA 0 HDD to load using Etherboot-5.2.6 on a Tyan 2891. I've built a filo.zelf payload and using hde2:/ as the boot parameter but it's returning No Device found. Thanks /ed -------------- next part -------------- An HTML attachment was scrubbed... URL: From ollie at lanl.gov Wed Sep 21 05:18:34 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Tue, 20 Sep 2005 21:18:34 -0600 Subject: [LinuxBIOS] Using SATA HDD In-Reply-To: <4B21D6C08BC8BA4A9530E43C980E58B0471D82@hawk.appro.com> References: <4B21D6C08BC8BA4A9530E43C980E58B0471D82@hawk.appro.com> Message-ID: <1127272715.5700.6.camel@logarithm.lanl.gov> On Tue, 2005-09-20 at 17:41 -0700, Edwin Morales wrote: > How do you get the SATA 0 HDD to load using Etherboot-5.2.6 on a Tyan > 2891. I?ve built a filo.zelf payload and using hde2:/ as the boot > parameter but it?s returning No Device found. > FILO doesn't have any driver for SATA. -- Li-Ta Lo Los Alamos National Lab From yinghailu at gmail.com Wed Sep 21 06:44:26 2005 From: yinghailu at gmail.com (yhlu) Date: Tue, 20 Sep 2005 21:44:26 -0700 Subject: [LinuxBIOS] Using SATA HDD In-Reply-To: <1127272715.5700.6.camel@logarithm.lanl.gov> References: <4B21D6C08BC8BA4A9530E43C980E58B0471D82@hawk.appro.com> <1127272715.5700.6.camel@logarithm.lanl.gov> Message-ID: <2ea3fae10509202144dedb77c@mail.gmail.com> FILO in Etherboot can support SATA that can work in IDE compatible mode. But it seems that NViadia ck804 SATA doesn't support that mode. YH On 9/20/05, Li-Ta Lo wrote: > > On Tue, 2005-09-20 at 17:41 -0700, Edwin Morales wrote: > > How do you get the SATA 0 HDD to load using Etherboot-5.2.6 on a Tyan > > 2891. I've built a filo.zelf payload and using hde2:/ as the boot > > parameter but it's returning No Device found. > > > > FILO doesn't have any driver for SATA. > > -- > Li-Ta Lo > Los Alamos National Lab > > > -- > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > -------------- next part -------------- An HTML attachment was scrubbed... URL: From windrainman at yahoo.com Wed Sep 21 23:24:09 2005 From: windrainman at yahoo.com (Frank Samuel) Date: Wed, 21 Sep 2005 14:24:09 -0700 (PDT) Subject: [LinuxBIOS] Asking help for serial output Message-ID: <20050921212409.65390.qmail@web50310.mail.yahoo.com> Dear all, Pretty new to linuxbios. I worked for a week to try to get serial output of linuxbios but failed. Hope someone can help me here. I tried two motherboards, Iwill/DK8S2 and tyan/s2882. Compiled succesfully and get a linuxbios.rom and flashed them to chip using flash_rom. But I didn't see any output via serial port. Can someone tell me what could be the causes. Thanks in advance. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From stepan at openbios.org Wed Sep 21 23:37:41 2005 From: stepan at openbios.org (Stefan Reinauer) Date: Wed, 21 Sep 2005 23:37:41 +0200 Subject: [LinuxBIOS] Asking help for serial output In-Reply-To: <20050921212409.65390.qmail@web50310.mail.yahoo.com> References: <20050921212409.65390.qmail@web50310.mail.yahoo.com> Message-ID: <20050921213741.GA26131@openbios.org> * Frank Samuel [050921 23:24]: > I tried two motherboards, Iwill/DK8S2 and tyan/s2882. > Compiled succesfully and get a linuxbios.rom and > flashed them to chip using flash_rom. But I didn't see > any output via serial port. 1) wrong baud rate? See the motherboard config file 2) 1:1 cable instead of null modem (cross) cable? Stefan From yinghai.lu at amd.com Wed Sep 21 23:50:03 2005 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Wed, 21 Sep 2005 14:50:03 -0700 Subject: [LinuxBIOS] Asking help for serial output Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0616A@ssvlexmb2.amd.com> Flash_rom? Did you try flash_rom -vw linuxbios.rom How many memory on MB? >4G or not? Linux Kernel version? 2.6, 64 bit? YH -----Original Message----- From: linuxbios-bounces at openbios.org [mailto:linuxbios-bounces at openbios.org] On Behalf Of Stefan Reinauer Sent: Wednesday, September 21, 2005 2:38 PM To: Frank Samuel Cc: linuxbios at openbios.org Subject: Re: [LinuxBIOS] Asking help for serial output * Frank Samuel [050921 23:24]: > I tried two motherboards, Iwill/DK8S2 and tyan/s2882. > Compiled succesfully and get a linuxbios.rom and > flashed them to chip using flash_rom. But I didn't see > any output via serial port. 1) wrong baud rate? See the motherboard config file 2) 1:1 cable instead of null modem (cross) cable? Stefan -- LinuxBIOS mailing list LinuxBIOS at openbios.org http://www.openbios.org/mailman/listinfo/linuxbios From windrainman at yahoo.com Thu Sep 22 02:12:58 2005 From: windrainman at yahoo.com (Frank Samuel) Date: Wed, 21 Sep 2005 17:12:58 -0700 (PDT) Subject: [LinuxBIOS] Asking help for serial output In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0616A@ssvlexmb2.amd.com> Message-ID: <20050922001258.68313.qmail@web50302.mail.yahoo.com> Here is the info: when running flash_rom -vw linuxbios.rom, I get ..... Part is SST49LF004A/B Programming Page: 0007 at address: 0x00070000 Verifying address: VERIFIED Memory of the machine with linuxbios installed is of size 1GB. I tired compiling on two machines with two different kernels. 2.6.11.4-20a-default (SuSE 9.3 on a uniprocessor desktop) 2.4.22-1.2115.nptlsmp (Fedora Core 1 on IWILL DK8S.) Both kernels are 32-bit. The machine that I install linuxbios has a kernel of 64 bit 2.6.5-7.97-smp #1 SMP (SuSE SLES9) Xuehua --- "Lu, Yinghai" wrote: > Flash_rom? > > Did you try > flash_rom -vw linuxbios.rom > > How many memory on MB? >4G or not? > Linux Kernel version? 2.6, 64 bit? > > YH > > -----Original Message----- > From: linuxbios-bounces at openbios.org > [mailto:linuxbios-bounces at openbios.org] On Behalf Of > Stefan Reinauer > Sent: Wednesday, September 21, 2005 2:38 PM > To: Frank Samuel > Cc: linuxbios at openbios.org > Subject: Re: [LinuxBIOS] Asking help for serial > output > > * Frank Samuel [050921 > 23:24]: > > I tried two motherboards, Iwill/DK8S2 and > tyan/s2882. > > Compiled succesfully and get a linuxbios.rom and > > flashed them to chip using flash_rom. But I didn't > see > > any output via serial port. > > 1) wrong baud rate? See the motherboard config file > 2) 1:1 cable instead of null modem (cross) cable? > > Stefan > > > -- > 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 > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From yinghai.lu at amd.com Thu Sep 22 02:35:02 2005 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Wed, 21 Sep 2005 17:35:02 -0700 Subject: [LinuxBIOS] Asking help for serial output Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0616B@ssvlexmb2.amd.com> About the serial console, did you verify the connection by enabling serial console on /etc/inittab? YH -----Original Message----- From: Frank Samuel [mailto:windrainman at yahoo.com] Sent: Wednesday, September 21, 2005 5:13 PM To: Lu, Yinghai; Stefan Reinauer Cc: linuxbios at openbios.org Subject: RE: [LinuxBIOS] Asking help for serial output Here is the info: when running flash_rom -vw linuxbios.rom, I get ..... Part is SST49LF004A/B Programming Page: 0007 at address: 0x00070000 Verifying address: VERIFIED Memory of the machine with linuxbios installed is of size 1GB. I tired compiling on two machines with two different kernels. 2.6.11.4-20a-default (SuSE 9.3 on a uniprocessor desktop) 2.4.22-1.2115.nptlsmp (Fedora Core 1 on IWILL DK8S.) Both kernels are 32-bit. The machine that I install linuxbios has a kernel of 64 bit 2.6.5-7.97-smp #1 SMP (SuSE SLES9) Xuehua --- "Lu, Yinghai" wrote: > Flash_rom? > > Did you try > flash_rom -vw linuxbios.rom > > How many memory on MB? >4G or not? > Linux Kernel version? 2.6, 64 bit? > > YH > > -----Original Message----- > From: linuxbios-bounces at openbios.org > [mailto:linuxbios-bounces at openbios.org] On Behalf Of > Stefan Reinauer > Sent: Wednesday, September 21, 2005 2:38 PM > To: Frank Samuel > Cc: linuxbios at openbios.org > Subject: Re: [LinuxBIOS] Asking help for serial > output > > * Frank Samuel [050921 > 23:24]: > > I tried two motherboards, Iwill/DK8S2 and > tyan/s2882. > > Compiled succesfully and get a linuxbios.rom and > > flashed them to chip using flash_rom. But I didn't > see > > any output via serial port. > > 1) wrong baud rate? See the motherboard config file > 2) 1:1 cable instead of null modem (cross) cable? > > Stefan > > > -- > 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 > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From windrainman at yahoo.com Thu Sep 22 03:43:28 2005 From: windrainman at yahoo.com (Frank Samuel) Date: Wed, 21 Sep 2005 18:43:28 -0700 (PDT) Subject: [LinuxBIOS] Asking help for serial output In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0616B@ssvlexmb2.amd.com> Message-ID: <20050922014328.13875.qmail@web50306.mail.yahoo.com> Thanks. --- "Lu, Yinghai" wrote: > About the serial console, did you verify the > connection by enabling > serial console on /etc/inittab? > > YH > > I just added s0:2345:respawn:/sbin/agetty -L -f /etc/issueserial 9600 ttyS0 vt100 s1:2345:respawn:/sbin/agetty -L -f /etc/issueserial 38400 ttyS1 vt100 into /etc/initab on the machine where I run minicom. And run init -q. After power cycle the machine with linuxbios.rom flashed, but I still cannot get output from serial cable. BTW, I connected the cable to another machine and can recieve serial output of booting process. BTW, I installed lxbios, and run it right after linuxbios.rom is flashed. But it said that that linuxbios is not installed. Does it mean that the linuxbios.rom generated is still incorrect? The way I flashed linuxbios and ran lxbios is below: -bash-2.05b# ./flash_rom -vw /home/opt/linuxbios/LinuxBIOSv2-2040/targets/Iwill/dk8s2/dk8s2/linuxbios.rom The arguments are: -vw /home/opt/linuxbios/LinuxBIOSv2-2040/targets/Iwill/dk8s2/dk8s2/linuxbios.rom Calibrating timer since microsleep sucks ... takes a second Setting up microsecond timing loop 454M loops per second OK, calibrated, now do the deed Enabling flash write on AMD8111...OK Trying Am29F040B, 512 KB probe_29f040b: id1 0x7f, id2 0x45 Trying At29C040A, 512 KB probe_jedec: id1 0xbf, id2 0x60 Trying Mx29f002, 256 KB probe_29f002: id1 0xbf, id2 0x60 Trying SST29EE020A, 256 KB probe_jedec: id1 0xbf, id2 0x60 Trying SST28SF040A, 512 KB probe_28sf040: id1 0x7f, id2 0x45 Trying SST39SF020A, 256 KB probe_jedec: id1 0xbf, id2 0x60 Trying SST39VF020, 256 KB probe_jedec: id1 0xbf, id2 0x60 Trying SST49LF040, 512 KB probe_jedec: id1 0xbf, id2 0x60 Trying SST49LF080A, 1024 KB probe_jedec: id1 0xff, id2 0xff Trying SST49LF002A/B, 256 KB probe_jedec: id1 0xbf, id2 0x60 Trying SST49LF003A/B, 384 KB probe_jedec: id1 0xbf, id2 0x60 Trying SST49LF004A/B, 512 KB probe_jedec: id1 0xbf, id2 0x60 SST49LF004A/B found at physical address: 0xfff80000 Part is SST49LF004A/B Programming Page: 0007 at address: 0x00070000 Verifying address: VERIFIED -bash-2.05b# lxbios -a lxbios: LinuxBIOS table not found. LinuxBIOS does not appear to be installed on this system. Scanning for the table produced the following results: 0 valid signatures were found with bad header checksums. 0 valid headers were found with bad table checksums. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From yinghai.lu at amd.com Thu Sep 22 03:49:13 2005 From: yinghai.lu at amd.com (Lu, Yinghai) Date: Wed, 21 Sep 2005 18:49:13 -0700 Subject: [LinuxBIOS] Asking help for serial output Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E0616C@ssvlexmb2.amd.com> So your serial cable connection is right. I don't know who port the dk8s2, maybe ollie, He may send you one pre-built image. YH -----Original Message----- From: Frank Samuel [mailto:windrainman at yahoo.com] Sent: Wednesday, September 21, 2005 6:43 PM To: Lu, Yinghai; Stefan Reinauer Cc: linuxbios at openbios.org Subject: RE: [LinuxBIOS] Asking help for serial output Thanks. --- "Lu, Yinghai" wrote: > About the serial console, did you verify the > connection by enabling > serial console on /etc/inittab? > > YH > > I just added s0:2345:respawn:/sbin/agetty -L -f /etc/issueserial 9600 ttyS0 vt100 s1:2345:respawn:/sbin/agetty -L -f /etc/issueserial 38400 ttyS1 vt100 into /etc/initab on the machine where I run minicom. And run init -q. After power cycle the machine with linuxbios.rom flashed, but I still cannot get output from serial cable. BTW, I connected the cable to another machine and can recieve serial output of booting process. BTW, I installed lxbios, and run it right after linuxbios.rom is flashed. But it said that that linuxbios is not installed. Does it mean that the linuxbios.rom generated is still incorrect? The way I flashed linuxbios and ran lxbios is below: -bash-2.05b# ./flash_rom -vw /home/opt/linuxbios/LinuxBIOSv2-2040/targets/Iwill/dk8s2/dk8s2/linuxbios .rom The arguments are: -vw /home/opt/linuxbios/LinuxBIOSv2-2040/targets/Iwill/dk8s2/dk8s2/linuxbios .rom Calibrating timer since microsleep sucks ... takes a second Setting up microsecond timing loop 454M loops per second OK, calibrated, now do the deed Enabling flash write on AMD8111...OK Trying Am29F040B, 512 KB probe_29f040b: id1 0x7f, id2 0x45 Trying At29C040A, 512 KB probe_jedec: id1 0xbf, id2 0x60 Trying Mx29f002, 256 KB probe_29f002: id1 0xbf, id2 0x60 Trying SST29EE020A, 256 KB probe_jedec: id1 0xbf, id2 0x60 Trying SST28SF040A, 512 KB probe_28sf040: id1 0x7f, id2 0x45 Trying SST39SF020A, 256 KB probe_jedec: id1 0xbf, id2 0x60 Trying SST39VF020, 256 KB probe_jedec: id1 0xbf, id2 0x60 Trying SST49LF040, 512 KB probe_jedec: id1 0xbf, id2 0x60 Trying SST49LF080A, 1024 KB probe_jedec: id1 0xff, id2 0xff Trying SST49LF002A/B, 256 KB probe_jedec: id1 0xbf, id2 0x60 Trying SST49LF003A/B, 384 KB probe_jedec: id1 0xbf, id2 0x60 Trying SST49LF004A/B, 512 KB probe_jedec: id1 0xbf, id2 0x60 SST49LF004A/B found at physical address: 0xfff80000 Part is SST49LF004A/B Programming Page: 0007 at address: 0x00070000 Verifying address: VERIFIED -bash-2.05b# lxbios -a lxbios: LinuxBIOS table not found. LinuxBIOS does not appear to be installed on this system. Scanning for the table produced the following results: 0 valid signatures were found with bad header checksums. 0 valid headers were found with bad table checksums. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From linuxbios at xdr.com Thu Sep 22 04:22:07 2005 From: linuxbios at xdr.com (Dave Ashley) Date: Wed, 21 Sep 2005 19:22:07 -0700 Subject: [LinuxBIOS] Asking help for serial output Message-ID: <200509220222.j8M2M7Ve027331@xdr.com> CompUSA sells BIOS Post code cards for $50, we bought one and it was very useful during a certain stage of development. It'd help you before serial output is working. They have a 2 digit LED display, it's a little pci card that plugs into any pci slot. Within linuxbios and all bios' in general during the bootup process different codes are displayed. You can put in debug statements like post_code(0xda); to cause a specific code to show up. So you can tell how far it gets before something goes wrong or whatever. Have you tried all the serial ports? Maybe linuxbios is bringing up a different serial port as the console output one. Most MB's have more than one. From nxtv3 at yahoo.com Thu Sep 22 19:51:43 2005 From: nxtv3 at yahoo.com (Doug Bell) Date: Thu, 22 Sep 2005 10:51:43 -0700 (PDT) Subject: [LinuxBIOS] chip vs device and enable / init explanation request Message-ID: <20050922175144.24626.qmail@web35915.mail.mud.yahoo.com> Can someone explain the usage of chip & device keywords in the mainboard Config file? Also can someone explain the invocation of __pci_driver ops like pci_dev_enable_resources? How should these ( and pci_domain ) be structured, i.e. would one list each chip (with its pci devices) and a corresponding 'end' statement ? It appears we have northbridge as the highest level (chip) block with everything inside, including chips such as CPU. However, I get multiple initialization of my southbridge. Also, how are these related to the chip_operations .enable_dev functions, and device_operations functions such as .init? We have made much progress on the Via EPIA-SP but these are some of the lingering questions. Doug __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From rminnich at lanl.gov Fri Sep 23 00:13:03 2005 From: rminnich at lanl.gov (Ronald G Minnich) Date: Thu, 22 Sep 2005 16:13:03 -0600 Subject: [LinuxBIOS] [Fwd: Per Our Lunch Discussion] Message-ID: <43332C6F.9050703@lanl.gov> I want this on a T-shirt. ron -------------- next part -------------- A non-text attachment was scrubbed... Name: B-ERROR_solo.gif Type: image/gif Size: 6022 bytes Desc: not available URL: From talbotx at comcast.net Fri Sep 23 00:39:52 2005 From: talbotx at comcast.net (Adam Talbot) Date: Thu, 22 Sep 2005 15:39:52 -0700 Subject: [LinuxBIOS] [Fwd: Per Our Lunch Discussion] In-Reply-To: <43332C6F.9050703@lanl.gov> References: <43332C6F.9050703@lanl.gov> Message-ID: <433332B8.8090709@comcast.net> OK, that is GREAT!! -Adam Ronald G Minnich wrote: > I want this on a T-shirt. > > ron > > ------------------------------------------------------------------------ > From Morales at appro.com Fri Sep 23 00:56:54 2005 From: Morales at appro.com (Edwin Morales) Date: Thu, 22 Sep 2005 15:56:54 -0700 Subject: [LinuxBIOS] SATA issues with Tyan2891 Message-ID: <4B21D6C08BC8BA4A9530E43C980E58B0471DB6@hawk.appro.com> HI, Still having SATA issues with Linuxbios and the Tyan 2891. I am using Etherboot 5.2.6, network booting, with a PATA hdd as the RH drive and a SATA as a data disk mounting to /export. RH sees the SATA hdd but it cannot initialize. System comes up fine but no SATA. No special arguments passed for the NBI. Here is the output, I've also attached the LinuxBios output. SCSI subsystem initialized ata1: SATA max UDMA/133 cmd 0x3050 ctl 0x3092 bmdma 0x3030 irq 201 ata2: SATA max UDMA/133 cmd 0x3060 ctl 0x30A2 bmdma 0x3038 irq 201 ata1: no device found (phy stat 00000000) scsi0 : sata_nv ata2: no device found (phy stat 00000000) scsi1 : sata_nv ata3: SATA max UDMA/133 cmd 0x3070 ctl 0x30B2 bmdma 0x3040 irq 193 ata4: SATA max UDMA/133 cmd 0x3080 ctl 0x30C2 bmdma 0x3048 irq 193 ata3: PIO error, drv_stat 0x50 ata3: dev 0 not supported, ignoring scsi2 : sata_nv ata4: no device found (phy stat 00000000) scsi3 : sata_nv kjournald starting. Commit interval 5 seconds Thanks /ed -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: output Type: application/octet-stream Size: 14518 bytes Desc: output URL: From san at google.com Fri Sep 23 18:58:26 2005 From: san at google.com (San Mehat) Date: Fri, 23 Sep 2005 09:58:26 -0700 Subject: [LinuxBIOS] Executing Real-Mode Binaries Message-ID: <236ccac050923095879481c43@mail.google.com> Greetings, Are there any facilities for linking in and executing real mode binaries? I have a 'blob' that I need to execute fairly early in real mode. If not its fine, I can start on one... thanks ;) -san -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at lanl.gov Fri Sep 23 19:12:35 2005 From: rminnich at lanl.gov (Ronald G Minnich) Date: Fri, 23 Sep 2005 11:12:35 -0600 Subject: [LinuxBIOS] sc520 support is in Message-ID: <43343783.7080305@lanl.gov> you can now build an sc520 bios for the digital logic msm586sev, and the ethernet works. Due to a glitch with hardware, the name of the target is mem586seg; I plan to fix this problem. For now, it's a great little cluster node. msm586sev is a nice little board, small, low power. To-dos - no vga bios yet (well, not totally, you can get it in user mode with the "testbios' program in linuxbios utilities, just not in linuxbios itself) - need to finish up dynamic memory sizing code - keyboard stuck error (no kb interrupts?) - reset is still not reliable this cpu was kind of a bear, and still does not fit well into the linuxbios way of doing things, and never will be that good a fit due to architectural design problems with the FLASH address map(see linux journal web article). I'm going to build a cluster of them anyway ... ron From smithbone at gmail.com Fri Sep 23 20:46:20 2005 From: smithbone at gmail.com (Richard Smith) Date: Fri, 23 Sep 2005 13:46:20 -0500 Subject: [LinuxBIOS] Executing Real-Mode Binaries In-Reply-To: <236ccac050923095879481c43@mail.google.com> References: <236ccac050923095879481c43@mail.google.com> Message-ID: <8a0c367805092311463e1c6a31@mail.gmail.com> > Greetings, > > Are there any facilities for linking in and executing real mode binaries? I > have a 'blob' that I need to execute fairly early in real mode. > > If not its fine, I can start on one... You want to look at ADLO in V1. ADLO is a payload that drops back to real mode an executes the BIOS from the bochs project. See the wiki for lots more detail. Since ADLO is just a payload it should come forward into V2 pretty easy. There aren't many users. In fact I think I (Bitworks, Inc) has been the only user for a long time. The project that used that is now dead so I haven't messed withit for a while. I'll be happy to help you all I can. What kind of hardware are you using this on? One key thing about the current way ADLO works is that you have to enable the shadow areas of your chipset. (Again see the wiki) and this is specific to each motherboard so you have to tweak the ADLO code to eable this. The ADLO in V1 works for the board that Adam orginally got it working on. I have patches that make it work for a Intel 440bx based board. But other than that you have to customize it. There have been some discussions on the list previously of a possible generic method of enableing the shadow areas for a chipset. But the payload boundry makes that somewhat difficult. Search the archives for "shadow" and I think you will find those threads. I don't remember the end result. So is google looking at using LinuxBIOS on some of it systems? -- Richard A. Smith From san at google.com Fri Sep 23 21:41:06 2005 From: san at google.com (San Mehat) Date: Fri, 23 Sep 2005 12:41:06 -0700 Subject: [LinuxBIOS] Executing Real-Mode Binaries In-Reply-To: <8a0c367805092311463e1c6a31@mail.gmail.com> References: <236ccac050923095879481c43@mail.google.com> <8a0c367805092311463e1c6a31@mail.gmail.com> Message-ID: <236ccac0509231241f96b922@mail.google.com> Hmm... that doesnt actually look like ADLO is what I need. Basically I have a binary blob that i need to jump into very early to do early setup tasks. This initial task doesnt look *that* difficult.. I'm thinking I'll just get the blob to link in at the segment it needs to run at (e000 segment), and write an asm wrapper for it which drops to big real mode, calls the blob, then pops back into pmode. In the long run, I think perhaps some kind of generic 16 bit 'callout' mechanism may be required for early call blobs and whatnot (perhaps even later.. option roms (gak)). As far as Google goes, we're currently trying to get LinuxBIOS to function for us to evaluate the featureset. So far it looks pretty good, and I'm excited to get it going, and enhance it with what I can... Thanks for the help, i appreciate the quick response. On 9/23/05, Richard Smith wrote: > > > Greetings, > > > > Are there any facilities for linking in and executing real mode > binaries? I > > have a 'blob' that I need to execute fairly early in real mode. > > > > If not its fine, I can start on one... > > You want to look at ADLO in V1. ADLO is a payload that drops back to > real mode an executes the BIOS from the bochs project. > > See the wiki for lots more detail. > > Since ADLO is just a payload it should come forward into V2 pretty easy. > > There aren't many users. In fact I think I (Bitworks, Inc) has been > the only user for a long time. The project that used that is now dead > so I haven't messed withit for a while. > > I'll be happy to help you all I can. What kind of hardware are you > using this on? > > One key thing about the current way ADLO works is that you have to > enable the shadow areas of your chipset. (Again see the wiki) and this > is specific to each motherboard so you have to tweak the ADLO code to > eable this. > > The ADLO in V1 works for the board that Adam orginally got it working > on. I have patches that make it work for a Intel 440bx based board. > But other than that you have to customize it. > > There have been some discussions on the list previously of a possible > generic method of enableing the shadow areas for a chipset. But the > payload boundry makes that somewhat difficult. > > Search the archives for "shadow" and I think you will find those > threads. I don't remember the end result. > > So is google looking at using LinuxBIOS on some of it systems? > > -- > Richard A. Smith > -------------- next part -------------- An HTML attachment was scrubbed... URL: From smithbone at gmail.com Fri Sep 23 21:57:07 2005 From: smithbone at gmail.com (Richard Smith) Date: Fri, 23 Sep 2005 14:57:07 -0500 Subject: [LinuxBIOS] Executing Real-Mode Binaries In-Reply-To: <236ccac0509231241f96b922@mail.google.com> References: <236ccac050923095879481c43@mail.google.com> <8a0c367805092311463e1c6a31@mail.gmail.com> <236ccac0509231241f96b922@mail.google.com> Message-ID: <8a0c36780509231257713eb83d@mail.gmail.com> > This initial task doesnt look *that* difficult.. I'm thinking I'll just get > the blob to link in at the segment it needs to run at (e000 segment), and > write an asm > wrapper for it which drops to big real mode, calls the blob, then pops back > into pmode. Ah ok. I think others have done similar stuff. Perhpas some of them will pipe up. > In the long run, I think perhaps some kind of generic 16 bit 'callout' > mechanism may be required for early call blobs and whatnot (perhaps even > later.. option roms (gak)). We already have this. Its the x86 emu code. You are comming in a little late in the game but the only way to do this and maintain cross-platform compability was to run the code under an emulator. Its in the V2 codebase and is used to POST many vga cards and some SCSI card option roms. You may wan't to go look at that and see if it fits your needs. Actually in fact I would ask you to go look at that and if it dosen't fit your needs please tell us why. -- Richard A. Smith From san at google.com Fri Sep 23 22:05:07 2005 From: san at google.com (San Mehat) Date: Fri, 23 Sep 2005 13:05:07 -0700 Subject: [LinuxBIOS] Executing Real-Mode Binaries In-Reply-To: <8a0c36780509231257713eb83d@mail.gmail.com> References: <236ccac050923095879481c43@mail.google.com> <8a0c367805092311463e1c6a31@mail.gmail.com> <236ccac0509231241f96b922@mail.google.com> <8a0c36780509231257713eb83d@mail.gmail.com> Message-ID: <236ccac050923130577b41b7f@mail.google.com> For sure, I'll definetly start hunting around more. Thanks for the response. -san On 9/23/05, Richard Smith wrote: > > > This initial task doesnt look *that* difficult.. I'm thinking I'll just > get > > the blob to link in at the segment it needs to run at (e000 segment), > and > > write an asm > > wrapper for it which drops to big real mode, calls the blob, then pops > back > > into pmode. > > Ah ok. I think others have done similar stuff. Perhpas some of them > will pipe up. > > > In the long run, I think perhaps some kind of generic 16 bit 'callout' > > mechanism may be required for early call blobs and whatnot (perhaps even > > later.. option roms (gak)). > > We already have this. Its the x86 emu code. You are comming in a > little late in the game but the only way to do this and maintain > cross-platform compability was to run the code under an emulator. > > Its in the V2 codebase and is used to POST many vga cards and some > SCSI card option roms. > > You may wan't to go look at that and see if it fits your needs. > Actually in fact I would ask you to go look at that and if it dosen't > fit your needs please tell us why. > > -- > Richard A. Smith > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Morales at appro.com Sat Sep 24 01:02:33 2005 From: Morales at appro.com (Edwin Morales) Date: Fri, 23 Sep 2005 16:02:33 -0700 Subject: FW: [Retrieved][LinuxBIOS] SATA issues with Tyan2891 Message-ID: <4B21D6C08BC8BA4A9530E43C980E58B0471DC9@hawk.appro.com> HI, Still having SATA issues with Linuxbios and the Tyan 2891. I am using Etherboot 5.2.6, network booting, with a PATA hdd as the RH drive and a SATA as a data disk mounting to /export. RH sees the SATA hdd but it cannot initialize. System comes up fine but no SATA. No special arguments passed for the NBI. Here is the output, I've also attached the LinuxBios output. SCSI subsystem initialized ata1: SATA max UDMA/133 cmd 0x3050 ctl 0x3092 bmdma 0x3030 irq 201 ata2: SATA max UDMA/133 cmd 0x3060 ctl 0x30A2 bmdma 0x3038 irq 201 ata1: no device found (phy stat 00000000) scsi0 : sata_nv ata2: no device found (phy stat 00000000) scsi1 : sata_nv ata3: SATA max UDMA/133 cmd 0x3070 ctl 0x30B2 bmdma 0x3040 irq 193 ata4: SATA max UDMA/133 cmd 0x3080 ctl 0x30C2 bmdma 0x3048 irq 193 ata3: PIO error, drv_stat 0x50 ata3: dev 0 not supported, ignoring scsi2 : sata_nv ata4: no device found (phy stat 00000000) scsi3 : sata_nv kjournald starting. Commit interval 5 seconds Thanks /ed -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: output Type: application/octet-stream Size: 14518 bytes Desc: output URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT04046.txt URL: From rminnich at lanl.gov Sat Sep 24 05:12:52 2005 From: rminnich at lanl.gov (Ronald G Minnich) Date: Fri, 23 Sep 2005 21:12:52 -0600 Subject: [LinuxBIOS] ignore this, testing. Message-ID: <4334C434.5090902@lanl.gov> ron From halbmond at macnews.de Sat Sep 24 23:42:08 2005 From: halbmond at macnews.de (Angel) Date: Sat, 24 Sep 2005 23:42:08 +0200 Subject: [LinuxBIOS] Does LinuxBIOS run on the ECS 760GX-M? Message-ID: <281d9dd511657c3a8c19e89d074ce8f4@macnews.de> On my search for a LinuxBIOS compatible AMD mainboard, I tripped over the ECS 760GX-M. It's socket 754 and uses the SiS chips 760GX and 964. As far as I know SiS is supporting LinuxBIOS actively, so in terms of the chipset the board should run LinuxBIOS. Plus, it has a 4Mb (=500 KiB) Flash ROM with the following description from the manufactorer's website: SYSTEM BIOS -------------- next part -------------- A non-text attachment was scrubbed... Name: point_3.gif Type: image/gif Size: 59 bytes Desc: not available URL: -------------- next part -------------- Award BIOS with 4Mb Flash ROM -------------- next part -------------- A non-text attachment was scrubbed... Name: point_3.gif Type: image/gif Size: 59 bytes Desc: not available URL: -------------- next part -------------- Supports Plug and Play 1.0A, APM 1.2, Multi Boot, DMI -------------- next part -------------- A non-text attachment was scrubbed... Name: point_3.gif Type: image/gif Size: 59 bytes Desc: not available URL: -------------- next part -------------- Supports ACPI revision 1.0 specification Because I want to be shure that this mainboard supports LinuxBIOS before I will buy it, I thought I'd better ask here if anyone has it in use and can say something about it. The chipset and the plug and play BIOS at least sound promisingly to me. Oh, and a previous ECS mainboard, the K7SEM, is proven to be compatible. From yinghailu at gmail.com Sun Sep 25 01:17:16 2005 From: yinghailu at gmail.com (yhlu) Date: Sat, 24 Sep 2005 16:17:16 -0700 Subject: [LinuxBIOS] Does LinuxBIOS run on the ECS 760GX-M? In-Reply-To: <281d9dd511657c3a8c19e89d074ce8f4@macnews.de> References: <281d9dd511657c3a8c19e89d074ce8f4@macnews.de> Message-ID: <2ea3fae1050924161735f9084e@mail.gmail.com> It is not support because of the SIS chipset is not supported right now. YH On 9/24/05, Angel wrote: > > On my search for a LinuxBIOS compatible AMD mainboard, I tripped over > the ECS 760GX-M. > It's socket 754 and uses the SiS chips 760GX and 964. As far as I know > SiS is supporting LinuxBIOS actively, so > in terms of the chipset the board should run LinuxBIOS. Plus, it has a > 4Mb (=500 KiB) Flash ROM with the following > description from the manufactorer's website: > > SYSTEM BIOS > > > Award BIOS with 4Mb Flash ROM > > > Supports Plug and Play 1.0A, APM 1.2, Multi Boot, DMI > > > Supports ACPI revision 1.0 specification > > Because I want to be shure that this mainboard supports LinuxBIOS > before I will buy it, I thought I'd better > ask here if anyone has it in use and can say something about it. > The chipset and the plug and play BIOS at least sound promisingly to > me. Oh, and a previous ECS mainboard, > the K7SEM, is proven to be compatible. > > > -- > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrg at toasterfish.com Mon Sep 26 00:35:38 2005 From: jrg at toasterfish.com (John Galloway) Date: Sun, 25 Sep 2005 15:35:38 -0700 Subject: [LinuxBIOS] VIA EPIA-MII in the supported list but no target? Message-ID: I'm looking at attempting to use LinuxBIOS to boot my VIA EPIA-MII10000 from the CF slot (a common desire among MII users, but with little success it seems). The EPIA-MII IS in the supported motherboards list, but targets/via only has an entry for epia and epia-m, no epia-mii. The M and the MII are different enough that I can't see them using the same target config. What gives? -jrg From rminnich at gmail.com Mon Sep 26 04:50:35 2005 From: rminnich at gmail.com (ron minnich) Date: Sun, 25 Sep 2005 20:50:35 -0600 Subject: [LinuxBIOS] testing again Message-ID: <13426df105092519507d32f3a4@mail.gmail.com> It has come to my attention that I've not been receiving mail from the list, hence this test. Something broke somewhere ... ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From noodles at earth.li Mon Sep 26 10:10:00 2005 From: noodles at earth.li (Jonathan McDowell) Date: Mon, 26 Sep 2005 09:10:00 +0100 Subject: [LinuxBIOS] VIA EPIA-MII in the supported list but no target? In-Reply-To: References: Message-ID: <20050926081000.GE7493@earth.li> On Sun, Sep 25, 2005 at 03:35:38PM -0700, John Galloway wrote: > I'm looking at attempting to use LinuxBIOS to boot my > VIA EPIA-MII10000 from the CF slot (a common desire among > MII users, but with little success it seems). The EPIA-MII > IS in the supported motherboards list, but targets/via > only has an entry for epia and epia-m, no epia-mii. The M > and the MII are different enough that I can't see them > using the same target config. What gives? I thought the main difference between the M and the M-II was the addition of the cardbus bridge for the CF/PCMCIA slots? What other differences are there? There's old code for the bridge in src/southbridge/ricoh/rl5c476/ but I don't think it even compiles at present. J. -- noodles is one of the most popular food all over the world From stepan at openbios.org Mon Sep 26 13:25:46 2005 From: stepan at openbios.org (Stefan Reinauer) Date: Mon, 26 Sep 2005 13:25:46 +0200 Subject: [LinuxBIOS] testing again In-Reply-To: <13426df105092519507d32f3a4@mail.gmail.com> References: <13426df105092519507d32f3a4@mail.gmail.com> Message-ID: <20050926112546.GA10923@openbios.org> * ron minnich [050926 04:50]: > It has come to my attention that I've not been receiving mail from the list, > hence this test. Something broke somewhere ... Ron, you should be able to read this message now through your gmail account. Seems like the mails get filtered out at your other mail account. Strange, since the linuxbios mailing list is well filtered without any spam to the list for months. Stefan From noodles at earth.li Mon Sep 26 14:19:07 2005 From: noodles at earth.li (Jonathan McDowell) Date: Mon, 26 Sep 2005 13:19:07 +0100 Subject: [LinuxBIOS] VIA EPIA-MII in the supported list but no target? In-Reply-To: References: <20050926081000.GE7493@earth.li> Message-ID: <20050926121907.GI26280@earth.li> [I don't know if you meant to take this offlist, but I think it's better it stays there so anyone wondering the status in the future can read the archives] On Mon, Sep 26, 2005 at 03:53:19AM -0700, John Galloway wrote: > On Sep 26, 2005, at 1:10 AM, Jonathan McDowell wrote: > >On Sun, Sep 25, 2005 at 03:35:38PM -0700, John Galloway wrote: > >>I'm looking at attempting to use LinuxBIOS to boot my VIA > >>EPIA-MII10000 from the CF slot (a common desire among MII users, but > >>with little success it seems). The EPIA-MII IS in the supported > >>motherboards list, but targets/via only has an entry for epia and > >>epia-m, no epia-mii. The M and the MII are different enough that I > >>can't see them using the same target config. What gives? > >I thought the main difference between the M and the M-II was the > >addition of the cardbus bridge for the CF/PCMCIA slots? What other > >differences are there? > Oh, none I guess (I thought there was more but checking the specs, > now, I don't see it) but that was in fact the difference that concerns > me since I want to boot off the CF slot. > >There's old code for the bridge in src/southbridge/ricoh/rl5c476/ > >but I don't think it even compiles at present. > but now I don't see why LinuxBIOS cares about that since its FILO that > will be loading the kernel off CF, so now I'm not sure that even that > matters. But FILO doesn't setup any of the low level hardware. You need LinuxBIOS to initialise the cardbus bridge and then map the CF slot appropriately so that the IDE code in FILO can talk to your CF device. > what was the code that doesn't compile for? (I suspect once I hit send > all this will make sense but just now I seem to have lost it). It looks like it does initial configuration of the bridge and maps the CF card to 0x1E8->0x1F0. I don't have an EPIA-MII so I've only looked at it just now. J. -- There are always at least two ways to program the same thing. [ Black Cat Networks ] [ 0845 PAYG dialup ] [ ADSL from ?20+VAT/month ] [ http://www.blackcatnetworks.co.uk/ ] From pj at cassens.com Mon Sep 26 14:46:34 2005 From: pj at cassens.com (pj at cassens.com) Date: Mon, 26 Sep 2005 07:46:34 -0500 Subject: [LinuxBIOS] VIA EPIA-MII in the supported list but no target? In-Reply-To: <20050926121907.GI26280@earth.li> References: <20050926081000.GE7493@earth.li> <20050926121907.GI26280@earth.li> Message-ID: <20050926124634.GA15175@cassens.com> On Mon, Sep 26, 2005 at 01:19:07PM +0100, Jonathan McDowell wrote: > [I don't know if you meant to take this offlist, but I think it's better > it stays there so anyone wondering the status in the future can read the > archives] The company I work for is currently sponsoring a developer to help update the MII code line in LinuxBios V2. There should be updates in about 3 weeks, if all goes well. This is a great board to work with. It's got everything and the, "kitchen sink". There are alot of people using it for MythTV (via miniMyth), for example. We use it for a mobile PC application. From rminnich at gmail.com Mon Sep 26 16:55:03 2005 From: rminnich at gmail.com (ron minnich) Date: Mon, 26 Sep 2005 08:55:03 -0600 Subject: [LinuxBIOS] testing again In-Reply-To: <20050926112546.GA10923@openbios.org> References: <13426df105092519507d32f3a4@mail.gmail.com> <20050926112546.GA10923@openbios.org> Message-ID: <13426df105092607557fd0eb0c@mail.gmail.com> I'm back on but I need to see if thunderbird can do gmail! I'm moving everything I can off LANL -- I don't like this business of losing mail. ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From ollie at lanl.gov Mon Sep 26 18:37:30 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Mon, 26 Sep 2005 10:37:30 -0600 Subject: [LinuxBIOS] testing again In-Reply-To: <20050926112546.GA10923@openbios.org> References: <13426df105092519507d32f3a4@mail.gmail.com> <20050926112546.GA10923@openbios.org> Message-ID: <1127752650.9707.2.camel@logarithm.lanl.gov> On Mon, 2005-09-26 at 13:25 +0200, Stefan Reinauer wrote: > * ron minnich [050926 04:50]: > > It has come to my attention that I've not been receiving mail from the list, > > hence this test. Something broke somewhere ... > > Ron, you should be able to read this message now through your > gmail account. Seems like the mails get filtered out at your > other mail account. Strange, since the linuxbios mailing list > is well filtered without any spam to the list for months. > Are you using the same mail server as I am? Why didn't I lost any mail? -- Li-Ta Lo Los Alamos National Lab From jrg at toasterfish.com Mon Sep 26 22:48:23 2005 From: jrg at toasterfish.com (John Galloway) Date: Mon, 26 Sep 2005 13:48:23 -0700 Subject: [LinuxBIOS] VIA EPIA-MII in the supported list but no target? In-Reply-To: <20050926124634.GA15175@cassens.com> References: <20050926081000.GE7493@earth.li> <20050926121907.GI26280@earth.li> <20050926124634.GA15175@cassens.com> Message-ID: <1C035D75-E94D-4436-85A7-8A2937F6560A@toasterfish.com> On Sep 26, 2005, at 5:46 AM, pj at cassens.com wrote: > On Mon, Sep 26, 2005 at 01:19:07PM +0100, Jonathan McDowell wrote: > > The company I work for is currently sponsoring a developer to help > update the MII code line in LinuxBios V2. There should be updates > in about 3 weeks, if all goes well. Excellent! I'll hold off till that work is ready (I'll be happy to help test) > > This is a great board to work with. It's got everything and the, > "kitchen sink". There are alot of people using it for MythTV (via > miniMyth), for example. We use it for a mobile PC application. I agree, though I'm using it for robotics -jrg From nxtv3 at yahoo.com Mon Sep 26 23:17:14 2005 From: nxtv3 at yahoo.com (Doug Bell) Date: Mon, 26 Sep 2005 14:17:14 -0700 (PDT) Subject: [LinuxBIOS] romcc - Internal compiler error: Cannot find block dominated .... Message-ID: <20050926211714.70436.qmail@web35908.mail.mud.yahoo.com> 0x8360d58 phi Internal compiler error: Cannot find block dominated by 0x82ba9a8 Any ideas on workarounds / fixes here? Is am I running out of registers or some other problem? __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From rminnich at gmail.com Tue Sep 27 03:30:12 2005 From: rminnich at gmail.com (ron minnich) Date: Mon, 26 Sep 2005 19:30:12 -0600 Subject: [LinuxBIOS] romcc - Internal compiler error: Cannot find block dominated .... In-Reply-To: <20050926211714.70436.qmail@web35908.mail.mud.yahoo.com> References: <20050926211714.70436.qmail@web35908.mail.mud.yahoo.com> Message-ID: <13426df1050926183048099695@mail.gmail.com> On 9/26/05, Doug Bell wrote: > > 0x8360d58 phi Internal compiler error: Cannot > find block dominated by 0x82ba9a8 > > Any ideas on workarounds / fixes here? Is am I running > out of registers or some other problem? can you tell us more about the environment, uname -a distro, and linuxbios target? ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebiederman at lnxi.com Tue Sep 27 10:16:37 2005 From: ebiederman at lnxi.com (Eric W. Biederman) Date: Tue, 27 Sep 2005 02:16:37 -0600 Subject: [LinuxBIOS] romcc - Internal compiler error: Cannot find block dominated .... In-Reply-To: <20050926211714.70436.qmail@web35908.mail.mud.yahoo.com> (Doug Bell's message of "Mon, 26 Sep 2005 14:17:14 -0700 (PDT)") References: <20050926211714.70436.qmail@web35908.mail.mud.yahoo.com> Message-ID: Doug Bell writes: > 0x8360d58 phi Internal compiler error: Cannot > find block dominated by 0x82ba9a8 > > Any ideas on workarounds / fixes here? Try commenting out code to isolate the problem or remove. > Is am I running out of registers or some other problem? Unless something has found a way to miscompile romcc it is a bug in the internal romcc logic. Bugs of that sort are pretty rare and almost always they break the compile instead of giving you bad code. This feels like something was optimized away and not everything was properly updated. Either that or there is a spaghetti mess of goto's somewhere in that chunk of code. Eric From nxtv3 at yahoo.com Tue Sep 27 16:26:57 2005 From: nxtv3 at yahoo.com (Doug Bell) Date: Tue, 27 Sep 2005 07:26:57 -0700 (PDT) Subject: [LinuxBIOS] romcc - Internal compiler error: Cannot find block dominated .... In-Reply-To: <13426df1050926183048099695@mail.gmail.com> Message-ID: <20050927142657.82182.qmail@web35911.mail.mud.yahoo.com> It seems to not be related to register allocation, how many layers of functions, or code size, but to nested if statements or variations thereof, e.g. if ( (condition a) && ( condition b) ) .... /home/dbell # uname -a Linux Doug 2.6.9 #1 Tue Jan 11 17:26:41 UTC 2005 i686 Intel(R) Pentium(R) 4 CPU 1500MHz GenuineIntel GNU/Linux Target is via epia-sp, under development but close to an alpha release with some open items. BTW, is there any documentation regarding what limitations romcc has (e.g. multidimensional arrays not allowed, etc )? Thanks, Doug --- ron minnich wrote: > On 9/26/05, Doug Bell wrote: > > > > 0x8360d58 phi Internal compiler error: Cannot > > find block dominated by 0x82ba9a8 > > > > Any ideas on workarounds / fixes here? Is am I > running > > out of registers or some other problem? > > > can you tell us more about the environment, > uname -a > distro, and linuxbios target? > > ron > > -- > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From nxtv3 at yahoo.com Tue Sep 27 18:31:09 2005 From: nxtv3 at yahoo.com (Doug Bell) Date: Tue, 27 Sep 2005 09:31:09 -0700 (PDT) Subject: [LinuxBIOS] romcc - Internal compiler error: Cannot find block dominated .... In-Reply-To: <20050927142657.82182.qmail@web35911.mail.mud.yahoo.com> Message-ID: <20050927163110.80747.qmail@web35915.mail.mud.yahoo.com> I had one version of code where it failed on a line like: if (speed==100) speed=0; but problem disappeared if I did : if (speed==100) speed2=0; This may have been a factor in the first reporting of the problem as well. -dB --- Doug Bell wrote: > It seems to not be related to register allocation, > how > many layers of functions, or code size, but to > nested > if statements or variations thereof, e.g. if ( > (condition a) && ( condition b) ) .... > > > /home/dbell # uname -a > Linux Doug 2.6.9 #1 Tue Jan 11 17:26:41 UTC 2005 > i686 > Intel(R) Pentium(R) 4 CPU 1500MHz GenuineIntel > GNU/Linux > > > Target is via epia-sp, under development but close > to > an alpha release with some open items. > > BTW, is there any documentation regarding what > limitations romcc has (e.g. multidimensional arrays > not allowed, etc )? > > Thanks, Doug > > --- ron minnich wrote: > > > On 9/26/05, Doug Bell wrote: > > > > > > 0x8360d58 phi Internal compiler error: Cannot > > > find block dominated by 0x82ba9a8 > > > > > > Any ideas on workarounds / fixes here? Is am I > > running > > > out of registers or some other problem? > > > > > > can you tell us more about the environment, > > uname -a > > distro, and linuxbios target? > > > > ron > > > -- > > LinuxBIOS mailing list > > LinuxBIOS at openbios.org > > http://www.openbios.org/mailman/listinfo/linuxbios > > > > > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com > > -- > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From rminnich at lanl.gov Tue Sep 27 22:50:35 2005 From: rminnich at lanl.gov (Ronald G Minnich) Date: Tue, 27 Sep 2005 14:50:35 -0600 Subject: [LinuxBIOS] linuxbios summit opens with talk by Richard Bruner, AMD Fellow Message-ID: <4339B09B.7050504@lanl.gov> This should whet your appetite for the 3-day linuxbios summit Oct. 11, 2005 in santa fe! For more information, http://lacsi.rice.edu/symposium/ Title: AMD's Roadmap for Free Firmware (as in Beer) Speaker: Rich Brunner, AMD Fellow Abstract: This will be a discussion of the upcoming AMD Processor roadmap, AMD plans for supporting LinuxBIOS, and AMD's directions for the future of firmware. Speaker BIO: Richard A. Brunner is the Software Architect for Advanced Micro Devices' AMD64 Architecture. He is an AMD fellow and is responsible for driving the technical direction of AMD's AMD64 software strategy for operating systems, device drivers, compilers, libraries, OS/firmware interaction, performance optimizations, and 3rd party tools. Richard led AMD's initial involvement into the Unified Extensible Firmware Interface (UEFI) forum. Richard holds a Masters of Science degree in Computer Engineering from Rensselaer Polytechnic Institute and a Bachelor of Science degree in Electrical Engineering from Case Western Reserve University. He holds patents in computer architecture and has presented extensively including Hot Chips, Siggraph, WinHec, Linux Kernel Summit, Linux World, Ottawa Linux Symposium. From nxtv3 at yahoo.com Tue Sep 27 22:57:38 2005 From: nxtv3 at yahoo.com (Doug Bell) Date: Tue, 27 Sep 2005 13:57:38 -0700 (PDT) Subject: [LinuxBIOS] romcc - Internal compiler error: Cannot find block dominated .... In-Reply-To: <20050927163110.80747.qmail@web35915.mail.mud.yahoo.com> Message-ID: <20050927205738.87739.qmail@web35912.mail.mud.yahoo.com> Beyond that, there was one version in which I simply switched the order of declaration of variables to make it compile: // unsigned char row,col; // broken unsigned char col,row; // works In another test run........ //if ( total < c) total+=div; // failed if ( total < c) subtotal+=div; // was ok total=subtotal; Ron / Eric - What is the best way to proceed on this? What info would you want? I don't think I'm doing anything bizarre, maybe 4 chars declared, no deep levels of functions. --- Doug Bell wrote: > I had one version of code where it failed on a line > like: > if (speed==100) speed=0; > > but problem disappeared if I did : > if (speed==100) speed2=0; > > This may have been a factor in the first reporting > of > the problem as well. > > -dB > > --- Doug Bell wrote: > > > It seems to not be related to register allocation, > > how > > many layers of functions, or code size, but to > > nested > > if statements or variations thereof, e.g. if ( > > (condition a) && ( condition b) ) .... > > > > > > /home/dbell # uname -a > > Linux Doug 2.6.9 #1 Tue Jan 11 17:26:41 UTC 2005 > > i686 > > Intel(R) Pentium(R) 4 CPU 1500MHz GenuineIntel > > GNU/Linux > > > > > > Target is via epia-sp, under development but close > > to > > an alpha release with some open items. > > > > BTW, is there any documentation regarding what > > limitations romcc has (e.g. multidimensional > arrays > > not allowed, etc )? > > > > Thanks, Doug > > > > --- ron minnich wrote: > > > > > On 9/26/05, Doug Bell wrote: > > > > > > > > 0x8360d58 phi Internal compiler error: Cannot > > > > find block dominated by 0x82ba9a8 > > > > > > > > Any ideas on workarounds / fixes here? Is am I > > > running > > > > out of registers or some other problem? > > > > > > > > > can you tell us more about the environment, > > > uname -a > > > distro, and linuxbios target? > > > > > > ron > > > > -- > > > LinuxBIOS mailing list > > > LinuxBIOS at openbios.org > > > > http://www.openbios.org/mailman/listinfo/linuxbios > > > > > > > > > > __________________________________ > > Yahoo! Mail - PC Magazine Editors' Choice 2005 > > http://mail.yahoo.com > > > > -- > > LinuxBIOS mailing list > > LinuxBIOS at openbios.org > > http://www.openbios.org/mailman/listinfo/linuxbios > > > > > > > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com > > -- > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From talbotx at comcast.net Tue Sep 27 23:39:35 2005 From: talbotx at comcast.net (Adam Talbot) Date: Tue, 27 Sep 2005 14:39:35 -0700 Subject: [LinuxBIOS] SMP hardware question In-Reply-To: <4339B09B.7050504@lanl.gov> References: <4339B09B.7050504@lanl.gov> Message-ID: <4339BC17.9080909@comcast.net> Currently I have a dual proc Tyan MPX system running two athlon XP's that I have converted to MP by closing a bridge on the top of the CPU's. So that little trick changed the name of the CPU, but what makes an XP CPU not capable of running in an SMP setup? Is this a factor of the BIOS or is there something more? -Adam Talbot From rminnich at lanl.gov Tue Sep 27 23:56:13 2005 From: rminnich at lanl.gov (Ronald G Minnich) Date: Tue, 27 Sep 2005 15:56:13 -0600 Subject: [LinuxBIOS] [Fwd: LB Summit Schedule] Message-ID: <4339BFFD.6000803@lanl.gov> Here is the sched. Notice a few things. We have left a lot of time for discussion in important areas. We need discussion leaders in: o user friendly -- how do we make this nice for users -- they can't use boot cds! How do we make linuxbios useful for the desktop? How can we make it more useful for other types of users -- e.g. embedded? What works for users? what doesn't? o user interface Should it be open firmware, a la sparc and apple? bash? efi shell? what should it be? How should people interact with linuxbios? o developer friendly -- how do we make linuxbios easier for developers what makes it hard right now? How can we improve it? what is the biggest change you'd like to see? o development model do we need a Linux-like code vetting and approval process? how do we manage patches? Who will the gatekeepers be? how do we ensure that the code base stays pure? We need ideas. o developer friendly II (more discussion) fuse the previous two sessions and try to find the right ideas. o device object model, table gen What are we going to do about: ACPI EFI tables openbios strings etc. What (if anything) needs to change in the current device model to make this all work? o automatic build and test automatic build is possible, but test? how can we do that? can people contribute systems at their site so that, when a new version comes out, we can make sure it is tested? How far can we automate the process of verifying a new release of linuxbios? Can industry help with this? OSDL? o programmer's manual How can we create a manual for new programmers? o vendor friendly What are effective and ineffective ways to work with vendors? what's the value proposition for vendors? How can we interest more vendors in linuxbios? What's missing? o efi strategy How do we address systems such as EFI? Can we, for example, find a way to run EFI modules under openbios or Linux? o N-party NDA (or NDAs in general) How do we address the issues raised by 3-, 4-, and more-way NDAS? What I'd like is people to nominate themselves to lead a discussion. Optionally, several people can nominate themselves and we'll form panels, where people put forth a position (5 mins) and then we have discussion on those ideas. So, we're looking for YOU. Please volunteer. We've come a long way, but there's more work to be done. You can make the difference. Thanks ron -------------- next part -------------- An embedded message was scrubbed... From: Li-Ta Lo Subject: LB Summit Schedule Date: Tue, 27 Sep 2005 15:30:28 -0600 Size: 178521 URL: From ollie at lanl.gov Wed Sep 28 00:07:52 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Tue, 27 Sep 2005 16:07:52 -0600 Subject: [LinuxBIOS] SMP hardware question In-Reply-To: <4339BC17.9080909@comcast.net> References: <4339B09B.7050504@lanl.gov> <4339BC17.9080909@comcast.net> Message-ID: <1127858872.5296.10.camel@logarithm.lanl.gov> On Tue, 2005-09-27 at 14:39 -0700, Adam Talbot wrote: > Currently I have a dual proc Tyan MPX system running two athlon XP's > that I have converted to MP by closing a bridge on the top of the CPU's. > > So that little trick changed the name of the CPU, but what makes an XP > CPU not capable of running in an SMP setup? Is this a factor of the > BIOS or is there something more? > -Adam Talbot > I guess it is the MP/APIC bus? The single processor XP doesn't have the bus to talk to each other. -- Li-Ta Lo Los Alamos National Lab From ollie at lanl.gov Wed Sep 28 00:11:59 2005 From: ollie at lanl.gov (Li-Ta Lo) Date: Tue, 27 Sep 2005 16:11:59 -0600 Subject: [LinuxBIOS] [Fwd: LB Summit Schedule] In-Reply-To: <4339BFFD.6000803@lanl.gov> References: <4339BFFD.6000803@lanl.gov> Message-ID: <1127859119.5296.13.camel@logarithm.lanl.gov> Minor update, Eswar Nallusamy will talk on Cache As RAM not me. -- Li-Ta Lo Los Alamos National Lab From nxtv3 at yahoo.com Wed Sep 28 00:15:10 2005 From: nxtv3 at yahoo.com (Doug Bell) Date: Tue, 27 Sep 2005 15:15:10 -0700 (PDT) Subject: [LinuxBIOS] romcc - Internal compiler error: Cannot find block dominated .... Message-ID: <20050927221511.30913.qmail@web35908.mail.mud.yahoo.com> The attached spd.c contains functions called from my raminit.c's sdram_set_spd_registers(). Raminit.c is #included into auto.c. I've tried various workarounds including putting all the code in spd.c under one function, getting rid of the device_t ctl, etc. but compilation doesn't yet work. Ideas appreciated. Thanks, dB --- Doug Bell wrote: > Beyond that, there was one version in which I simply > switched the order of declaration of variables to > make > it compile: > > // unsigned char row,col; // broken > unsigned char col,row; // works > > In another test run........ > //if ( total < c) total+=div; // failed > > if ( total < c) subtotal+=div; // was ok > total=subtotal; > > Ron / Eric - What is the best way to proceed on > this? > What info would you want? I don't think I'm doing > anything bizarre, maybe 4 chars declared, no deep > levels of functions. > > --- Doug Bell wrote: > > > I had one version of code where it failed on a > line > > like: > > if (speed==100) speed=0; > > > > but problem disappeared if I did : > > if (speed==100) speed2=0; > > > > This may have been a factor in the first reporting > > of > > the problem as well. > > > > -dB > > > > --- Doug Bell wrote: > > > > > It seems to not be related to register > allocation, > > > how > > > many layers of functions, or code size, but to > > > nested > > > if statements or variations thereof, e.g. if ( > > > (condition a) && ( condition b) ) .... > > > > > > > > > /home/dbell # uname -a > > > Linux Doug 2.6.9 #1 Tue Jan 11 17:26:41 UTC 2005 > > > i686 > > > Intel(R) Pentium(R) 4 CPU 1500MHz GenuineIntel > > > GNU/Linux > > > > > > > > > Target is via epia-sp, under development but > close > > > to > > > an alpha release with some open items. > > > > > > BTW, is there any documentation regarding what > > > limitations romcc has (e.g. multidimensional > > arrays > > > not allowed, etc )? > > > > > > Thanks, Doug > > > > > > --- ron minnich wrote: > > > > > > > On 9/26/05, Doug Bell wrote: > > > > > > > > > > 0x8360d58 phi Internal compiler error: > Cannot > > > > > find block dominated by 0x82ba9a8 > > > > > > > > > > Any ideas on workarounds / fixes here? Is am > I > > > > running > > > > > out of registers or some other problem? > > > > > > > > > > > > can you tell us more about the environment, > > > > uname -a > > > > distro, and linuxbios target? > > > > > > > > ron > > > > > -- > > > > LinuxBIOS mailing list > > > > LinuxBIOS at openbios.org > > > > > > http://www.openbios.org/mailman/listinfo/linuxbios > > > > > > > > > > > > > > > __________________________________ > > > Yahoo! Mail - PC Magazine Editors' Choice 2005 > > > http://mail.yahoo.com > > > > > > -- > > > LinuxBIOS mailing list > > > LinuxBIOS at openbios.org > > > > http://www.openbios.org/mailman/listinfo/linuxbios > > > > > > > > > > > > > __________________________________ > > Yahoo! Mail - PC Magazine Editors' Choice 2005 > > http://mail.yahoo.com > > > > -- > > LinuxBIOS mailing list > > LinuxBIOS at openbios.org > > http://www.openbios.org/mailman/listinfo/linuxbios > > > > > > > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- A non-text attachment was scrubbed... Name: spd.c Type: text/x-csrc Size: 5210 bytes Desc: 2307221761-spd.c URL: From talbotx at comcast.net Wed Sep 28 00:27:12 2005 From: talbotx at comcast.net (Adam Talbot) Date: Tue, 27 Sep 2005 15:27:12 -0700 Subject: [LinuxBIOS] Re: SMP hardware question In-Reply-To: <4339C23A.6060900@lanl.gov> References: <4339B09B.7050504@lanl.gov> <4339BC17.9080909@comcast.net> <4339C062.3010606@lanl.gov> <4339C16F.5050703@comcast.net> <4339C23A.6060900@lanl.gov> Message-ID: <4339C740.3080208@comcast.net> Humm So AMD will not give out this info easily or free... Then let us find it. Test a system in both states (Single and Dual) and look at the differences. See if we can spoof the system into thinking it has two MP CPU's when we have two XP's in the box. The one question would be linuxbios support for the Tyan MPX board or something along those lines. -Adam Ronald G Minnich wrote: > Adam Talbot wrote: > >> Been over two years on this setup, no hardware problems, yet. The >> big question, could this be faked in the bios? > > > it's a great question. what we could do is dump the model specific > registers, on jumpered and unjumpered, and see if all that happens is > the hardware jumper turns into an MSR setting ... > > the Athlon docs are highly NDA'ed, so this would be hard to find, > that's the big issue. > > ron > From rminnich at lanl.gov Wed Sep 28 00:41:03 2005 From: rminnich at lanl.gov (Ronald G Minnich) Date: Tue, 27 Sep 2005 16:41:03 -0600 Subject: [LinuxBIOS] Re: SMP hardware question In-Reply-To: <4339C740.3080208@comcast.net> References: <4339B09B.7050504@lanl.gov> <4339BC17.9080909@comcast.net> <4339C062.3010606@lanl.gov> <4339C16F.5050703@comcast.net> <4339C23A.6060900@lanl.gov> <4339C740.3080208@comcast.net> Message-ID: <4339CA7F.2080807@lanl.gov> Adam Talbot wrote: > Humm > So AMD will not give out this info easily or free. I don't want people to start beating too hard on AMD on this one. The Athlon issue is an old story; the Opteron issue is the new story, and AMD has been very open on the Opteron. So let's not be too hard on them, they've even got a full-time linuxbios guy now :-) ron From nxtv3 at yahoo.com Wed Sep 28 01:02:29 2005 From: nxtv3 at yahoo.com (Doug Bell) Date: Tue, 27 Sep 2005 16:02:29 -0700 (PDT) Subject: [LinuxBIOS] compiler error isolated In-Reply-To: <20050927221511.30913.qmail@web35908.mail.mud.yahoo.com> Message-ID: <20050927230229.82925.qmail@web35911.mail.mud.yahoo.com> The attached revised spd.c compiles as is. When you have : subtotal=dev+0; // it works subtotal=dev; // it fails ( internal compiler error - rhs not used ) Amazing but true. What's going on here? --- Doug Bell wrote: > The attached spd.c contains functions called from my > raminit.c's sdram_set_spd_registers(). Raminit.c is > #included into auto.c. I've tried various > workarounds > including putting all the code in spd.c under one > function, getting rid of the device_t ctl, etc. but > compilation doesn't yet work. Ideas appreciated. > > Thanks, dB > > --- Doug Bell wrote: > > > Beyond that, there was one version in which I > simply > > switched the order of declaration of variables to > > make > > it compile: > > > > // unsigned char row,col; // broken > > unsigned char col,row; // works > > > > In another test run........ > > //if ( total < c) total+=div; // failed > > > > if ( total < c) subtotal+=div; // was ok > > total=subtotal; > > > > Ron / Eric - What is the best way to proceed on > > this? > > What info would you want? I don't think I'm doing > > anything bizarre, maybe 4 chars declared, no deep > > levels of functions. > > > > --- Doug Bell wrote: > > > > > I had one version of code where it failed on a > > line > > > like: > > > if (speed==100) speed=0; > > > > > > but problem disappeared if I did : > > > if (speed==100) speed2=0; > > > > > > This may have been a factor in the first > reporting > > > of > > > the problem as well. > > > > > > -dB > > > > > > --- Doug Bell wrote: > > > > > > > It seems to not be related to register > > allocation, > > > > how > > > > many layers of functions, or code size, but > to > > > > nested > > > > if statements or variations thereof, e.g. if ( > > > > (condition a) && ( condition b) ) .... > > > > > > > > > > > > /home/dbell # uname -a > > > > Linux Doug 2.6.9 #1 Tue Jan 11 17:26:41 UTC > 2005 > > > > i686 > > > > Intel(R) Pentium(R) 4 CPU 1500MHz GenuineIntel > > > > GNU/Linux > > > > > > > > > > > > Target is via epia-sp, under development but > > close > > > > to > > > > an alpha release with some open items. > > > > > > > > BTW, is there any documentation regarding what > > > > limitations romcc has (e.g. multidimensional > > > arrays > > > > not allowed, etc )? > > > > > > > > Thanks, Doug > > > > > > > > --- ron minnich wrote: > > > > > > > > > On 9/26/05, Doug Bell > wrote: > > > > > > > > > > > > 0x8360d58 phi Internal compiler error: > > Cannot > > > > > > find block dominated by 0x82ba9a8 > > > > > > > > > > > > Any ideas on workarounds / fixes here? Is > am > > I > > > > > running > > > > > > out of registers or some other problem? > > > > > > > > > > > > > > > can you tell us more about the environment, > > > > > uname -a > > > > > distro, and linuxbios target? > > > > > > > > > > ron > > > > > > -- > > > > > LinuxBIOS mailing list > > > > > LinuxBIOS at openbios.org > > > > > > > > > http://www.openbios.org/mailman/listinfo/linuxbios > > > > > > > > > > > > > > > > > > > > __________________________________ > > > > Yahoo! Mail - PC Magazine Editors' Choice 2005 > > > > > http://mail.yahoo.com > > > > > > > > -- > > > > LinuxBIOS mailing list > > > > LinuxBIOS at openbios.org > > > > > > http://www.openbios.org/mailman/listinfo/linuxbios > > > > > > > > > > > > > > > > > > > __________________________________ > > > Yahoo! Mail - PC Magazine Editors' Choice 2005 > > > http://mail.yahoo.com > > > > > > -- > > > LinuxBIOS mailing list > > > LinuxBIOS at openbios.org > > > > http://www.openbios.org/mailman/listinfo/linuxbios > > > > > > > > > > > > > __________________________________ > > Yahoo! Mail - PC Magazine Editors' Choice 2005 > > http://mail.yahoo.com > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam > protection around > http://mail.yahoo.com > > > > //ALL SPD STUFF IS IN PROGRESS > > #include > > void spd_dram_presence( void ){} > void spd_dram_size( void ) {} > void spd_dram_other( void ) {} > //unsigned char spd_trp( void ) { > // return 0; > //} > > > > unsigned char spd_dram_timings( void ) { // set > dram bus speed based off CPU's FSB and SPD byte 9 > > > print_info("sdram_spd_dram_timings..........\r\n"); > > device_t ctl = (device_t) 0; > unsigned char c; > unsigned char col,row; > unsigned char freq; > unsigned char reg; > unsigned char i; > > // find CPU controlller - the CN400 device 0 > function 3 so use virtual device function 2 > pci_write_config8(0,0x4f,1); // but first allow it > to be seen using multiple function enable > > ctl = pci_locate_device( > PCI_ID( > PCI_VENDOR_ID_VIA,PCI_DEVICE_ID_VIA_CN400_2 ), > 0 ); > c=pci_read_config8(ctl,0x54); > > print_debug_hex8(c); > print_debug(" is CPU FSB\r\n"); > > unsigned char fsb; > fsb = c >> 5; > > print_debug_hex8(fsb); > print_debug(" = fsb \r\n"); > > c=smbus_read_byte(SMBUS_MEM_DEVICE_START, 9); // > one DIMM > print_debug_hex8(c); > print_debug(" returned as spd data for register > 9\r\n"); > > // decide supported dram speed per PG > unsigned char speed; > if ( c <= 0x50 ) { > speed = 200; > } > else if ( c <= 0x60 ) { > speed = 166; > } > else if ( c <= 0x75 ) { > speed = 133; > } > else { > speed = 100; > } > print_debug_hex8(speed); > print_debug(" = speed\r\n"); > > //revisit > static const unsigned char timing[5][5] = { > > //dram 100 133 166 200 266 > > { 0xff, 1, 5, 9, 0xff}, // row 0 cpu=100 > { 0xff, 0, 1, 5, 0xff}, // row 1 cpu=133 > { 0xff, 2, 0, 1, 0xff}, // row 2 cpu=166 > { 0xff, 6, 2, 0, 0xff}, // row 3 cpu=200 > { 0xff, 0x0a, 6, 2, 0xff}, // row 4 cpu=266 > > }; // on datasheet there seems to be two > values for cpu=266 dram=133 > // also see p. 30 of PG, looks like 0x0a is right > // note no 100 or 266 dram speeds > > // important - revise fsb and speed for correct > indexing into table > if ( fsb == 0 ) row=0; // 100 > else if ( fsb == 1 ) row=1; // 133 > else if ( fsb == 3 ) row=2; // 166 note value > else if ( fsb == 2 ) row=3; // 200 note value > else if ( fsb == 4 ) row=4; // 266 > else { > print_debug(" bad fsb setting\r\n"); > return -1; > } > if ( speed == 100 ) col=0; // 100 > else if ( speed == 133 ) col=1; // 133 > else if ( speed == 166 ) col=2; // 166 > else if ( speed == 200 ) col=3; // 200 > else if ( speed == 266 ) col=4; // 266 > else { > print_debug(" bad speed setting\r\n"); > return -2; > } > > freq=timing[row][col]; > print_debug_hex8(freq); // row / col > print_debug(" = timing table value \r\n"); > > if ( freq==0xff ) { > print_debug(" bad timing value\r\n"); > return -3; > } > > ctl = pci_locate_device( > PCI_ID( > PCI_VENDOR_ID_VIA,PCI_DEVICE_ID_VIA_CN400_3 ), > 0 ); > c=pci_read_config8(ctl,0x68); > print_debug_hex8(c); > print_debug(" = r68\r\n"); > c &=0xf0; > c|=freq; > pci_write_config8(ctl,0x68,c); > print_debug_hex8(c); > print_debug(" = r68 written \r\n"); > > /***************** BANK INTERLEAVE ***************/ > > c=smbus_read_byte(SMBUS_MEM_DEVICE_START, 17); > if ( ! (c==2 || c==4 ) ) { > print_info("unexpected reg 17 value\r\n"); > return -4; > } > > reg=pci_read_config8(ctl,0x69); > reg &=0x3f; > reg |= (c<<6); > pci_write_config8(ctl,0x69,reg); > print_debug_hex8(reg); > print_debug(" = r69 written \r\n"); > > > /*********************************************************/ > > > > print_info("sdram_set_spd_registers done\r\n"); > return 0; > } > > > > > unsigned char spd_trp( void ) { > > > // GRAB A BOGUS NON-CONST VALUE FOR COMPILATION TEST > ONLY!!! > unsigned char > speed=smbus_read_byte(SMBUS_MEM_DEVICE_START, 9); > > print_info("spd_trp.........\r\n"); > > device_t ctl = (device_t) 0; > > > unsigned char div=0; > unsigned char i; > unsigned char total,subtotal; > unsigned char c; > > // find CPU controlller - the CN400 device 0 > function 3 so use virtual device function 2 > pci_write_config8(0,0x4f,1); // but first allow it > to be seen using multiple function enable > > ctl = pci_locate_device( > PCI_ID( > PCI_VENDOR_ID_VIA,PCI_DEVICE_ID_VIA_CN400_3 ), > 0 ); > > /*************** tRP > **********************************/ > > if ( speed == 100 ) div=0x28; // divisor > else if ( speed == 133 ) div=0x1e; > else if ( speed == 166 ) div=0x18; > else if ( speed == 200 ) div=0x14; > else { > > // print_debug(" bad tRP speed setting\r\n"); > return -5; > } > > > > === message truncated ===> -- > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- A non-text attachment was scrubbed... Name: spd.c Type: text/x-csrc Size: 5623 bytes Desc: 2307221761-spd.c URL: From xun_fang at hotmail.com Wed Sep 28 00:40:37 2005 From: xun_fang at hotmail.com (shawn fang) Date: Tue, 27 Sep 2005 15:40:37 -0700 Subject: [LinuxBIOS] Linux BIOS support for SuperMicro p8sci motherboard Message-ID: Hi, Does any know if LinuxBIOS can support SuperMicro p8sci motherboard? Here is the url to motherboard: http://www.supermicro.com/products/motherboard/P4/E7221/P8SCi.cfm The BIOS is hosted in socketed PLCC chip. thanks, -xun From steve at digidescorp.com Wed Sep 28 03:13:47 2005 From: steve at digidescorp.com (Steve Magnani) Date: Tue, 27 Sep 2005 20:13:47 -0500 Subject: [LinuxBIOS] compiler error isolated Message-ID: This sounds something like the bug I reported in http://openbios.org/ pipermail/linuxbios/2005-June/011782.html. I notice in the revised spd.c file there are several if/else/else... constructs. I wonder if you would have better luck using 'switch' statements - when I have problems with 'if/else' statements, I've found that recoding as 'switch' makes the problem go away. See the latest e7501 raminit code. ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!" #include From jschildt at lnxi.com Wed Sep 28 19:59:34 2005 From: jschildt at lnxi.com (Jason Schildt) Date: Wed, 28 Sep 2005 11:59:34 -0600 Subject: [LinuxBIOS] Linux BIOS support for SuperMicro p8sci motherboard In-Reply-To: References: Message-ID: <20050928175934.GF11242@zoot.lnxi.com> Shawn, We did some Supermicro MB ports with Xeon cpus a while back, but those had the E7500 and E7501 chipsets. I looked back at our old repository and there's nothing for the E7221 that I could find. Do you need _that_ board specifically, our would one of the others work for you. The boards that we ported are the X5DPR,(X5DP8 I think), P4DPR-igm, and the P4DPE. However, most of those boards have probably been end-of-life'd, so good luck finding one. --jason-- On Tue, Sep 27, 2005 at 03:40:37PM -0700, shawn fang wrote: > Hi, > > Does any know if LinuxBIOS can support SuperMicro p8sci motherboard? > Here is the url to motherboard: > http://www.supermicro.com/products/motherboard/P4/E7221/P8SCi.cfm > > The BIOS is hosted in socketed PLCC chip. > > thanks, > -xun > > -- > LinuxBIOS mailing list > LinuxBIOS at openbios.org > http://www.openbios.org/mailman/listinfo/linuxbios -- Jason W. Schildt LinuxBIOS Software Engineer Linux Networx From halbmond at macnews.de Thu Sep 29 19:13:49 2005 From: halbmond at macnews.de (Angel) Date: Thu, 29 Sep 2005 19:13:49 +0200 Subject: [LinuxBIOS] Does LinuxBIOS run on the ECS 760GX-M? In-Reply-To: <2ea3fae1050924161735f9084e@mail.gmail.com> References: <281d9dd511657c3a8c19e89d074ce8f4@macnews.de> <2ea3fae1050924161735f9084e@mail.gmail.com> Message-ID: <925d83e72b23e17bae08309c0121d520@macnews.de> Oh, I thought every SIS chipset was supported. What is the newest supported SIS chipset? 735? I need a mATX mainboard for Athlon64/Turion64 that supports LinuxBIOS, but the only mATX mainboard for AMD I found is the old K7SEM. Am 25.09.2005 um 01:17 schrieb yhlu: > It is not support because of the SIS chipset is not supported right > now. > > YH From yinghailu at gmail.com Thu Sep 29 21:25:38 2005 From: yinghailu at gmail.com (yhlu) Date: Thu, 29 Sep 2005 12:25:38 -0700 Subject: [LinuxBIOS] Does LinuxBIOS run on the ECS 760GX-M? In-Reply-To: <925d83e72b23e17bae08309c0121d520@macnews.de> References: <281d9dd511657c3a8c19e89d074ce8f4@macnews.de> <2ea3fae1050924161735f9084e@mail.gmail.com> <925d83e72b23e17bae08309c0121d520@macnews.de> Message-ID: <2ea3fae10509291225651c3e09@mail.gmail.com> There is no LinuxBIOS support with SIS to K8 now...., So need to port. You need to find K8 MB with amd chipset or nvidia chipset....for that. YH On 9/29/05, Angel wrote: > > Oh, I thought every SIS chipset was supported. What is the newest > supported SIS chipset? 735? > I need a mATX mainboard for Athlon64/Turion64 that supports LinuxBIOS, > but the only mATX mainboard for AMD I found is the old K7SEM. > > > > Am 25.09.2005 um 01:17 schrieb yhlu: > > > It is not support because of the SIS chipset is not supported right > > now. > > > > YH > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From JJia at Fortinet.com Fri Sep 30 23:41:37 2005 From: JJia at Fortinet.com (Jia Jianwei) Date: Fri, 30 Sep 2005 14:41:37 -0700 Subject: [LinuxBIOS] AMD serenade help Message-ID: <04fc01c5c607$bc33f6c0$3a4610ac@fortinet.com> AMD serenade hangs when initialize ram. in the function "route_dram_accesses", when write to limit register, system just hang. If anyone has this problem before? Please help. Thanks! static void route_dram_accesses(const struct mem_controller *ctrl, unsigned long base_k, unsigned long limit_k) { /* Route the addresses to the controller node */ unsigned node_id; unsigned limit; unsigned base; unsigned index; unsigned limit_reg, base_reg; device_t device; node_id = ctrl->node_id; index = (node_id << 3); limit = (limit_k << 2); limit &= 0xffff0000; limit -= 0x00010000; limit |= ( 0 << 8) | (node_id << 0); base = (base_k << 2); base &= 0xffff0000; base |= (0 << 8) | (1<<1) | (1<<0); limit_reg = 0x44 + index; base_reg = 0x40 + index; for(device = PCI_DEV(0, 0x18, 1); device <= PCI_DEV(0, 0x1f, 1); device += PCI_DEV(0, 1, 0)) { /* hangs here */ pci_write_config32(device, limit_reg, limit); pci_write_config32(device, base_reg, base); } } Jianwei