According to the data sheet these are identical to the 39LV010 in every
respect except capacity.
Unfortunately I can't test this, as I am on a laptop. Flashrom simply doesn't
detect the chip.
Signed-of-by: Anders Juel Jensen <andersjjensen(a)gmail.com>
Include detailed versioning information in the binary (--version).
Signed-off-by: Idwer Vollering <vidwer(a)gmail.com>
---
Future thoughts: include the used version of libpci.
On 19.02.2010 11:08, Michael Karcher wrote:
> http://www.flashrom.org/pipermail/flashrom/2010-February/002318.html
>
> Should we commit single patches for each positive test report we get,
> or collect them?
>
Not sure. I think collecting them and committing once a week (or
something like that) would help keep the number of patches down.
> --- a/flashchips.c
> +++ b/flashchips.c
> @@ -3763,7 +3763,7 @@ struct flashchip flashchips[] = {
> .total_size = 256,
> .page_size = 128,
> .feature_bits = FEATURE_LONG_RESET,
> - .tested = TEST_UNTESTED,
> + .tested = TEST_OK_PR,
> .probe = probe_jedec,
>
I propose to have people test probe_jedec with full address bits and
restricted address bits. If both work, we might as well use the full
version (same for all other operations of the chip) and note it
somewhere that the upper bits are "don't care".
Maybe we'll get to a point where we can run probe_jedec just once per
chip size instead of once per size+addressbits+delay combination in
flashchips.c which would be an alternative to the current code. Long
term goal, feel free to ignore.
Regards,
Carl-Daniel
--
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This board has a supported chipset and a supported bios, but it's
connected indirectly through IT8716 and not recognized.
- --
Raúl Soriano (GatoLoko), SpainTeam Local Community Contact.
http://www.ubuntuspain.org - http://wiki.ubuntu.com/GatoLoko
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuJwa4ACgkQ063tJLOwQucjdACfSfZMkU2oN1V6QbAo2XIhAIXH
j/4An2d9dxyoLkZeBqXgqn2ZkxqZbv/J
=d3h4
-----END PGP SIGNATURE-----
If you add your signoff, this is
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net>
Note: I'm not a native speaker, so I just checked if the text is
understandable.
Regards,
Carl-Daniel
--
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth
For optimal partial reflashing, we have to find out which parts of the
chip can be written without erase. For that, the only criterion (except
a limit on the number of writes for very old chips) is whether the write
will only clear bits (set them to 0).
If (current&new==new) we can skip the erase.
If any bit would have to be set to 1, we need to erase.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net>
Index: flashrom-need_erase/flash.h
===================================================================
--- flashrom-need_erase/flash.h (Revision 725)
+++ flashrom-need_erase/flash.h (Arbeitskopie)
@@ -455,6 +455,7 @@
int max(int a, int b);
int check_erased_range(struct flashchip *flash, int start, int len);
int verify_range(struct flashchip *flash, uint8_t *cmpbuf, int start, int len, char *message);
+int need_erase(uint8_t *have, uint8_t *want, int len);
char *strcat_realloc(char *dest, const char *src);
#define OK 0
Index: flashrom-need_erase/flashrom.c
===================================================================
--- flashrom-need_erase/flashrom.c (Revision 725)
+++ flashrom-need_erase/flashrom.c (Arbeitskopie)
@@ -379,6 +379,26 @@
return ret;
}
+/**
+ * Check if the buffer have can be programmed to the content of want without
+ * erasing. This is only possible if no bit has to be set to 1.
+ *
+ * @have buffer with current content
+ * @want buffer with desired content
+ * @len length of the verified area
+ * @return 0 if no erase is needed, >0 otherwise
+ */
+int need_erase(uint8_t *have, uint8_t *want, int len)
+{
+ int failcount = 0;
+ int i;
+
+ for (i = 0; i < len; i++)
+ if ((have[i] & want[i]) != want[i])
+ failcount++;
+ return failcount;
+}
+
struct flashchip *probe_flash(struct flashchip *first_flash, int force)
{
struct flashchip *flash;
--
http://www.hailfinger.org/
On 27.02.2010 19:30, Michael Karcher wrote:
> The message printing code greatly exceed the 80 character limit. I can
> reformat it on request to obey the limit.
>
Heh, this is one of the places where our coding standard says nothing.
Detailed comment below.
> Intended behaviour:
> on untested boards an explanation of that status is printed and the board
> enable code is not run, unless the option "boardenable=force" has been
> passed to the internal programmer.
>
> Signed-off-by: Michael Karcher <flashrom(a)mkarcher.dialup.fu-berlin.de>
>
Thanks a lot for this patch. It will allow us to get the number of
pending patches down to a manageable level.
> diff --git a/board_enable.c b/board_enable.c
> index 4278b6d..8f76b9b 100644
> --- a/board_enable.c
> +++ b/board_enable.c
> @@ -1349,6 +1349,30 @@ static struct board_pciid_enable *board_match_pci_card_ids(void)
> }
> }
>
> + if (board->status == NT) {
>
IMHO this check should live in board_flash_enable() instead. Otherwise
the board status is completely ignored if someone uses the coreboot IDs
to match.
> + if (!force_boardenable)
> + {
> + printf("WARNING: Your mainboard is %s %s, but the mainboard-specific\n"
> + "code has not been marked as working. To help flashrom development, please\n"
>
s/has not been marked as working/has not been tested/
> + "test flashrom on your board. As the code to support your board is untested,\n"
> + "we strongly recommend that as an additional safety measure you make\n"
> + "store backup of your current ROM contents (obtained by flashrom -r) on\n"
>
"...make store backup..." looks like a few words are missing here.
> + "a medium that can be accessed from a different computer (like an USB\n"
> + "drive or a network share of another system) before you try to erase or\n"
> + "write.\n"
> + "The untested code does not run unless you specify the\n"
> + " \"-p internal:boardenable=force\" command line option. Depending on your\n"
> + "hardware environment, erasing, writing or even probing can fail without\n"
> + "running the board specific code. Running the board-specific code might\n"
> + "cause your computer to behave erratically if it is wrong.\n"
> + "Please report the results of running the board enable code to\n"
> + "flashrom(a)flashrom.org.\n",
>
I'm tempted to make this message way shorter and point people to the man
page instead.
WARNING: Your mainboard has been detected as %s %s, and it needs
mainboard specific code to write or erase your chip. This code is
present in flashrom, but it has not been tested. Please see the flashrom
man page for details how to enable it. Please report your results to
flashrom(a)flashrom.org.
Either way, we should think about throwing the whole message text into
some #define and align that to the left, or maybe break indentation
rules for such messages.
Ther's no standard for long message coding style, and every part of the
code does it in a different way. Each possibility sucks, but it would be
great if the suckage was standard.
> + board->vendor_name, board->board_name);
> + continue;
> + }
> + printf("NOTE: Running an untested board enable procedure.\n"
> + "Please report success/failure to flashrom(a)flashrom.org\n");
> + }
> return board;
> }
>
>
Rest looks good. Explain of fix the points above (message formatting can
be postponed until after 0.9.2), and you get an ack.
Regards,
Carl-Daniel
--
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth