It seems that in show_id() type of 'walk' variable should of fixed size
(i.e. uint32_t) for x86_64 portability.
Also, it looks suspicious that two legacy bios checks (nvidia and
general) are exactly the same:
if ((*walk) == 0 || ((*walk) 0x3ff) != 0) {
/* We might have an Nvidia
Author: stuge
Date: 2008-06-07 13:36:30 +0200 (Sat, 07 Jun 2008)
New Revision: 3361
Modified:
trunk/util/superiotool/nsc.c
trunk/util/superiotool/superiotool.h
Log:
Add dump support for Winbond (NSC) PC87427. Dumps available from real hardware.
Signed-off-by: Tom Sylla [EMAIL PROTECTED]
On Fri, Jun 06, 2008 at 09:10:49PM +0200, Peter Stuge wrote:
On Thu, May 29, 2008 at 10:46:33AM -0400, Tom Sylla wrote:
Add dump support for Winbond (NSC) PC87427. Dumps available from real
hardware.
Signed-off-by: Tom Sylla [EMAIL PROTECTED]
Acked-by: Peter Stuge [EMAIL PROTECTED]
Dear coreboot readers!
This is the automated build check service of coreboot.
The developer stuge checked in revision 3361 to
the coreboot source repository and caused the following
changes:
Change Log:
Add dump support for Winbond (NSC) PC87427. Dumps available from real hardware.
On Sat, Jun 07, 2008 at 01:40:39PM +0200, Carl-Daniel Hailfinger wrote:
Ouch. So one of the other probe functions kills communication. Can one
of you try disabling other chip definitions in flashchips.c with #if 0
to narrow this problem down?
This is the culprit:
{Winbond, W29EE011,
On 07.06.2008 05:47, Ward Vandewege wrote:
On Sat, Jun 07, 2008 at 05:37:05AM +0200, Carl-Daniel Hailfinger wrote:
Ouch. So one of the other probe functions kills communication. Can one
of you try disabling other chip definitions in flashchips.c with #if 0
to narrow this problem down?
I did
Dear coreboot readers!
This is the automated build check service of coreboot.
The developer stepan checked in revision 3362 to
the coreboot source repository and caused the following
changes:
Change Log:
fix via epia cn abuild.
Signed-off-by: Stefan Reinauer [EMAIL PROTECTED]
Acked-by: Stefan
Ward Vandewege wrote:
On Sat, Jun 07, 2008 at 03:40:35PM +0200, Stefan Reinauer wrote:
Ward Vandewege wrote:
On Sat, Jun 07, 2008 at 01:40:39PM +0200, Carl-Daniel Hailfinger wrote:
Ouch. So one of the other probe functions kills communication. Can one
of you try
On Sat, Jun 07, 2008 at 04:07:29PM +0200, Stefan Reinauer wrote:
Ah, this is broken... flashrom should not continue when it found a
chip in a given memory area already.
flashrom supports boards with more than one flash chip.
But perhaps we need to teach flashrom more about how chips can be
On 07.06.2008 16:29, Peter Stuge wrote:
On Sat, Jun 07, 2008 at 04:07:29PM +0200, Stefan Reinauer wrote:
Ah, this is broken... flashrom should not continue when it found a
chip in a given memory area already.
flashrom supports boards with more than one flash chip.
But perhaps we
Carl-Daniel Hailfinger wrote:
On 07.06.2008 16:29, Peter Stuge wrote:
On Sat, Jun 07, 2008 at 04:07:29PM +0200, Stefan Reinauer wrote:
Ah, this is broken... flashrom should not continue when it found a
chip in a given memory area already.
flashrom supports boards
On 07.06.2008 18:37, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
On 07.06.2008 16:29, Peter Stuge wrote:
On Sat, Jun 07, 2008 at 04:07:29PM +0200, Stefan Reinauer wrote:
Ah, this is broken... flashrom should not continue when it found a
chip in a given
Hi,
I tried to erase the flash tonight. But without result, both
erase_49lf040 and erase_chip_jedec.
But after a erase_49fl040 the chip does not reacts anymore,until a reboot.
I will compare the Specs of SST49LF040 and the AMIC and will try again
tomorrow.
Good night from Germany.
CU
Jens
http://www.whiterocker.com/gpxe/
FYI - At this point I don't plan to submit any patches to gPXE as my
approach is rather hackish and still experimental.
Any comments/suggestions welcome.
Chris.
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Sat, Jun 07, 2008 at 09:23:07PM -0700, Chris Kilgour wrote:
http://www.whiterocker.com/gpxe/
FYI - At this point I don't plan to submit any patches to gPXE as
my approach is rather hackish and still experimental.
Any comments/suggestions welcome.
Great work!
How do you think that a
May we add this into the coreboot wiki?
-Bari
Chris Kilgour wrote:
http://www.whiterocker.com/gpxe/
FYI - At this point I don't plan to submit any patches to gPXE as my
approach is rather hackish and still experimental.
Any comments/suggestions welcome.
Chris.
--
coreboot
Peter Stuge wrote:
On Sat, Jun 07, 2008 at 09:23:07PM -0700, Chris Kilgour wrote:
FYI - At this point I don't plan to submit any patches to gPXE as
my approach is rather hackish and still experimental.
How do you think that a proper port of gPXE to coreboot differs
from your
bari wrote:
May we add this into the coreboot wiki?
I was going to do that originally. But I wondered if putting it on the
coreboot Wiki before any success reports would give it some
as-yet-undeserved credence.
That said, if anyone would like to adapt my instructions to the coreboot
Wiki,
18 matches
Mail list logo