[LinuxBIOS] linuxbios Digest, Vol 25, Issue 71
C.-Valentin Schmitt
c-v.schmitt at web.de
Tue Mar 20 10:56:41 CET 2007
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
More information about the coreboot
mailing list