On Fri, 22 Jul 2011 10:38:45 +0200
Joël Obrecht <joel.obrecht(a)gmail.com> wrote:
> Hi Joshua,
> I'm sorry I looked a bit around but I guess I need some more explanations
> for using / installing that patch. May I have to replace the data in source
> files ? Where ?
> Anyway, I tried again with last svn, failed again, I joined the verbose
> output.
> Joël
hello joël!
i am not entirely sure how your building process works, but you
basically need to apply joshua's patch on top of a current source
snapshot before compiling it.
lets say you have the source in your current working directory.
you can then fetch and apply the patch by:
wget http://patchwork.coreboot.org/patch/2125/raw/ -O p5ne.patch
patch < p5ne.patch
after that you have to recompile it. it should print something like
"Disabling flash write protection for P5N-E" when run then.
it is possible that it does not work yet. please dont reboot if
flashrom tells you that and report back (you can get even faster
reponses on IRC, if that's an issue btw).
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
Author: stefanct
Date: Sat Aug 6 14:45:21 2011
New Revision: 1405
URL: http://flashrom.org/trac/flashrom/changeset/1405
Log:
Clear byte 0x92 of the LPC bridge for all CK804 (and MCP51) chipsets
The OEM BIOS on the EPoX EP-8PA7I and a number of other boards clear
byte 0x92 in the LPC bridge configuration space. Do the same for
all CK804 chips, assuming this to be some sort of chipset-generic
write-enable.
Currently the same chipset enable is used for MCP51 (nForce 430).
There have been reports of successful writes with its variations
(e.g. A8N-LA (Nagami-GL8E)), but they were not tagged as OK. Due to
the new "unsupported chipset"-message we will get success reports in
the case this patch does not break anything on the MCP51-based boards.
See also:
http://www.flashrom.org/pipermail/flashrom/2011-July/007252.htmlhttp://patchwork.coreboot.org/patch/3176/
Signed-off-by: Jonathan Kollasch <jakllsch(a)kollasch.net>
Acked-by: Joshua Roys <roysjosh(a)gmail.com>
Acked-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at>
Modified:
trunk/chipset_enable.c
Modified: trunk/chipset_enable.c
==============================================================================
--- trunk/chipset_enable.c Thu Aug 4 19:40:25 2011 (r1404)
+++ trunk/chipset_enable.c Sat Aug 6 14:45:21 2011 (r1405)
@@ -801,6 +801,12 @@
{
uint8_t old, new;
+ pci_write_byte(dev, 0x92, 0x00);
+ if (pci_read_byte(dev, 0x92) != 0x00) {
+ msg_pinfo("Setting register 0x%x to 0x%x on %s failed "
+ "(WARNING ONLY).\n", 0x92, 0x00, name);
+ }
+
old = pci_read_byte(dev, 0x88);
new = old | 0xc0;
if (new != old) {
Hello all,
I have just tried to flash my BIOS using the flashrom, and I have ran
into the following situation:
lucifer@lucifer-desktop:~/Letöltések/flashrom-0.9.4$ sudo ./flashrom -w
/tmp/sp35111/3.10
flashrom v0.9.4-r1395 on Linux 2.6.35-28-generic (i686), built with
libpci 3.1.7, GCC 4.4.5, little endian
flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OK.
Found chipset "NVIDIA MCP51".
This chipset is marked as untested. If you are using an up-to-date version
of flashrom please email a report to flashrom(a)flashrom.org including a
verbose (-V) log. Thank you!
Enabling flash write... OK.
This chipset supports the following protocols: Non-SPI.
Found PMC flash chip "Pm49FL004" (512 kB, LPC, FWH) at physical address
0xfff80000.
Flash image seems to be a legacy BIOS. Disabling coreboot-related checks.
Reading old flash chip contents... done.
Erasing and writing flash chip... ERASE FAILED at 0x00000000!
Expected=0xff, Read=0x23, failed byte count from 0x00000000-0x00000fff:
0xfec
ERASE FAILED!
Reading current flash chip contents... done. ERASE FAILED at 0x00000000!
Expected=0xff, Read=0x23, failed byte count from 0x00000000-0x0000ffff:
0xfef9
ERASE FAILED!
Reading current flash chip contents... done. ERASE FAILED at 0x00000000!
Expected=0xff, Read=0x23, failed byte count from 0x00000000-0x0007ffff:
0x6494b
ERASE FAILED!
FAILED!
Uh oh. Erase/write failed. Checking if anything changed.
Good. It seems nothing was changed.
Writing to the flash chip apparently didn't do anything.
This means we have to add special support for your board, programmer or
flash chip.
Please report this on IRC at irc.freenode.net (channel #flashrom) or
mail flashrom(a)flashrom.org!
-------------------------------------------------------------------------------
You may now reboot or simply leave the machine running.
Flashrom info:
lucifer@lucifer-desktop:~/Letöltések/flashrom-0.9.4$ sudo ./flashrom
flashrom v0.9.4-r1395 on Linux 2.6.35-28-generic (i686), built with
libpci 3.1.7, GCC 4.4.5, little endian
flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OK.
Found chipset "NVIDIA MCP51".
This chipset is marked as untested. If you are using an up-to-date version
of flashrom please email a report to flashrom(a)flashrom.org including a
verbose (-V) log. Thank you!
Enabling flash write... OK.
This chipset supports the following protocols: Non-SPI.
Found PMC flash chip "Pm49FL004" (512 kB, LPC, FWH) at physical address
0xfff80000.
No operations were specified.
I have tried the latest revision (1402) but it did not works too.
Let me know if I should provide any additional information.
Regards,
Miklós Márton
On Tue, 2 Aug 2011 14:48:15 -0700
David Hendricks <dhendrix(a)google.com> wrote:
> The patch is mostly ack-able, save for a few nits.
>
> On Mon, Aug 1, 2011 at 6:05 PM, Stefan Tauner <
> stefan.tauner(a)student.tuwien.ac.at> wrote:
>
> > My implementation does not defer the processing until doit(), but after the
> > argument parsing loop only (doit() should not contain argument checks).
> >
>
> Just FYI -- The reason we deferred processing until doit() was because our
> usage case calls for reading the ROM content to find pre-existing mappings
> (e.g. fmap) which exist in the ROM image. It might be useful to eventually
> do the same thing for cbfs and Intel's flash descriptor.
jup i am aware of that. but i dont like to inflate doit() with even
more stuff, that does not belong there. we need to think about
refactoring the whole processing... we need something like pre-doit()
before doit() but after init and unlocking. a bit like the shutdown
process with the registration of some callbacks... i hope work on
libflashrom will enforce us to move forward with that.
> On Mon, Aug 1, 2011 at 6:05 PM, Stefan Tauner <
> stefan.tauner(a)student.tuwien.ac.at> wrote:
>
> > This allows to specify -i and -l parameters in any order.
> >
> > I don't like the output in error cases much, any ideas?
> > example of a good run:
> > flashrom -p dummy:emulate=SST25VF032B -i normal -w
> > ../testimages/4096kB.rand.img -l test.layout -i gfxrom -i fallback
> > flashrom v0.9.4-r1396 on Linux 2.6.35-30-generic (x86_64), built with
> > libpci 3.1.7, GCC 4.4.5, little endian
> > flashrom is free software, get the source code at http://www.flashrom.org
> >
> > Using region(s): "normal", "gfxrom", "fallback".
> > Calibrating delay loop... OK.
> > Found SST flash chip "SST25VF032B" (4096 kB, SPI) on dummy.
> > Reading old flash chip contents... done.
> > Erasing and writing flash chip... Erase/write done.
> > Verifying flash... VERIFIED.
> >
>
> Looks okay to me. And IIRC -V will list all ROM layout entries found even if
> they are not included, which is nice for debugging.
that was printed at default verbosity before, and is now spew-verbose
(which is now at -VVV level). but yes i wanted to keep something for
debugging.
>
> On Mon, Aug 1, 2011 at 6:05 PM, Stefan Tauner <
> stefan.tauner(a)student.tuwien.ac.at> wrote:
>
> > example of a semi-good run:
> > flashrom -p dummy:emulate=SST25VF032B -i normal -w
> > ../testimages/4096kB.rand.img -l test.layout -i gfxrom -i fallback
> > flashrom v0.9.4-r1396 on Linux 2.6.35-30-generic (x86_64), built with
> > libpci 3.1.7, GCC 4.4.5, little endian
> > flashrom is free software, get the source code at http://www.flashrom.org
> >
> > Maximum number of ROM images (4) in layout file reached before end of
> > layout file.
> > Ignoring the rest of the layout file.
> >
>
> I think that if the user accidentally specifies an invalid layout or number
> of included regions, then Flashrom should quit. Otherwise Flashrom might not
> flash everything the user intends, leaving the content in an inconsistent
> (probably bricked) state. This has become problematic due to complicated ROM
> layouts in systems where multiple masters use a shared SPI flash (e.g. an EC
> or Intel's ME insanity).
yes, that's certainly a well argued proposal imo. carl-daniel?
> On Mon, Aug 1, 2011 at 6:05 PM, Stefan Tauner <
> stefan.tauner(a)student.tuwien.ac.at> wrote:
>
> > example of a faulty run:
> > flashrom -p dummy:emulate=SST25VF032B -i normal -w
> > ../testimages/4096kB.rand.img -l test.layout -i gfxrom -i fallback -i bios
> > flashrom v0.9.4-r1396 on Linux 2.6.35-30-generic (x86_64), built with
> > libpci 3.1.7, GCC 4.4.5, little endian
> > flashrom is free software, get the source code at http://www.flashrom.org
> >
> > Maximum number of ROM images (4) in layout file reached before end of
> > layout file.
> > Ignoring the rest of the layout file.
> > Using region(s): "normal", "gfxrom", "fallback"Invalid region specified:
> > "bios"
> >
>
> If you split that last line so that the "Invalid region" part shows up on a
> newline, it looks okay.
that is one option yes. but i tend to think we may defer the output of
the used regions and push it into its own loop at the end of
process_include_args.
this was there would be no "using region..." output in case of errors
at all. and it may even be more readable(?)
> > Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at>
> > ---
> > cli_classic.c | 11 ++++-----
> > flash.h | 2 +
> > layout.c | 68
> > ++++++++++++++++++++++++++++++++++++++++++++++++++------
> > 3 files changed, 67 insertions(+), 14 deletions(-)
> >
> > diff --git a/cli_classic.c b/cli_classic.c
> > index 36fe9ad..e44ea86 100644
> > --- a/cli_classic.c
> > +++ b/cli_classic.c
> > @@ -233,14 +233,9 @@ int cli_classic(int argc, char *argv[])
> > cli_classic_abort_usage();
> > break;
> > case 'i':
> > - /* FIXME: -l has to be specified before -i. */
> > tempstr = strdup(optarg);
> > - if (find_romentry(tempstr) < 0) {
> > - fprintf(stderr, "Error: image %s not found
> > in "
> > - "layout file or -i specified before
> > "
> > - "-l\n", tempstr);
> > + if (register_include_arg(tempstr) < 0)
> > cli_classic_abort_usage();
> > - }
> > break;
> > case 'L':
> > if (++operation_specified > 1) {
> > @@ -325,6 +320,10 @@ int cli_classic(int argc, char *argv[])
> > cli_classic_abort_usage();
> > }
> >
> > + if (process_include_args() < 0) {
> > + cli_classic_abort_usage();
> > + }
> > +
> > /* FIXME: Print the actions flashrom will take. */
> >
> > if (list_supported) {
> > diff --git a/flash.h b/flash.h
> > index 5b49e9d..0848255 100644
> > --- a/flash.h
> > +++ b/flash.h
> > @@ -251,6 +251,8 @@ int print(int type, const char *fmt, ...)
> > __attribute__((format(printf, 2, 3)));
> > int cli_classic(int argc, char *argv[]);
> >
> > /* layout.c */
> > +int register_include_arg(char *name);
> > +int process_include_args(void);
> > int read_romlayout(char *name);
> > int find_romentry(char *name);
> > int handle_romentries(struct flashchip *flash, uint8_t *oldcontents,
> > uint8_t *newcontents);
> > diff --git a/layout.c b/layout.c
> > index d719a05..936e316 100644
> > --- a/layout.c
> > +++ b/layout.c
> > @@ -41,6 +41,12 @@ typedef struct {
> > char name[256];
> > } romlayout_t;
> >
> > +/* include_args lists arguments specified at the command line with -i.
> > They
> > + * must be processed at some point so that desired regions are marked as
> > + * "included" in the rom_entries list.
> > + */
> > +static char *include_args[MAX_ROMLAYOUT];
> > +static int num_include_args = 0; /* the number of valid entries. */
> > static romlayout_t rom_entries[MAX_ROMLAYOUT];
> >
> > #if CONFIG_INTERNAL == 1 /* FIXME: Move the whole block to cbtable.c? */
> > @@ -194,6 +200,20 @@ int read_romlayout(char *name)
> > }
> > #endif
> >
> > +/* register an include argument (-i) for later processing */
> > +int register_include_arg(char *name)
> > +{
> > + if (num_include_args >= MAX_ROMLAYOUT) {
> > + msg_gerr("Too many regions included (%i).\n",
> > num_include_args);
> > + return -1;
> > + }
> > +
> > + include_args[num_include_args] = name;
> > + num_include_args++;
> > + return num_include_args;
> > +}
> > +
> > +/* returns the index of the entry (or a negative value if it is not found)
> > */
> > int find_romentry(char *name)
> > {
> > int i;
> > @@ -201,20 +221,49 @@ int find_romentry(char *name)
> > if (!romimages)
> > return -1;
> >
> > - msg_ginfo("Looking for \"%s\"... ", name);
> > -
> > + msg_gspew("Looking for region \"%s\"... ", name);
> > for (i = 0; i < romimages; i++) {
> > if (!strcmp(rom_entries[i].name, name)) {
> > rom_entries[i].included = 1;
> > - msg_ginfo("found.\n");
> > + msg_gspew("found.\n");
> > return i;
> > }
> > }
> > - msg_ginfo("not found.\n"); // Not found. Error.
> > -
> > + msg_gspew("not found.\n");
> > return -1;
> > }
> >
> > +/* process -i arguments
> > + * returns 0 to indicate success, <0 to indicate failure
> >
>
> I think the usual Flashrom convention is to return 1 to indicate failure. I
> used <0 out of habit. Let's go ahead and fix that coding convention for
> upstream if desired, and update the call sites to do error checking
> correctly.
well -1 is also used very often, but that's no argument to introduce
more inconsistencies :) i'll fix this, thanks.
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner