[LinuxBIOS] linuxbios Digest, Vol 25, Issue 79
Stefan Reinauer
stepan at coresystems.de
Tue Mar 20 13:02:25 CET 2007
* C.-Valentin Schmitt <c-v.schmitt at web.de> [070320 12:54]:
>
>
> looks like symbiotic bios - stuff . . .
>
> my recommendation: $hithappen$
Please stop sending whole digests to the list. Nobody gets what you are
trying to refer to, making your comments useless at best.
Stefan
> > ----------------------------------------------------------------------
> >
> > 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
>
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.linuxbios.org/mailman/listinfo/linuxbios
>
--
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/
More information about the coreboot
mailing list