Dear LinuxBIOS readers!
This is the automated build check service of LinuxBIOS.
The developer "stuge" checked in revision 2744 to
the LinuxBIOS source repository and caused the following
changes:
Change Log:
Fix bug in probe_28sf040() causing flash corruption on SST49LF160C verify.
The first b
On Sun, Aug 12, 2007 at 08:47:42PM -0700, Ed Swierk wrote:
> Signed-off-by: Ed Swierk <[EMAIL PROTECTED]>
Acked, r2744
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Author: stuge
Date: 2007-08-13 06:10:32 +0200 (Mon, 13 Aug 2007)
New Revision: 2744
Modified:
trunk/util/flashrom/sst28sf040.c
Log:
Fix bug in probe_28sf040() causing flash corruption on SST49LF160C verify.
The first byte of the flash chip was read at the start of the function
and later writte
On Sun, Aug 12, 2007 at 05:18:49PM +0200, Stefan Reinauer wrote:
> Of course, if we fear that we might find non-flash media in the
> 4G-size area, we need to think about restoring.
Yeah. When we want to port flashrom to flash also on other archs, it
will need a redesign. I don't care for now.
>
Signed-off-by: Ed Swierk <[EMAIL PROTECTED]>
--Ed
linuxbios-300-flashrom-bug.patch
Description: Binary data
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
On 8/12/07, Stefan Reinauer <[EMAIL PROTECTED]> wrote:
> Or remove the restore? The code only restores for the case that there is
> no 28sf040 anyways...?
Makes sense to me :-)
--Ed
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
On Sun, Aug 12, 2007 at 10:26:20PM -0400, Ward Vandewege wrote:
> I was having some problems with flashrom while running LB (but
> *not* while running the proprietary bios) a few months ago, but I
> need to revisit that. I'll make a trac bug if the problem persists
> with the latest and greatest fl
Thanks for yinghailu and libos' help~
Now the new CPU has arrived, and most of Linuxbios's process is done.
^_^
- Original Message
From: "Feng, Libo" <[EMAIL PROTECTED]>
To: Richard Wei <[EMAIL PROTECTED]>; yhlu <[EMAIL PROTECTED]>
Cc: linuxbios@linuxbios.org
Sent: Friday, August 3, 2007
On Mon, Aug 13, 2007 at 02:46:53AM +0200, Peter Stuge wrote:
> Didn't flashrom work at least with the flash chip on the Gigabyte
> board? (I remember there were problems with BIOS savior, but seem
> to recall that flashing the chip alone worked OK.)
Yeah, it works fine. I was having some problems
On Mon, Aug 13, 2007 at 01:48:07AM +, LOU Ludovic wrote:
> Hello everyone i hope i don't annoy you.
No worries.
> I own a vaio VGN-AR21SR
>
> click or copy link to see spec
>
> http://www.vaio-link.com/specifications/specifications.asp?site=voe_en_gb_cons&c=-1&s=-1&m=2417
>
> and i would
Hello everyone i hope i don't annoy you.
I own a vaio VGN-AR21SR
click or copy link to see spec
http://www.vaio-link.com/specifications/specifications.asp?site=voe_en_gb_cons&c=-1&s=-1&m=2417
and i would like to install linuxbios is it compatible? will it erase BIOS
config and password?.
than
On Sun, Aug 12, 2007 at 07:25:17PM -0500, David H. Barr wrote:
> > > Where are we with that board?
> >
> > I don't think anyone got around to it.
>
> I never got around to it; stalled at flashrom support.
Didn't flashrom work at least with the flash chip on the Gigabyte
board? (I remember there w
On 8/12/07, Peter Stuge <[EMAIL PROTECTED]> wrote:
> On Sun, Aug 12, 2007 at 06:25:26PM -0400, Ward Vandewege wrote:
> > Where are we with that board?
>
> I don't think anyone got around to it.
I never got around to it; stalled at flashrom support. I still have
two of the boards sitting here, wai
On Sun, Aug 12, 2007 at 06:25:26PM -0400, Ward Vandewege wrote:
> Where are we with that board?
I don't think anyone got around to it.
> It's cheap and on the face of it should be fairly easy to port -
> MCP55 chipset, etc. There was some concern about the ehternet card?
For LB purposes the NIC
I'm looking to buy a new desktop machine today or tomorrow. There were
several posts last November bout the MSI K9N Neo-F:
http://www.openbios.org/pipermail/linuxbios/2006-November/thread.html
Where are we with that board? It's cheap and on the face of it should be
fairly easy to port - MCP55 c
Quoting Stefan Reinauer <[EMAIL PROTECTED]>:
> * Joseph Smith <[EMAIL PROTECTED]> [070812 19:49]:
>> SPD would show up at 0x50 or 0x51 right? It doesn't appear there is SPD on
>> the on-board memory.I only show items at 0x2d (sensor) and 0x69 (clock
>> chip).
>
> Are these devices (sensor, clock c
* Joseph Smith <[EMAIL PROTECTED]> [070812 19:49]:
> SPD would show up at 0x50 or 0x51 right? It doesn't appear there is SPD on
> the on-board memory.I only show items at 0x2d (sensor) and 0x69 (clock
> chip).
Are these devices (sensor, clock chip) identified? Any chance there is
an i2c mux some
Quoting Corey Osgood <[EMAIL PROTECTED]>:
> Joseph Smith wrote:
>> Ok, so I tried this and it just returns a "SPD located at 0x69" is
>> this correct?
>> It is much different than the standard 0x50, etc. Is this because it
>> is embedded?? Thanks for all help.
>>
>> Thanks - Joe
>>
>
>
> I'd do an
* Remy Bruno <[EMAIL PROTECTED]> [070727 19:41]:
> Hello,
>
> It seems that the linuxBIOS mailing list also manages FILO, so I post this
> here, please let me know if I'm wrong.
>
> I'm trying to boot on an USB key using Filo and an OHCI host, but without
> success for now. I don't know if this i
Joseph Smith wrote:
> Ok, so I tried this and it just returns a "SPD located at 0x69" is
> this correct?
> It is much different than the standard 0x50, etc. Is this because it
> is embedded?? Thanks for all help.
>
> Thanks - Joe
>
I'd do an dump first, just to make sure that it really is an spd
* Peter Stuge <[EMAIL PROTECTED]> [070811 04:41]:
> > The attached patch removes the seemingly unnecessary restoring of
> > the value at location 0 in probe_28sf040(), and indeed fixes the
> > problem.
>
> We can't say if that restore really is neccessary or not. Erring on
> the side of caution wo
* Ed Swierk <[EMAIL PROTECTED]> [070811 03:58]:
> All of this sounds ridiculously unlikely, and without understanding
> the details of the flash protocols it's hard to know whether I'm
> misdiagnosing the problem. The attached patch removes the seemingly
> unnecessary restoring of the value at loca
Quoting Corey Osgood <[EMAIL PROTECTED]>:
> Joseph Smith wrote:
>> Quoting Corey Osgood <[EMAIL PROTECTED]>:
>>
So, I tried the
dump_spd_registers(&memctrl[0]);
dump_smbus_registers();
from debug.c and here is the results:
-
LinuxBIOS-2.0.0.0Fa
hi,
maybe this would be a good start for a decent source code documentation.
at least it should help understanding the code.
Holger
/**
*
* HOW INTEL FX/VX/HX/TX DRAM BOUNDARY WORKS
* -
*
* Allowing the user to install different types and sizes of mem
I'm sorry, I had a problem with subscription. I hope it's OK now.
--
Janek Kozicki |
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
* Quux <[EMAIL PROTECTED]> [070812 05:52]:
> F11beta legacy bios still has amd-v disbled, according to xenoppix,
> which boots, however --Q
Can't XEN just turn it on? AFAIK you can't lock the AMD-V bits forever,
while on Intel-V the BIOS sets a lock bit and only the BIOS can turn it
back on.
Us
* ron minnich <[EMAIL PROTECTED]> [070812 06:23]:
> On 8/11/07, Quux <[EMAIL PROTECTED]> wrote:
> > the idea is kinda thrilling ... it would allow to have legacy bios
> > available beside LinuxBIOS ?
>
> I doubt it, as the legacy would still be proprietary. It would let you
> boot many OSes though
Joseph Smith wrote:
> Quoting Corey Osgood <[EMAIL PROTECTED]>:
>
>>> So, I tried the
>>> dump_spd_registers(&memctrl[0]);
>>> dump_smbus_registers();
>>> from debug.c and here is the results:
>>> -
>>> LinuxBIOS-2.0.0.0Fallback Sat Aug 11 21:37:10 EDT 2007 starting...
>>>
>
28 matches
Mail list logo
