[LinuxBIOS] linuxbios Digest, Vol 25, Issue 79
C.-Valentin Schmitt
c-v.schmitt at web.de
Tue Mar 20 12:54:02 CET 2007
looks like symbiotic bios - stuff . . .
my recommendation: $hithappen$
> -----Ursprüngliche Nachricht-----
> Von: linuxbios at linuxbios.org
> Gesendet: 20.03.07 12:15:48
> An: linuxbios at linuxbios.org
> Betreff: linuxbios Digest, Vol 25, Issue 79
> Send linuxbios mailing list submissions to
> linuxbios at linuxbios.org
>
> 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
> linuxbios-request at linuxbios.org
>
> You can reach the person managing the list at
> linuxbios-owner at linuxbios.org
>
> 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 <stepan at coresystems.de>
> Subject: Re: [LinuxBIOS] how flashrom works
> To: Anton <anton.borisov at gmail.com>
> Cc: linuxbios at linuxbios.org
> Message-ID: <20070320085216.GA23927 at coresystems.de>
> Content-Type: text/plain; charset=utf-8
>
> * Anton <anton.borisov at gmail.com> [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: info at coresystems.de ? http://www.coresystems.de/
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 20 Mar 2007 05:30:25 -0400
> From: Corey Osgood <corey_osgood at verizon.net>
> Subject: Re: [LinuxBIOS] usage of pci_write_config32()?
> To: Stefan Reinauer <stepan at coresystems.de>
> Cc: ron minnich <rminnich at gmail.com>, LinuxBIOS Mailing List
> <linuxbios at linuxbios.org>
> Message-ID: <45FFA9B1.7070609 at verizon.net>
> Content-Type: text/plain; charset=UTF-8
>
> Stefan Reinauer wrote:
> > * Corey Osgood <corey_osgood at verizon.net> [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" <c-v.schmitt at web.de>
> Subject: Re: [LinuxBIOS] linuxbios Digest, Vol 25, Issue 71
> To: linuxbios at linuxbios.org
> Message-ID: <275643733 at web.de>
> Content-Type: text/plain; charset=iso-8859-15
>
>
>
> I dont know ! I have no clue !
>
> misco ???
> kingston ???
>
>
> > -----Urspr?ngliche Nachricht-----
> > Von: linuxbios at linuxbios.org
> > Gesendet: 19.03.07 09:47:00
> > An: linuxbios at linuxbios.org
> > Betreff: linuxbios Digest, Vol 25, Issue 71
>
>
> > Send linuxbios mailing list submissions to
> > linuxbios at linuxbios.org
> >
> > 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
> > linuxbios-request at linuxbios.org
> >
> > You can reach the person managing the list at
> > linuxbios-owner at linuxbios.org
> >
> > 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 (joe at smittys.pointclark.net)
> > 9. Re: northbridge docs (Corey Osgood)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Mon, 19 Mar 2007 01:08:37 +0100
> > From: Peter Stuge <stuge-linuxbios at cdy.org>
> > Subject: Re: [LinuxBIOS] Flashrom and AM29LV040B flash chip
> > To: linuxbios at linuxbios.org
> > Message-ID: <20070319000837.5522.qmail at cdy.org>
> > 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 <stuge-linuxbios at cdy.org>
> > Subject: Re: [LinuxBIOS] filo ide speedup patch?
> > To: linuxbios at linuxbios.org
> > Message-ID: <20070319002053.7138.qmail at cdy.org>
> > 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 <peter at stuge.se>
> > 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 <stuge-linuxbios at cdy.org>
> > Subject: Re: [LinuxBIOS] linuxbios + xf86-video-unichrome: no VGA BIOS
> > needed.
> > To: linuxbios at linuxbios.org
> > Message-ID: <20070319003529.9391.qmail at cdy.org>
> > 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 <stuge-linuxbios at cdy.org>
> > Subject: Re: [LinuxBIOS] filo ide speedup patch?
> > To: linuxbios at linuxbios.org
> > Message-ID: <20070319011025.14293.qmail at cdy.org>
> > Content-Type: text/plain; charset=us-ascii
> >
> > On Sun, Mar 18, 2007 at 06:25:30PM +0100, Stefan Reinauer wrote:
> > > * Peter Stuge <stuge-linuxbios at cdy.org> [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 (stuge at carep
> > > > 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" <dhbarr at gozelle.com>
> > Subject: [LinuxBIOS] Getting Friendly with Flashrom
> > To: linuxbios at linuxbios.org
> > Message-ID:
> > <e8d467740703181854o559c7ae0g31b00d2c4e500a7 at mail.gmail.com>
> > 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.
> >
> >
> > dhbarr at ms7260:~/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 <stuge-linuxbios at cdy.org>
> > Subject: Re: [LinuxBIOS] Getting Friendly with Flashrom
> > To: linuxbios at linuxbios.org
> > Message-ID: <20070319030637.30171.qmail at cdy.org>
> > Content-Type: text/plain; charset=us-ascii
> >
> > On Sun, Mar 18, 2007 at 08:54:29PM -0500, David H. Barr wrote:
> > > dhbarr at ms7260:~/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 <corey_osgood at verizon.net>
> > Subject: Re: [LinuxBIOS] Is my hardware supported?
> > To: Eki Fa-Clang Shabazz <shabazz at nerdshack.com>
> > Cc: linuxbios at linuxbios.org
> > Message-ID: <45FE34AC.7060904 at verizon.net>
> > 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: joe at smittys.pointclark.net
> > Subject: Re: [LinuxBIOS] northbridge docs
> > To: linuxbios at linuxbios.org
> > Message-ID:
> > <20070319042706.o5ghatdhs80kc8gs at www.smittys.pointclark.net>
> > Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes";
> > format="flowed"
> >
> > Quoting joe at smittys.pointclark.net:
> >
> > > 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
> > > linuxbios at linuxbios.org
> > > 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 <corey_osgood at verizon.net>
> > Subject: Re: [LinuxBIOS] northbridge docs
> > To: joe at smittys.pointclark.net
> > Cc: linuxbios at linuxbios.org
> > Message-ID: <45FE4DAA.8030402 at verizon.net>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > joe at smittys.pointclark.net wrote:
> > > Quoting joe at smittys.pointclark.net:
> > >
> > >> 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
> > >> linuxbios at linuxbios.org
> > >> 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
> > linuxbios at linuxbios.org
> > 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 <stepan at coresystems.de>
> Subject: [LinuxBIOS] microcode updates on amd64
> To: linuxbios at linuxbios.org
> Message-ID: <20070320103124.GA10355 at coresystems.de>
> 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: info at coresystems.de ? http://www.coresystems.de/
>
>
>
> ------------------------------
>
> _______________________________________________
> linuxbios mailing list
> linuxbios at linuxbios.org
> 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
More information about the coreboot
mailing list