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 -- linuxbios mailing list [email protected] http://www.linuxbios.org/mailman/listinfo/linuxbios
