looks like symbiotic bios - stuff . . .
my recommendation: $hithappen$ > -----Ursprüngliche Nachricht----- > Von: [email protected] > Gesendet: 20.03.07 12:15:48 > An: [email protected] > Betreff: linuxbios Digest, Vol 25, Issue 79 > Send linuxbios mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.linuxbios.org/mailman/listinfo/linuxbios > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of linuxbios digest..." > > > Today's Topics: > > 1. Re: how flashrom works (Stefan Reinauer) > 2. Re: usage of pci_write_config32()? (Corey Osgood) > 3. Re: linuxbios Digest, Vol 25, Issue 71 (C.-Valentin Schmitt) > 4. microcode updates on amd64 (Stefan Reinauer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 20 Mar 2007 09:52:16 +0100 > From: Stefan Reinauer <[EMAIL PROTECTED]> > Subject: Re: [LinuxBIOS] how flashrom works > To: Anton <[EMAIL PROTECTED]> > Cc: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=utf-8 > > * Anton <[EMAIL PROTECTED]> [070320 09:31]: > > Can someone give me a pointer on flashrom programming? > > I look into sst28sf040.h, there are 3 functions available: probe(), > > erase(), write(). How the read() from chip is implemented? > > The area is mmap'ed and then just read as normal memory. > If you do -r, it uses memcpy, flash_rom.c:325 > > Stefan > > -- > coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. > Tel.: +49 761 7668825 ? Fax: +49 761 7664613 > Email: [EMAIL PROTECTED] ? http://www.coresystems.de/ > > > > ------------------------------ > > Message: 2 > Date: Tue, 20 Mar 2007 05:30:25 -0400 > From: Corey Osgood <[EMAIL PROTECTED]> > Subject: Re: [LinuxBIOS] usage of pci_write_config32()? > To: Stefan Reinauer <[EMAIL PROTECTED]> > Cc: ron minnich <[EMAIL PROTECTED]>, LinuxBIOS Mailing List > <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=UTF-8 > > Stefan Reinauer wrote: > > * Corey Osgood <[EMAIL PROTECTED]> [070320 05:45]: > >> It's raminit.c from LBv1's src/northbridge/440gx/, it addresses the > >> first register for a 32-bit write to 0x50-0x53, then the second for a > >> 16-bit write later on, can't see at the moment which it was. I'm working > >> on trying to port that up to v2, to see if it'll work on a 440zx, since > >> nothing else I've done seems to be working. > > > > Note that on some systems, a 32bit write is very different from 4 8bit > > writes. If it is a 32bit register, you should always read/write all 32 > > bits. > > > > Stefan > > > > Yes, but on 440bx doesn't seem to matter, LBv1 uses 8-bit writes all > over the place on it. And yes, it was 0x44332211, written to the last > reg in the set, I've fixed my code accordingly (not that it works, but > at least correct now on that part). > > -Corey > > > > ------------------------------ > > Message: 3 > Date: Tue, 20 Mar 2007 10:56:41 +0100 > From: "C.-Valentin Schmitt" <[EMAIL PROTECTED]> > Subject: Re: [LinuxBIOS] linuxbios Digest, Vol 25, Issue 71 > To: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=iso-8859-15 > > > > I dont know ! I have no clue ! > > misco ??? > kingston ??? > > > > -----Urspr?ngliche Nachricht----- > > Von: [email protected] > > Gesendet: 19.03.07 09:47:00 > > An: [email protected] > > Betreff: linuxbios Digest, Vol 25, Issue 71 > > > > Send linuxbios mailing list submissions to > > [email protected] > > > > To subscribe or unsubscribe via the World Wide Web, visit > > http://www.linuxbios.org/mailman/listinfo/linuxbios > > or, via email, send a message with subject or body 'help' to > > [EMAIL PROTECTED] > > > > You can reach the person managing the list at > > [EMAIL PROTECTED] > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of linuxbios digest..." > > > > > > Today's Topics: > > > > 1. Re: Flashrom and AM29LV040B flash chip (Peter Stuge) > > 2. Re: filo ide speedup patch? (Peter Stuge) > > 3. Re: linuxbios + xf86-video-unichrome: no VGA BIOS needed. > > (Peter Stuge) > > 4. Re: filo ide speedup patch? (Peter Stuge) > > 5. Getting Friendly with Flashrom (David H. Barr) > > 6. Re: Getting Friendly with Flashrom (Peter Stuge) > > 7. Re: Is my hardware supported? (Corey Osgood) > > 8. Re: northbridge docs ([EMAIL PROTECTED]) > > 9. Re: northbridge docs (Corey Osgood) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Mon, 19 Mar 2007 01:08:37 +0100 > > From: Peter Stuge <[EMAIL PROTECTED]> > > Subject: Re: [LinuxBIOS] Flashrom and AM29LV040B flash chip > > To: [email protected] > > Message-ID: <[EMAIL PROTECTED]> > > Content-Type: text/plain; charset=us-ascii > > > > On Sun, Mar 18, 2007 at 05:46:34PM +0200, Priit Laes wrote: > > > How well does Flashrom work with AM29LV040B [1] flash chip? > > > > It should work out of the box, if not it will be trivial to add. > > > > > > > I took apart my old Dell Latitude C600 laptop with thoughts that I could > > > maybe get it working with LinuxBIOS, but well, chip itself is soldered > > > on the motherboard [2] (16 pins inside 8 millimeters) so I would first > > > have to figure out how to implement the hotswapping. > > > > Emulation Technology have a TSOP prototyping socket that you could > > solder on to the board instead of the TSOP chip. Then have a few TSOP > > chips to swap between. > > > > http://www.emulation.com/catalog/off-the-shelf_solutions/sockets/tsop/ > > > > Note that these sockets are rated for a minimum of 50 insert/remove > > cycles. > > > > > > > Also, does anyone have ideas where to order these flash chips > > > (PLCC) in Europe, preferably Finland? > > > > On the picture is a TSOP chip. Either way, I think Farnell or maybe > > Avnet are good sources for single quantity chips. > > > > > > > [2] http://plaes.org/files/2007-Q1/2007-03-18-latitude-c600-bios.jpg > > > > There are pads for a PLCC chip on the board. PLCC is much easier to > > work with so I would go for that instead of the TSOP. (Maybe that was > > your thought too.) You would have to scrape off the green lacquer to > > expose the pads but if done carefully with a steady hand and a sharp > > knife (or fibre glass brush) that's fairly easy. > > > > > > //Peter > > > > > > > > ------------------------------ > > > > Message: 2 > > Date: Mon, 19 Mar 2007 01:20:53 +0100 > > From: Peter Stuge <[EMAIL PROTECTED]> > > Subject: Re: [LinuxBIOS] filo ide speedup patch? > > To: [email protected] > > Message-ID: <[EMAIL PROTECTED]> > > Content-Type: text/plain; charset="us-ascii" > > > > On Sun, Mar 18, 2007 at 06:36:44PM +0100, Stefan Reinauer wrote: > > > > Find attached a patch for timer2 and hard reset. I'm looking at > > > > FILO right now. > > > > > > The below patch works fine on my system, but some older versions of > > > the C3 lack support for the rdtsc command. (Nehemiah has it) > > > > > > Whereas the Centaur/Wincore is said to not have rdtsc. > > > > Aha! > > > > > > > I would assume the patch is wrong for the epia and right for the > > > epia-m. > > > > > > Do you mind dropping the epia part? > > > > Not at all, we should have working defaults, but I'll add a note to > > the wiki for people to enable it if they have Nehemiah. > > > > Can CONFIG_UDELAY_TSC=1 in targets/via/epia/Config.lb also > > automatically set CONFIG_UDELAY_IO=0 ? > > > > > > //Peter > > -------------- next part -------------- > > Changes by Richard Smith and me from the LinuxBIOS symposium 2006. > > > > Without CONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2 1 million outb():s are > > used for timer calibration and that takes over one second. > > EPIA-M boards have the x86 timer2 so let's use it and make boot faster. > > Since only some EPIA boards have the Nehemiah CPU default to IO based but > > add the options so user can change it on Config.lb. > > > > src/mainboard/via/epia*/reset.c is dead code so HARD_RESET should be 0. > > (entire file within #if 0) > > > > Signed-off-by: Peter Stuge <[EMAIL PROTECTED]> > > Index: src/mainboard/via/epia-m/Options.lb > > =================================================================== > > --- src/mainboard/via/epia-m/Options.lb (revision 2570) > > +++ src/mainboard/via/epia-m/Options.lb (working copy) > > @@ -38,6 +38,7 @@ > > uses MAXIMUM_CONSOLE_LOGLEVEL > > uses CONFIG_CONSOLE_SERIAL8250 > > uses CONFIG_UDELAY_TSC > > +uses CONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2 > > uses CONFIG_PCI_ROM_RUN > > uses CONFIG_CONSOLE_VGA > > uses CONFIG_MAX_PCI_BUSES > > @@ -66,11 +67,12 @@ > > ## Use TSC for udelay. > > ## > > default CONFIG_UDELAY_TSC=1 > > +default CONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2=1 > > > > ## > > ## Build code to reset the motherboard from linuxBIOS > > ## > > -default HAVE_HARD_RESET=1 > > +default HAVE_HARD_RESET=0 > > > > ## > > ## Build code to export a programmable irq routing table > > Index: src/mainboard/via/epia/Options.lb > > =================================================================== > > --- src/mainboard/via/epia/Options.lb (revision 2570) > > +++ src/mainboard/via/epia/Options.lb (working copy) > > @@ -11,6 +11,8 @@ > > uses HAVE_FALLBACK_BOOT > > uses HAVE_HARD_RESET > > uses CONFIG_UDELAY_IO > > +uses CONFIG_UDELAY_TSC > > +uses CONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2 > > uses HAVE_OPTION_TABLE > > uses USE_OPTION_TABLE > > uses CONFIG_ROM_PAYLOAD > > @@ -81,12 +83,15 @@ > > ## > > ## Build code to reset the motherboard from linuxBIOS > > ## > > -default HAVE_HARD_RESET=1 > > +default HAVE_HARD_RESET=0 > > > > ## > > -## use io based udelay function > > +## use ui based udelay function > > +## change to TSC if you have a Nehemiah CPU > > ## > > default CONFIG_UDELAY_IO=1 > > +default CONFIG_UDELAY_TSC=0 > > +default CONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2=0 > > > > ## > > ## Build code to export a programmable irq routing table > > > > ------------------------------ > > > > Message: 3 > > Date: Mon, 19 Mar 2007 01:35:29 +0100 > > From: Peter Stuge <[EMAIL PROTECTED]> > > Subject: Re: [LinuxBIOS] linuxbios + xf86-video-unichrome: no VGA BIOS > > needed. > > To: [email protected] > > Message-ID: <[EMAIL PROTECTED]> > > Content-Type: text/plain; charset=us-ascii > > > > On Sun, Mar 18, 2007 at 05:48:48PM +0100, Stefan Reinauer wrote: > > > For the Kernel bootsplash, a guy at SUSE wrote a jpeg decoder in > > > roughly 8k. > > > > Would that be Oliver Fromme? :) > > > > > > > That plus a jpeg will be smaller than a lzmaed raw image in almost > > > all cases. > > > > JPEG is great for photos, not so good for quality of painted > > graphics, but the size benefit is important. > > > > > > > > > * Maybe the bootloader should take care? > > > > > > > > > > What do you think? I really don't know. > > > > > > > > How does GRUB2 feel about it? > > > > > > If it's a seperate stage, grub2 (linuxbios version) might want to > > > know how to switch it off anyways. But making it a seperate stage > > > would for sure be a good idea as nobody feels offended by having > > > to maintain that graphics stuff "in their stage" :-) > > > > Yep, nice and isolated. > > > > > > //Peter > > > > > > > > ------------------------------ > > > > Message: 4 > > Date: Mon, 19 Mar 2007 02:10:25 +0100 > > From: Peter Stuge <[EMAIL PROTECTED]> > > Subject: Re: [LinuxBIOS] filo ide speedup patch? > > To: [email protected] > > Message-ID: <[EMAIL PROTECTED]> > > Content-Type: text/plain; charset=us-ascii > > > > On Sun, Mar 18, 2007 at 06:25:30PM +0100, Stefan Reinauer wrote: > > > * Peter Stuge <[EMAIL PROTECTED]> [070317 04:43]: > > > > > I'm looking at FILO right now. > > > > > > > > I've hacked FILO to read up to 256 blocks per ATA command now, but am > > > > repeatedly getting some bad data here and there already in the first > > > > 10kb at kern_addr. > > > > > > Can all devices read 256 blocks at once? > > > > It's the exact same command as reading a single sector. > > > > > > > Does the problem happen with 16 blocks, too? > > > > Because of the fs, not all sectors are consecutive. > > > > In my case it's first 7 sectors then 90. I compare 10kb, the first 10 > > fs (20 device) sectors and there are differences already in the first > > sector, even though the read code path is the same except for the > > sector_count parameter in pio_data_in(). :\ > > > > > > > > The two hexdumps don't change after reset. > > > > > > You mean, the error is always at the same position? > > > > Right. I only tried a few resets, will try more. > > > > > > > > There's a note in ide.c:pio_data_in() : > > > > /* FIXME handle commands with multiple blocks */ > > > > > > > > ..but looking at the ATA PDF the code looks OK as it is, plus I'm > > > > getting bad data already in the first sector. Dunno. > > > > > > Do you ever get a timeout? Is the ndelay too short for multiple > > > blocks? > > > > No timeouts or errors seen. > > > > > > > try udelay(1) instead. The openbios ide driver reads IDEREG_ASTATUS > > > 4 times before delaying. Also, it waits 1000 times for the drive to > > > become ready, while the FILO driver only seems to try 1 time? > > > > I'm using CF so it should be ready immediately. > > > > > > > maybe it makes sense to port the openbios ide driver (ie clean out > > > the device tree hooks)? > > > > > > It knows how to do multiple blocks and it knows hot to do ATAPI > > > correctly. And cleaning this up might make it easily usable for > > > GRUB2 as well..? > > > > Sounds good. Is the code structure a lot different? > > > > > > > > --- single_sector_read_kernel 2007-03-17 03:41:21.000000000 +0100 > > > > +++ multi_sector_read_kernel 2007-03-17 03:40:01.000000000 +0100 > > > > @@ -3,27 +3,27 @@ > > > > 00100020 32 00 00 00 02 00 00 00 45 4c 46 42 6f 6f 74 00 > > > > 2.......ELFBoot. > > > > 00100030 30 2e 35 20 28 73 74 75 67 65 40 63 61 72 65 70 0.5 > > > > ([EMAIL PROTECTED] > > > > 00100040 61 64 34 29 20 53 61 74 20 4d 61 72 20 31 37 20 ad4) Sat > > > > Mar 17 > > > > -00100050 30 33 3a 34 30 3a 30 38 20 43 45 54 20 32 30 30 03:40:08 > > > > CET 200 > > > > +00100050 30 33 3a 33 38 3a 34 38 20 43 45 54 20 32 30 30 03:38:48 > > > > CET 200 > > > > > > It's hard to day what is wrong and what is not, as it seems to load > > > two different versions of filo. Can you try loading the same > > > version of filo? > > > > No, one version does what svn trunk does; read one sector at a time, > > the other tries to read multiple sectors. > > > > I've restructured the code a bit and added some new multi-sector > > functions since single sector reads were assumed everywhere. > > > > I realize it's difficult to suggest anything at this point. > > > > > > //Peter > > > > > > > > ------------------------------ > > > > Message: 5 > > Date: Sun, 18 Mar 2007 20:54:29 -0500 > > From: "David H. Barr" <[EMAIL PROTECTED]> > > Subject: [LinuxBIOS] Getting Friendly with Flashrom > > To: [email protected] > > Message-ID: > > <[EMAIL PROTECTED]> > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > I'm trying to get Flashrom to flash a legacy BIOS image to the RD1 > > slot on a BIOS Savior PMC4 (thanks Eksidtata!), but I must be missing > > something... > > > > * I got flashrom checked out, compiled, and make installed. > > * I show that both the W39V040B (ORG) and Pm49FL004 (RD1) are supported > > * I've tested that a loose PMC Pm49FL004 is compatible with my mainboard > > * I've tried issuing a flashrom line three or four times in sequence > > > > However, I cannot get a successful write. Any suggestions? Excerpt > > follows. > > > > -dhbarr. > > > > > > [EMAIL PROTECTED]:~/msi_orig$ sudo flashrom -vV -c Pm49FL004 A7260NMS.300 > > Calibrating delay loop... Setting up microsecond timing loop > > 401M loops per second > > ok > > No LinuxBIOS table found. > > Enabling flash write on NVIDIA MCP55...OK > > Trying Pm49FL004, 512 KB > > probe_jedec: id1 0x9d, id2 0x6e > > Pm49FL004 found at physical address: 0xfff80000 > > Flash part is Pm49FL004 (512 KB) > > Flash image seems to be a legacy BIOS. Disabling checks. > > Verifying flash address: 0x00015f58 - FAILED > > > > > > > > ------------------------------ > > > > Message: 6 > > Date: Mon, 19 Mar 2007 04:06:37 +0100 > > From: Peter Stuge <[EMAIL PROTECTED]> > > Subject: Re: [LinuxBIOS] Getting Friendly with Flashrom > > To: [email protected] > > Message-ID: <[EMAIL PROTECTED]> > > Content-Type: text/plain; charset=us-ascii > > > > On Sun, Mar 18, 2007 at 08:54:29PM -0500, David H. Barr wrote: > > > [EMAIL PROTECTED]:~/msi_orig$ sudo flashrom -vV -c Pm49FL004 A7260NMS.300 > > > > Try -w > > > > > > //Peter > > > > > > > > ------------------------------ > > > > Message: 7 > > Date: Mon, 19 Mar 2007 02:58:52 -0400 > > From: Corey Osgood <[EMAIL PROTECTED]> > > Subject: Re: [LinuxBIOS] Is my hardware supported? > > To: Eki Fa-Clang Shabazz <[EMAIL PROTECTED]> > > Cc: [email protected] > > Message-ID: <[EMAIL PROTECTED]> > > Content-Type: text/plain; charset=ISO-8859-1 > > > > Eki Fa-Clang Shabazz wrote: > > >> Start with this: http://linuxbios.org/Supported_Chipsets_and_Devices and > > >> http://linuxbios.org/Supported_Motherboards. If you've still got > > >> questions, respond with the output of lspci. > > >> > > >> -Corey > > > > > > Okay, I don't see mine. Sorry for the amount of stuff I'm sending, but: > > > ~# lspci -v > > > 00:00.0 Host bridge: Intel Corporation 925X/XE Express Memory Controller > > > Hub > > > (rev 04) > > <snip> > > > 00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) > > > PCI > > > Express Port 1 (rev 03) (prog-if 00 [Normal decode]) > > > > Thanks for the info! > > Neither of these chips are supported right now, although the ICH6 might > > not be that hard to get going, using ICH5 code (making a serious > > assumption here, probably will get shot for it later). But the 925 is > > definitely not supported, at least for now. > > > > -Corey > > > > > > > > ------------------------------ > > > > Message: 8 > > Date: Mon, 19 Mar 2007 04:27:06 -0400 > > From: [EMAIL PROTECTED] > > Subject: Re: [LinuxBIOS] northbridge docs > > To: [email protected] > > Message-ID: > > <[EMAIL PROTECTED]> > > Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; > > format="flowed" > > > > Quoting [EMAIL PROTECTED]: > > > > > Hello, > > > I am working on the code for my northbridge (Intel 82830). > > > Particularly the raminit.c file. By looking at the sources from the > > > other northbridges and my datasheets, I am getting a little lost. My > > > datasheet (Intel) lists all the registers and their defaults but > > > doesn't really explain the memory initialization process. Could > > > someone direct me to some good docs that explain how memory > > > initialization happens at boot time? The more detail the better. I am > > > using SDRAM so SDRAM specific would be great. I was looking at the > > > code from the via vt8601, but it seems like alot of the registers are > > > hardcoded into the code (no disrespect Ron, I saw you converted it to > > > C). I would like to write one that is a lot more dynamic (more > > > definitions to uniqe code) so it can also be used to as sort of a > > > template for other SDRAM based northbridges. > > > > > > Thanks - Joe > > > > > > -- > > > linuxbios mailing list > > > [email protected] > > > http://www.openbios.org/mailman/listinfo/linuxbios > > > > > > > > I just have to say, after hours of reading datasheets and examining > > code that who ever wrote the code for the e7520 and e7525 nothbridges > > is brilliant!! The way the code is setup is going to work perfect for > > me and maybe other people looking for Intel northbridge code starting > > points. I think if any of you working on the 440bx should just scrap > > the existing and start over with e7520 and e7525 as a template, maybe > > not, but you might be able to get it working this way. Anyways, I just > > wanted to Acknowledge some great code writing. > > > > Thanks - Joe > > > > > > > > > > ------------------------------ > > > > Message: 9 > > Date: Mon, 19 Mar 2007 04:45:30 -0400 > > From: Corey Osgood <[EMAIL PROTECTED]> > > Subject: Re: [LinuxBIOS] northbridge docs > > To: [EMAIL PROTECTED] > > Cc: [email protected] > > Message-ID: <[EMAIL PROTECTED]> > > Content-Type: text/plain; charset=ISO-8859-1 > > > > [EMAIL PROTECTED] wrote: > > > Quoting [EMAIL PROTECTED]: > > > > > >> Hello, > > >> I am working on the code for my northbridge (Intel 82830). > > >> Particularly the raminit.c file. By looking at the sources from the > > >> other northbridges and my datasheets, I am getting a little lost. My > > >> datasheet (Intel) lists all the registers and their defaults but > > >> doesn't really explain the memory initialization process. Could > > >> someone direct me to some good docs that explain how memory > > >> initialization happens at boot time? The more detail the better. I am > > >> using SDRAM so SDRAM specific would be great. I was looking at the > > >> code from the via vt8601, but it seems like alot of the registers are > > >> hardcoded into the code (no disrespect Ron, I saw you converted it to > > >> C). I would like to write one that is a lot more dynamic (more > > >> definitions to uniqe code) so it can also be used to as sort of a > > >> template for other SDRAM based northbridges. > > >> > > >> Thanks - Joe > > >> > > >> -- > > >> linuxbios mailing list > > >> [email protected] > > >> http://www.openbios.org/mailman/listinfo/linuxbios > > >> > > >> > > > I just have to say, after hours of reading datasheets and examining > > > code that who ever wrote the code for the e7520 and e7525 nothbridges > > > is brilliant!! The way the code is setup is going to work perfect for > > > me and maybe other people looking for Intel northbridge code starting > > > points. I think if any of you working on the 440bx should just scrap > > > the existing and start over with e7520 and e7525 as a template, maybe > > > not, but you might be able to get it working this way. Anyways, I just > > > wanted to Acknowledge some great code writing. > > > > > > Thanks - Joe > > > > > > > > > > Joe, Uwe already did, and I really appreciate it ;) Although neither of > > us has gotten it running yet, it definitely is a better design, I've > > also been using something similar for via vt82c694 (again, no success > > yet). I only wish there was some way to haul apart or examine the > > factory bios to figure out what's going on with both of these chips, in > > principle this should be so simple. Why does what worked with v1 not > > work with v2??? > > > > -Corey > > > > > > > > ------------------------------ > > > > _______________________________________________ > > linuxbios mailing list > > [email protected] > > http://www.linuxbios.org/mailman/listinfo/linuxbios > > > > End of linuxbios Digest, Vol 25, Issue 71 > > ***************************************** > > > > .?:?.?:?.?:?.________________.?:?.?:?.?:?. > . ? `?^._ Carl-Valentin Schmitt _.^???. > .?-._-\?--- Schlossstr. 184 ---?/-_.-?. > .?._____?? 54293 Trier `?____.?. > ?????????...______________...????????? > _______________________________________________________________ > SMS schreiben mit WEB.DE FreeMail - einfach, schnell und > kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 > > > > > ------------------------------ > > Message: 4 > Date: Tue, 20 Mar 2007 11:31:24 +0100 > From: Stefan Reinauer <[EMAIL PROTECTED]> > Subject: [LinuxBIOS] microcode updates on amd64 > To: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=utf-8 > > Hi, > > There seem to be no microcode updates for K8 C0 CPUs. Can any of the > available microcode updates be used on the C0? Any chance to get them > supported? > > Stefan > > -- > coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br. > Tel.: +49 761 7668825 ? Fax: +49 761 7664613 > Email: [EMAIL PROTECTED] ? http://www.coresystems.de/ > > > > ------------------------------ > > _______________________________________________ > linuxbios mailing list > [email protected] > http://www.linuxbios.org/mailman/listinfo/linuxbios > > End of linuxbios Digest, Vol 25, Issue 79 > ***************************************** > .·:·.·:·.·:·.________________.·:·.·:·.·:·. . · `·^._ Carl-Valentin Schmitt _.^·Ž·. .·-._-\°--- Schlossstr. 184 ---°/-_.-·. .·._____·Ž 54293 Trier `·____.·. ·········...______________...········· _______________________________________________________________ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 -- linuxbios mailing list [email protected] http://www.linuxbios.org/mailman/listinfo/linuxbios
