Thanks again for the additional comments. I made the changes (comments
below) and re-compiled with the extra programmers enabled.
New version of the patch attached.
Signed-off-by: David Hendricks
On Sat, Jun 11, 2011 at 5:09 AM, Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2...@gmx.net>
On Mon, Jun 13, 2011 at 5:13 PM, Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2...@gmx.net> wrote:
> Am 14.06.2011 00:45 schrieb David Hendricks:
> > Thanks again for the additional comments. I made the changes (comments
> > below) and re-compiled with the extra programmers
to read hsfc before
going into the if() statement (like you did with hsfs).
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
___
flashrom mailing list
flashrom@flashrom.org
http://www.flashrom.org/mailman/listinfo/flashrom
On Thu, Jun 16, 2011 at 7:45 AM, Stefan Tauner <
stefan.tau...@student.tuwien.ac.at> wrote:
> On Wed, 15 Jun 2011 16:23:27 -0700
> David Hendricks wrote:
>
> > fyi, the following small errors are made in multiple times (copy +
> paste?)
> > in ichspi.c
>
> tha
ow, erase_size_high, size_high;
> + struct block_eraser eraser;
>
This should be a pointer, right? I am assuming you intended to directly
update the flash->block_erasers[0] member later in this function.
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
__
is* enough :-P)
On Mon, Jun 27, 2011 at 8:33 PM, Stefan Tauner <
stefan.tau...@student.tuwien.ac.at> wrote:
> +static uint8_t ich_fill_data(const uint8_t *data, uint8_t len, int
> reg0_off)
As mentioned on IRC, the caller tends to pass in a "len" value > 255, e.g. 1
bl
06-30 19:35:50.190944388 -0700
+++ b/arch.h2011-06-30 19:35:35.280103884 -0700
@@ -27,5 +27,7 @@
#define __FLASHROM_ARCH__ "mips"
#elif defined(__powerpc__) || defined(__powerpc64__) || defined(__ppc__) ||
defined(__ppc64__)
#define __FLAS
only used it here since it's
the only non-x86 platform I have set up for testing at the moment.
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
___
flashrom mailing list
flashrom@flashrom.org
http://www.flashrom.org/mailman/listinfo/flashrom
to:
if (!flashrom_pci_init())
pci_scan_bus(pacc);
and it works on systems w/o PCI (at least it did on ARM)
Here are my test results with this patch and the tegra2 patch:
http://paste.flashrom.org/view.php?id=683
--
David Hendricks (dhendrix)
Systems So
The latest revision fixed the issue seen on IRC where the ARCH string might
get duplicated.
I tested it on both x86 and ARM (using the tegra2 patches) and it worked,
so:
Acked-by: David Hendricks
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc
and the libpci hack <http://patchwork.coreboot.org/patch/3255/>).
The difference between this patchset and the previous one is pretty minor.
We can now discard the first patch which #ifdef'd out PCI code for ARM
targets. The
rint the equivalent FADDR in the ICH9 branch. patch appended.
Acked-by: David Hendricks
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
___
flashrom mailing list
flashrom@flashrom.org
http://www.flashrom.org/mailman/listinfo/flashrom
i_classic.c (working copy)
@@ -146,6 +146,7 @@
print_version();
print_banner();
+ print_expiration();
if (selfcheck())
exit(1);
where print_expiration() contains the code that prints warning.
--
David Hendricks
ntroducing gratuitous
> user interface changes would be a bad idea.
> Side note: This also reduces the amount of code changes needed for the
> logfile patch.
>
> Signed-off-by: Carl-Daniel Hailfinger
>
Looks good to me.
Acked-by: David Hendricks
t; {
>int i;
> @@ -246,11 +295,12 @@ int handle_romentries(struct flashchip *flash,
> uint8_t *oldcontents, uint8_t *ne
>int entry;
> unsigned int size = flash->total_size * 1024;
>
> - /* If no layout file was specified or the layout file was emp
l the
necessary erase regions and checks to ensure they are all readable and
erasable. Much of the work will be done to address issues mentioned earlier
in Carl-Daniel's list.
On Thu, Aug 18, 2011 at 4:41 AM, Tadas Slotkus wrote:
> Use UNIX philosophy: do one thing and do it well.
>
A
ip lock, but to remove that
> software chip lock, a hardware chip lock has to be disabled first, then
> the software chip lock can be disabled.
>
Just fail if it's not easy to defeat the write protection (and hopefully
restore it). There are so many hardware write protection mecha
Did you want to fix the inconsistent use of -1 instead of 1 as the return
code for some functions?
Other than that it looks good (i'm biased, of course :-))
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
___
flashrom mailing
Oops, disregard that last message. I was looking at find_romentry() and
indeed it makes sense to return a negative value to indicate error since it
returns an index otherwise.
Acked-by: David Hendricks
On Fri, Aug 19, 2011 at 2:53 PM, David Hendricks wrote:
> Did you want to fix
t sure why we used perror()... Perhaps it would be better to
use msg_gerr(strerror(errno))?
> + return 1;
> + }
> + numbytes = fread(newcontents + entry->start, 1, len, fp);
> + fclose(fp);
> + i
can also make your
life easier when doing simple low-level operations.
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
___
flashrom mailing list
flashrom@flashrom.org
http://www.flashrom.org/mailman/listinfo/flashrom
On Fri, Sep 30, 2011 at 10:32 AM, Bernd Blaauw wrote:
> Op 30-9-2011 19:09, Marcos Felipe Rasia de Mello schreef:
>
>
> I get differences with the previous one. I haven't enter in the bios or
>>> change
>>> anything... I was expecting no differences between them. Am I missing
>>> anything?
>>>
>
On Fri, Nov 25, 2011 at 8:10 AM, Pontus Rodling wrote:
> Hi!
> flashrom told me to send you guys this, so here it is.
>
> I'm getting a transaction error when trying to read the (fully supported
> according to the wiki) W25Q64 flash chip on a Intel H57 chipset which is
> marked as untested.
> I tr
On Sat, Nov 26, 2011 at 3:35 PM, Stefan Tauner <
stefan.tau...@student.tuwien.ac.at> wrote:
> This includes the notorious read-only flash descriptors and locked ME
> regions.
> ---
> non-verbose sample output from my laptop:
> […]
> Found chipset "Intel QS57". Enabling flash write... WARNING: SPI
For what it's worth, when I tested the patch earlier it worked on ARM with
that libpci hack.
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
___
flashrom mailing list
flashrom@flashrom.org
http://www.flashrom.org/mailman/listinfo/flashrom
On Fri, Dec 16, 2011 at 11:06 AM, Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2...@gmx.net> wrote:
> Am 09.12.2011 05:02 schrieb David Hendricks:
> > On Thu, Dec 8, 2011 at 12:18 PM, Carl-Daniel Hailfinger <
> > c-d.hailfinger.devel.2...@gmx.net> wrote:
> >
- the data for a single address
> is the same anyway.
> when different files are given this is no longer true. i think the best
> option would be to abort and/or require --force in that case in
> addition to a defined precedence (e.g. last -i wins).
>
I'd prefer to simply abo
On Tue, Dec 27, 2011 at 2:52 PM, David Hendricks wrote:
> For read, if the sum of regions included covers the entire chip, then you
> will end up with two identical files. Included regions will also show up in
> the -r argument, while the rest is filled in with 0xff's.
>
Bleh
r Chrome/Chromium OS keep pace with upstream, and help us test
upstream code and get it merged more frequently.
Note that in addition to the EC code itself, we'll also need to add the
command-line processing to switch between SPI/LPC targets on the fly. This
is the "-p internal:bus="
re details, and ensure the NC
field is programmed appropriately for your mainboard configuration.
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
___
flashrom mailing list
flashrom@flashrom.org
http://www.flashrom.org/mailman/listinfo/flashrom
ram opcode (0x02)
show either "1" or "2" for op.atomic.
This will help us to prove whether or not this is the problem you are
encountering.
>
> Yes jumper selects the ROM at a time.
>
Okay. I do not think Flashrom is confused about t
0x38-0x38:EW, 0x39-0x39:EW, 0x3a-0x3a:EW,
> 0x3b-0x3b:EW, 0x3c-0x3c:EW, 0x3d-0x3dffff:EW,
> 0x3e-0x3e:EW, 0x3f-0x3f:EW
> Erase/write done.
> Verifying flash... VERIFIED.
> Writing dummy_simulator.rom
>
>
> Signed-off
It's a step in the right direction, and compiles for (and runs) on my
Tegra2 test platform, so:
Acked-by: David Hendricks
> > David: This is mostly your code (I only extracted it from the chromium
> > branch of flashrom), could you sign off on it?
>
All code in th
uld take some careful
consideration but should not distract from the ultimate goal of readability
and maintainability.
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
___
flashrom mailing list
flashrom@flashrom.org
http://www.flashrom.org/mailman/listinfo/flashrom
protection, where by you block protect 1/Nth the
size of the chip, while 26-series is much more flexible. Supporting all the
different variations presenting them to the user in a sane manner takes
some thought.
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
___
flashrom mailing list
flashrom@flashrom.org
http://www.flashrom.org/mailman/listinfo/flashrom
On Tue, Apr 24, 2012 at 3:42 PM, David Hendricks wrote:
> Also, your chipset might be configured to target the LPC bus instead of
> the SPI bus.
>
More specifically, check the value of the boot BIOS straps (BBS) register.
--
David Hendricks (dhendrix)
Systems Software Engineer, G
Hi Raghu,
I've seen similar symptoms when on laptops when embedded controller (EC)
interactions interfere. Delay loop calibration can be interfered if the EC
is spamming the host chipset with SCIs (check dmesg output and see if the
kernel complains about interrupt storms or some such). Also, if the
This seems trivial, as internal_init() already does the right thing when a
return value is used here.
Acked-by: David Hendricks
On Wed, May 30, 2012 at 11:48 AM, Niklas Söderlund wrote:
> Replace with a return instead, all other plumbing is already in place
>
> Signed-off-by: Niklas
Seems trivial, and I think you're also helping to make sure memory alloc'd
in doit() gets free'd properly. So:
Acked-by: David Hendricks
Thanks for doing this!
On Wed, May 30, 2012 at 11:21 AM, Niklas Söderlund wrote:
> Sorry I forgot,
>
> Signed-off-by: Niklas Söde
This adds the following:
- missing feature_bits to indicate WREN required before WRSR and the
presence of OTP bytes
- a comment mentioning SFDP support
- voltage range
Signed-off-by: David Hendricks
Index: flashchips.c
with a good solution. I am thinking that "N25Q064" is sufficient and
that we should just re-use the same .name for two chip entries with
different .voltage parameters.
Thoughts?
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
__
On Wed, Jul 25, 2012 at 2:03 PM, Stefan Tauner <
stefan.tau...@student.tuwien.ac.at> wrote:
> On Wed, 25 Jul 2012 12:14:33 -0700
> David Hendricks wrote:
>
> > There's a SPI chip named "N25Q064" with 1.8V and 3V variants N25Q064A11
> and
> > N25Q06
break fragile scripts and confuse people.
More about this schema here:
http://www.flashrom.org/pipermail/flashrom/2012-July/009595.html
Signed-off-by: David Hendricks
Index: flashchips.c
===
--- flashchips.c(revision 1553
;t have bothered to make a patch for it :-)
On Thu, Jul 26, 2012 at 8:48 PM, Stefan Tauner <
stefan.tau...@student.tuwien.ac.at> wrote:
> There are a number of other N25Q* chips available apparently. Do you
> plan to add them too (NB: http://p
adcnt);
> + }
> + return ret;
> }
>
> int spi_send_multicommand(struct flashctx *flash, struct spi_command
> *cmds)
>
Interesting approach. However, I think 3-byte vs. 4-byte RDID commands and
caching REMS might make patching spi_send_command rather messy.
On Thu, Oct 11, 2012 at 7:44 PM, Stefan Tauner <
stefan.tau...@student.tuwien.ac.at> wrote:
> On Thu, 11 Oct 2012 19:16:40 -0700
> David Hendricks wrote:
>
> > On Wed, Oct 3, 2012 at 3:59 PM, Carl-Daniel Hailfinger <
> > c-d.hailfinger.devel.2...@gmx.net> wrot
, I'm just forwarding it
upstream:
Signed-off-by: Nathan Laredo
Signed-off-by: David Hendricks
Index: dediprog.c
===
--- dediprog.c (revision 1620)
+++ dediprog.c (working copy)
@@ -46,7 +46,9 @@
#endif
/* Might be useful for ot
ashrom to properly write
> the new BIOS?
>
> ___
> flashrom mailing list
> flashrom@flashrom.org
> http://www.flashrom.org/mailman/listinfo/flashrom
>
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
___
flashrom mailing list
flashrom@flashrom.org
http://www.flashrom.org/mailman/listinfo/flashrom
ers.
The MX25L25835E actually should look the same as MX25L12805D from a
software perspective. The difference is that MX25L25835E is stacked (two
128Mbit flash memories). Each bank is selected by a different chip-select
line (referred to as CS#1 and CS#2 in the datasheet).
HTH!
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
___
flashrom mailing list
flashrom@flashrom.org
http://www.flashrom.org/mailman/listinfo/flashrom
ad/write access denied)
- etc.
- Incorporate EC code from ChromiumOS branch. Code will be tested on
"known-working" production systems.
- Improve the "-p internal" syntax so that internal targets can be
specified by device class instead of bus, e.g. "-p inte
kB: probe_jedec_common: id1 0x02, id2
> 0x01, id1 is normal flash content, id2 is normal flash content
> Probing for Winbond W39V080FA (dual mode), 512 kB: probe_jedec_common: id1
> 0x71, id2 0x5d, id1 parity violation, id1 is normal flash content, id2 is
> normal flash content
>
You can find a lot of similar parts in flashchips.c. Judging by the part
number you gave, you'll want to look at 32Mbit "25" series SPI ROMs such as
the AMIC A25, Atmel AT25, Eon EN25, Winbond W25, etc. Of course you will
need to look at the Winbond 25Q32BVSIG datasheet for package type and
voltage
rding
> the "Internal programmer improvements for complex systems" project.
>
> If everything works out as planned I would like to release another
> stable (or at least release candidate) a few months after the big
> changes have been merged, certainly before 2014.
> --
hrom@flashrom.org
> http://www.flashrom.org/mailman/listinfo/flashrom
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
___
flashrom mailing list
flashrom@flashrom.org
http://www.flashrom.org/mailman/listinfo/flashrom
What flash chip is this for?
The id1 byte corresponds to ISSI, but there are not any ISSI SPI flash
chips supported at the moment. If you can provide the part number we can
add support.
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc
emented by either, though in most cases it's the SPI
controller on Intel systems.
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
___
flashrom mailing list
flashrom@flashrom.org
http://www.flashrom.org/mailman/listinfo/flashrom
C device %" PRIx16 ":%" PRIx16
> ".\n"
> - "Please report this to flashrom@flashrom.org
> and include this log and\n"
> + "Please report this to " SUPPORT_EMAIL " and
> include this log and\n"
>
It found your flash chip, so that's a good sign. Try reading the content to
a file (flashrom -p internal -r /tmp/bios.bin).
On Sat, Oct 18, 2014 at 1:17 PM, Bernhard Schiffner <
bernh...@schiffner-limbach.de> wrote:
> Some output of flashrom -V attached
>
> Good luck, it seems a non cooperating s
+1 to soic8_30degrees.
The lightning bolt could be a a tiny bit smaller IMO, but no big deal
either way.
On Sat, Feb 21, 2015 at 5:04 PM, Stefan Tauner <
stefan.tau...@alumni.tuwien.ac.at> wrote:
> Hello,
>
> we have used two logos in the past for flashrom. The one most are
> familiar with is ac
oesn’t match: Stat 4194304 bytes, wanted 524288”
>
>
>
>
>
> I was hoping I could get some help on what to do.
>
>
>
> Thanks
> Mohammed Rizwan Ahmed
>
>
>
> ___
> flashrom mailing list
> flashrom@flashrom.org
ng a dediprog or buspirate. Is there a
> command line argument to specify the addresses you would like to read from?
>
> Thanks!
>
> ___
> flashrom mailing list
> flashrom@flashrom.org
> http://www.flashrom.org/mailman/listinfo/flash
Acked-by: David Hendricks
On Sun, Jun 21, 2015 at 6:37 PM, Stefan Tauner
wrote:
>
> Previously we have used low-active macros (because the hardware and
> old protocol were so too) and set every single LED explicitly although we
> only used a limited number of combinations. Using an
Mostly looks good to me, just a couple minor comments.
On Sun, Jun 21, 2015 at 6:37 PM, Stefan Tauner
wrote:
> Use names for the commands and request types instead of magic
> numbers and remove some of the unnecessary unexplained arguments.
> Also, cleanup the nonsense code left over from RE. Mos
Apply this patch after patch 4 so that dediprog_read() is defined.
Aside from that:
Acked-by: David Hendricks
On Sun, Jun 21, 2015 at 6:37 PM, Stefan Tauner
wrote:
> Whatever that is...
> To that end, send the respective command and print result with a "new"
> helpers.c f
Acked-by: David Hendricks
On Sun, Jun 21, 2015 at 6:37 PM, Stefan Tauner
wrote:
> Signed-off-by: Stefan Tauner
> ---
> Makefile | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index c439d8d..e7c8fde 100644
> --- a/M
Sounds good to me.
Acked-by: David Hendricks
On Jun 28, 2015 4:07 PM, "Stefan Tauner"
wrote:
> On Sat, 27 Jun 2015 17:24:43 -0700
> David Hendricks wrote:
>
> > Mostly looks good to me, just a couple minor comments.
> >
>
On Thu, Jul 9, 2015 at 9:24 AM, David Woodhouse wrote:
> On Thu, 2015-07-09 at 16:59 +0100, David Woodhouse wrote:
>>
>> Here's an updated version of the next patch in the sequence.
>
>> ...
>
>> From: Stefan Tauner
>> Date: Mon, 22 Jun 2015 03:37:23 +0200
>> Subject: [PATCH] dediprog: Support ne
, Ubuntu has a few nice
pages on that subject such as https://help.ubuntu.com/community/AptGet/Howto
.
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
___
flashrom mailing list
flashrom@flashrom.org
http://www.flashrom.org/mailman/listinfo/flashrom
comments for clarity, and only runs it
conditionally if we cannot query the devicestring during init.
Tested with SF100 V:5.1.5 and SF600 V:7.1.4 (with subsequent patches)
Signed-off-by: David Hendricks
Index: dediprog.c
===
--- dediprog.c
conditionally if we cannot query the devicestring during
init.
Tested with SF100 V:5.1.5 and SF600 V:7.1.4 (with subsequent patches).
Signed-off-by: David Hendricks
Index: dediprog.c
===
--- dediprog.c (revision 1896)
+++ dediprog.c (working
, David Hendricks wrote:
> As per e-mail with Dediprog, command 0x0B (which is not listed in the
> command spec) is used to set voltage level on older Dediprogs. SF100
> V6.0.0 and newer as well as all SF600 programmers do not support it.
>
> This patch renames the function and ad
On Mon, Aug 3, 2015 at 4:50 PM, David Woodhouse wrote:
> On Sun, 2015-08-02 at 15:09 -0700, David Hendricks wrote:
> > Tested with SF100 V:5.1.5 and SF600 V:7.1.4 (with subsequent patches)
>
> Where are these subsequent patches of which you speak? I have SF600
> testers who wou
ame usability as
> gerrit. I really mean it. We seriously should consider moving to a forum
> _if_ developers prefer forum interfaces to mail.
Would you also make the same recommendation for the coreboot mailing
list? I doubt that anybody on the CB mailing list would want to do
that.
>
Str. 19, 20354 Hamburg
> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
> Hamburg
> Geschäftsführer: Graham Law, Christine Elizabeth Flores
>
> ___
> flashrom mailing list
> flashrom@flashrom.org
> http://www.flashrom.org/mailman/listinfo/flashrom
>
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
___
flashrom mailing list
flashrom@flashrom.org
http://www.flashrom.org/mailman/listinfo/flashrom
Voilà!
https://chromium-review.googlesource.com/#/c/293924/
Freed of the shackles of Subversion and Patchwork, maybe now I can get some
real work done on this thing.
On Fri, Aug 14, 2015 at 2:09 AM, David Woodhouse
wrote:
> On Sun, 2015-08-02 at 15:09 -0700, David Hendricks wr
(I figured we could use a new thread to track overall progress)
A few more tweaks and now writes work, too:
https://chromium-review.googlesource.com/#/c/293889
On Sat, Aug 15, 2015 at 6:26 PM, David Hendricks
wrote:
> Voilà!
>
> https://chromium-review.googlesource.com/#/c/293924/
ff, you can try using an
external power supply (the usual warnings about possibly frying your board
apply).
>
> Thanks in advance,
> - Arpita
>
> --
> coreboot mailing list: coreb...@coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
--
David Hendri
> (verify) and -V (verbose).
> I also could live without the short argument, but that would break the
> "standard".
>
> Thanks in advance for your feedback!
>
> --
> Regards,
> Miklos Marton
>
>
> ___
&
the same workflow as coreboot (I actually kinda like
gerrit), as do others who filled out the Doodle poll a while back:
http://doodle.com/poll/p2dxtnksmsgwmzrq
But I won't object so switching to github. It will be an improvement over
the current workflow and ought to make the coreboot.org admin
ash or erase.
>
> Here is my output: http://paste.flashrom.org/view.php?id=2856
>
> Any ideas would be appreciated
>
> Thank you,
> Mike
>
> ___
> flashrom mailing list
> flashrom@flashrom.org
> http://www.flashrom.or
ead/write/erase on a GD25VQ41B.
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
___
flashrom mailing list
flashrom@flashrom.org
http://www.flashrom.org/mailman/listinfo/flashrom
se
allocated buffers whose length depends on whether we're using a 3- or
4-byte address.
I'll borrow some ideas from your patch as well to support the "4-byte
address only" chips.
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
__
e was not running 4.5 kernel
>
> coreboot machine:
>
> bios machine:
>
>
>
> --
> Arthur Heymans
>
> ___
> flashrom mailing list
> flashrom@flashrom.org
> https://www.flashrom.org/mailman/listinfo/flashrom
>
--
oelectrónica (CMNB) http://www.inti.gob.ar/
> Unidad Técnica Sistemas Inteligentes Av. General Paz 5445
> Tel: (+54 11) 4724 6300 ext. 6919 San Martín - B1650KNA
> FAX: (+54 11) 4754 5194 Buenos Aires * Argentina
>
>
>
>
>
> __
On Thu, Apr 21, 2016 at 1:41 PM, Salvador Eduardo Tropea <
salva...@inti.gob.ar> wrote:
> Hi David:
>
> Thanks for your comments.
>
>
> El 20/04/16 a las 20:42, David Hendricks escribió:
>
>> Hello Salvador,
>> Yes, this is a very useful feature - we'
Looks good to me.
Acked-by: David Hendricks
On Wed, May 4, 2016 at 4:37 AM, Nico Huber wrote:
> Signed-off-by: Nico Huber
> ---
> dediprog.c | 17 ++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/dediprog.c b/dediprog.c
> index 01
Looks good to me.
Acked-by: David Hendricks
On Wed, May 4, 2016 at 4:37 AM, Nico Huber wrote:
> We didn't check the total number of queued transfers in the inner most
> loop. Up to DEDIPROG_ASYNC_TRANSFERS - 1 invalid transfers could be
> queued therefore. So add another chec
om.
>
>
>
> Regards,
>
>
>
> Victor
>
>
>
>
>
> *From:* David Hendricks [mailto:dhend...@google.com]
> *Sent:* Sunday, May 8, 2016 7:43 PM
> *To:* Victor Lim
> *Cc:* Hatim Kanchwala ; flashrom ;
> Katherine (GigaDevice//US)
>
> *Subject:* Re: [fl
Hi Hatim,
Interesting approach. It seems to work well for pretty printing, though I
am curious how this will translate into ranges. Do you have an example for
translating status_register_layout structs to a range of bytes protected,
for example 0x00-0x1f?
___
Hi Hatim,
On Tue, May 31, 2016 at 3:25 AM, Hatim Kanchwala wrote:
> On Sunday 29 May 2016 02:40 PM, David Hendricks wrote:
>
>> Hi Hatim,
>> Interesting approach. It seems to work well for pretty printing, though
>> I am curious how this will translate into ranges. Do yo
644 spi4ba.h
>
> --
> 2.1.4
>
>
> _______
> flashrom mailing list
> flashrom@flashrom.org
> https://www.flashrom.org/mailman/listinfo/flashrom
>
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
___
flashrom mailing list
flashrom@flashrom.org
https://www.flashrom.org/mailman/listinfo/flashrom
On Fri, Jun 17, 2016 at 6:32 PM, Hatim Kanchwala wrote:
> Hi,
>
> Regarding block protection scheme, I am very glad to say I have had a
> breakthrough observation. After having sifted through around 90 datasheets,
> I was able to spot a pattern that majority of chips follow. GigaDevice and
> Winb
stion of
whether that would be better in another script or as a whitebox test (more
on that later...).
Here's the patch as of revision #14 on chromium.org's gerrit server:
https://chromium-review.googlesource.com/#/c/353912/
As in the gerrit message, Signed-off-by: David H
On Tue, Jul 5, 2016 at 12:11 AM, Stefan Tauner
wrote:
>
> I don't have time to look at the code right now
No rush - It's still in flux and the script itself is pretty monstrous
so I don't expect a thorough review any time soon. So far I've been
the only person to use it, but that will change soon
2/:
>From 8af85a07966b9486ea78c381c948aeb44bdcca7c Mon Sep 17 00:00:00 2001
From: David Hendricks
Date: Sun, 19 Jun 2016 12:53:22 -0700
Subject: [PATCH] WIP: New test script for flashrom
** work in progress **
Shiny new testing capabilities for Flashrom:
- Region awareness
- Remote testing
- Primary
kB, SPI) on ft2232_spi.
>> > Error: Image size (106976 B) doesn't match the flash chip's size
>> (8388608
>> > B)!
>> >
>> > Please let me know about the error.
>>
>> The current layout system will only limit the actually written area,
>
On Fri, Aug 5, 2016 at 10:49 PM, wrote:
> Hi,
>
> In the Laptop table the Aspire one is listed as BAD
> But as there are so many different aspire one models i wonder if ALL Aspire
> one models are BAD
>
> In my case i have the ZG5 model also known as AOA110 (512MB) and AOA150
> (1GB)
> These mode
82,7 @@
> void print_banner(void);
> void list_programmers_linebreak(int startcol, int cols, int paren);
> int selfcheck(void);
> -int doit(struct flashctx *flash, int force, const char *filename, int
> read_it, int write_it, int erase_it, int verify_it);
> +int doit(struct flashctx *flash, int force, const char *filename, int
> read_it, int write_it, int erase_it, int verify_it, int lock_it);
> int read_buf_from_file(unsigned char *buf, unsigned long size, const char
> *filename);
> int write_buf_to_file(const unsigned char *buf, unsigned long size, const
> char *filename);
>
> Index: spi.h
> ===
> --- spi.h (revision 1955)
> +++ spi.h (working copy)
> @@ -121,6 +121,11 @@
> #define JEDEC_RDSR_OUTSIZE 0x01
> #define JEDEC_RDSR_INSIZE 0x01
>
> +/* Read Status Register 2 */
> +#define JEDEC_RDSR20x35
> +#define JEDEC_RDSR2_OUTSIZE0x01
> +#define JEDEC_RDSR2_INSIZE 0x01
> +
> /* Status Register Bits */
> #define SPI_SR_WIP (0x01 << 0)
> #define SPI_SR_WEL (0x01 << 1)
>
> ___
> flashrom mailing list
> flashrom@flashrom.org
> https://www.flashrom.org/mailman/listinfo/flashrom
>
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
___
flashrom mailing list
flashrom@flashrom.org
https://www.flashrom.org/mailman/listinfo/flashrom
What exactly are you trying to do? How do you plan to use the CC3200? How
is the flash memory connected / accessed?
TI has some information about flashing it here:
http://processors.wiki.ti.com/index.php/CC31xx_%26_CC32xx_FTDI_Flashing
If you'd like, you can try adding support for the FTDI chip i
t?
> Regards
> -Chris
>
> ___
> flashrom mailing list
> flashrom@flashrom.org
> https://www.flashrom.org/mailman/listinfo/flashrom
>
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
___
flas
1 - 100 of 274 matches
Mail list logo
