[flashrom] Re: Release preparations

[David Hendricks]

On Mon, Mar 21, 2022 at 4:48 PM Thomas Heijligen  wrote:

> Beside from the documentation, the meson file currently only works for
> Linux and was never announced as official way to build flashrom.
>

The original reason for adding Meson was to support fwupd, a very important
use case which AFAIK is only intended to work with internal programmers for
in-system flashing in Linux.

Mission creep was not the intention, though Meson has evidently gained
popularity for other use cases. Notably, according to a comment in CB:61198
 Chromium now uses Meson
for all builds too. ChromeOS and fwupd are probably the biggest users of
flashrom when it comes to use of internal programmers. Also, as mentioned
earlier in the thread there are many distributions using Meson for
packaging.

It will be good to understand why they are going this route and if it's
better for the project in the long run. Personally I am more familiar with
Make, but even I can see that our Makefile is one that only a flashrom
developer could love.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Truncating flash for oversized image

[David Hendricks]

On Sun, Oct 31, 2021 at 10:10 AM Rob Shore  wrote:

> Hello!
>
> I've just discovered Flashrom as a way to use a Dediprog SPI programmer
> with MacOS, which is awesome.  I've got a bit of a strange question though:
>
> I've got a 1Mbit rom on a board, but the image I was given for it is for a
> 2Mbit part. The firmware itself in the raw image is < 1Mbit, but the file
> is still larger than my ROM. Flashrom won't run the flash saying "Error:
> Image size (262144 B) doesn't match the flash chip's size (131072 B)!",
> which is technically correct. Is there a way to force the flash, and just
> have the process end after the first 131072B, which would result in the
> data I need being on the ROM?
>
> Thanks, and looking forward to using this tool some more!
>

Try one of these:
- Use a layout file to tell flashrom exactly where you intend to write:
`echo "0:01 fw" > layout.txt && flashrom -p dediprog -l layout.txt
-i fw --noverify-all -w `
- Create a new file that is the appropriate size, for example using `dd
if= of= bs=1k count=128`

The size check is an intentional UI decision to help prevent writing an
incorrect file to the flash. A little bit of extra caution here is
typically much easier than recovering a bricked host.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Wiki Edit Access

[David Hendricks]

Hello Henry,
We're gradually moving documentation into the flashrom git
repository, giving us better versioning and eliminating the need to
maintain additional accounts. Rather than putting more effort into the wiki
which we hope to deprecate, perhaps you can you start a bbb text or
markdown file in the Documentation/ directory instead?

On Sat, Oct 31, 2020 at 10:14 AM  wrote:

> Hello. I would like an account on the wiki. I was going to edit the
> flashrom setup page on the bbb, and reference libreboot's documentation
> somewhere, as they have more up to date guides. Though flashrom's bbb
> guide is a good place to have links, and an older reference.
>
> Thanks,
>
> -
> This free account was provided by VFEmail.net - report spam to
> ab...@vfemail.net
>
> ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of
> the NSA's hands!
> $24.95 ONETIME Lifetime accounts with Privacy Features!
> 15GB disk! No bandwidth quotas!
> Commercial and Bulk Mail Options!
> ___
> flashrom mailing list -- flashrom@flashrom.org
> To unsubscribe send an email to flashrom-le...@flashrom.org
>
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: One build system to rule them all (Meson)

[David Hendricks]

Tossing in my $0.02

On Wed, Oct 28, 2020 at 4:19 PM Nico Huber  wrote:

> > Meson makes it possible to build fwupd as a subproject of fwupd, on
> > any architecture, on any distro, which means we can use libflashrom on
> > machines that don't ship a new enough distro version.
>
> That doesn't explain what doesn't work with the Makefile.
>

IIRC the addition of Meson was solely intended to enable an important user
of flashrom, fwupd.

Instead of pushing Meson as a full replacement for Make, perhaps we can
make the scope of Meson support explicit and clean up anything that doesn't
fit within that scope. Something like "build libflashrom with internal
programmer support for fwupd" might do. Anything beyond that must be done
in the Makefile.

Would that simplify things, or would there still be too much overhead by
having some limited support for meson?
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: S25FL127S-128k

[David Hendricks]

On Fri, Jul 10, 2020 at 1:33 PM ruckzuck--- via flashrom
 wrote:
> List only S25FL127S-64kB and S25FL127S-256k
> but not S25FL127S-128k why ? need flashrom a update ?

The suffix indicates the sector layout - 64kB "hybrid" sectors or
256kB uniform sectors.

> Probing for Spansion S25FL127S-64kB, 16384 kB: programmer_map_flash_region: 
> mapping S25FL127S-64kB from 0xff00 to 0x
> RDID returned 0x00 0x18 0x0e. RDID byte 0 parity violation. 
> probe_spi_rdid_generic: id1 0x00, id2 0x180e

That ID looks wrong for this chip, id1 should be 0x01 and id2 should
be 0x2018. Please check your connections, wire length (should be less
than 15cm), and use a conservative spispeed such as 2000 (for
2000KHz).
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Hardware Support

[David Hendricks]

> Is the Spansion S25FL127S 128-Mb supportet

Yes, however it's currently marked as "untested":
https://review.coreboot.org/cgit/flashrom.git/tree/flashchips.c#n15558
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Uprgrae SPIROM for Skylake-D platform

[David Hendricks]

Hello Hubert,

Thanks for your help, I finally able to upgrade BIOS and Intel ME with "-c
> "Opaque flash chip"" parameter.
>

I'm glad you got it working! For what it's worth you probably don't even
need to use the '-c' option when using hardware sequencing.


> But I can't find description of "Opaque flash chip" on flashrom wiki, may
> you please help to explain what is this parameter used for?
> Or guide us where can I find the document.
>

That is a great question. I took a stab at adding a brief explanation here:
https://review.coreboot.org/c/flashrom/+/42485. Let me know if that
explanation is helpful and feel free to chime in on that patch with
suggestions.

For more details, Stefan Tauner also wrote a blog post about it here:
https://blogs.coreboot.org/blog/2011/06/11/gsoc-2011-flashrom-part-1
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Do you have support for W25Q128FW and W25Q256.W?

[David Hendricks]

Hello Amin and Shekar,
It took a while, but I finally received the parts and was able to test them
out on a TInkerboard (RPi-like SBC using linux_spi programmer interface).
The W25Q128FW works in flashrom-v1.2. I also tested a W25Q256JW_DTR
operating in single data rate mode using the master branch and it worked
fine, however it needs the following patch applied:
https://review.coreboot.org/c/flashrom/+/42386

Since there are some Winbond people on this thread, perhaps they can offer
some guidance regarding chip naming. Is there a canonical list of Winbond
devices and their device IDs or some other guidance on naming and device
IDs?

On Wed, Jun 10, 2020 at 6:29 PM Wu, Amin  wrote:

> [AMD Official Use Only - Internal Distribution Only]
>
> Add Ryan. 
>
>
>
>
>
> BR
>
> AMIN
>
>
>
> *From:* Mike Banon 
> *Sent:* Monday, June 1, 2020 7:20 PM
> *To:* kcshe...@winbond.com
> *Cc:* jl...@winbond.com; yl...@winbond.com; Wu, Amin ;
> flashrom@flashrom.org; David Hendricks 
> *Subject:* Re: [flashrom] Re: Do you have support for W25Q128FW and
> W25Q256.W?
>
>
>
> [CAUTION: External Email]
>
> Dear Shekar,
>
>
>
> I hope that Dave and Amin (and other concerned people subscribed to a
> flashrom mailing list) will test the W25Q128FW and W25Q256.W parts as soon
> as possible and tell the results. Huge benefit of flashrom is that it is
> 100% open source (so much less likely to suffer from bad code quality and
> security issues), and flashrom supports the inexpensive programmers like
> CH341A which costs just $2. The commercial programmers are often expensive
> and have a proprietary closed source software, which is usually bloated,
> may have the security holes (sometimes the deliberate backdoors) and often
> are supported only by Windows OS, so they aren't an option for many people.
> Our goal is to ensure the flashrom's good function in as many use cases and
> for as many parts as possible - and hope that together, with your kind
> help, we will achieve it.
>
>
>
> Best regards,
>
> Mike Banon
>
>
>
> On Thu, May 28, 2020 at 4:27 AM kcshe...@winbond.com 
> wrote:
>
> Hi Dave and Amin,
>
>
>
> Just following up to ensure this programming issue was resolved at your
> end. Since the newer parts are supported on most commercial programmers and
> we did not hear back from you, we thought you have been able to program the
> parts successfully and have been able to use these parts on the AMD board.
> These parts are already supported on the AMD reference boards with Renoir.
> Thanks.
>
>
>
> Regards,
>
> Shekar
>
>
>
> *From:* US00 Krishna Shekar
> *Sent:* Friday, May 8, 2020 1:33 PM
> *To:* Mike Banon 
> *Cc:* US40 Jack Lee ; SM10 YLLi5 ;
> Wu, Amin ; flashrom@flashrom.org; David Hendricks <
> david.hendri...@gmail.com>
> *Subject:* RE: [flashrom] Re: Do you have support for W25Q128FW and
> W25Q256.W?
>
>
>
> Copying Dave Hendricks.
>
>
>
> *From:* US00 Krishna Shekar
> *Sent:* Friday, May 8, 2020 1:31 PM
> *To:* Mike Banon 
> *Cc:* US40 Jack Lee ; SM10 YLLi5 ;
> Wu, Amin ; flashrom@flashrom.org
> *Subject:* RE: [flashrom] Re: Do you have support for W25Q128FW and
> W25Q256.W?
>
>
>
> Resending this message with datasheet links below
>
>
>
>
> https://www.winbond.com/resource-files/W25Q256JW%20SPI%20RevG%2011252019%20Plus.pdf
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.winbond.com%2Fresource-files%2FW25Q256JW%2520SPI%2520RevG%252011252019%2520Plus.pdf=02%7C01%7CAmin.Wu%40amd.com%7C012fc4d0c7e8472508d8061dcd03%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637266073433707740=eZsoLx2%2FxTog0WpX5izBVBCZ9fDa%2B35lQncl4kOoPd8%3D=0>
>
> https://www.winbond.com/resource-files/W25Q128JW_RevD_03132020%20Plus.pdf
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.winbond.com%2Fresource-files%2FW25Q128JW_RevD_03132020%2520Plus.pdf=02%7C01%7CAmin.Wu%40amd.com%7C012fc4d0c7e8472508d8061dcd03%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637266073433707740=6JeVSOj5qSYRFKUhm%2B97fial5wS7ru17VufXpBwK9Z0%3D=0>
>
>
>
> *From:* US00 Krishna Shekar
> *Sent:* Thursday, May 7, 2020 12:14 PM
> *To:* Mike Banon 
> *Cc:* US40 Jack Lee ; SM10 YLLi5 ;
> Wu, Amin ; flashrom@flashrom.org
> *Subject:* RE: [flashrom] Re: Do you have support for W25Q128FW and
> W25Q256.W?
>
>
>
> W25Q128FW and W25Q256FW are older products and have been replaced by the
> latest W25Q128JW and W25Q256JW serial flash products. These newer
> datasheets are publicly available on the Winbond web site www.winbond.com
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.winbond.com%2F=02%7C01%7CAmin.Wu%40amd.com

[flashrom] Re: Uprgrae SPIROM for Skylake-D platform

[David Hendricks]

Hi Hubert,

> I have modified OPTYPE and OPMENU to support OPCODE 0x20 sector erase, but it 
> still failed.
> //===
> Running OPCODE 0x20 failed at address 0x00 (payload length was 0).
> spi_write_cmd failed during command execution at address 0x100
> //===

Opcode 0x20 takes a 3-byte address and 0x100 is a 4-byte address,
so this failure makes sense. You either need to use opcode 0x21 which
is 4KiB erase with 4-byte address, or use the extended address
register in the flash chip. I'm not sure how to do that (or if it's
possible) with software sequencing on Skylake-D though...

> I also try your suggestion and it also failed.
> //===
> The following protocols are supported: Parallel, LPC, FWH, 
> Programmer-specific.
> No EEPROM/flash device found.
> Note: flashrom can never write if the flash chip isn't found automatically.
> //===

I forgot to mention that for hardware sequencing you should either
omit the chip option or set it to "Opaque flash chip", i.e.
"./flashrom -p internal:boardmismatch=force,ich_spi_mode=hwseq -l
allregion.xml -i bios -w Lightning_R01.2_test.bin -c "Opaque flash
chip" -V -N"
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Uprgrae SPIROM for Skylake-D platform

[David Hendricks]

Hello Hubert,
There was some discussion about Skylake-D a few months ago:
https://www.mail-archive.com/flashrom@flashrom.org/msg14426.html .
There were some PCI IDs which were added
(https://review.coreboot.org/c/flashrom/+/39780) after flashrom-v1.2

The problems you describe are strange, indeed... Can send a verbose
log using `-V`? The W25Q256JVFIQ is also in the table already (as
W25Q256.V), so I'm curious why you needed to add another chip entry.

On Mon, Jun 1, 2020 at 5:10 PM HubertLin  wrote:
>
> Hi,
>
>
>
> I would like to use flashrom to upgrade BIOS on Skylake-D platform.
>
> I have done some work to unlock ME and fill W25Q256JVFIQ table in 
> flashschips.c.
>
> But there still have some opcode problem.
>
>
>
> Have you try flashrom on Skylake-D platform before?
>
> Is there any temporary patch for Skylake-D platform after v1.2 version.
>
> I would like to try it, may you please help me?
>
>
>
> The problem I meet as below,
>
> 1. ich_spi_send_command: Internal command size error for opcode 0xe9, got 
> writecnt=1, want >=4
>
> 2. Probing for Winbond W25Q256JVFIQ, 32768 kB: Invalid OPCODE 0x9f, will 
> not execut
>
> 3. Probing for Winbond W25Q256JVFIQ, 32768 kB: probe_spi_rdid_generic: 
> id1 0xf7, id
>
>
>
> Thank you
>
> BR, Hubert.lin
>
>
>
> ___
> flashrom mailing list -- flashrom@flashrom.org
> To unsubscribe send an email to flashrom-le...@flashrom.org
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Current state of meson

[David Hendricks]

> Well, as I stated previously, flashrom built with meson results in the
> `-o` option not working at all. When helping others via IRC, we
> recommend fetching flashrom logs using that option so that no messages
> get lost, so not being able to rely on it is rather inconvenient.

Ouch... Yeah, that shouldn't happen.

> I can see [1] that you have two changes on gerrit, one of which is
> currently not submittable due to merge conflicts and has not been
> touched in two months.

To be fair, that's not a lot of time when we're talking about flashrom...

> Are there any
> future plans for meson, such as making Jenkins build-test it? Edward
> O'Callaghan is working on unit testing [2], and it would be great if
> Jenkins could actually run these tests alongside the usual build
> tests. There isn't a thing such as too much coverage, or is there? :-P

Patrick already chimed in, w.r.t. Jenkins. Automating some QA has been
on my todo list for a while, and I'm in between jobs at the moment so
I'll finally have a bit of time to work on it :-)

Overall I'd like to keep meson support working for fwupd. Like
ChromeOS it's a valuable user that provides development, hardware
support, and testing on realworld hardware at the cost of a few
relatively minor bumps. It's better to work with those communities
rather than them forking or reinventing flashrom.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Do you have support for W25Q128FW and W25Q256.W?

[David Hendricks]

Hi Amin,
Please note that the W25Q128FW is a 1.8V chip, while Raspberry PI IOs are
3.3V.

For Dediprog, pass in the `voltage` parameter, e.g. `flashrom -p
dediprog:voltage=1.8 -r foo.bin`

Also, as Mike mentioned it will help if we know the version of flashrom
which you are trying to use. Some distributions provide very old versions.

On Wed, Apr 22, 2020 at 1:33 AM Wu, Amin  wrote:

> [AMD Official Use Only - Internal Distribution Only]
>
>
>
> Hi David Hendricks,
>
> “No EEPROM/flash device found” pop after I added below code to
> flashchips.c and flashchips.h to install flashrom in Raspberry 4B.
>
> pi@raspberrypi:~ $ sudo flashrom -p
> linux_spi:dev=/dev/spidev0.0,spispeed=4096
>
> flashrom  on Linux 4.19.57-v7l+ (armv7l)
>
> flashrom is free software, get the source code at https://flashrom.org
>
>
>
> Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
>
> No EEPROM/flash device found.
>
> Note: flashrom can never write if the flash chip isn't found automatically.
>
>
>
> Do you have any suggestions? Thanks 
>
>
>
> flashchips.h
>
> #define WINBOND_NEX_W25Q128FW 0xef6018 /*W25Q128FW */
>
>
>
> flashchips.c
>
>  {
>
>   .vendor= "Winbond",
>
>   .name   = "W25Q128FW",
>
>   .bustype  = BUS_SPI,
>
>   .manufacture_id = WINBOND_NEX_ID,
>
>   .model_id= WINBOND_NEX_W25Q128FW,
>
>   .total_size   = 16384,
>
>   .page_size   = 256,
>
>   /* supports SFDP */
>
>   /* OTP: 1024B total, 256B reserved; read 0x48; write
> 0x42, erase 0x44, read ID 0x4B */
>
>   .feature_bits   = FEATURE_WRSR_WREN | FEATURE_OTP |
> FEATURE_QPI,
>
>   .tested  = TEST_OK_PREW,
>
>   .probe  = probe_spi_rdid,
>
>   .probe_timing = TIMING_ZERO,
>
>   .block_erasers =
>
>   {
>
>   {
>
>.eraseblocks = { {4 * 1024, 4096} },
>
>.block_erase = spi_block_erase_20,
>
>   }, {
>
>.eraseblocks = { {32 * 1024, 512} },
>
>.block_erase = spi_block_erase_52,
>
>   }, {
>
>.eraseblocks = { {64 * 1024, 256} },
>
>.block_erase = spi_block_erase_d8,
>
>   }, {
>
>.eraseblocks = { {16 * 1024 * 1024, 1}
> },
>
>.block_erase = spi_block_erase_60,
>
>   }, {
>
>.eraseblocks = { {16 * 1024 * 1024, 1}
> },
>
>.block_erase = spi_block_erase_c7,
>
>   }
>
>   },
>
>   .printlock = spi_prettyprint_status_register_plain, /*
> TODO: improve */
>
>       .unlock = spi_disable_blockprotect,
>
>   .write= spi_chip_write_256,
>
>   .read = spi_chip_read,
>
>   .voltage   = {1650, 1950},
>
>  },
>
>
>
>
>
> BR
>
> AMIN
>
> *From:* Wu, Amin
> *Sent:* Wednesday, April 22, 2020 2:55 PM
> *To:* 'David Hendricks' ; '
> mkt_onl...@winbond.com' 
> *Cc:* 'flashrom@flashrom.org' 
> *Subject:* RE: [flashrom] Do you have support for W25Q128FW and W25Q256.W?
>
>
>
> [AMD Official Use Only - Internal Distribution Only]
>
>
>
> Hi Winbond,
>
> Do you have a plan to support flash bios for W25Q128FW and W25Q256.W via
> flashrom in Raspberry?
>
>
>
>
>
> BR
>
> AMIN
>
> *From:* Wu, Amin
> *Sent:* Tuesday, April 21, 2020 1:32 PM
> *To:* David Hendricks 
> *Cc:* flashrom@flashrom.org
> *Subject:* RE: [flashrom] Do you have support for W25Q128FW and W25Q256.W?
>
>
>
> [AMD Official Use Only - Internal Distribution Only]
>
>
>
> Hi David, Hendricks,
>
> Can you share the flashrom link to download which support W25Q128FW and
> W25Q256.W?
>
> Now I used DediProg to flash these bioschip. I can try with raspberry to
> flash when I get the flashrom from you. 
>
> It is great help for me if flashrom support W25Q128FW and W25Q256.W. I
> tried edit flashchip.c and flashchip.h, but flash fa

[flashrom] Re: Do you have support for W25Q128FW and W25Q256.W?

[David Hendricks]

Yes and yes :-)

On Mon, Apr 20, 2020 at 10:05 PM Wu, Amin  wrote:

> [AMD Official Use Only - Internal Distribution Only]
>
> Hi
>
> Do you have support for W25Q128FW and W25Q256.W? Thanks
>
>
>
>
>
> BR
>
> AMIN
> ___
> flashrom mailing list -- flashrom@flashrom.org
> To unsubscribe send an email to flashrom-le...@flashrom.org
>
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Flashrom tool failed on the Intel Bakerville platform(CPU:SKY-D)

[David Hendricks]

(Resending to the mailing list)

From: David Hendricks 
Sent: Monday, March 2, 2020 2:50:24 PM
To: flashrom@flashrom.org ; Ocean Huang 

Subject: Re: [flashrom] Flashrom tool failed on the Intel Bakerville 
platform(CPU:SKY-D)

Hello Ocean,
At the moment we do not support updating the Intel ME region. You may target 
other regions described by the flash descriptor using the --ifd option, for 
example `flashrom -p internal --ifd -i bios --noverify-all -w CBR.1.00.01.bin`.

Depending on your use case, another option is to modify the flash descriptor to 
allow the host to write to the ME region. However Intel recommends locking the 
ME region so that reads and writes to the ME region from the host are not 
allowed.

Please also see https://flashrom.org/ME#Suggested_workarounds for additional 
guidance.

From: Ocean Huang via flashrom 
Sent: Wednesday, February 26, 2020 5:20 AM
To: flashrom@flashrom.org 
Subject: [flashrom] Flashrom tool failed on the Intel Bakerville 
platform(CPU:SKY-D)

Hi Vendor:

We have some issue when using flashrom tool update BIOS & ME firmware on the 
Intel Bakeville platform, you can refer to the below error log, could you 
please help give some comments or suggestions about this issue?

[root@localhost flashrom-v1.1]# ./flashrom  -p internal -w CBR.1.00.01.bin
flashrom v1.1 on Linux 3.10.0-957.el7.x86_64 (x86_64)
flashrom is free software, get the source code at 
https://flashrom.org<https://urldefense.proofpoint.com/v2/url?u=https-3A__flashrom.org=DwMFaQ=5VD0RTtNlTh3ycd41b3MUw=4-bAjA7rj5_lsAnGYQCM_w=532SYzVno7CxakMNFHC-ELomxuPqcWKaBcM1kqjV6qc=lw-AUImht5ouHueP-_e7nSmbqEDP4RPihF9Y8o5_70A=>

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found chipset "Intel C620 Series Chipset Supersku".
This chipset is marked as untested. If you are using an up-to-date version
of flashrom *and* were (not) able to successfully update your firmware with it,
then please email a report to 
flashrom@flashrom.org<mailto:flashrom@flashrom.org> including a verbose (-V) 
log.
Thank you!
Enabling flash write... SPI Configuration is locked down.
FREG2: Management Engine region (0x3000-0x00a15fff) is locked.
Not all flash regions are freely accessible by flashrom. This is most likely
due to an active ME. Please see 
https://flashrom.org/ME<https://urldefense.proofpoint.com/v2/url?u=https-3A__flashrom.org_ME=DwMFaQ=5VD0RTtNlTh3ycd41b3MUw=4-bAjA7rj5_lsAnGYQCM_w=532SYzVno7CxakMNFHC-ELomxuPqcWKaBcM1kqjV6qc=X8yqTjX2TTNy16DkSDCTNXyOc8FAG1Yfn126AxBHqVI=>
 for details.
At least some flash regions are read protected. You have to use a flash
layout and include only accessible regions. For write operations, you'll
additionally need the --noverify-all switch. See manpage for more details.
Enabling hardware sequencing because some important opcode is locked.
OK.
Found Programmer flash chip "Opaque flash chip" (32768 kB, Programmer-specific) 
mapped at physical address 0x.
Reading old flash chip contents... Transaction error between offset 0x3000 
and 0x303f (= 0x3000 + 63)!
FAILED.
[root@localhost flashrom-v1.1]# ./flashrom  -p internal -r 111.bin --ifd -i bios
flashrom v1.1 on Linux 3.10.0-957.el7.x86_64 (x86_64)
flashrom is free software, get the source code at 
https://flashrom.org<https://urldefense.proofpoint.com/v2/url?u=https-3A__flashrom.org=DwMFaQ=5VD0RTtNlTh3ycd41b3MUw=4-bAjA7rj5_lsAnGYQCM_w=532SYzVno7CxakMNFHC-ELomxuPqcWKaBcM1kqjV6qc=lw-AUImht5ouHueP-_e7nSmbqEDP4RPihF9Y8o5_70A=>

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found chipset "Intel C620 Series Chipset Supersku".
This chipset is marked as untested. If you are using an up-to-date version
of flashrom *and* were (not) able to successfully update your firmware with it,
then please email a report to 
flashrom@flashrom.org<mailto:flashrom@flashrom.org> including a verbose (-V) 
log.
Thank you!
Enabling flash write... SPI Configuration is locked down.
FREG2: Management Engine region (0x3000-0x00a15fff) is locked.
Not all flash regions are freely accessible by flashrom. This is most likely
due to an active ME. Please see 
https://flashrom.org/ME<https://urldefense.proofpoint.com/v2/url?u=https-3A__flashrom.org_ME=DwMFaQ=5VD0RTtNlTh3ycd41b3MUw=4-bAjA7rj5_lsAnGYQCM_w=532SYzVno7CxakMNFHC-ELomxuPqcWKaBcM1kqjV6qc=X8yqTjX2TTNy16DkSDCTNXyOc8FAG1Yfn126AxBHqVI=>
 for details.
At least some flash regions are read protected. You have to use a flash
layout and include only accessible regions. For write operations, you'll
additionally need the --noverify-all switch. See manpage for more details.
Enabling hardware sequencing because some important opcode is locked.
OK.
Found Programmer flash chip "Opaque flash chip" (32768 kB, Programmer-specific) 
mapped at physical address 0x.
Reading ich descriptor... done.
Using region: "bios&q

[flashrom] flashrom-v1.2 tagged and released

[David Hendricks]

Hello everyone,
Flashrom v1.2 is out. A tarball has been added to
download.flashrom.org/releases, and a new branch (1.2.x) and tag
(v1.2) have been pushed.

This release was rushed a bit so that we have a release that includes
numerous build fixes that have been merged since v1.1. Fedora's build
system started to encounter compilation issues that needed to be
addressed for their upcoming release, so that became our canary in the
coal mine this time around.

Other highlights:
- Meson support (hello fwupd!)
- Layout improvements/fixes and many, many code cleanups.
- New chips: MX25U25635F, MX25L51245G, GD25Q256D, M95M02-A125,
N25Q/MT25Q variants, W25Q128JW_DTR, AT25SF321, S25FL512S
- New programmers: National Instruments USB-845x, Tin Can Tools
Flyswatter/Flyswatter 2, STLINK V3, more Intel PCHs (Apollo Lake,
Cannon Lake variants, Ice Lake U)
- Reduced dependency on libusb0
- Syntax: Added --flash-name and --flash-size arguments to print
information about the flash chip

Please report issues, and as always thanks to all who have contributed.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: "pcidev.c: Factor out pcidev_validate() into pure fn" broke PCI programmers

[David Hendricks]

> I am working locally on building out a test infrastructure that uses EM100's 
> to emulate flashchips and a bunch of different Chromebooks to exercise 
> flashrom more. The idea I have is to turn this into a upstream CI bot somehow 
> but I have to work out how that would work in practice and if it is 
> sufficient to use EM100's to test most things? The problem with QEMU is that 
> only a limited chipset range is there so I guess that would only exercise the 
> core flashrom logic itself? I am open to more ideas on what we need as a 
> community setup to help catch these things better than having breakage merged 
> which is less than ideal!

Great to see more interest in this :-)

EM100 testing would be great to help test on all the various chipsets
you use, and save some time too. Though I'm wondering if the EM100
really helps much in your case. For one, the EM100 doesn't emulate
write protection capabilities AFAIK (maybe I'm wrong?). Also, if
you're worried about wearing down NOR flash parts, you could test
erase/writes on a small region (maybe 8 blocks at a time selected at
random, or something to that effect). And if there are flash chips in
Chromebooks that wear out faster than expected then that's probably
something you want to know ;-)

It would be nice to see dummyflasher used more. Some simple sanity
check could even be made into part of the git presubmit hooks.

I also attempted to port the ginormous test_v2.sh script to upstream a
while back, but it never made it in:
https://review.coreboot.org/c/flashrom/+/23025 (documentation is still
at https://goo.gl/qNwdmm). It's kind of the brute force approach and
got unwieldy, but IMO with some work it can still be useful to have
upstream especially if there's some easier to access documentation to
help users with it.

There are also some opportunities for whitebox testing since flashrom
knows all about block erasers and write protections for the
chip/programmer being used. I hacked up something a while back to
demonstrate this with NOR flash write protections:
https://chromium-review.googlesource.com/c/chromiumos/third_party/flashrom/+/386428

Lots of fun and exciting things to do here for whoever has time...
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Stepping Down as Flashrom Maintainer/Developer

[David Hendricks]

Hi Nico,
Thanks again for all the work you've done! As others have said it's
much appreciated.

I hope you'll find time to stay engaged. One thing I believe is
frustrating to all of us is the state of paralysis that might be (at
least partially) solved with better tools and automation. For example,
I'd like to prioritize getting your manibuilder patches in, and I
think things like the clang-format (CB:38208) can help reduce reviewer
burden as well and make it easier for newcomers to produce
commit-ready patches. We can also prioritize documentation (and move
it into Git?) since I think a lot of time is spent on IRC and
elsewhere helping people out with the same problems over and over
again.

> Hard to put a name here when it feels like deciding who is to be
> burned out next :)

No kidding! As CDH noted it's hard and not always rewarding.

We've never really had a BDFL, and most contributions are for specific
hardware that a developer is concerned with so there's not much
incentive to stay on the project for a long time.

> David is definitely the next most active maintainer
> and he knows his way around the project. If it wasn't for his support,
> I wouldn't have done the job in the first place. However, I fear he is
> as busy as any other senior developer.

Indeed, I've been mostly absent for the last few months due to time
constraints. Most of my recent activity has been focused on catching
up on reviews (usually small ones, but larger ones too if I have time
on a weekend or something) and responding to issues reported on
Github.

I definitely plan to remain involved and am happy to help move things
along wherever I can, but can't make a huge time commitment.

> I don't know the exact
> cause for the fork (maybe it was the lack of resources or the will to
> spend them) but I fear it might have rooted and not vanished.

I can help shed some light on this. The original cause for the fork
was due to EC vendors who didn't want certain things in publicly
visible code. We eventually got all that code published - it turns out
there's nothing really valuable from an IP perspective as far as
flashrom functionality is concerned. Eventually Chromebooks started
using their own open-source EC code which eliminated the problem, but
by then things had diverged quite significantly and the project was in
a similar state as it is now.

There have been efforts to minimize divergence, but they always ended
up in a stalemate and patches were left to bitrot on Gerrit. Nobody's
fault per se, it's just how things have played out as priorities and
people have changed over the years.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: ST 95XXX chips

[David Hendricks]

Hello,
Thanks for the PR (https://github.com/flashrom/flashrom/pull/84). I
actually started to review this a long time ago, but apparently never
finished :-/ My bad.

The patch has a few merge conflicts, lots of dead code, and makes
changes that appear unrelated to ST 95XXX support. Please resolve the
merge conflicts and clean up the patch, and send another PR. Or better
yet, send directly to review.coreboot.org which is where upstream
review happens:
https://www.flashrom.org/Development_Guidelines#Sending_a_patch

On Sun, Dec 1, 2019 at 12:18 PM Николай Николаев  wrote:
>
> Hello
> My pull request has already been created that had occurred several months 
> previously. I added support for ST 95XXX chips . The following chipsets have 
> been successfully tested for read, erase and write operations: ST [ 95080, 
> 95160, 95320, 95640, 95128, 95256 ]. I would like to discuss a new features.
> Maybe someone in the community will spent a bit of time and review my pull 
> request. Don't worry about the conflicting files. The part of the code has 
> already been merged into effect.
>
> I'm open-minded and ready.
>
>
> ___
> flashrom mailing list -- flashrom@flashrom.org
> To unsubscribe send an email to flashrom-le...@flashrom.org
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: GitHub PRs

[David Hendricks]

On Sat, Nov 30, 2019 at 7:37 AM Angel Pons  wrote:
>
> Hi everyone,
>
> On Sat, Nov 30, 2019, 14:15 Nico Huber  wrote:
>>
>> Hi all,
>>
>> the GitHub PR topic popped up from time to time on IRC in the past but
>> it seems we never discussed it here or came to any conclusion that led
>> to action.
>>
>> When we switched to Git, we wrote down three ways to send patches [1]:
>>
>>   o Via our mailing list
>>
>>   o Via gerrit on coreboot.org
>>
>>   o Via pull request on flashrom's github mirror
>
>
> If the repo on github is a mirror which tracks the "master repo" in coreboot, 
> it does not make sense to use pull requests, as they would land on the mirror.

Correct - The flow is to move the PR to Gerrit, get it merged, and
then it shows up in the mirror. One nice thing about Github is that it
is smart enough to automatically close PRs that get merged this way.

>
> I have never reviewed on the mailing list, so I don't know how tedious it is. 
> In any case, it's easier to move mailing list patches to gerrit than pull 
> requests.
>
>> Now, roughly 2 years later, some PRs have been merged, but some, even
>> smaller ones, were left unanswered. We also never set a clear process
>> how to move things to Gerrit.

For what it's worth, here are the steps I use to manually move things to Gerrit:
# Clone flashrom from upstream and add the github mirror as a remote:
git clone ssh://@review.coreboot.org:29418/flashrom.git
cd flashrom
git remote add -f github g...@github.com:flashrom/flashrom.git

# Create a new local branch with the PR applied
git fetch github pull//head:
git checkout 

# Push it to gerrit with a topic indicating what PR it's from
git push origin HEAD:refs/for/master%topic=

> Agreed. Should we stop accepting pull requests, it would be good to document 
> (or link to) the procedure to create a change on gerrit.

I think it's useful to have a Github mirror since that's where a lot
of developers are. However, we should make presubmit hooks more strict
to increase likelihood of a patch getting merged with minimal feedback
needed from reviewers. This is true with Gerrit as well, of course,
but especially Github since a lot of one-time contributors send
patches that way.

Another way which Github is useful is for reporting issues, asking for
a release, etc. AFAIK the closest thing we have for flashrom is the
mailing list, but of course that's far less convenient for most people
who have an account on Github and can easily open an issue that way.

>
>> While I still don't object to reviewing on Github, if somebody wants
>> to do so, it has some downsides: no global overview of pending patches,
>> no build testing before moving things to Gerrit, the overhead of moving
>> things, ofc (IMHO, reviewing on Github is also much harder, maybe I'm
>> just Gerrit spoiled).
>
>
> IMHO, handling the merging of pull requests alone is cumbersome enough to 
> outweigh the benefits of allowing pull requests.

I prefer the Gerrit UI for the reasons Nico cited and also the
subjective feel of it. That said, I don't think that handling PRs and
merging them is a big deal, so long as they're simple and don't need a
lot of back-and-forth.

>
>> Especially the build-test integration makes it hard for me to come up
>> with a reasonable process. Hence, I suggest that we just stop accepting
>> PRs on GitHub and tell contributors to push to Gerrit directly. This
>> may be more work for the contributors and might even scare some away;
>> but I don't see any lack of contributions to this project rather a lack
>> of reviewer resources. So we should make reviewing as easy as possible,
>> IMO.
>
>
> I completely agree.

Seems a bit extreme IMO, but I'm not totally opposed to it if PRs are
deemed a big enough nuisance. Perhaps we can start by allowing PRs,
but say that anything complex will need the author to submit directly
to Gerrit? I think people who want to make multiple, complex changes
will be OK with that and it keeps things easy for one-time
contributors who just want to add a flash chip or fix a small
compilation issue or something. If we don't get the desired result
then we can try disabling PRs entirely.

In any case, we should start by documenting the process to send a
patch to review.coreboot.org using Github credentials. I've added a
section for this at https://www.flashrom.org/Development_Guidelines.
For now I just wrote what I described here, but if we disable PRs
entirely we can update that section to reflect that.

We should also figure out a way to make info relevant to Github users
more obvious. Currently Github displays our generic README by default,
I'm not sure if there is a way to change that without removing the
README from the repository. I also updated the heading on Github to
point straight toward the development guidelines.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Flashrom using slowest item from block_erasers list

[David Hendricks]

Hi Ryan,

> What would be the best solution here? Would it make sense to submit this 
> change for this particular chip? I understand there may also be a speed/wear 
> tradeoff.
>
> I am also interested in the more general case. Do larger erase sizes tend to 
> reprogram a chip faster? If so, why does flashrom not always use the larger 
> sizes?

Flashrom knows the current contents of the flash chip and the new
contents that will be programmed. So ideally it should
opportunistically use the largest block erase size for any given
chunk, whether it's 4KB or 64KB or the entire chip. The work just
needs to be done to implement that.

Of course things are never quite that simple and we must also check
that it doesn't interfere with chip or programmer enforced write
protection. For example if the chip has certain block ranges
protected, or in the usual Intel platform case with the flash
descriptor regions and permissions (and opmenu stuff).
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Multiple flash chip defs on one chip

[David Hendricks]

Hi Christopher,
This means that Macronix reuses chip IDs for multiple chips with different
capabilities (hence why there are multiple chip entries). It's very
frustrating. I recommend avoiding Macronix and using a different flash chip
vendor if you can.

On Tue, Nov 19, 2019 at 9:45 PM OMGdaDPS 
wrote:

> I wouldalso like to report that i have found a few flash chips, that when
> read or attempted do perform any action on, it tells me that there are
> multiple chips found:
>
> `dps@vulcan:~$ sudo flashrom  --programmer ch341a_spi -r backup.bin
> flashrom  on Linux 5.0.0-36-generic (x86_64)
> flashrom is free software, get the source code at https://flashrom.org
>
> Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
> Found Macronix flash chip "MX25L6405" (8192 kB, SPI) on ch341a_spi.
> Found Macronix flash chip "MX25L6405D" (8192 kB, SPI) on ch341a_spi.
> Found Macronix flash chip "MX25L6406E/MX25L6408E" (8192 kB, SPI) on
> ch341a_spi.
> Found Macronix flash chip
> "MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F" (8192 kB, SPI) on
> ch341a_spi.
> Multiple flash chip definitions match the detected chip(s): "MX25L6405",
> "MX25L6405D", "MX25L6406E/MX25L6408E",
> "MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F"
> Please specify which chip definition to use with the -c  option`
>
>
> what does this mean?
> [image: Sent from Mailspring]
> ___
> flashrom mailing list -- flashrom@flashrom.org
> To unsubscribe send an email to flashrom-le...@flashrom.org
>
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Info

[David Hendricks]

On Sat, Oct 5, 2019 at 8:31 PM Patrick Rogers
 wrote:
>
> Hello Ray,
>
> The hardware that you would need is something called a BIOS programmer.
> Usually they use a USB port and might be found cheaply online. Flashrom
> has a list of supported programmers:
>
> https://www.flashrom.org/Supported_hardware#External_flashers.2Fprogrammers
>
> My suggestion would be to purchase a Raspberry Pi, which is a cheap
> Linux computer that has builtin hardware support needed to flash ROMs.
> It might be less trouble and more easier to get. The Pi, microSD card,
> case, breadboard jumper cables and breadboard (for easier seating of
> BIOS chip) may cost around $50 USD.

The Raspberry Pi certainly makes a nice, fast flasher, however the IO
pins are connected to 3.3V rails so you'll need to be careful to use
it with 3.3V flash chips only (not 1.8V).
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Kaby Lake R - not detecting chip & size correctly

[David Hendricks]

Hi Rafael,

> So would the  solution be to flash the larger chip with some external tool 
> like a Raspberry Pi and adjust the size of the CBFS in coreboot (can do both, 
> shouldn't be a problem).

That's part of it. However, you still need to update the flash
descriptor contents (bottom 4KiB of the ROM image) so that it
describes the larger flash chip you wish to use. Details about the
flash descriptor layout can be found in "SPI Programming Guide"
documents from Intel which may require registering an account on
developer.intel.com and agreeing to their terms.

> I guess I'll need some other payload with a SPI driver to access the 
> remaining space (u-boot? No luck there so far..) right?

The limitation that Nico describes is due to the way the SPI
controller works on modern Intel platforms. Software/firmware running
on the CPU will not be able to access any ROM region that is not
defined with appropriate parameters in the flash descriptor.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: flashrom support for Atmel/Adesto AT25SF041

[David Hendricks]

Hi Jens,
Thanks for the patch, it looks good. There's one important thing missing
though: https://www.flashrom.org/Development_Guidelines#Sign-off_Procedure.

Once we have your "sign-off" we can go forward with merging it.

On Fri, May 24, 2019 at 3:06 PM Jens Gollasch  wrote:

> Hi folks,
>
> I tried to flash some new Atmel/Adesto SPI 512k flash chips with
> flashrom0.9.9-rc1-r1942 on Linux 4.15.0-50-generic (x86_64) (from
> repositories in linux mint 18.3) and flashrom v1.0.1 on Linux
> 4.15.0-50-generic (x86_64) (compiled it from source).
>
>
> Both versions could not find the chip:
>
> -
> Found Atmel flash chip "unknown Atmel SPI chip" (0 kB, SPI).
> This flash part has status NOT WORKING for operations: PROBE READ ERASE
> WRITE
>
> -
>
>
> The IDs of this flash chip are:
>
> Manufacturer ID: 1f
> Memory Type: 8401
>
> So I checked the datasheet and added support in flashchips.h at line 154:
>
> #define ATMEL_AT25SF041 0x8401  /* Adesto */
>
> and in flashchips.c at line 2178:
>
>  {
>  .vendor= "Atmel",
>  .name= "AT25SF041",
>  .bustype= BUS_SPI,
>  .manufacture_id= ATMEL_ID,
>  .model_id= ATMEL_AT25SF041,
>  .total_size= 512,
>  .page_size= 256,
>  .feature_bits= FEATURE_WRSR_WREN,
>  .tested= TEST_OK_PREW,
>  .probe= probe_spi_rdid,
>  .probe_timing= TIMING_ZERO,
>  .block_erasers=
>  {
>  {
>  .eraseblocks = { {4 * 1024, 128} },
>  .block_erase = spi_block_erase_20,
>  }, {
>  .eraseblocks = { {32 * 1024, 16} },
>  .block_erase = spi_block_erase_52,
>  }, {
>  .eraseblocks = { {64 * 1024, 8} },
>  .block_erase = spi_block_erase_d8,
>  }, {
>  .eraseblocks = { {512 * 1024, 1} },
>  .block_erase = spi_block_erase_60,
>  }, {
>  .eraseblocks = { {512 * 1024, 1} },
>  .block_erase = spi_block_erase_c7,
>  }
>  },
>  .printlock= spi_prettyprint_status_register_at25df,
>  .unlock= spi_disable_blockprotect_at2x_global_unprotect,
>  .write= spi_chip_write_256,
>  .read= spi_chip_read,
>  .voltage= {2700, 3600}, /* 2.3-3.6V & 2.7-3.6V models
> available */
>
>  },
>
>
> Compiled, Works perfect!
> So you can add support for this beast in your next version.
>
>
> Bye,
> Jens
>
> ___
> flashrom mailing list -- flashrom@flashrom.org
> To unsubscribe send an email to flashrom-le...@flashrom.org
>
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Intel Atom E3845

[David Hendricks]

Hi Karthik

I'm working on Opencellular 
(https://code.fb.com/connectivity/introducing-opencellular-an-open-source-wireless-access-platform/)
 which is based on Intel Atom E3845. I have built the coreboot image and would 
like to flash onto the Opencellular board. Could you tell how to flash only 
onto the BIOS region using Flashrom?


Try the following command: flashrom -p internal --noverify-all --ifd -i bios -w 
bios.bin


I recommend adding -V to the command the first time you use it - That will 
increase verbosity which can help with troubleshooting if needed.



From: karthikm...@gmail.com 
Sent: Monday, May 6, 2019 11:45:11 PM
To: flashrom@flashrom.org
Subject: [flashrom] Intel Atom E3845

Hello,

I'm working on Opencellular 
(https://code.fb.com/connectivity/introducing-opencellular-an-open-source-wireless-access-platform/)
 which is based on Intel Atom E3845. I have built the coreboot image and would 
like to flash onto the Opencellular board. Could you tell how to flash only 
onto the BIOS region using Flashrom?

Thank you, in advance.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: patch for allowing the use of the SOCKET target of the SF600

[David Hendricks]

Looks good to me. Thanks!

FWIW, I actually wrote a patch that is very similar, but never quite
completed it: https://review.coreboot.org/c/flashrom/+/19673

So at least we know your patch is already tested ;-)

On Mon, Jan 14, 2019 at 5:02 AM Florian Kaiser 
wrote:

> Hello Nico,
>
> thanks for your feedback! I attached an improved patch that hopefully
> solves
> these issues.
>
> Thanks a lot!
>
> Florian
>
> Am Sonntag, 23. Dezember 2018, 14:34:16 schrieb Nico Huber:
> > Hello Florian,
> >
> > thanks for your patch, I've commented on it inline.
> >
> > On 10.12.18 11:05, Florian Kaiser wrote:
> > > I am using this patch for a while now and I did not encounter any
> > > problems. I am not sure if this was/is not supported. Is there any
> reason
> > > why this is not supported?
> >
> > No reason beside that nobody cared about it yet, I guess.
> >
> > Nico
> >
> > > From 5df0b1ff7bb95f4384c98727a56a03660dde6aaa Mon Sep 17 00:00:00 2001
> > > From: Florian Kaiser 
> > > Date: Tue, 31 Jul 2018 13:42:22 +0200
> > > Subject: [PATCH] dediprog: allow the use of the programming target
> > > "socket".
> > >
> > > Change-Id: I8c5120ce2151138093be0f27951916ec7f725574
> > > Signed-off-by: Florian Kaiser 
> > > ---
> > >
> > >  dediprog.c  | 6 +-
> > >  flashrom.8.tmpl | 5 +++--
> > >  2 files changed, 8 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/dediprog.c b/dediprog.c
> > > index 72818ea..0eb84ec 100644
> > > --- a/dediprog.c
> > > +++ b/dediprog.c
> > > @@ -1028,7 +1028,7 @@ int dediprog_init(void)
> > >
> > > free(target_str);
> > > return 1;
> > >
> > > }
> > >
> > > -   if (target < 1 || target > 2) {
> > > +   if (target < 1 || target > 3) {
> > >
> > > msg_perr("Error: Value for 'target' is out of
> range.\n");
> > > free(target_str);
> > > return 1;
> > >
> > > @@ -1047,6 +1047,10 @@ int dediprog_init(void)
> > >
> > > msg_pinfo("Using target %s.\n",
> "FLASH_TYPE_APPLICATION_FLASH_2");
> > > target = FLASH_TYPE_APPLICATION_FLASH_2;
> > > break;
> > >
> > > +   case 3:
> > > +   msg_pinfo("Using target %s.\n",
> "FLASH_TYPE_SOCKET");
> > > +   target = FLASH_TYPE_SOCKET;
> > > +   break;
> >
> > This makes a flaw in set_target_flash() obvious now. Not all programmers
> > have a socket. I just checked set_target_flash() silently fails with an
> > SF 100. So we should check for compatibility there or at the calling
> > site.
> >
> > > default:
> > > break;
> > >
> > > }
> > >
> > > diff --git a/flashrom.8.tmpl b/flashrom.8.tmpl
> > > index c557af7..04fd1c8 100644
> > > --- a/flashrom.8.tmpl
> > > +++ b/flashrom.8.tmpl
> > > @@ -946,8 +946,9 @@ parameter specifies which target chip should be
> used.
> > > Syntax is>
> > >  where
> > >  .B value
> > >  can be
> > >
> > > -.BR 1 " or " 2
> > > -to select target chip 1 or 2 respectively. The default is target chip
> 1.
> > > +.BR 1 ", " 2 " or " 3
> > > +to select target chip 1 or 2 respectively. The default is target chip
> 1.
> > > To use the programming socket
> > This reads confusing now (set 1, 2 or 3 to choose between 1 and 2?).
> >
> > > +of the SF600 you need to select target 3.
> > >
> > >  .SS
>
> --
> Mit freundlichen Grüssen
>
> Florian Kaiser
> Microkernel Systems Development
> tel +49 89 991950 - 320
>
> ~~~
> genua
> Gesellschaft für Netzwerk - und Unix-Administration mbH
> Domagkstr. 7, D-85551 Kirchheim. http://www.genua.de
> Tel: (089) 99 19 50-0, Fax: (089) 99 19 50 - 999
>
> Geschaeftsfuehrer: Matthias Ochs, Marc Tesch
> Amtsgericht Muenchen HRB 98238
> 
> --
> Mit freundlichen Grüssen
>
> Florian Kaiser
> Microkernel Systems Development
> tel +49 89 991950 - 320
>
> ~~~
> genua
> Gesellschaft für Netzwerk - und Unix-Administration mbH
> Domagkstr. 7, D-85551 Kirchheim. http://www.genua.de
> Tel: (089) 99 19 50-0, Fax: (089) 99 19 50 - 999
>
> Geschaeftsfuehrer: Matthias Ochs, Marc Tesch
> Amtsgericht Muenchen HRB 98238
> 
> ___
> flashrom mailing list -- flashrom@flashrom.org
> To unsubscribe send an email to flashrom-le...@flashrom.org
>
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Is it possible to change only DMI data using flashrom ?

[David Hendricks]

Hi,
The answer is usually "no", but it depends on your BIOS. DMI data is
usually not stored in the BIOS image in a structured format, and sometimes
the strings (such as serial number) are also in a compressed region.

On Tue, Jan 8, 2019 at 4:30 AM Марк Коренберг  wrote:

> I want to change, say, serial number of motherboard.
>
> --
> Segmentation fault
> ___
> flashrom mailing list -- flashrom@flashrom.org
> To unsubscribe send an email to flashrom-le...@flashrom.org
>
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

[flashrom] Re: Help with a Winbond W25Q16

[David Hendricks]

Hi,
Thanks for posting the verbose output. It looks like the device ID bytes
are showing up inconsistently - Sometimes probe_spi_rdid_generic shows
0x4011 and sometimes 0x4015.

Often this indicates that your connection is bad or you are running the
programmer too fast. The output also shows:
MPSSE clock: 60.00 MHz, divisor: 2, SPI clock: 30.00 MHz

Try increasing the divisor value by passing it on the command-line as a
programmer parameter, e.g. `./flashrom -p
ft2232_spi:type=232H,port=A,divisor=16 -r dump.rom -V`

On Tue, Jan 8, 2019 at 4:30 AM iafdan  wrote:

> Hi to the cool guys from Flashrom!
>
> I'm trying to dump the contents of a Winbond W25Q16 using the command:
> ./flashrom -p ft2232_spi:type=232H,port=A -c W25Q16 -r dump.rom
>
> I'm getting an error that:
> This flash part has status NOT WORKING for operations...
>
> However, when I do "flashrom -L" the W25Q16 chip, with the exact same ID
> appears on the list.
>
> Here's a verbose output:
> https://paste.flashrom.org/view.php?id=3163
>
> I also tried reading the chip without specifying the exact chip.
>
> Many thanks!!
>
>
> ___
> flashrom mailing list -- flashrom@flashrom.org
> To unsubscribe send an email to flashrom-le...@flashrom.org
>
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

Re: [flashrom] 80/100/132 column line width policy

[David Hendricks]

Regarding exceptions, I was taught that function signatures in header
> files are an exception too. I don't mind either way, but if the rules
> disagree with the current practice, we should make that explicit.
>

This makes sense, but can linters be taught the difference between source
and header files? It would be nice to enforce the hard limit via commit
hook.


> Actually, I can't recall ever hearing about a soft limit. Though, I like
> the idea. I tried to formalize something like that once with the notion
> of a "visible width" during a [coreboot] discussion. Quoting myself here
> in case somebody is interested:
>
> > [...] I see three
> > major cases that people care about:
> >
> >  1. Function signatures,
> >  2. Code lines and
> >  3. Code lines containing string literals[1].
> >
> > Let's assume 72 chars of visible width (line length minus the inden-
> > tation) is enough for code lines. If we say two additional indentation
> > levels are always reasonable (a third might be too, here and there) we
> > would be at 96 chars.
> >
> > So I would compromise as follows:
> >
> >   o Set a hard limit around 100 chars (96 would be a nice number).
> >   o If a line doesn't contain a string literal, recommend a
> > visible width <= 72 chars.
> >
> > Nico
> >
> > [1] I think we should treat the latter two separately because you can
> > easily argue that lines with a string literal might get too long but
> > if you apply the same rules to regular code, you'll get all the
> > crappy stuff (too many levels of indentation, unnecessary long, less
> > distinctive identifiers etc.).
>
> Full message here[2]. That would only apply to the bulk of the code and
> comments. For me, carefully hand-formatted passages (like tables) are
> always an exception.
>
> Nico
>
> [2] https://mail.coreboot.org/pipermail/coreboot/2018-May/086834.html
>
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] 80/100/132 column line width policy

[David Hendricks]

This topic came up in a patch submission, and it occurred to me that we
never actually wrote down canonical limits in the wiki. So I went ahead and
added the proposed limits here:
https://www.flashrom.org/Development_Guidelines#Coding_style

It seems that we never really decided on 112-characters vs. 120-characters,
so I wrote down 112-characters for now. At least most were satisfied with
an 80-column "soft" limit and an exception to the limits for tables...

On Sun, May 6, 2012 at 7:10 AM Uwe Hermann  wrote:

> On Sun, May 06, 2012 at 02:12:32PM +0200, Carl-Daniel Hailfinger wrote:
> > Unless someone protests, I'd say 112 columns are the new absolute hard
> > limit, and there is no exception for anything except tables.
> > Table compression (i.e. having a few rows with unaligned elements
> > following a super-long element) is good as long as the majority of
> > elements in each column are aligned.
> >
> > Those limits only affect new code for the next 2 months starting today,
> > and if we're still happy with the limit after 2 months, the rest of the
> > code will be changed gradually where it helps readability.
> > Should we encounter code within the next 2 months where 112 columns are
> > way worse than 120, the limit will be increased to 120 with no
> > additional evaluation time period.
>
> I for one would very much prefer the 79/80 character (soft) limit per
> default.
>
> No objections about breaking the rule for exception cases where this
> makes sense (large tables, long lines which cannot be split nicely for
> whatever reasons), but as a general guideline sticking to 79 char/line
> is a very good thing IMHO.
>
>
> Uwe.
> --
> http://hermann-uwe.de | http://sigrok.org
> http://randomprojects.org | http://unmaintained-free-software.org
>
> ___
> flashrom mailing list
> flashrom@flashrom.org
> http://www.flashrom.org/mailman/listinfo/flashrom
>
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] [LinuxBoot] FOSDEM 2019 deadline today

[David Hendricks]

On Fri, Nov 2, 2018 at 9:15 AM 'Ron Minnich' via linuxboot <
linuxb...@googlegroups.com> wrote:

> I"m leaning to yes, by which I mean if you do it, I'll show up.
>
> I can't believe I said that.
> On Fri, Nov 2, 2018 at 7:20 AM Carl-Daniel Hailfinger
>  wrote:
> >
> > Hi!
> >
> > FOSDEM next year will be on 2 & 3 February 2019.
> > The deadline for applying for a stand is today.
> > Do we want a coreboot/flashrom/LinuxBoot stand/booth?
>

Same as what Ron said. I think someone from FB can be there to talk about
coreboot/LinuxBoot stuff and perhaps bring some hardware to demo.
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] flashrom error code message

[David Hendricks]

Hello,
I've seen this issue in cases where the voltage is not set correctly.

What programmer are you using? A verbose log will also help.

On Mon, Oct 15, 2018 at 11:28 PM MIAN VEREST  wrote:

> Recently i start to use flashrom software, moreless in a winbond chip i
> receive this message, is probably IC could be damage?
>
> Waiting for your comments.
>
> thanks in advance.
>
> Erasing and writing flash chip... Erase/write done in 8 min and 26 sec.
> Verifying flash... FAILED at 0x00016650! Expected=0x3f, Found=0x3d, failed
> byte count from 0x-0x007f: 0x2
> Your flash chip is in an unknown state.
>
>
>
>
>
> ___
> flashrom mailing list
> flashrom@flashrom.org
> https://mail.coreboot.org/mailman/listinfo/flashrom
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] FAILED: grunt

[David Hendricks]

On Mon, Jul 9, 2018 at 5:05 AM, Charles Marslett
 wrote:
> Well, never mind, I rebooted the target and the host systems, did a "repo
> sync" of my chromeos setup, did a full firmware rebuild (described in the
> care and feeding doc) then did a flash of the coreboot firmware, followed by
> a flash of the ec firmware and the target system automatically booted
> successfully after the ec firmware flash.
>
> Perhaps it could have been an issue with unsynchronized ec and coreboot
> firmware?

Possibly. I am guessing that the EC was unable to jump to the other
copy for some reason (this isn't in the output you posted, just a
guess), and the EC locks down its active copy which would explain why
attempting to flash it failed. You should also check the EC serial
console whenever you see EC firmware upgrade failures.

___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] Why does the flash content differ

[David Hendricks]

On Mon, Jul 9, 2018 at 6:37 PM, microsoft gaofei  wrote:
> The commands are just the following:
> sudo flashrom -w newbios --programmer internal
> The operation is successful, BIOS content is replaced and the computer can
> reboot successfully.
> sudo flashrom -r compare --programmer internal
> I later checked their SHA256 and found they’re different. So what happened?
> Did the internal programmer modify the content?

It's likely that something else wrote to the ROM (management engine,
embedded controller, BIOS, etc), especially during after doing a
reboot cycle.

___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] Fail to flash W25X40

[David Hendricks]

On Wed, May 30, 2018 at 9:03 AM, Yang Hu  wrote:
> Hi,
>
> I'm trying to rewrite a W24X40AL flash on a Seagate hard drive motherboard.
> I can successfully read the data, although some weird things happened.
> (First dumped code is nonsense, second time works fine, third or the rest
> are just partial corrupted code).
>
> Then I want to flash the code back but get the following error,
>
> parallels@ubuntu:~/Desktop$ sudo flashrom -p
> buspirate_spi:dev=/dev/ttyUSB0,spispeed=2M -E
> flashrom  on Linux 4.4.0-59-generic (x86_64)
> flashrom is free software, get the source code at https://flashrom.org
>
> Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
> Found Winbond flash chip "W25X40" (512 kB, SPI) on buspirate_spi.
> Erasing and writing flash chip... FAILED at 0x1000! Expected=0xff,
> Found=0x7f, failed byte count from 0x1000-0x1fff: 0x1
> ERASE FAILED!
> Looking for another erase function.
> FAILED at 0x1800! Expected=0xff, Found=0x00, failed byte count from
> 0x-0x: 0x42b
> ERASE FAILED!
> Looking for another erase function.
> FAILED at 0x2000! Expected=0xff, Found=0x00, failed byte count from
> 0x-0x0007: 0x6596
> ERASE FAILED!
> Looking for another erase function.
> Looking for another erase function.
> Looking for another erase function.
> No usable erase functions left.
> FAILED!
> Your flash chip is in an unknown state.
> Please report this on IRC at chat.freenode.net (channel #flashrom) or
> mail flashrom@flashrom.org, thanks!
>
> My connection right now is: the motherboard is not powered, using bus pirate
> 3.3v directly connects to VCC, /WP and /HOLD. I've tried to add 10k, 20k
> resistor between 3.3v and /WP, /HOLD pin but the chip won't be recognized
> then.
>
> I don't have much experience in electronics. Is this do with write
> protection? Is there anything I can do with this?

Hi Yang,
It sounds like your Bus Pirate is backpowering other electronics on
the board (e.g. an embedded controller), which in turn try to access
the SPI flash and interfere. This happens when the vendor does not
isolate the SPI flash circuitry.

Determine what other electronics might be powered by the Bus Pirate
and see if you can hold them in reset so that they don't try to access
the SPI flash.

___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] Update bios (not full flash) with flashrom

[David Hendricks]

On Sun, May 27, 2018 at 11:44 AM, Skoll RC  wrote:
> Hi everyone,
>
> I would like to update my GA-8I915P-MF's bios with flashrom but Gigabyte
> only provide updates and no full bios so when I try to update with
> flashrom -p internal -w 8i9pmf.f2 I have an error message: Error: Image size
> (262144 B) doesn't match the flash chip's size (524288 B)!
> How can I fix it?

That's unfortunate. Do you have an external programmer (something like
a buspirate) that can be used in case things go wrong? Can you tell if
there is anything written to the lower half of the chip? It could be
as simple as concatenating the 256KB image to itself to create a 512KB
image. But I wouldn't recommend trying that unless you have a good
means of recovering.

___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] program MX25R3235F

[David Hendricks]

Hi Daniel,
Thanks for the report and confirming getting it initially working.

I filed an issue on github to add support:
https://github.com/flashrom/flashrom/issues/43

If you have time, send a patch:
https://www.flashrom.org/Development_Guidelines#Patch_submission.



On Sun, May 13, 2018 at 9:13 AM, Daniel Gomez  wrote:

>
> I have added a new entry for ID 0x2816 with the same parameters as
> MX25L3235D creating MX25R3235F and it works correctly, thanks.
>
> 2018-05-13 17:42 GMT+02:00 Daniel Gomez :
>
>>
>> Hello, I am trying to program an MX25R3235F memory with flashrom. Report
>> attached. Is there any way to force the operation?
>> Thanks in advance.
>>
>> Daniel
>>
>>
>
> ___
> flashrom mailing list
> flashrom@flashrom.org
> https://mail.coreboot.org/mailman/listinfo/flashrom
>
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] MX66l51235f

[David Hendricks]

On Mon, May 14, 2018 at 9:48 AM, Nico Huber  wrote:

> Hi Ron,
>
> On 14.05.2018 18:01, ron minnich wrote:
> > anyone got the incantation to flash this with an sf100 ;-)
>
> TLDR; If it doesn't work with current master, you can try [1].
>
> 512M, huh? what's that for, UbuntuBoot? xD
>
> You need 4-byte addresses to access the full chip and that's rather
> delicate with Dediprog (because we don't control the SPI commands
> directly for read and write). The chip supports an extended address
> register for the most significant byte, though it's unclear to me
> if this register's state is maintained between Dediprog commands.
> So it might just work with flashrom master, or might wreak havoc ;)
>
> [1] https://review.coreboot.org/19858/


Indeed, in my experience the extended address enable got reset between
commands, so the follow-up patch forced that chip to use native 4BA access
mode. The patches were also based on the old 4BA access methods, so they
will need to be updated to work with the new way. At the very least I think
this means adding SPI_MASTER_4BA in spi_master_dediprog, but there's likely
some other stuff I'm overlooking.
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] [coreboot] flashrom on osx ...

[David Hendricks]

[+flashrom, coreboot --> bcc]

What version of OSX? I looked at this a bit last year, and they changed
their frameworks in Sierra such that DirectHW needs to be updated. Stefan
Tauner mentioned using osxcross (
https://github.com/tpoechtrager/osxcross.git) to build for OSX, but I've
never used it.

Here's some more background:
https://mail.coreboot.org/pipermail/flashrom/2017-June/015033.html
https://mail.coreboot.org/pipermail/flashrom/2017-June/015034.html


On Fri, May 11, 2018 at 10:42 AM, ron minnich  wrote:

> if I just want to use a dediprog sf100 what's the best way to build
> flashrom on osx?
>
> besides "throw the macbook in the trash and get a real computer" :-)
>
> ron
>
> --
> coreboot mailing list: coreb...@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] reading the flash image of my Celsius H265

[David Hendricks]

On Fri, May 11, 2018 at 7:52 AM, Elmar Stellnberger <estel...@elstel.org>
wrote:

>
>
> On 2018-05-11 00:08, Nico Huber wrote:
> > actually, I don't see a BIOS in there at all. ...
>
>> If you want to hunt more clues nevertheless, you can send us the output
>> of `flashrom -p internal:laptop=force_I_want_a_brick -V`. IIRC, it
>> also tells from which bus the BIOS was loaded.
>>
>> I think the ME has some logging enabled and simply writes to the flash.
>>
>> Nico
>>
>>
> On 2018-05-10 23:24, David Hendricks wrote:
> > If this is the case, then you will need to figure out how to prevent
> > the EC  from reading/writing the ROM at the same time as flashrom.
> > This could be as simple as disabling your OS's power management daemon
> > to avoid stimulating it, or ...
>
> Here comes the verbose output of flashrom as attachement.
> This time the output was taken after shutting down the backlight daemons:
> systemctl stop systemd-backlight@backlight:acpi_video0.service
> systemctl stop systemd-backlight@backlight:nv_backlight.service
>
> - and see the newly loaded rom images do not differ any more (though the
> time between taking both images has been less this time).
>

Glad that seems to have worked for reading. However as Nico said we really
can't recommend attempting to write using flashrom. At least not unless you
can get a full understanding of how this works and how to safely disable
the EC for updates, and have a method for recovery (e.g. an external
programmer). Anything that interacts with the EC (power, thermal, input
events, maybe other things) can wake it up and put your system in a bad
(possibly bricked) state.


> wget https://www.elstel.org/uploads/celsius3.rom
> wget https://www.elstel.org/uploads/celsius4.rom
>
>   Is it true that these flash images do not contain a BIOS?
>

It appears true. As Nico said it appears this chip is only for ME firmware
and configuration data. There is almost certainly another SPI flash on the
motherboard for the BIOS. You may need to (de-)assert some GPIO or send a
special command to the EC to select it.


> If it still contains all ME regions that should be enough for disabling
> ME? How to do that - I have heard that me_cleaner only works on gen2 and
> gen3 MEs but that my ME would be gen1?
>

I'm not an expert on me_cleaner, but the long story short is that ME is a
complicated beast that changes frequently and is very intertwined with how
the system works. me_cleaner can remove some (many?) modules but can't
disable it completely since ME controls some functions needed to bring-up
the CPU. I'm sure they'd appreciate your help demystifying your ME's
generation!
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] reading the flash image of my Celsius H265

[David Hendricks]

On Wed, May 9, 2018 at 1:12 PM, Elmar Stellnberger 
wrote:

> When I boot with iomem=relaxed and enable flash writing in my BIOS I get
> the following result with my Celsius H265 notebook:
>
> > flashrom -p internal:laptop=force_I_want_a_brick --read celsius2.rom
> flashrom p1.0-74-g2568357 on Linux 4.17.0-rc3+ (x86_64)
> flashrom is free software, get the source code at https://flashrom.org
>
> Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
> 
> WARNING! You seem to be running flashrom on an unsupported laptop.
> Laptops, notebooks and netbooks are difficult to support and we
> recommend to use the vendor flashing utility. The embedded controller
> (EC) in these machines often interacts badly with flashing.
> See the manpage and https://flashrom.org/Laptops for details.
>
> If flash is shared with the EC, erase is guaranteed to brick your laptop
> and write may brick your laptop.
> Read and probe may irritate your EC and cause fan failure, backlight
> failure and sudden poweroff.
> You have been warned.
> 
> Proceeding anyway because user forced us to.
> Found chipset "Intel ICH9M-E".
> Enabling flash write... OK.
> Found Winbond flash chip "W25X32" (4096 kB, SPI) mapped at physical
> address 0xffc0.
> Reading flash... done.
>
> However if I execute this twice I get two different images:
> wget https://www.elstel.org/uploads/celsius.rom
> wget https://www.elstel.org/uploads/celsius2.rom
>
> Using vbindiff I can see that quite a lot is different between both
> images. - which would be difficult to achieve if the firmware was changed
> while I am running my computer. The image may be somehow corrupted as
> me_cleaner (BIOS offers Intel AMT) can not process the image:
>
> python ../me_cleaner/me_cleaner.py -S -O celsius-no-me.rom celsius.rom
> Unknown image
>
> See also the dmidecode that I have attached.
> How can it be that both images are different?
> Do you think that the images are corrupted?
> If so what could we do about it?
>

There is probably an embedded controller (EC) connected to the SPI ROM that
is accessing the ROM at the same time as flashrom. See
https://flashrom.org/Laptops for details.

If this is the case, then you will need to figure out how to prevent the EC
from reading/writing the ROM at the same time as flashrom. This could be as
simple as disabling your OS's power management daemon to avoid stimulating
it, or it may require sending a command to the EC (likely a sequence of
OUTBs) to put it into an update or recovery mode to prevent it from
accessing the firmware ROM.
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] FAILED: Soraka DVT1

[David Hendricks]

Hello Hongxia,
Were you able to get in touch with someone on the chromiumos team?

It appears that you attempted to write the entire firmware ROM, but it
failed to write the flash descriptor region. You should target the
region(s) you want updated using the -i option, along with --fast-verify,
so that flashrom does not attempt to write and verify regions that it might
not have access to.

On Mon, Apr 23, 2018 at 11:54 PM, Gao, HongxiaX 
wrote:

> Hi,
>
>
>
> It is failed on my board when flashing firmware R68 10599. Can you help me
> on it?
>
>
>
> *HW:* Soraka DVT1
>
>
>
> *Issue description:*
>
> Flash firmware 10431 without any problems, but it is failed when flashing
> firmware R68 10599. Steps are:
>
>
>
> 1.   Download firmware R68 10599
> ,
> then extract it.
>
> 2.   Enter board terminal
>
> localhost /home # flashrom -w 10599/image.bin
>
> flashrom v0.9.9  : cfd7dfc : Apr 06 2018 05:12:10 UTC on Linux 4.4.128
> (x86_64)
>
> flashrom v0.9.9  : cfd7dfc : Apr 06 2018 05:12:10 UTC on Linux 4.4.128
> (x86_64)
>
> Calibrating delay loop... OK.
>
> coreboot table found at 0x7aac5000.
>
> WARNING: SPI Configuration Lockdown activated.
>
> Erasing and writing flash chip... Verifying flash... VERIFY FAILED at
> 0x0081! Expected=0xff, Read=0x0b, failed byte count from
> 0x-0x00ff: 0x9
>
> Your flash chip is in an unknown state.
>
> Get help on IRC at irc.freenode.net (channel #flashrom) or
>
> mail flashrom@flashrom.org with FAILED: your board name in the subject
> line!
>
> 
> ---
>
> DO NOT REBOOT OR POWEROFF!
>
> FAILED
>
>
>
> 3.   Try to update firmware
>
> localhost /home/10599 # chromeos-firmwareupdate -m autoupdate
>
> Starting Google_Soraka firmware updater v4 (autoupdate)...
>
> - Updater package: [Google_Soraka.10431.32.0 /
> EC:soraka_v1.1.8047-2c5917d7d]
>
> - Current system:  [RO:Google_Soraka.10431.32.0 ,
> ACT:Google_Soraka.10431.32.0 / EC:soraka_v1.1.8047-2c5917d7d]
>
> - Write protection: Hardware: ON, Software: Main=off
>
> * invoke: flashrom -p host -r _current/bios.bin
>
> RO Contents are different.
>
> autoupdate(recovery): update RO+RW
>
> * invoke: flashrom -p host --fast-verify -w bios.bin
>
> autoupdate(recovery): update ec/RO+RW
>
> * invoke: flashrom -p ec --fast-verify -w ec.bin
>
> autoupdate(recovery): EC may be restored or updated in next boot.
>
> Firmware update (autoupdate) completed.
>
>
>
> 4.   Reboot the board, then power off and power on
>
> 5.   Flash fw 10599 again
>
> localhost /home # flashrom -w 10599/image.bin
>
> flashrom v0.9.9  : cfd7dfc : Apr 06 2018 05:12:10 UTC on Linux 4.4.128
> (x86_64)
>
> flashrom v0.9.9  : cfd7dfc : Apr 06 2018 05:12:10 UTC on Linux 4.4.128
> (x86_64)
>
> Calibrating delay loop... OK.
>
> coreboot table found at 0x7aac5000.
>
> WARNING: SPI Configuration Lockdown activated.
>
> Erasing and writing flash chip... Verifying flash... VERIFY FAILED at
> 0x0081! Expected=0xff, Read=0x0b, failed byte count from
> 0x-0x00ff: 0x9
>
> Your flash chip is in an unknown state.
>
> Get help on IRC at irc.freenode.net (channel #flashrom) or
>
> mail flashrom@flashrom.org with FAILED: your board name in the subject
> line!
>
> 
> ---
>
> DO NOT REBOOT OR POWEROFF!
>
> FAILED
>
>
>
>
>
> Thanks
>
>
>
> Br,
>
> Hongxia
>
>
>
> ___
> flashrom mailing list
> flashrom@flashrom.org
> https://mail.coreboot.org/mailman/listinfo/flashrom
>
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] Failed flash on Intel Bay Trail platform

[David Hendricks]

Hi Quinn,

On Wed, Jan 31, 2018 at 5:01 AM, Quinn Plattel  wrote:

> 13:56 < quinn> flashrom shows warning when reading or writing: BIOS region
> SMM
>protection is enabled!
>

Did you have any luck with this? There might be a BIOS setting in the menu
that allows you to disable the SMM lock, and as icon suggested on IRC the
speed racer exploit might also be a feasible workaround.

Another idea might be to try using coreboot on this board and simply not
set the SMM lock bit until you need to do so ;-) There's a decent chance
the Bayley Bay CRB implementation will work, though you may need to do some
customization for your board: https://review.coreboot.org/cgit/coreboot.git
/tree/src/mainboard/intel/bayleybay_fsp
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] Github PRs

[David Hendricks]

Hi Miklos,

Yes, coreboot's gerrit system is likely where the review will take place. The 
github repository is a mirror of coreboot's flashrom repository, however we 
recognize that a lot of people do development on github so we work with pull 
requests as well. We also still have patch submissions via e-mail.


You may receive comments to your pull request on github, however if the patch 
is small enough (like PR33) then it might just be sent directly to 
review.coreboot.org for final review before being merged and ultimately 
mirrored in the github repo.


As usual the bottleneck is the amount of spare time reviewers have and we've 
been juggling some large changes lately. We do appreciate the contributions, 
and please feel free to nudge us if there is urgency or if things simply linger 
for too long.


From: flashrom  on behalf of Miklos Marton 

Sent: Tuesday, January 30, 2018 12:47:44 PM
To: flashrom
Subject: [flashrom] Github PRs

Hello flashrom developers!

I have submitted two PRs to github (as the wiki mentions it is also a
possible contribution channel).

Do I need to do anything else with that? I am not intended to seems to
be impatient I just would like to make sure that everything is in place
(this is my first contribution to flashrom this way).

If I remember correctly the coreboot gerrit was used to do code review.
Is it going to be moved there or we will perform the code review at the
github?

--
Best regards,
Miklos Marton


___
flashrom mailing list
flashrom@flashrom.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.coreboot.org_mailman_listinfo_flashrom=DwICAg=5VD0RTtNlTh3ycd41b3MUw=CFWWReJabtqA8oU7yaBHbIE9YvsZmeYWXWpJOiuGyNM=5TRHJNBzy4Ly4wu_seBtgMrm4lLIHJEwJ9sFPAyQ3Ak=iU6v_NcdY8-R_kO427ws-_UchWm5UZ692qxfiE_Xl90=
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] CrOS flashrom compatibility and upstreaming of CrOS features

[David Hendricks]

On Wed, Jan 24, 2018 at 10:36 AM, Nico Huber  wrote:

> Hey folks,
>
> during review of commits that port per-region file arguments [1] from
> CrOS flashrom over here, we ran into a discussion about the command line
> interface changes. The basic question that arose is
>
> Do we want to maintain full CLI compatibility to CrOS flashrom?
>
> This would have the upside, that it would ease remerging of the two
> flashrom versions (in some unknown future). And anybody currently
> using CrOS flashrom could transition more smoothly. OTOH, depending on
> how the compatibility is achieved, it might increase the costs for
> review and development heavily (for a project with 0 spare resources).
>
> To not have to discuss this each and every time when some non-trivial
> feature is ported over from CrOS, I'd like to have some opinions, how
> valuable CLI compatibility is to you all and how we want to achieve it.
> I have currently some alternative ideas in mind that I'll sketch below.
> Feel free to add other ideas or just to comment them.
>

Option #2 seems pretty good IMHO. I suspect that CrOS will need to maintain
their legacy behavior for a while longer, but that does not need to hold
back upstream. We should of course improve our testing to avoid breaking
one or the other, at least without sufficient reason and time to adjust.

Some background on this: CrOS currently maintains a separate CLI in their
tree, cli_mfg.c, specifically because the upstream CLI was not well-suited
for their manufacturing needs. Things like syntax changes, additional
options, verbosity, error handling, etc. were simply different from what
typical users expect. The partial read/write/verify syntax was developed to
meet specific needs of the manufacturing flow, and the write-protection
syntax was added specifically to address the way write-protection works on
Chromebooks. Stuff like "combining multiple files" was done to avoid
wasting valuable time on the assembly line and at runtime during normal OS
maintenance (yes, seconds really do matter).

I'd still like to see CrOS converge with upstream so we share development
and testing efforts. It would also be great to have more device
manufacturers working with upstream. Having an alternate CLI coexist
alongside the "classic" CLI seems like a decent compromise IMO. Both sides
will benefit from a converged codebase, let's not make the CLI a blocking
issue.
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] GPG signature on flashrom release

[David Hendricks]

Hi Bruno,
Try again, it should be posted now (I used keys.gnupg.net).

On Thu, Jan 11, 2018 at 9:44 AM, Archange  wrote:

> Hi,
>
> It seems that flashrom provides GPG sigs for the tarball, e.g.
> http://download.flashrom.org/releases/flashrom-1.0.tar.bz2.asc, which is
> nice.
>
> However, I seems I can’t find the key use to sign this on usual
> keyservers. Could you tell me where it is available?
>
> Regards,
> Bruno
>
> ___
> flashrom mailing list
> flashrom@flashrom.org
> https://mail.coreboot.org/mailman/listinfo/flashrom
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] [announce] flashrom 1.0

[David Hendricks]

On Wed, Jan 3, 2018 at 10:05 AM, Nico Huber  wrote:

> > It is very discouraging - after 2 years of
> > waiting to not see them at 1.0
>
> It is indeed. There are also unmerged patches that are nearly 8 years
> old... (not to mention patches in forks of flashrom). But things might
> get better in the future. At least everything currently pushed to gerrit
> gets a review. And I'm working on cleaning up old patches on patchwork
> as well.


On that note, it would be helpful for folks to step up and take on
maintainership of certain parts of the code. We often get patches for
programmer X or mainboard Y, but without intimate knowledge of X or Y it
can be difficult to review patches, and testing is often not possible due
to the wide variety of hardware supported.

Maybe we should add a MAINTAINERS file or a wiki where people can volunteer
based on their area of expertise - General infrastructure, Bus Pirate,
Arduino, Intel platforms, Thinkpad issues, BSD/DOS/Windows support, etc.
That will help triage patches and issues and get the right people looking
at them.
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] Bad MX25L4005AM2C ?

[David Hendricks]

Hi Ondrej,
The MX25L4005A is listed in the flashchips database as being supported, but
as you point out the incorrect ID is being seen by the programmer. This is
likely due to a signal integrity problem. Please try the following:
1. Slow down the SPI interface by setting a higher divisor value in the
programmer parameter, e.g. `./flashrom -V -p
ft2232_spi:type=arm-usb-ocd-h:divisor=60
-o test.txt`. Currently your output shows "MPSSE clock: 60.00 MHz,
divisor: 2, SPI clock: 30.00 MHz" which is generally very fast for an
external programmer.
2. Use shorter wires to connect the programmer to the chip, ideally 10cm or
less.


2017-12-17 5:19 GMT-08:00 ondrej ondrej :

> Hi flashrom maintainers,
>
> I failed to read a MX25L4005AM2C (this name is written on chip) via the 
> "Olimex ARM-USB-OCD-H". Maybe
> this chip have wrong id? Id for this chip in datasheet is Id1=0xC2, Id2=0x2013
>
> flashrom v0.9.9-98-g3083ed9 on Linux 4.0.5-gentoo (x86_64)
> flashrom was built with libpci 3.2.0, GCC 4.8.4, little endian
> Command line (5 args): ./flashrom -V -p ft2232_spi:type=arm-usb-ocd-h -o 
> test.txt
> Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
> Initializing ft2232_spi programmer
> Using device type Olimex ARM-USB-OCD-H channel A.
> Disable divide-by-5 front stage
> Set clock divisor
> MPSSE clock: 60.00 MHz, divisor: 2, SPI clock: 30.00 MHz
> No loopback of TDI/DO TDO/DI
> Set data bits
> The following protocols are supported: SPI.
> Probing for AMIC A25L05PT, 64 kB: RDID byte 0 parity violation. 
> probe_spi_rdid_generic: id1 0xe1, id2 0x1009
> Probing for AMIC A25L05PU, 64 kB: RDID byte 0 parity violation. 
> probe_spi_rdid_generic: id1 0xe1, id2 0x1009
> Probing for AMIC A25L10PT, 128 kB: RDID byte 0 parity violation. 
> probe_spi_rdid_generic: id1 0xe1, id2 0x1009
> Probing for AMIC A25L10PU, 128 kB: RDID byte 0 parity violation. 
> probe_spi_rdid_generic: id1 0xe1, id2 0x1009
> Probing for AMIC A25L20PT, 256 kB: RDID byte 0 parity violation. 
> probe_spi_rdid_generic: id1 0xe1, id2 0x1009
> Probing for AMIC A25L20PU, 256 kB: RDID byte 0 parity violation. 
> probe_spi_rdid_generic: id1 0xe1, id2 0x1009
> Probing for AMIC A25L40PT, 512 kB: RDID byte 0 parity violation. 
> probe_spi_rdid_generic: id1 0xe1, id2 0x1009
> Probing for AMIC A25L40PU, 512 kB: RDID byte 0 parity violation. 
> probe_spi_rdid_generic: id1 0xe1, id2 0x1009
> Probing for AMIC A25L80P, 1024 kB: RDID byte 0 parity violation. 
> probe_spi_rdid_generic: id1 0xe1, id2 0x1009
> Probing for AMIC A25L16PT, 2048 kB: RDID byte 0 parity violation. 
> probe_spi_rdid_generic: id1 0xe1, id2 0x1009
> Probing for AMIC A25L16PU, 2048 kB: RDID byte 0 parity violation. 
> probe_spi_rdid_generic: id1 0xe1, id2 0x1009
> Probing for AMIC A25L512, 64 kB: RDID byte 0 parity violation. 
> probe_spi_rdid_generic: id1 0xe1, id2 0x1009
> Probing for AMIC A25L010, 128 kB: RDID byte 0 parity violation. 
> probe_spi_rdid_generic: id1 0xe1, id2 0x1009
> Probing for AMIC A25L020, 256 kB: RDID byte 0 parity violation. 
> probe_spi_rdid_generic: id1 0xe1, id2 0x1009
> Probing for AMIC A25L040, 512 kB: RDID byte 0 parity violation. 
> probe_spi_rdid_generic: id1 0xe1, id2 0x1009
> Probing for AMIC A25L080, 1024 kB: RDID byte 0 parity violation. 
> probe_spi_rdid_generic: id1 0xe1, id2 0x1009
> Probing for AMIC A25L016, 2048 kB: RDID byte 0 parity violation. 
> probe_spi_rdid_generic: id1 0xe1, id2 0x1009
> Probing for AMIC A25L032, 4096 kB: RDID byte 0 parity violation. 
> probe_spi_rdid_generic: id1 0xe1, id2 0x1009
> Probing for AMIC A25LQ16, 2048 kB: RDID byte 0 parity violation. 
> probe_spi_rdid_generic: id1 0xe1, id2 0x1009
> Probing for AMIC A25LQ032/A25LQ32A, 4096 kB: RDID byte 0 parity violation. 
> probe_spi_rdid_generic: id1 0xe1, id2 0x1009
> Probing for AMIC A25LQ64, 8192 kB: RDID byte 0 parity violation. 
> probe_spi_rdid_generic: id1 0xe1, id2 0x1009
> Probing for Atmel AT25DF021, 256 kB: RDID byte 0 parity violation. 
> probe_spi_rdid_generic: id1 0xe1, id2 0x1009
> Probing for Atmel AT25DF041A, 512 kB: RDID byte 0 parity violation. 
> probe_spi_rdid_generic: id1 0xe1, id2 0x1009
> Probing for Atmel AT25DF081, 1024 kB: RDID byte 0 parity violation. 
> probe_spi_rdid_generic: id1 0xe1, id2 0x1009
> Probing for Atmel AT25DF081A, 1024 kB: RDID byte 0 parity violation. 
> probe_spi_rdid_generic: id1 0xe1, id2 0x1009
> Probing for Atmel AT25DF161, 2048 kB: RDID byte 0 parity violation. 
> probe_spi_rdid_generic: id1 0xe1, id2 0x1009
> Probing for Atmel AT25DF321, 4096 kB: RDID byte 0 parity violation. 
> probe_spi_rdid_generic: id1 0xe1, id2 0x1009
> Probing for Atmel AT25DF321A, 4096 kB: RDID byte 0 parity violation. 
> probe_spi_rdid_generic: id1 0xe1, id2 0x1009
> Probing for Atmel AT25DF641(A), 8192 kB: RDID byte 0 parity violation. 
> probe_spi_rdid_generic: id1 0xe1, id2 0x1009
> Probing for Atmel AT25DL081, 1024 kB: RDID byte 0 parity violation. 
> probe_spi_rdid_generic: id1 0xe1, id2 0x1009
> 

Re: [flashrom] chipset not found

[David Hendricks]

On Wed, Dec 6, 2017 at 8:29 PM, David Velasco  wrote:

> Hi carl,
>
> I have the following error:
>
> # flashrom --programmer internal
> flashrom v0.9.9-rc1-r1942 on Linux 4.10.0-40-generic (x86_64)
> flashrom is free software, get the source code at https://flashrom.org
>
> Calibrating delay loop... OK.
> WARNING: *No chipset found. Flash detection will most likely fail.*
> No EEPROM/flash device found.
> Note: flashrom can never write if the flash chip isn't found automatically.
> # flashrom --programmer internal
> flashrom v0.9.9-rc1-r1942 on Linux 4.10.0-40-generic (x86_64)
> flashrom is free software, get the source code at https://flashrom.org
>
> Calibrating delay loop... OK.
> WARNING: No chipset found. Flash detection will most likely fail.
> No EEPROM/flash device found.
> Note: flashrom can never write if the flash chip isn't found automatically.
> # flashrom
> flashrom v0.9.9-rc1-r1942 on Linux 4.10.0-40-generic (x86_64)
> flashrom is free software, get the source code at https://flashrom.org
>
> Please select a programmer with the --programmer parameter.
> Previously this was not necessary because there was a default set.
> To choose the mainboard of this computer use 'internal'. Valid choices are:
> internal, dummy, nic3com, nicrealtek, gfxnvidia, drkaiser, satasii, atavia,
> it8212, serprog, buspirate_spi, dediprog, rayer_spi, pony_spi, nicintel,
> nicintel_spi, nicintel_eeprom, ogp_spi, satamv, linux_spi, pickit2_spi,
> ch341a_spi.
>
>
> I can give you the result of
>
> lspci -nnvvvxxx
>
> Yes, please copy + paste lspci output to https://paste.flashrom.org/ .
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] particular spi flash controller

[David Hendricks]

On Fri, Dec 1, 2017 at 12:11 AM, Andriy Gapon  wrote:

>
> Hello.
>
> I wonder if anyone here encountered an SPI flash controller (master) that
> has a
> three register interface where the first register is used for control and
> status
> bits, the second register is used for setting a flash address (if one is
> needed)
> and the third is used for reading or writing the flash data.  A specific
> operation is requested by writing an SPI opcode into the control register.
> The interface seems to be rather simple, but I couldn't find any driver
> that
> implements access to anything like that or any documentation that would
> describe
> a similar interface.
>
> Does it sound familiar to anyone?
> Could anyone give me some hints / pointers?
>

Is this an interface that you've actually used before? It sounds too
simplistic since at the very least you'd also need to set the number of
bytes to transfer, the direction, and have some control over chip select.
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] winbond 25q128jvfm

[David Hendricks]

Hi Ron,
Can you check the full part number? There appears to be a couple versions
of this chip, one with ID 0x4018 (like the existing W25Q128.V chips) and
another version with additional instructions that identifies with 0x7018.

I found a W25Q128JVSIQ and it reads/writes successfully with the existing
code. If your chip ends with an 'M' instead of a 'Q' then you can try this,
which just does as Nico suggested: https://review.coreboot.org/#/c/22567/

On Fri, Nov 17, 2017 at 9:49 AM, ron minnich  wrote:

> any suggestions on making this part work? I have not done this in a while.
>
> ___
> flashrom mailing list
> flashrom@flashrom.org
> https://mail.coreboot.org/mailman/listinfo/flashrom
>
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] Patch to flashrom for Macronix M25U12835F flash support and write protection bug fix

[David Hendricks]

Hello Alex,
Thank you for this patch and your friendly nudge in the other thread. I
have uploaded it to chromium.org so that they can review, test, and merge
it:
https://chromium-review.googlesource.com/c/chromiumos/third_party/flashrom/+/753007

On Mon, Sep 4, 2017 at 8:47 PM,  wrote:

> Dear Sir,
>
> I am from Macronix (Taiwan), here I send you the source patch that
> could
> fix the write protection error on Chromebook project which came form
> Quatun Computer.
> I hope you can help patching into the Flashrom project (branch: master).
>   Thanks a lot !
>
> Alex Lu
> Macronix , FAE Dept.
>
>
> CONFIDENTIALITY NOTE:
>
> This e-mail and any attachments may contain confidential information
> and/or personal data, which is protected by applicable laws. Please be
> reminded that duplication, disclosure, distribution, or use of this e-mail
> (and/or its attachments) or any part thereof is prohibited. If you receive
> this e-mail in error, please notify us immediately and delete this mail as
> well as its attachment(s) from your system. In addition, please be informed
> that collection, processing, and/or use of personal data is prohibited
> unless expressly permitted by personal data protection laws. Thank you for
> your attention and cooperation.
>
> Macronix International Co., Ltd.
>
> =
>
>
> CONFIDENTIALITY NOTE:
>
> This e-mail and any attachments may contain confidential information
> and/or personal data, which is protected by applicable laws. Please be
> reminded that duplication, disclosure, distribution, or use of this e-mail
> (and/or its attachments) or any part thereof is prohibited. If you receive
> this e-mail in error, please notify us immediately and delete this mail as
> well as its attachment(s) from your system. In addition, please be informed
> that collection, processing, and/or use of personal data is prohibited
> unless expressly permitted by personal data protection laws. Thank you for
> your attention and cooperation.
>
> Macronix International Co., Ltd.
>
> =
>
> ___
> flashrom mailing list
> flashrom@flashrom.org
> https://mail.coreboot.org/mailman/listinfo/flashrom
>
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] Future flashrom development

[David Hendricks]

On Wed, Oct 25, 2017 at 4:04 AM, Nico Huber  wrote:
>
> On 23.10.2017 09:39, Stefan Tauner wrote:
>>
>> On Fri, 13 Oct 2017 17:42:11 +0200
>> Nico Huber  wrote:
>>
>>> What I didn't realize last night: the `staging` branch contains
>>> valuable information in lots of fixup! commits that would be lost
>>> if we don't keep `staging`. They look ugly in the log but their
>>> messages still contain some reasoning about the changes. I prefer
>>> to use the current `staging` branch as `master` therefore.
>>
>>
>> *If* there is valuable information in them then they should get into
>> the final commit message (i.e. the one that squashes everything to
>> stable). I deem them basically as part of the review process of the
>> whole change (i.e. the commit eventually committed to stable) and sure,
>> there is information in it that might be interesting but this likewise
>> applies to all review comments and I would not want them to be part of
>> the commit messages, would you?
>
>
> No, ofc not. But there is always a compromise of what to include into
> the commit message. Though, maybe I'd write too elaborate ones, I think
> yours are often too thin (it only doesn't look like it because you do
> too much in single commits, IMHO).

This is another area where Gerrit helps us. Each patch gets a
"Reviewed-on:" line appended which makes it easy refer to review
comments when additional context is needed. If we squash several
patches into one we lose that context. We could have multiple
"Reviewed-on:" lines in squashed patches, but that would be sort of
awkward.

>> For someone not
>> involved in the respective review/development process (i.e.
>> everybody but the author of the fixups and respective reviewer(s)) it
>> is very hard to track what the actual outcome of all of the fixups
>> is.
>
>
> In the git way of fixups (e.g. `fixup! `), this is
> pretty easy: The outcome is what the original commit message promised.

Also, fixups and refactoring should not be conflated. Fixups should
only ensure the intended outcome of the original patch is met.
Refactoring code, for example simplification, cosmetic changes, etc.
should be done in separate patches anyway.

>> Both can make bisecting for specific problems tedious if unlucky.
>
>
> Lol, that's still better than squashing commits into bigger ones which
> makes bisecting less feasible.

Squashing into uber-patches also defeats the purpose of `git blame`.

Squashing approach has a lot of significant drawbacks - it breaks `git
bisect`, it breaks `git blame`, and depending on who is doing the
squashing we might lose references to code reviews from "Reviewed-on:"
lines. It also requires a lot of time and manual effort which leads to
arbitrary decisions and possibly more errors. I just don't see why we
would go thru all that when git and gerrit make things so simple and
without all the manual steps.

___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] Future flashrom development (Stefan's PoV II)

[David Hendricks]

On Mon, Oct 23, 2017 at 7:03 PM, Stefan Tauner  wrote:
> Hi again,
>
> just to summarize my last email (since it's been over a week again):
> there was quite some work done behind the scenes for flashrom's git
> conversion that also included a proposed change in the development
> process in form of a second "main" branch named staging that would have
> been introduced to get patches up to a sane quality level faster.
>
> What I had not anticipated was the strong wish to change the reviewing
> process/tools and the resulting surge of reviews and new (conflicting)
> changes. My plan was simply to take patches provided by any means (and
> thus lowering the barrier for contributing although that was only a
> bonus) polish them only minimally and then push them to staging to get
> them tested. The old (and already somewhat tested) patches would have
> had priority to keep conflicts low. This would have been done rather
> manually and without much interaction with others (there were
> practically no others in the last years :).

This seems to have been a simple misunderstanding with what the
branches were for. The name "staging" implies that we're supposed to
dump all of our patches there.

If you want those to be your own branches that you have exclusive
commit rights for, we should be able to accommodate that. We can do as
Antonio suggested in the other thread and use master for the typical
git workflow where people send patches, and you can do with "staging"
and "stable" as you please. Perhaps we should also prefix them with
"stefanct-" so that there is no confusion about who the gatekeeper is.

___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] Future flashrom development (Stefan's PoV I)

[David Hendricks]

On Wed, Oct 18, 2017 at 10:31 AM, Nico Huber <nic...@gmx.de> wrote:

> On 17.10.2017 01:14, David Hendricks wrote:
>
>> On Sat, Oct 14, 2017 at 7:20 AM, Stefan Tauner <stefan.tau...@gmx.at>
>> wrote:
>>
>>> While there was a bunch of patches that have been piled up back then it
>>> was less of a problem then the increasing divergence between the
>>> chromiumos fork and upstream. Thus we have discussed ways to converge
>>> that (by pulling changes mainly from upstream into chromium but also
>>> vice versa) and also increase the pace of merging stuff into upstream
>>> later. This was still with no intention to switch to git because of
>>> Carl-Daniel's concerns.
>>>
>>>
>> I'm surprised that you think that chromiumos's divergence is a *worse*
>> problem than the huge backlog of upstream patches. The chromiumos fork is
>> self-contained, has its own review system, its own testing, and is
>> targeted
>> at a narrow set of devices. I don't understand how it could have been a
>> problem for upstream and would be interested if you can elaborate on this
>> point.
>>
>
> I think there are at least two views on this:
>
> What might happen in such a case: People loose interest in upstream and
> less patches get send there. (This might even have a positive effect on
> the patch queue.)
>
> What I think happened (and maybe Stefan had something like this in
> mind): Progress on upstream stalled on more invasive topics because
> people tried to find a solution fitting both branches, first. FWIW,
> this was the case for better layout support in upstream. Maybe there
> were more topics stalled, I don't know the cros fork well enough.


That makes sense. However I think it's worth considering _why_ people lose
interest rather than blaming forks. IMO much of this is due to the
historically glacial pace of reviews, commits, and releases, which might be
fine for hobbyists or occasional users but was simply unworkable for
commercial development.

The good news is that this is getting fixed now that we have modern code
management and review systems in-place. Contributors have more ways to
submitting patches (mailing list, PR on Github, or push to
review.coreboot.org). Tracking and rebasing patches and revisions is much,
much easier now with Gerrit. Jenkins provides some value for sanity
checking, and Stefan's upcoming buildbot provide will go a long way here as
well. There are some other ways we can get cheap/easy QA to help accelerate
the pace of development and merging.

Anyway, I'm optimistic. There's a lot of work to be done but we're
definitely on the right path toward making the flashrom codebase easier to
work with and more accessible so that fewer users/developers will see a
need to fork.
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] Future flashrom development (Stefan's PoV I)

[David Hendricks]

Thanks for the detailed write-up. I suppose there's another part coming so
I don't want to get too deep into discussion just yet, but one part in
particular caught my eye:

On Sat, Oct 14, 2017 at 7:20 AM, Stefan Tauner  wrote:

> While there was a bunch of patches that have been piled up back then it
> was less of a problem then the increasing divergence between the
> chromiumos fork and upstream. Thus we have discussed ways to converge
> that (by pulling changes mainly from upstream into chromium but also
> vice versa) and also increase the pace of merging stuff into upstream
> later. This was still with no intention to switch to git because of
> Carl-Daniel's concerns.
>

I'm surprised that you think that chromiumos's divergence is a *worse*
problem than the huge backlog of upstream patches. The chromiumos fork is
self-contained, has its own review system, its own testing, and is targeted
at a narrow set of devices. I don't understand how it could have been a
problem for upstream and would be interested if you can elaborate on this
point.

FWIW I did try pushing some features from chromiumos to upstream, but like
other patches they never really got anywhere. I also tried working with
Carl-Daniel for a couple months to sync the trees, but that effort didn't
get very far.
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] Unsupported Chip

[David Hendricks]

Hello Abran,
Can you post a verbose log (flashrom -V ...)? The chip should be supported,
though there might be some limitation with your programmer that prevents it
from being flashed, especially if you're using an Intel platform.

On Sun, Oct 15, 2017 at 3:48 PM, Abran DeCarlo Hernandez <
abranantoniodecarlohernan...@gmail.com> wrote:

> Flashrom cannot PROBE/READ/ERASE/WRITE to my BIOS chip (Winbond 25064BVAIG)
>
> How do I go about fixing this?  It detects the chip but it is unsupported
>
> ___
> flashrom mailing list
> flashrom@flashrom.org
> https://mail.coreboot.org/mailman/listinfo/flashrom
>
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] Future flashrom development

[David Hendricks]

On Fri, Oct 13, 2017 at 11:42 PM, Nico Huber  wrote:

> On 13.10.2017 02:40, Nico Huber wrote:
>
>> So I propose the following: Forget the two branches model, start
>> a `master` branch with either the current state of `staging` or
>> my proposed move to `stable` [3] and release flashrom-1.0 right
>> away.
>>
>
> What I didn't realize last night: the `staging` branch contains
> valuable information in lots of fixup! commits that would be lost
> if we don't keep `staging`. They look ugly in the log but their
> messages still contain some reasoning about the changes. I prefer
> to use the current `staging` branch as `master` therefore.
>

I'm fine with that.

I think Peter's suggestions are worth further consideration as well. As he
pointed out, Flashrom has always been pretty simple and flat, and tags seem
like a good way to do releases without the difficulties we've experienced
with multiple branches.

Your idea to do release branches is fine, too. So long as we have something
that is low-overhead, less bottlenecked, and won't cause as much friction
moving forward.


> And I'm convinced that `staging` is in better shape than flashrom-0.9.9.


This is somewhat subjective, but I agree largely due to the libflashrom and
layout patches. And aside from code quality `staging` also has features and
hardware support (either merged or pending) that I need to do work.
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] When flashrom support Intel Purley platform Lewisburg PCH?

[David Hendricks]

Hi Sandy,

I updated the flashrom code to better take into account differences with 
Lewisburg, including the number of FREG registers as you point out: 
https://review.coreboot.org/#/c/20922/


When you have a chance, please and try again (using -V). You can copy+paste 
your result here for convenience: https://paste.flashrom.org/.

Flashrom -- File upload serivce<https://paste.flashrom.org/>
paste.flashrom.org
Welcome to flashrom's file upload service Please post only 
flashrom/coreboot/seabios or other firmware related contents. Post a new paste 
You can either post text ...




From: flashrom <flashrom-boun...@flashrom.org> on behalf of Sandy Zhang 
<sanzh...@celestica.com>
Sent: Monday, August 14, 2017 4:36:00 AM
To: David Hendricks
Cc: flashrom@flashrom.org
Subject: Re: [flashrom] When flashrom support Intel Purley platform Lewisburg 
PCH?

Hi David,

Lewisburg PCH defines sixty SPI regions, but from the code in ichspi.c, I find 
it defines only 10 regions, is this the reason about only 10 regions was 
described in the log file?

code as below: (num_freg define the spi regions)

int ich_init_spi(void *spibar, enum ich_chipset ich_gen)
{
...
...
...
/* Moving registers / bits */
if (ich_generation == CHIPSET_100_SERIES_SUNRISE_POINT) {
num_freg = 10;
num_pr = 6;
reg_pr0 = PCH100_REG_FPR0;
swseq_data.reg_ssfsc = PCH100_REG_SSFSC;
swseq_data.reg_preop = PCH100_REG_PREOP;
swseq_data.reg_optype = PCH100_REG_OPTYPE;
swseq_data.reg_opmenu = PCH100_REG_OPMENU;
hwseq_data.addr_mask = PCH100_FADDR_FLA;
hwseq_data.only_4k = true;
hwseq_data.hsfc_fcycle = PCH100_HSFC_FCYCLE;
}

2017-08-14 14:23 GMT+08:00 David Hendricks 
<david.hendri...@gmail.com<mailto:david.hendri...@gmail.com>>:
On Sun, Aug 13, 2017 at 6:26 PM, Sandy Zhang 
<sanzh...@celestica.com<mailto:sanzh...@celestica.com>> wrote:
Hi David,

I'm inline.

I don't see your responses. Did you intend to reply to my comments?


2017-08-14 9:17 GMT+08:00 David Hendricks 
<david.hendri...@gmail.com<mailto:david.hendri...@gmail.com>>:
Hi Sandy,

Responses in-line.

On Fri, Aug 11, 2017 at 1:38 AM, Sandy Zhang 
<sanzh...@celestica.com<mailto:sanzh...@celestica.com>> wrote:
Hi David,

 Sorry, I have a doubt about the range outside, from the binary map, we can 
find the Spare 3 Region size is 0x00FF - 0xFF + 1 = 0x1, and the 
binary size map to this range is also 0x1, they are equal, why outside was 
happened? and can you tell me how to update the binary region's range defined 
in the flash description?

Start (hex)End (hex)Length (hex)Area Name
-----
...
...

00FF   00FF 0001Spare 3 Region
0100   01FF 0100BIOS Region

The Flash Region registers (BIOS_FREGn) define the boundaries of each region. I 
don't see where 0xa36000-0xff is covered:
0x54: 0x FREG0: Flash Descriptor region (0x-0x0fff) is 
read-write.
0x58: 0x1fff1000 FREG1: BIOS region (0x0100-0x01ff) is read-write.
0x5C: 0x0a250003 FREG2: Management Engine region (0x3000-0x00a25fff) is 
read-write.
0x60: 0x00020001 FREG3: Gigabit Ethernet region (0x1000-0x2fff) is 
read-write.
0x64: 0x7fff FREG4: Platform Data region is unused.
0x68: 0x0a350a26 FREG5: unknown region (0x00a26000-0x00a35fff) is read-write.
0x6C: 0x7fff FREG6: unknown region is unused.
0x70: 0x7fff FREG7: unknown region is unused.
0x74: 0x7fff FREG8: unknown region is unused.
0x78: 0x7fff FREG9: unknown region is unused.

You might also need to set permissions for the "BIOS" master (i.e. flashrom 
running on the CPU) via BRWA and BRRA in the FRACC register.

 In addition, from flash log file(please see attachment 
"Lewisburg_W25Q256.log"), it shows:
Found Programmer flash chip "Opaque flash chip" (32768 kB, Programmer-specific) 
mapped at physical address 0x.
 but, my flash chip is "Winbond flash chip", what do you think about this?

This is OK. Intel hardware sequencing is an "opaque" programmer interface since 
flashrom does not directly send NOR flash commands via a raw SPI interface. For 
hardware sequencing we use the FCYCLE field as our command interface to the SPI 
flash.




--

Best Regard!

Sandy Zhang ( 张立康)
BIOS Engineer
Global Design Service
Celestica(Shanghai) R Center, China
Mail: sanzh...@celestica.com<mailto:viter...@celestica.com>
Mobile: (+86)15965353952<tel:+86%20159%206535%203952>
Phone: (+86)021-61006028-7623




--

Best Regard!

Sandy Zhang ( 张立康)
BIOS Engineer
Global Design Service
Celestica(Shanghai) R Center, China
Mail: sanzh...@celestica.com<mailto:viter...@celestica.com>
Mobile: (+86)15965353952
Phone: (+86)021-61006028-7623
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] Using libflashrom from fwupd

[David Hendricks]

On Tue, Aug 15, 2017 at 4:55 AM, Richard Hughes  wrote:

> Hi all,
>
> I'm the maintainer of fwupd, which is a daemon for doing firmware
> updates in Linux. Using fwupd about 200,000 people update firmware
> every month. At the moment I have an out-of-tree patch to use the
> flashrom CLI for updating coreboot on Purism laptops, which exec's a
> flashrom binary with the correct arguments and then screen scrapes the
> output. This is less than ideal. I saw the appearance of a libflashrom
> in the staging branch and got very excited. I'm assuming the long term
> goal here is to install a shared with stable API/ABI library and a
> pkg-config file. If so, please keep reading.
>
> One thing that is really important for fwupd is progress completion;
> as flashing the firmware is an inherently scary thing to do users do
> like to see a progress bar move from 0% to 100% in a gradual way as
> it's very re-assuring. This is even more important for the GUI, where
> people that just see a spinner don't know if the process is going to
> take 10 seconds, or 10 minutes.
>

Agreed! Especially since a lot of users have large chips, slow programmers,
or sometimes both. Simple read operations can take a worryingly long time
on some common hardware these days.


>
> Would it be possible to have a process callback for
> flashrom_image_read(), flashrom_image_write() and
> flashrom_image_verify()? It'd need to have some kind of callback
> userdata too, for instance:
>
> int flashrom_image_verify(struct flashrom_flashctx *, const void
> *buffer, size_t buffer_len, flashrom_progress_callback callback_fn,
> void *callback_user_data);
>
> and also:
>
> typedef void(flashrom_progress_callback)(uint64 completed, unit64
> total, void *user_data)
>

The short answer is yes. Nico also briefly mentioned an idea on IRC to use
a mechanism similar to flashrom_set_log_callback() to avoid complicating
function signatures for the read, write, and verify functions.


>
> I'm not familiar at all with flashrom internals, but could try to
> produce a patch if required -- although to propagate the progress
> through operations would mean patching a lot of chip->read() callbacks
> which probably requires a more experienced hand. Ideas welcome,
> thanks.
>
> Richard.
>
> ___
> flashrom mailing list
> flashrom@flashrom.org
> https://mail.coreboot.org/mailman/listinfo/flashrom
>
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] When flashrom support Intel Purley platform Lewisburg PCH?

[David Hendricks]

On Sun, Aug 13, 2017 at 6:26 PM, Sandy Zhang <sanzh...@celestica.com> wrote:

> Hi David,
>
> I'm inline.
>

I don't see your responses. Did you intend to reply to my comments?


>
> 2017-08-14 9:17 GMT+08:00 David Hendricks <david.hendri...@gmail.com>:
>
>> Hi Sandy,
>>
>> Responses in-line.
>>
>> On Fri, Aug 11, 2017 at 1:38 AM, Sandy Zhang <sanzh...@celestica.com>
>> wrote:
>>
>>> Hi David,
>>>
>>>  Sorry, I have a doubt about the range outside, from the binary map,
>>> we can find the Spare 3 Region size is 0x00FF - 0xFF + 1 = 0x1,
>>> and the binary size map to this range is also 0x1, they are equal, why
>>> outside was happened? and can you tell me how to update the binary region's
>>> range defined in the flash description?
>>>
>>> Start (hex)End (hex)Length (hex)Area Name
>>> -----
>>> ...
>>> ...
>>> 
>>> 00FF   00FF 0001Spare 3 Region
>>> 0100   01FF 0100BIOS Region
>>>
>>
>> The Flash Region registers (BIOS_FREGn) define the boundaries of each
>> region. I don't see where 0xa36000-0xff is covered:
>> 0x54: 0x FREG0: Flash Descriptor region (0x-0x0fff)
>> is read-write.
>> 0x58: 0x1fff1000 FREG1: BIOS region (0x0100-0x01ff) is read-write.
>> 0x5C: 0x0a250003 FREG2: Management Engine region (0x3000-0x00a25fff)
>> is read-write.
>> 0x60: 0x00020001 FREG3: Gigabit Ethernet region (0x1000-0x2fff)
>> is read-write.
>> 0x64: 0x7fff FREG4: Platform Data region is unused.
>> 0x68: 0x0a350a26 FREG5: unknown region (0x00a26000-0x00a35fff) is
>> read-write.
>> 0x6C: 0x7fff FREG6: unknown region is unused.
>> 0x70: 0x7fff FREG7: unknown region is unused.
>> 0x74: 0x7fff FREG8: unknown region is unused.
>> 0x78: 0x7fff FREG9: unknown region is unused.
>>
>> You might also need to set permissions for the "BIOS" master (i.e.
>> flashrom running on the CPU) via BRWA and BRRA in the FRACC register.
>>
>>  In addition, from flash log file(please see attachment
>>> "Lewisburg_W25Q256.log"), it shows:
>>> Found Programmer flash chip "Opaque flash chip" (32768 kB,
>>> Programmer-specific) mapped at physical address 0x.
>>>  but, my flash chip is "Winbond flash chip", what do you think about
>>> this?
>>>
>>
>> This is OK. Intel hardware sequencing is an "opaque" programmer interface
>> since flashrom does not directly send NOR flash commands via a raw SPI
>> interface. For hardware sequencing we use the FCYCLE field as our command
>> interface to the SPI flash.
>>
>>
>
>
> --
>
> *Best Regard!*
>
> *Sandy Zhang (* 张立康*)*
> *BIOS Engineer*
> *Global Design Service*
> *Celestica(Shanghai) R Center, China*
> *Mail: sanzh...@celestica.com <viter...@celestica.com>*
> *Mobile: (+86)15965353952 <+86%20159%206535%203952>*
> *Phone: (+86)021-61006028-7623*
>
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] When flashrom support Intel Purley platform Lewisburg PCH?

[David Hendricks]

Hi Sandy,

Responses in-line.

On Fri, Aug 11, 2017 at 1:38 AM, Sandy Zhang  wrote:

> Hi David,
>
>  Sorry, I have a doubt about the range outside, from the binary map,
> we can find the Spare 3 Region size is 0x00FF - 0xFF + 1 = 0x1,
> and the binary size map to this range is also 0x1, they are equal, why
> outside was happened? and can you tell me how to update the binary region's
> range defined in the flash description?
>
> Start (hex)End (hex)Length (hex)Area Name
> -----
> ...
> ...
> 
> 00FF   00FF 0001Spare 3 Region
> 0100   01FF 0100BIOS Region
>

The Flash Region registers (BIOS_FREGn) define the boundaries of each
region. I don't see where 0xa36000-0xff is covered:
0x54: 0x FREG0: Flash Descriptor region (0x-0x0fff) is
read-write.
0x58: 0x1fff1000 FREG1: BIOS region (0x0100-0x01ff) is read-write.
0x5C: 0x0a250003 FREG2: Management Engine region (0x3000-0x00a25fff) is
read-write.
0x60: 0x00020001 FREG3: Gigabit Ethernet region (0x1000-0x2fff) is
read-write.
0x64: 0x7fff FREG4: Platform Data region is unused.
0x68: 0x0a350a26 FREG5: unknown region (0x00a26000-0x00a35fff) is
read-write.
0x6C: 0x7fff FREG6: unknown region is unused.
0x70: 0x7fff FREG7: unknown region is unused.
0x74: 0x7fff FREG8: unknown region is unused.
0x78: 0x7fff FREG9: unknown region is unused.

You might also need to set permissions for the "BIOS" master (i.e. flashrom
running on the CPU) via BRWA and BRRA in the FRACC register.

 In addition, from flash log file(please see attachment
> "Lewisburg_W25Q256.log"), it shows:
> Found Programmer flash chip "Opaque flash chip" (32768 kB,
> Programmer-specific) mapped at physical address 0x.
>  but, my flash chip is "Winbond flash chip", what do you think about this?
>

This is OK. Intel hardware sequencing is an "opaque" programmer interface
since flashrom does not directly send NOR flash commands via a raw SPI
interface. For hardware sequencing we use the FCYCLE field as our command
interface to the SPI flash.
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] When flashrom support Intel Purley platform Lewisburg PCH?

[David Hendricks]

Hi Sandy,
That range is outside of what you have defined in your flash descriptor.
Can you update your flash descriptor to include it?

On Thu, Aug 10, 2017 at 4:43 AM, Sandy Zhang <sanzh...@celestica.com> wrote:

> Hi David,
>
> I have used your program to verify,  but it still can't flash, it prompts
> "Transaction error between offset 0x00ff and 0x00ff003f  (= 0x00ff003f
> + 63)"!
>
>
>
>
> 2017-08-10 15:29 GMT+08:00 David Hendricks <david.hendri...@gmail.com>:
>
>> Hi Sandy,
>> Recent Intel PCHs use hardware sequencing which abstracts a lot of
>> details about the chip. So we don't actually need flashrom to explicitly
>> support the W25Q256.
>>
>> Here is a tarball based on the latest sources from git:
>> https://drive.google.com/file/d/0Bz3WBh8gVeIuSlJYZ2c1bS1LdGc
>> /view?usp=sharing
>>
>> It has the following patches applied:
>> https://review.coreboot.org/#/c/20922/ : chispet_enable: Add PCI IDs for
>> C620-series PCHs
>> https://review.coreboot.org/#/c/20936/ : ich_descriptors: Modify limits
>> for C620/Lewisburg PCH
>> https://review.coreboot.org/#/c/20937/ : ich_descriptors: Fix off-by-one
>> error
>>
>> Let us know if it works for you.
>>
>>
>> On Wed, Aug 9, 2017 at 8:04 PM, Sandy Zhang <sanzh...@celestica.com>
>> wrote:
>>
>>> Hi David,
>>>
>>> I have get the package from the web, but I can't find the code about
>>> "25Q256" in flashchip.c, so, maybe this will lead to flash fail.
>>>
>>> 2017-08-09 15:11 GMT+08:00 Sandy Zhang <sanzh...@celestica.com>:
>>>
>>>> Hi David,
>>>>
>>>> Yes, My system's ISA/LPC vendor id and device id is 8086:a1c6,
>>>> In fact, I can't access the clone https://review.coreboot.
>>>> org/flashrom.git,  I attempt to add the patch to flashrom-0.9.9, but I
>>>> found the difference is a bit big between these files, I'm very hard to add
>>>> the patch completely, so, could you send the latest package to me to try
>>>> this on my system?
>>>> Thanks for your great help!
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 2017-08-09 14:04 GMT+08:00 David Hendricks <david.hendri...@gmail.com>:
>>>>
>>>>> Hi Sandy,
>>>>> What is the result of `lspci -nn | grep ISA` on your system? I
>>>>> uploaded a patch for Lewisburg PCI IDs here: https://review.coreboot.
>>>>> org/#/c/20922/
>>>>>
>>>>> I have tested Lewisburg PCH + W25Q256xxx and it seems to work. Let me
>>>>> know if you need any help applying the patch and testing it out on your
>>>>> system.
>>>>>
>>>>>
>>>>> On Tue, Aug 8, 2017 at 7:09 PM, Sandy Zhang <sanzh...@celestica.com>
>>>>> wrote:
>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>> Do you know whether the configuration "Lewisburg PCH + W25Q256xxx
>>>>>> SPI" has been tested with the flashrom? thank you!
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2017-08-08 3:55 GMT+08:00 David Hendricks <david.hendri...@gmail.com>
>>>>>> :
>>>>>>
>>>>>>> Hi Sandy,
>>>>>>> Correct - The PCH will not allow us to write anything to regions
>>>>>>> which are not defined in the flash descriptor. You could add those 
>>>>>>> regions
>>>>>>> to the "BIOS" region if you wish to update them from your host OS. The 
>>>>>>> SPI
>>>>>>> Programming Guide for your PCH (Lewisburg?) should also have info about
>>>>>>> additional regions which you may set up in the flash descriptor.
>>>>>>>
>>>>>>> "EW" means erase and write, "S" means skip (content does not need to
>>>>>>> change), "E" means erase only, "W" means write only
>>>>>>>
>>>>>>> On Mon, Aug 7, 2017 at 12:50 AM, Sandy Zhang <sanzh...@celestica.com
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>> It seems that the below 2 regions are "write denied":
>>>>>>

Re: [flashrom] When flashrom support Intel Purley platform Lewisburg PCH?

[David Hendricks]

Hi Sandy,
Recent Intel PCHs use hardware sequencing which abstracts a lot of details
about the chip. So we don't actually need flashrom to explicitly support
the W25Q256.

Here is a tarball based on the latest sources from git:
https://drive.google.com/file/d/0Bz3WBh8gVeIuSlJYZ2c1bS1LdGc/view?usp=sharing

It has the following patches applied:
https://review.coreboot.org/#/c/20922/ : chispet_enable: Add PCI IDs for
C620-series PCHs
https://review.coreboot.org/#/c/20936/ : ich_descriptors: Modify limits for
C620/Lewisburg PCH
https://review.coreboot.org/#/c/20937/ : ich_descriptors: Fix off-by-one
error

Let us know if it works for you.


On Wed, Aug 9, 2017 at 8:04 PM, Sandy Zhang <sanzh...@celestica.com> wrote:

> Hi David,
>
> I have get the package from the web, but I can't find the code about
> "25Q256" in flashchip.c, so, maybe this will lead to flash fail.
>
> 2017-08-09 15:11 GMT+08:00 Sandy Zhang <sanzh...@celestica.com>:
>
>> Hi David,
>>
>> Yes, My system's ISA/LPC vendor id and device id is 8086:a1c6,
>> In fact, I can't access the clone https://review.coreboot.
>> org/flashrom.git,  I attempt to add the patch to flashrom-0.9.9, but I
>> found the difference is a bit big between these files, I'm very hard to add
>> the patch completely, so, could you send the latest package to me to try
>> this on my system?
>> Thanks for your great help!
>>
>>
>>
>>
>>
>>
>> 2017-08-09 14:04 GMT+08:00 David Hendricks <david.hendri...@gmail.com>:
>>
>>> Hi Sandy,
>>> What is the result of `lspci -nn | grep ISA` on your system? I uploaded
>>> a patch for Lewisburg PCI IDs here: https://review.coreboot.
>>> org/#/c/20922/
>>>
>>> I have tested Lewisburg PCH + W25Q256xxx and it seems to work. Let me
>>> know if you need any help applying the patch and testing it out on your
>>> system.
>>>
>>>
>>> On Tue, Aug 8, 2017 at 7:09 PM, Sandy Zhang <sanzh...@celestica.com>
>>> wrote:
>>>
>>>> Hi David,
>>>>
>>>> Do you know whether the configuration "Lewisburg PCH + W25Q256xxx SPI"
>>>> has been tested with the flashrom? thank you!
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 2017-08-08 3:55 GMT+08:00 David Hendricks <david.hendri...@gmail.com>:
>>>>
>>>>> Hi Sandy,
>>>>> Correct - The PCH will not allow us to write anything to regions which
>>>>> are not defined in the flash descriptor. You could add those regions to 
>>>>> the
>>>>> "BIOS" region if you wish to update them from your host OS. The SPI
>>>>> Programming Guide for your PCH (Lewisburg?) should also have info about
>>>>> additional regions which you may set up in the flash descriptor.
>>>>>
>>>>> "EW" means erase and write, "S" means skip (content does not need to
>>>>> change), "E" means erase only, "W" means write only
>>>>>
>>>>> On Mon, Aug 7, 2017 at 12:50 AM, Sandy Zhang <sanzh...@celestica.com>
>>>>> wrote:
>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>> It seems that the below 2 regions are "write denied":
>>>>>>
>>>>>> 00A26000   00A35FFF 0001DER #1 Region
>>>>>> 00A36000   00FE 005BA00010 Gbe A Region
>>>>>>
>>>>>> By the way, can you tell me what is the other parament "EW", "S" and
>>>>>> "E" meana? thank you!
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2017-08-07 13:02 GMT+08:00 David Hendricks <david.hendri...@gmail.com
>>>>>> >:
>>>>>>
>>>>>>> Hi Sandy,
>>>>>>> It might not have done what you expect. The error is because offsets
>>>>>>> 0xa26000-0xff are not defined in the flash descriptor, so the PCH 
>>>>>>> gives
>>>>>>> us an error when flashrom attempts to update it. ":WD" next to the 
>>>>>>> offsets
>>>>>>> in the log means "write denied".
>>>>>>>
>>>>>>> If you wish to update that region of the ROM then you must change
>>>>>>> your flash descriptor to include it and set the permissi

Re: [flashrom] flash verification failure over and over

[David Hendricks]

On Wed, Aug 9, 2017 at 8:22 AM, Ian Stewart  wrote:

> Thanks David,
>
> Yes, the chip is detected and I'm able to read the chip just fine.  Would
> this indicate everything is hooked up properly?  Or could missing the /HOLD
> /WP /RESET cause write issues, but not read issues?  Knowing that would
> really help.
>

In general, yes, the behavior for disconnected inputs is undefined. Some
chips (like the Winbond W25Q-series) have internal pull resistors that
allow for pins to be left disconnected (the datasheet explicitly mentions
those). I don't see that in the Macronix datasheet though.
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] "Intel Braswell" with PCI ID 8086:229c

[David Hendricks]

Thanks!

Patch to mark Braswell as tested: https://review.coreboot.org/#/c/20923/

On Mon, Aug 7, 2017 at 6:06 AM, Vieweg, Uwe  wrote:

> Dear Ladies and Gentlemen.
>
> *”**Found chipset "Intel Braswell" with PCI ID 8086:229c.* *This chipset
> is marked as **untested*
>
> We can verify the successful usage with a Braswell (N3160) prototype
> board. BIOS AMI.
>
> sudo flashrom -V --programmer internal:laptop=this_is_not_a_laptop -c
> W25Q64.W -w test.img
> sudo flashrom -V --programmer internal:laptop=this_is_not_a_laptop  -r
> test.img
>
> Read/Write to W25Q64 8Mbyte 1.8V
> Without specifying chip:
> Thank you very much for your work.
>
> With best regards,
> Uwe Vieweg
>
> Siemens AG
> Digital Factory Division
> Factory Automation
> HiMed
> DF FA SE R HM
> Breslauer Str. 5
> 90766 Fuerth, Germany
> Tel.: +49 911 750-9839 <+49%20911%207509839>
> Fax: +49 911 750-9800 <+49%20911%207509800>
> Mail uwe dot vieweg at siemens dot com
> *www.siemens.com/ingenuityforlife*
> 
>
> Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard
> Cromme; Managing Board: Joe Kaeser, Chairman, President and Chief Executive
> Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik
> Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich,
> Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich,
> HRB 6684; WEEE-Reg.-No. DE 23691322
>
>
> ___
> flashrom mailing list
> flashrom@flashrom.org
> https://mail.coreboot.org/mailman/listinfo/flashrom
>
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] When flashrom support Intel Purley platform Lewisburg PCH?

[David Hendricks]

Hi Sandy,
What is the result of `lspci -nn | grep ISA` on your system? I uploaded a
patch for Lewisburg PCI IDs here: https://review.coreboot.org/#/c/20922/

I have tested Lewisburg PCH + W25Q256xxx and it seems to work. Let me know
if you need any help applying the patch and testing it out on your system.


On Tue, Aug 8, 2017 at 7:09 PM, Sandy Zhang <sanzh...@celestica.com> wrote:

> Hi David,
>
> Do you know whether the configuration "Lewisburg PCH + W25Q256xxx SPI" has
> been tested with the flashrom? thank you!
>
>
>
>
>
>
> 2017-08-08 3:55 GMT+08:00 David Hendricks <david.hendri...@gmail.com>:
>
>> Hi Sandy,
>> Correct - The PCH will not allow us to write anything to regions which
>> are not defined in the flash descriptor. You could add those regions to the
>> "BIOS" region if you wish to update them from your host OS. The SPI
>> Programming Guide for your PCH (Lewisburg?) should also have info about
>> additional regions which you may set up in the flash descriptor.
>>
>> "EW" means erase and write, "S" means skip (content does not need to
>> change), "E" means erase only, "W" means write only
>>
>> On Mon, Aug 7, 2017 at 12:50 AM, Sandy Zhang <sanzh...@celestica.com>
>> wrote:
>>
>>> Hi David,
>>>
>>> It seems that the below 2 regions are "write denied":
>>>
>>> 00A26000   00A35FFF     0001DER #1 Region
>>> 00A36000   00FE 005BA00010 Gbe A Region
>>>
>>> By the way, can you tell me what is the other parament "EW", "S" and "E"
>>> meana? thank you!
>>>
>>>
>>>
>>>
>>> 2017-08-07 13:02 GMT+08:00 David Hendricks <david.hendri...@gmail.com>:
>>>
>>>> Hi Sandy,
>>>> It might not have done what you expect. The error is because offsets
>>>> 0xa26000-0xff are not defined in the flash descriptor, so the PCH gives
>>>> us an error when flashrom attempts to update it. ":WD" next to the offsets
>>>> in the log means "write denied".
>>>>
>>>> If you wish to update that region of the ROM then you must change your
>>>> flash descriptor to include it and set the permissions to enable read and
>>>> write.
>>>>
>>>>
>>>> On Sun, Aug 6, 2017 at 8:20 PM, Sandy Zhang <sanzh...@celestica.com>
>>>> wrote:
>>>>
>>>>> Hi David,
>>>>>
>>>>> Attachment is the log file when flash bios into Winbond 32MB SPI rom,
>>>>>  could you help to check if it's updated sucessfully? thank you!
>>>>>
>>>>> 2017-08-05 10:45 GMT+08:00 Sandy Zhang <sanzh...@celestica.com>:
>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>> Thank you very much, I will try to add the patch to flashrom-0.9.9,
>>>>>> As a BIOS engineer, it is a bit difficult for me to complete this.
>>>>>> Do you know when will make it into a release tarball?
>>>>>>
>>>>>>
>>>>>>
>>>>>> BR
>>>>>> Sandy
>>>>>>
>>>>>> 2017-08-05 0:05 GMT+08:00 David Hendricks <david.hendri...@gmail.com>
>>>>>> :
>>>>>>
>>>>>>> On Aug 3, 2017 11:51 PM, "Sandy Zhang" <sanzh...@celestica.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>> Thanks for your reply, can you tell me where to download the flash
>>>>>>>> package like "flashrom-0.9.9.tar" which is downloaded from the address 
>>>>>>>> ''
>>>>>>>> https://www.flashrom.org/Downloads;?  thank you!
>>>>>>>>
>>>>>>>
>>>>>>> The Skylake patches have not made it into a release tarball yet. Can
>>>>>>> you try using the git sources from https://review.coreboot.o
>>>>>>> rg/cgit/flashrom.git? E.g:
>>>>>>>
>>>>>>> git clone https://review.coreboot.org/flashrom.git
>>>>>>> git checkout origin/staging
>>>>>>> make
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>

Re: [flashrom] When flashrom support Intel Purley platform Lewisburg PCH?

[David Hendricks]

Hi Sandy,
It might not have done what you expect. The error is because offsets
0xa26000-0xff are not defined in the flash descriptor, so the PCH gives
us an error when flashrom attempts to update it. ":WD" next to the offsets
in the log means "write denied".

If you wish to update that region of the ROM then you must change your
flash descriptor to include it and set the permissions to enable read and
write.


On Sun, Aug 6, 2017 at 8:20 PM, Sandy Zhang <sanzh...@celestica.com> wrote:

> Hi David,
>
> Attachment is the log file when flash bios into Winbond 32MB SPI rom,
>  could you help to check if it's updated sucessfully? thank you!
>
> 2017-08-05 10:45 GMT+08:00 Sandy Zhang <sanzh...@celestica.com>:
>
>> Hi David,
>>
>> Thank you very much, I will try to add the patch to flashrom-0.9.9, As a
>> BIOS engineer, it is a bit difficult for me to complete this.
>> Do you know when will make it into a release tarball?
>>
>>
>>
>> BR
>> Sandy
>>
>> 2017-08-05 0:05 GMT+08:00 David Hendricks <david.hendri...@gmail.com>:
>>
>>> On Aug 3, 2017 11:51 PM, "Sandy Zhang" <sanzh...@celestica.com> wrote:
>>>
>>>> Hi David,
>>>>
>>>> Thanks for your reply, can you tell me where to download the flash
>>>> package like "flashrom-0.9.9.tar" which is downloaded from the address ''
>>>> https://www.flashrom.org/Downloads;?  thank you!
>>>>
>>>
>>> The Skylake patches have not made it into a release tarball yet. Can you
>>> try using the git sources from https://review.coreboot.o
>>> rg/cgit/flashrom.git? E.g:
>>>
>>> git clone https://review.coreboot.org/flashrom.git
>>> git checkout origin/staging
>>> make
>>>
>>>
>>>>
>>>>
>>>>
>>>> BR
>>>> Sandy
>>>>
>>>> 2017-08-04 14:35 GMT+08:00 David Hendricks <david.hendri...@gmail.com>:
>>>>
>>>>> Hi Sandy,
>>>>> Skylake support was recently merged: https://review.coreboot.org/18973
>>>>>
>>>>> However you may need to add your PCH PCI ID. What does `lspci -nn |
>>>>> grep LPC` show on your test system?
>>>>>
>>>>> And yes, a 32MB ROM should work fine.
>>>>>
>>>>> On Mon, Jul 31, 2017 at 4:11 AM, Sandy Zhang <sanzh...@celestica.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Can you tell me when flashrom support Intel Purley platform Lewisburg
>>>>>> PCH?
>>>>>> and if it can support flash 32 MB SPI rom?
>>>>>>  I am eager to your reply as soon as possible, thank you very much!
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> *Best Regard!*
>>>>>>
>>>>>> *Sandy Zhang (* 张立康*)*
>>>>>> *BIOS Engineer*
>>>>>> *Global Design Service*
>>>>>> *Celestica(Shanghai) R Center, China*
>>>>>> *Mail: sanzh...@celestica.com <viter...@celestica.com>*
>>>>>> *Mobile: (+86)15965353952 <+86%20159%206535%203952>*
>>>>>> *Phone: (+86)021-61006028-7623*
>>>>>>
>>>>>> ___
>>>>>> flashrom mailing list
>>>>>> flashrom@flashrom.org
>>>>>> https://mail.coreboot.org/mailman/listinfo/flashrom
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *Best Regard!*
>>>>
>>>> *Sandy Zhang (* 张立康*)*
>>>> *BIOS Engineer*
>>>> *Global Design Service*
>>>> *Celestica(Shanghai) R Center, China*
>>>> *Mail: sanzh...@celestica.com <viter...@celestica.com>*
>>>> *Mobile: (+86)15965353952 <+86%20159%206535%203952>*
>>>> *Phone: (+86)021-61006028-7623*
>>>>
>>>
>>
>>
>> --
>>
>> *Best Regard!*
>>
>> *Sandy Zhang (* 张立康*)*
>> *BIOS Engineer*
>> *Global Design Service*
>> *Celestica(Shanghai) R Center, China*
>> *Mail: sanzh...@celestica.com <viter...@celestica.com>*
>> *Mobile: (+86)15965353952 <+86%20159%206535%203952>*
>> *Phone: (+86)021-61006028-7623*
>>
>
>
>
> --
>
> *Best Regard!*
>
> *Sandy Zhang (* 张立康*)*
> *BIOS Engineer*
> *Global Design Service*
> *Celestica(Shanghai) R Center, China*
> *Mail: sanzh...@celestica.com <viter...@celestica.com>*
> *Mobile: (+86)15965353952 <+86%20159%206535%203952>*
> *Phone: (+86)021-61006028-7623*
>
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] When flashrom support Intel Purley platform Lewisburg PCH?

[David Hendricks]

On Aug 3, 2017 11:51 PM, "Sandy Zhang" <sanzh...@celestica.com> wrote:

> Hi David,
>
> Thanks for your reply, can you tell me where to download the flash package
> like "flashrom-0.9.9.tar" which is downloaded from the address ''
> https://www.flashrom.org/Downloads;?  thank you!
>

The Skylake patches have not made it into a release tarball yet. Can you
try using the git sources from https://review.coreboot.org/cgit/flashrom.git?
E.g:

git clone https://review.coreboot.org/flashrom.git
git checkout origin/staging
make


>
>
>
> BR
> Sandy
>
> 2017-08-04 14:35 GMT+08:00 David Hendricks <david.hendri...@gmail.com>:
>
>> Hi Sandy,
>> Skylake support was recently merged: https://review.coreboot.org/18973
>>
>> However you may need to add your PCH PCI ID. What does `lspci -nn | grep
>> LPC` show on your test system?
>>
>> And yes, a 32MB ROM should work fine.
>>
>> On Mon, Jul 31, 2017 at 4:11 AM, Sandy Zhang <sanzh...@celestica.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Can you tell me when flashrom support Intel Purley platform Lewisburg
>>> PCH?
>>> and if it can support flash 32 MB SPI rom?
>>>  I am eager to your reply as soon as possible, thank you very much!
>>>
>>>
>>> --
>>>
>>> *Best Regard!*
>>>
>>> *Sandy Zhang (* 张立康*)*
>>> *BIOS Engineer*
>>> *Global Design Service*
>>> *Celestica(Shanghai) R Center, China*
>>> *Mail: sanzh...@celestica.com <viter...@celestica.com>*
>>> *Mobile: (+86)15965353952 <+86%20159%206535%203952>*
>>> *Phone: (+86)021-61006028-7623*
>>>
>>> ___
>>> flashrom mailing list
>>> flashrom@flashrom.org
>>> https://mail.coreboot.org/mailman/listinfo/flashrom
>>>
>>
>>
>
>
> --
>
> *Best Regard!*
>
> *Sandy Zhang (* 张立康*)*
> *BIOS Engineer*
> *Global Design Service*
> *Celestica(Shanghai) R Center, China*
> *Mail: sanzh...@celestica.com <viter...@celestica.com>*
> *Mobile: (+86)15965353952 <+86%20159%206535%203952>*
> *Phone: (+86)021-61006028-7623*
>
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] When flashrom support Intel Purley platform Lewisburg PCH?

[David Hendricks]

Hi Sandy,
Skylake support was recently merged: https://review.coreboot.org/18973

However you may need to add your PCH PCI ID. What does `lspci -nn | grep
LPC` show on your test system?

And yes, a 32MB ROM should work fine.

On Mon, Jul 31, 2017 at 4:11 AM, Sandy Zhang  wrote:

> Hi,
>
> Can you tell me when flashrom support Intel Purley platform Lewisburg PCH?
> and if it can support flash 32 MB SPI rom?
>  I am eager to your reply as soon as possible, thank you very much!
>
>
> --
>
> *Best Regard!*
>
> *Sandy Zhang (* 张立康*)*
> *BIOS Engineer*
> *Global Design Service*
> *Celestica(Shanghai) R Center, China*
> *Mail: sanzh...@celestica.com *
> *Mobile: (+86)15965353952 <+86%20159%206535%203952>*
> *Phone: (+86)021-61006028-7623*
>
> ___
> flashrom mailing list
> flashrom@flashrom.org
> https://mail.coreboot.org/mailman/listinfo/flashrom
>
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] Larger SPI NOR flash parts

[David Hendricks]

On Wed, Jun 21, 2017 at 6:51 PM, Ed Swierk <eswi...@skyportsystems.com>
wrote:

> On Mon, Apr 17, 2017 at 9:54 PM, David Hendricks
> <david.hendri...@gmail.com> wrote:
> > Getting 4-byte address support in is something I'm interested in as
> well. In fact I have parts coming in the mail this week :-)
> >
> > On Mon, Apr 17, 2017 at 6:43 PM, Alex Henderson <
> ahender...@aparnasystems.com> wrote:
> >>
> >> Hi there:
> >>
> >>I just started experimenting with flashrom using a
> Dediprog SF600 this weekend. I noticed that there’s no support for any of
> the 256Mb or 512Mb SPI NOR parts (4 byte addressing an issue?).
> >
> >
> > The Dediprog SF600 has commands for 4-byte addressing, but I was not
> able to get them working in the time I had to play with it. We can probably
> also ask Dediprog if they have an updated command spec, maybe there was a
> problem in the one I was looking at.
> >
> >>
> >> Is there a newer version than 0.9.9 that I should try? I did find that
> the Google fork for chromeOS has a number of these parts (W25Q256, N25Q256,
> SST_25F256).
> >
> >
> > Yes, but the systems those went in treated them as 16MB parts. The
> firmware (coreboot) is small so there wasn't really need for the extra
> space.
> >
> >>I would be happy to try an unreleased version & report
> results. I can also test with an FTDI232 based programmer. The boards I can
> test with currently have various versions of 25q512, 25q256, 25q128 and
> 25q32. Functionality with the smaller parts looks good.
>
> I'm a bit late to the party here, but in case it's relevant: I
> successfully programmed a Micron N25Q512, which is a 64 MByte SPI
> flash with 4-byte addressing, using patches originally from Boris
> Baykov on top of a more current flashrom. See
> https://github.com/skyportsystems/flashrom/commits/master .
>
> Both FT232H module and STM32 Blue Pill board with stm32-vserprog
> firmware work as programmers.
>

Nice! I've also had success with Boris's patches, as have others:
https://review.coreboot.org/#/c/19525/ . That version is squashed, though,
so perhaps the patches in your repo will be better for merging.

I also uploaded a patch to enable 4BA support on the Dediprog SF600 which
Alex might be interested in trying out:
https://review.coreboot.org/#/c/19858/
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

[flashrom] Flashrom and DirectHW on MacOS

[David Hendricks]

I am interested in getting flashrom running on MacOS, but it seems that the
DirectHW package [1] which it depends on hasn't been updated for quite some
time and won't install on Sierra (10.12.4).

There's an updated branch of DirectHW from PureDarwin [2] that resolves
compilation errors due to Xcode changes. However it doesn't update the
packager from packagemaker to pkgbuild and productbuild.

I'm a Mac n00b and didn't get far trying to make it all work, and was
curious if there's anyone who would like to take a swing at this. Getting
DirectHW updated will also help with other low-level tools. I'd be happy to
help test and get patches committed.

[1] https://review.coreboot.org/cgit/directhw.git
[2] https://github.com/PureDarwin/DirectHW
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] Namespace prefix for libflashrom

[David Hendricks]

On Sun, Apr 23, 2017 at 7:07 AM, Stefan Tauner <stefan.tau...@gmx.at> wrote:

> On Sat, 22 Apr 2017 11:16:18 -0700
> David Hendricks <david.hendri...@gmail.com> wrote:
>
> > Thanks for getting this discussion going on the list, Nico.
> >
> > For reference, folks can view the proposed libflashrom.h at
> > https://review.coreboot.org/#/c/17946 to get a better idea for how these
> > prefixes will look in libflashrom functions and data structures.
> >
> > Also, let's add "fi_" for flashrom interface to the list of proposed
> > prefixes.
> >
> > My preferences (in order):
> > 1. lf_
> > 2. flashrom_
> > 3. fi_
> > 4. fl_
> > 5. flash_
> > 6. fr_
> >
> > IMO not only is "lf_" most intuitive, but the way the keys are spaced
> apart
> > comfortably on qwerty, dvorak, and colemak layouts and each character
> > (including the underscore) use a different hand to type. Same could be
> said
> > about fl_ with regards to keyboard layout. fr_ is awkward (keys
> vertically
> > adjacent) on qwerty and colemak, and fi_ is vertically adjacent on
> dvorak.
> > flash_ and flashrom_ are not bad but are obviously many more keystrokes.
>
> I value giving thoughts to details, but in this case I reside more with
> torvalds: "if your typing speed is the main issue when you're coding,
> you're doing something seriously wrong."
>
> In my opinion the prefix has to satisfy a number of requirements:
>
>  - no ISO C(99/11) or POSIX violations
>  - no easy collisions with other libraries or user functions
>  - easily recognizable prefix for humans associated with the concept of
>libflashrom (i.e. some kind of abstraction to interact with NOR
>flash chips via different programmers)
>  - reasonable short length to avoid overly long function names etc.
>based on the prefix
>
> > flash_ is pretty good - For the most part it flows well with functions
> such
> > as flash_image_read() and flash_image_write(), but is awkward with some
> > other stuff like "flash_set_log_callback()". If we're already typing >2
> > letters I think we ought to just use flashrom_ as the prefix to be
> > complete, avoid awkward contexts, and avoid namespace conflicts (users
> > might want to use flash_ in their code).
>
> flash_ seems to me a bit too concrete... it gets (too) easily associated
> with the actual memory device and not so much to libflashrom IMHO.
>

Agreed.


> flashrom_ is quite long and would be associated with flashrom (the
> utility) and would make it harder to distinguishing the library from
> the program.
>

I don't see why that distinction is important.

libflashrom_ is probably too long but would at least transport the
> meaning best in my opinion.
>

Agreed. And if a user of the library really hates typing that many letters
then they can create trivial wrappers.


>
> So... shorter but conveying the same meaning:
>
>  - lflashrom, lfrom: meh
>  - lflashr: would require a new awful website with flash chips dancing
>for no good reason ;)
>  - lf: was already mentioned, I deem it a bit too short and ambiguous
>  - fl: too easily misinterpreted as a flashrom function prefix IMHO -
>the aspect of being a library is important to me.
>  - libf: would be in the tradition of short-named unix libraries (and
>seems to be unused actually as a library name), but does not really
>improve on lf and would make it look way too important than it is :)
>  - lfr: was proposed in the wiki, possibly by myself - can't remember.
>This might be the optimal compromise: intuitive if you heard it
>once, probably quite unique and very short.
>  - lfl: might also work if neither lfr nor lf are acceptable (but why
>would lfl then be :)
>
> Thus my favorites are basically
>  - lfr_
>  - libflashrom_
>  - lf_
>
> I'd love to hear some arguments about your preferences.


I'd be fine with libflashrom_. Since it seems there is no definitive
favorite short prefix I think we should just forget about those and use a
longer one. And in the grand scheme of things neither libflashrom_ nor
flashrom_ are very long.

For the public API we just need to pick something that's intuitive and
unlikely to collide. The user can always write shorthand wrappers that fit
into their program's namespace if they call the library functions often
enough to make the extra characters feel burdensome.
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] Namespace prefix for libflashrom

[David Hendricks]

Thanks for getting this discussion going on the list, Nico.

For reference, folks can view the proposed libflashrom.h at
https://review.coreboot.org/#/c/17946 to get a better idea for how these
prefixes will look in libflashrom functions and data structures.

Also, let's add "fi_" for flashrom interface to the list of proposed
prefixes.

My preferences (in order):
1. lf_
2. flashrom_
3. fi_
4. fl_
5. flash_
6. fr_

IMO not only is "lf_" most intuitive, but the way the keys are spaced apart
comfortably on qwerty, dvorak, and colemak layouts and each character
(including the underscore) use a different hand to type. Same could be said
about fl_ with regards to keyboard layout. fr_ is awkward (keys vertically
adjacent) on qwerty and colemak, and fi_ is vertically adjacent on dvorak.
flash_ and flashrom_ are not bad but are obviously many more keystrokes.

The problem I have with fl_ is that it is also used for flash layout
structs: https://review.coreboot.org/#/c/17944/4/layout.h . The layout
structs are used internally and can be changed easily, though.

flash_ is pretty good - For the most part it flows well with functions such
as flash_image_read() and flash_image_write(), but is awkward with some
other stuff like "flash_set_log_callback()". If we're already typing >2
letters I think we ought to just use flashrom_ as the prefix to be
complete, avoid awkward contexts, and avoid namespace conflicts (users
might want to use flash_ in their code).


On Sat, Apr 22, 2017 at 9:42 AM, Nico Huber  wrote:

> Hi flashrom folks,
>
> working again on implementing the libflashrom interface described here
> [1]. During review [2] the question arose what `fl_` means and if we
> don't want to use something else. The following alternatives were pro-
> posed in the wiki:
>
>   * fl_ / FL_ (probably *fl*ashrom)
>   * lf_ / LF_ (*l*ib *f*lashrom)
>   * lfr_ / LFR_ (*l*ib *f*lash *r*om)
>   * rom_ / ROM_
>
> IIRC, on IRC the following was proposed:
>
>   * fr_ / FR_ (*f*lash *r*om)
>
> I don't think it has to be an acronym, so I'd add:
>
>   * flash_ / FLASH_
>   * flashrom_ / FLASHROM_
>
> My personal preference would be either `fr_` or `flash_`.
>
> I think this will be open for discussion only for few days. Moving
> forward is currently more important than finding the perfect name.
>
> Best regards,
> Nico
>
> [1] https://www.flashrom.org/Libflashrom
> [2] https://review.coreboot.org/#/c/17946/
>
> ___
> flashrom mailing list
> flashrom@flashrom.org
> https://mail.coreboot.org/mailman/listinfo/flashrom
>
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] Larger SPI NOR flash parts

[David Hendricks]

Hi Alex,
Getting 4-byte address support in is something I'm interested in as well.
In fact I have parts coming in the mail this week :-)

On Mon, Apr 17, 2017 at 6:43 PM, Alex Henderson <
ahender...@aparnasystems.com> wrote:

> Hi there:
>
>I just started experimenting with flashrom using a Dediprog
> SF600 this weekend. I noticed that there’s no support for any of the 256Mb
> or 512Mb SPI NOR parts (4 byte addressing an issue?).
>

The Dediprog SF600 has commands for 4-byte addressing, but I was not able
to get them working in the time I had to play with it. We can probably also
ask Dediprog if they have an updated command spec, maybe there was a
problem in the one I was looking at.


> Is there a newer version than 0.9.9 that I should try? I did find that the
> Google fork for chromeOS has a number of these parts (W25Q256, N25Q256,
> SST_25F256).
>

Yes, but the systems those went in treated them as 16MB parts. The firmware
(coreboot) is small so there wasn't really need for the extra space.

   I would be happy to try an unreleased version & report
> results. I can also test with an FTDI232 based programmer. The boards I can
> test with currently have various versions of 25q512, 25q256, 25q128 and
> 25q32. Functionality with the smaller parts looks good.
>

Great! We've got some pending patches for you to try, then...

For the chromiumos branch, try this patch series:
https://chromium-review.googlesource.com/c/323359/ (Click "Download" and
then you can just checkout the full thing).
For upstream, try this: https://mail.coreboot.org/pipe
rmail/flashrom/2016-April/014579.html

The thing to keep in mind is that there are at least three ways in which
4-byte addressing is handled, and the method depends on the chip:
- The chip uses the same instructions for 3-byte and 4-byte operations, but
has a status/control register bit that extends the address to 4-bytes.
("Mode 1" in my patch)
- The chip has separate instructions for operations using 3-byte and 4-byte
addresses. ("Mode 2" in my patch)
- The chip only supports 4-byte instructions; 3-byte instructions are not
even implemented (The style that Tim's patch addressed)

For chromiumos:
1. Clone the flashrom repo: https://chromium.googles
ource.com/chromiumos/third_party/flashrom/
2. cd to the newly created directory (e.g. cd flashrom/)
3. Checkout the patch series:
a. Go to https://chromium-review.googlesource.com/c/323359
b. Click "Download"
c. Copy these the "Checkout" command and paste it into your
terminal.
___
flashrom mailing list
flashrom@flashrom.org
https://mail.coreboot.org/mailman/listinfo/flashrom

Re: [flashrom] question on padding

[David Hendricks]

That comes up once in a while, but the idea usually gets shot down
because the size check is more important for the general case.
Deciding whether to place the content at the top or bottom is another
matter.

For chromiumos I added a command to get the flash chip's size
(--get-size IIRC) so that the user can easily create an image of the
appropriate size and dd the content in place. One could also create a
layout file and do a partial write using "-i region:" syntax
which will only check that the file matches the size of the specified
region.

On Thu, Mar 30, 2017 at 11:09 AM, ron minnich  wrote:
> has anyone ever looked at flashing an image smaller than the part and
> auto-padding it? Someone just asked me about that.
>
> ___
> flashrom mailing list
> flashrom@flashrom.org
> https://www.flashrom.org/mailman/listinfo/flashrom

___
flashrom mailing list
flashrom@flashrom.org
https://www.flashrom.org/mailman/listinfo/flashrom

Re: [flashrom] Terminology to help distinguish different ways of using Flashrom

[David Hendricks]

On Sun, Mar 19, 2017 at 10:42 AM, Sam Kuper  wrote:
> Is there a term that unambiguously describes method 2(b)?

Just to clarify, in that situation is the ROM is in a dedicated programmer
such as http://www.dediprog.com/pd/universal-programmer/progmaster-u4 ? I'd
describe it as "standalone."
___
flashrom mailing list
flashrom@flashrom.org
https://www.flashrom.org/mailman/listinfo/flashrom

Re: [flashrom] Layout Aware Flash Reading and Erase Blocks

[David Hendricks]

On Fri, Mar 10, 2017 at 8:02 AM, Nico Huber  wrote:
>
> Hi,
>
> I've just updated my solution to _the_ layout problem that I wrote last
> year [1]. I'm not asking for a review at this moment. There are at least
> two competing approaches that I want to discuss first (I couldn't start
> a discussion before I wrote it, due to time constraints).
>
> We can
>
>   1) walk over the given layout regions in an outer loop and
> walk over the erase blocks in each region in an inner loop
>
>  This is how my patch tackles it.
>
> or
>
>   2) walk over all erase blocks in an outer loop and
> walk over the touched layout regions in an inner loop
>
> Thoughts?
>
> Both sounds easy to do but it gets really complicated when you account
> for a) regions that are not erase block aligned, b) our fallback to dif-
> ferent erase functions (and blocks thereby) and c) read-locks that might
> render a) impossible.


I think the second approach results in an extra layer of logic that really
isn't needed. With the first, we:
1. We find what needs to change
2. Select the appropriate block eraser
3. Do the work.

The second approach requires selecting a block erase size beforehand for
the outer loop, and that blockerase size might not be the one we want to
use to actually do the work (especially with the unaligned and optimized
cases).

>
> One pretty simple solution would be to exclude unaligned layout regions.
> How about this? anybody ever needed it?

Historically some ChromeOS devices have had unaligned layout regions.
Generally speaking, excluding them would impose an artificial limitation on
the images that flashrom can handle that will just bite users. Layout
regions might be defined automatically by a firmware's build system without
awareness of a particular flash chip's blockerase sizes, or some users may
want to use unaligned regions to avoid wasting space (like putting multiple
small regions into a 64KB block).

>
> Another related thing is an optimization that I have in mind since ever
> I used flashrom: Selection of the biggest possible erase block size.
> Currently, if we erase/write say 16 blocks of 4KiB, we waste a lot of
> time because most chips would erase a 64KiB block much faster. If we
> ever add something like this, I guess it would be easier with approach
> 1). But maybe it'd be so invasive that it doesn't matter much...

I'd like this as well, and agree that it would be easier with the first
approach. As far as invasiveness goes, the tricky part IMO is updating
portions of read logic to deal with unaligned layout regions to ensure data
outside the targeted region is restored, which requires knowing the
eraseblock size in advance. Otherwise you end up with hacks like this:
https://chromium-review.googlesource.com/c/240176/
___
flashrom mailing list
flashrom@flashrom.org
https://www.flashrom.org/mailman/listinfo/flashrom

Re: [flashrom] FAILED: GA-B75M-D3V

[David Hendricks]

Looks like it failed to overwrite the descriptor region (Intel ME-related
headache): https://www.flashrom.org/ME

You can target regions more carefully using a layout file. It appears the
other regions (ME, BIOS, GbE) are unlocked, so you can try creating a
layout that includes only those regions.

On Mon, Dec 19, 2016 at 7:54 PM, Shawn  wrote:

> Hi flashrom maintainers,
>
> I failed to write a modified ROM to the flash via internal. Maybe this
> chipset can only be writable via external programmer?
>
> root@sysresccd /root % flashrom -p internal
> flashrom v0.9.8-r1888 on Linux 4.4.28-std490-amd64 (x86_64)
> flashrom is free software, get the source code at http://www.flashrom.org
>
> Calibrating delay loop... OK.
> Found chipset "Intel B75".
> Enabling flash write... Warning: SPI Configuration Lockdown activated.
> OK.
> Found Macronix flash chip "MX25L6405" (8192 kB, SPI) mapped at
> physical address 0xff80.
> Found Macronix flash chip "MX25L6405D" (8192 kB, SPI) mapped at
> physical address 0xff80.
> Found Macronix flash chip "MX25L6406E/MX25L6408E" (8192 kB, SPI)
> mapped at physical address 0xff80.
> Found Macronix flash chip
> "MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E" (8192 kB, SPI) mapped at
> physical address 0xff80.
> Multiple flash chip definitions match the detected chip(s):
> "MX25L6405", "MX25L6405D", "MX25L6406E/MX25L6408E",
> "MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E"
> Please specify which chip definition to use with the -c  option.
>
>
> root@sysresccd /root % flashrom -VV -p internal -c MX25L6405  -w
> factory_giga1.bin.new.new
> flashrom v0.9.8-r1888 on Linux 4.4.28-std490-amd64 (x86_64)
> flashrom is free software, get the source code at http://www.flashrom.org
>
> flashrom was built with libpci 3.4.1, GCC 4.8.5, little endian
> Command line (7 args): flashrom -VV -p internal -c MX25L6405 -w
> factory_giga1.bin.new.new
> Calibrating delay loop... OS timer resolution is 1 usecs, 1944M loops
> per second, 10 myus = 10 us, 100 myus = 117 us, 1000 myus = 1021 us,
> 1 myus = 10021 us, 4 myus = 4 us, OK.
> Initializing internal programmer
> No coreboot table found.
> Using Internal DMI decoder.
> DMI string chassis-type: "Desktop"
> DMI string system-manufacturer: "Gigabyte Technology Co., Ltd."
> DMI string system-product-name: "To be filled by O.E.M."
> DMI string system-version: "To be filled by O.E.M."
> DMI string baseboard-manufacturer: "Gigabyte Technology Co., Ltd."
> DMI string baseboard-product-name: "B75M-D3V"
> DMI string baseboard-version: "To be filled by O.E.M."
> Found ITE Super I/O, ID 0x8728 on port 0x2e
> Found chipset "Intel B75" with PCI ID 8086:1e49.
> Enabling flash write... Root Complex Register Block address = 0xfed1c000
> GCS = 0xc64: BIOS Interface Lock-Down: disabled, Boot BIOS Straps: 0x3
> (SPI)
> Top Swap: enabled (A16(+) inverted)
> 0xfff8/0xffb8 FWH IDSEL: 0x0
> 0xfff0/0xffb0 FWH IDSEL: 0x0
> 0xffe8/0xffa8 FWH IDSEL: 0x1
> 0xffe0/0xffa0 FWH IDSEL: 0x1
> 0xffd8/0xff98 FWH IDSEL: 0x2
> 0xffd0/0xff90 FWH IDSEL: 0x2
> 0xffc8/0xff88 FWH IDSEL: 0x3
> 0xffc0/0xff80 FWH IDSEL: 0x3
> 0xff70/0xff30 FWH IDSEL: 0x4
> 0xff60/0xff20 FWH IDSEL: 0x5
> 0xff50/0xff10 FWH IDSEL: 0x6
> 0xff40/0xff00 FWH IDSEL: 0x7
> 0xfff8/0xffb8 FWH decode enabled
> 0xfff0/0xffb0 FWH decode enabled
> 0xffe8/0xffa8 FWH decode enabled
> 0xffe0/0xffa0 FWH decode enabled
> 0xffd8/0xff98 FWH decode enabled
> 0xffd0/0xff90 FWH decode enabled
> 0xffc8/0xff88 FWH decode enabled
> 0xffc0/0xff80 FWH decode enabled
> 0xff70/0xff30 FWH decode enabled
> 0xff60/0xff20 FWH decode enabled
> 0xff50/0xff10 FWH decode enabled
> 0xff40/0xff00 FWH decode enabled
> Maximum FWH chip size: 0x10 bytes
> SPI Read Configuration: prefetching enabled, caching enabled,
> BIOS_CNTL = 0x09: BIOS Lock Enable: disabled, BIOS Write Enable: enabled
> SPIBAR = 0xf7795000 + 0x3800
> 0x04: 0xe008 (HSFS)
> HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1, FLOCKDN=1
> Warning: SPI Configuration Lockdown activated.
> Reading OPCODES... done
> OPType  Pre-OP
> op[0]: 0x02, write w/  addr, none
> op[1]: 0x03, read  w/  addr, none
> op[2]: 0x20, write w/  addr, none
> op[3]: 0x05, read  w/o addr, none
> op[4]: 0x9f, read  w/o addr, none
> op[5]: 0x01, write w/o addr, none
> op[6]: 0x00, read  w/o addr, none
> op[7]: 0x00, read  w/o addr, none
> Pre-OP 0: 0x06, Pre-OP 1: 0x00
> 0x06: 0x (HSFC)
> HSFC: FGO=0, FCYCLE=0, FDBC=0, SME=0
> 0x08: 0x (FADDR)
> 0x50: 0x (FRAP)
> BMWAG 0x00, BMRAG 0x00, BRWA 0xff, BRRA 0xff
> 0x54: 0x FREG0: Flash Descriptor region
> (0x-0x0fff) is read-write.
> 0x58: 0x07ff FREG1: BIOS region (0x-0x007f) is read-write.
> 0x5C: 0x04ff0001 FREG2: Management Engine region
> 

Re: [flashrom] (no subject)

[David Hendricks via flashrom]

On Sun, Dec 4, 2016 at 2:38 PM, SandShark--- via flashrom <
flashrom@flashrom.org> wrote:

> But v0.9.7 requires configuration first, which fails, even though it finds
> both the chipset and the BIOS chip.  This is also under a later Debian
> release, if that matters.
>

It might. There were some kernel changes which can impact flashrom's
ability to read /dev/mem:
https://www.flashrom.org/FAQ#I_get_.27Can.27t_mmap_memory_using_.2Fdev.2Fmem:_Invalid_argument.27

Try out the latest sources which (hopefully) don't require you to change
kernel options: https://review.coreboot.org/cgit/flashrom.git

-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
___
flashrom mailing list
flashrom@flashrom.org
https://www.flashrom.org/mailman/listinfo/flashrom

Re: [flashrom] Apollo Lake

[David Hendricks via flashrom]

Hi Tim,

On Tue, Nov 8, 2016 at 1:02 PM, Tim Lewis <tim.le...@insyde.com> wrote:
> On the most recent version of the Chromium flashrom effort, there was a
> patch for Apollo Lake. I have applied it to the latest, fixed up one issue
> in the get_target_bus_from_chipset() to return the right BBS strapping.

Do you mean that you applied it to the latest upstream flashrom version?

I'm afraid upstream and chromium.org's flashrom branches have diverged
quite significantly, so there are likely other patches needed to get
Apollo Lake support fully functioning. Ramya Vijaykumar at Intel
submitted a few patches to update hardware sequencing logic (for
Skylake support).

Here are a few gleaned from the commit log:
https://chromium-review.googlesource.com/#/c/265818/
https://chromium-review.googlesource.com/#/c/322078/
https://chromium-review.googlesource.com/#/c/360192/
https://chromium-review.googlesource.com/#/c/359981/
https://chromium-review.googlesource.com/#/c/385186/

Have you tried using chromium.org's flashrom? It might be a better
starting point for the platform you're working on.

> Transaction error between offset 0x and 0x003f (= 0x +
> 63)

This is pretty interesting since your flash descriptor permissions are
set to read-write. Hmmm...

Further, upstream flashrom will fail once it encounters a region that
is fully locked by the ME, whereas chromium.org's flashrom will ignore
such errors. So you'll need to be careful not to try accessing locked
regions.

-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.

___
flashrom mailing list
flashrom@flashrom.org
https://www.flashrom.org/mailman/listinfo/flashrom

Re: [flashrom] [PATCH] RFC: enable flashrom to write images of arbitrary size

[David Hendricks via flashrom]

Hi Peter,
Thanks for the patch! However, I suspect this will not be accepted
since the size check is an important safety measure for the general
use case.

In general layout files should be used for this sort of thing. The way
we've gone about this in the chromium.org branch is to augment the -i
syntax to allow the user to specify a region and corresponding file,
and we also added a "--fast-verify" mode to only verify regions which
were targeted. So for example you could do "flashrom -p 
-l  -i region:filename.bin --fast-verify --ignore-fmap
-w" which will write filename.bin to the targeted region and verify
only that region.

Details here: 
https://www.chromium.org/chromium-os/packages/cros-flashrom#TOC-Partial-Reads-and-Writes
. LMK if this is any help.



On Mon, Nov 7, 2016 at 1:00 PM, Peter Mamonov <pmamo...@gmail.com> wrote:
> Flashrom restricts an image size to be equal to a ROM capacity. This is
> inconvenient in case of large and slow ROM chips, when only part of the ROM
> should be updated. This patch removes this restriction in a quick-and-dirty
> manner.
>
> Signed-off-by: Peter Mamonov <pmamo...@gmail.com>
> ---
>  flashrom.c | 26 +++---
>  1 file changed, 15 insertions(+), 11 deletions(-)
>
> diff --git a/flashrom.c b/flashrom.c
> index d51a44c..f805e00 100644
> --- a/flashrom.c
> +++ b/flashrom.c
> @@ -1255,30 +1255,30 @@ int read_buf_from_file(unsigned char *buf, unsigned 
> long size,
>
> if ((image = fopen(filename, "rb")) == NULL) {
> msg_gerr("Error: opening file \"%s\" failed: %s\n", filename, 
> strerror(errno));
> -   return 1;
> +   return -1;
> }
> if (fstat(fileno(image), _stat) != 0) {
> msg_gerr("Error: getting metadata of file \"%s\" failed: 
> %s\n", filename, strerror(errno));
> fclose(image);
> -   return 1;
> +   return -1;
> }
> -   if (image_stat.st_size != size) {
> +   if (image_stat.st_size > size) {
> msg_gerr("Error: Image size (%jd B) doesn't match the flash 
> chip's size (%lu B)!\n",
>  (intmax_t)image_stat.st_size, size);
> -   fclose(image);
> -   return 1;
> +   return -1;
> }
> +   size = image_stat.st_size;
> numbytes = fread(buf, 1, size, image);
> if (fclose(image)) {
> msg_gerr("Error: closing file \"%s\" failed: %s\n", filename, 
> strerror(errno));
> -   return 1;
> +   return -1;
> }
> if (numbytes != size) {
> msg_gerr("Error: Failed to read complete file. Got %ld bytes, 
> "
>  "wanted %ld!\n", numbytes, size);
> -   return 1;
> +   return -1;
> }
> -   return 0;
> +   return size;
>  #endif
>  }
>
> @@ -1481,7 +1481,10 @@ static int walk_eraseregions(struct flashctx *flash, 
> int erasefunction,
>  * members so the loop below won't be executed for them.
>  */
> len = eraser.eraseblocks[i].size;
> -   for (j = 0; j < eraser.eraseblocks[i].count; j++) {
> +   for (j = 0;
> +j < eraser.eraseblocks[i].count &&
> +start + len <= flash->chip->total_size * 1024;
> +j++) {
> /* Print this for every block except the first one. */
> if (i || j)
> msg_cdbg(", ");
> @@ -1988,11 +1991,12 @@ int doit(struct flashctx *flash, int force, const 
> char *filename, int read_it,
> }
>
> if (write_it || verify_it) {
> -   if (read_buf_from_file(newcontents, size, filename)) {
> +   size = read_buf_from_file(newcontents, size, filename);
> +   if (size < 0) {
> ret = 1;
> goto out;
> }
> -
> +   flash->chip->total_size = size / 1024; /* FIXME */
>  #if CONFIG_INTERNAL == 1
> if (programmer == PROGRAMMER_INTERNAL && 
> cb_check_image(newcontents, size) < 0) {
> if (force_boardmismatch) {
> --
> 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

Re: [flashrom] Can't find Write protect screw on Samsung XE500C21

[David Hendricks]

If it's Alex, then you'll want to check this page:
http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/samsung-series-5-chromebook

Unfortunately the page for Alex doesn't have the WP switch circled, and
it's been so long that I forgot where it is. It *should* be a jumper,
though. I seem to recall that there is a plastic shroud near it to guard
against potential tampering thru the exhaust grill or SD card slot.

PS. Please reply to all so that others in the list can view and/or
contribute.


On Fri, Oct 14, 2016 at 4:19 PM, Chris M <pugsly...@gmail.com> wrote:

> Actually, I checked on the ribbon cables and it says Alex. I might of
> typed in the wrong model number, Whoops https://www.chromium.org/
> chromium-os/developer-information-for-chrome-os-devices/samsung-series-5-
> chromebook
>
> On Fri, Oct 14, 2016 at 7:13 PM, David Hendricks <dhend...@google.com>
> wrote:
>
>> Hi Chris,
>> IIRC the development name for that machine is "Lumpy." There are full
>> disassembly instructions here: http://www.chromium.org/
>> chromium-os/developer-information-for-chrome-os-devices/
>> samsung-sandy-bridge
>>
>> The write-protect signal is gated by a jumper instead of a screw. The
>> jumper is located next to the keyboard ribbon connector and memory module.
>>
>>
>> On Thu, Oct 13, 2016 at 5:08 PM, Chris M <pugsly...@gmail.com> wrote:
>>
>>> Hello, I'm wondering where i could find the Write protect screw on my
>>> Samsung  XE500C21. Got any ideas where I could find it?
>>> Regards
>>> -Chris
>>>
>>> ___
>>> flashrom mailing list
>>> flashrom@flashrom.org
>>> https://www.flashrom.org/mailman/listinfo/flashrom
>>>
>>
>>
>>
>> --
>> David Hendricks (dhendrix)
>> Systems Software Engineer, Google Inc.
>>
>
>


-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
___
flashrom mailing list
flashrom@flashrom.org
https://www.flashrom.org/mailman/listinfo/flashrom

Re: [flashrom] Can't find Write protect screw on Samsung XE500C21

[David Hendricks]

Hi Chris,
IIRC the development name for that machine is "Lumpy." There are full
disassembly instructions here:
http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/samsung-sandy-bridge

The write-protect signal is gated by a jumper instead of a screw. The
jumper is located next to the keyboard ribbon connector and memory module.


On Thu, Oct 13, 2016 at 5:08 PM, Chris M <pugsly...@gmail.com> wrote:

> Hello, I'm wondering where i could find the Write protect screw on my
> Samsung  XE500C21. Got any ideas where I could find it?
> Regards
> -Chris
>
> ___
> 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

Re: [flashrom] Development flashrom

[David Hendricks]

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 in
ft2232_spi.c. If the FTDI D2XX is significantly different you can create a
new file (ftdi_d2xx.c, for example), and use ft2232_spi.c as a template.
​
___
flashrom mailing list
flashrom@flashrom.org
https://www.flashrom.org/mailman/listinfo/flashrom

Re: [flashrom] [RFC] [PATCH] Add ability to lock bootblock on Winbond Flash ROMs

[David Hendricks]

ect_winbond,
> .write  = spi_chip_write_256,
> .read   = spi_chip_read,
> .voltage= {2700, 3600},
> Index: chipdrivers.h
> ===
> --- chipdrivers.h   (revision 1955)
> +++ chipdrivers.h   (working copy)
> @@ -73,6 +73,7 @@
>  int spi_prettyprint_status_register_bp4_srwd(struct flashctx *flash);
>  int spi_prettyprint_status_register_bp2_bpl(struct flashctx *flash);
>  int spi_prettyprint_status_register_bp2_tb_bpl(struct flashctx *flash);
> +int spi_enable_sectorprotect_winbond(struct flashctx *flash, const
> uint8_t status_flags);
>  int spi_disable_blockprotect(struct flashctx *flash);
>  int spi_disable_blockprotect_bp1_srwd(struct flashctx *flash);
>  int spi_disable_blockprotect_bp2_srwd(struct flashctx *flash);
> Index: flash.h
> ===
> --- flash.h (revision 1955)
> +++ flash.h (working copy)
> @@ -200,6 +200,7 @@
> } block_erasers[NUM_ERASEFUNCTIONS];
>
> int (*printlock) (struct flashctx *flash);
> +   int (*lock) (struct flashctx *flash, const uint8_t status_flags);
> int (*unlock) (struct flashctx *flash);
> int (*write) (struct flashctx *flash, const uint8_t *buf, unsigned
> int start, unsigned int len);
> int (*read) (struct flashctx *flash, uint8_t *buf, unsigned int
> start, unsigned int len);
> @@ -281,7 +282,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

Re: [flashrom] Aspire One

[David Hendricks]

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 models have Winbond W25x80 EEPROMS (these are listed as supported, all
> OK
>
> I wonder what's the safest way to try?

The flash chip shouldn't be a problem, it's the embedded controller
(EC) that can cause problems. If the EC uses the same ROM as the BIOS
and accesses it during a firmware update, the update will likely fail
and your machine may be bricked.

>
> Also the link regarding the Aspire One in the Laptop table points to the
> coreboot mailing list, but in the entire post there is NO mention of the
> aspire one.
>
> Eventually i could de-solder the chip and try to flash it in an external
> programmer.
>
> I have 3 of these Acers that could use a fresh BIOS.  (hopefully the latest
> one allows to boot from SD)
> Most Aspire One netbooks have BIOS issues and having a tool that doesn't
> require Microsoft would be very welcome.
>
>
> In software there is a mention of SST2400 and there is no mention of
> Winbond, but on the mainboard there is a Winbond 25x80 chip.
>
>
> Best,
>
> Wilfried
>
>
> ___
> flashrom mailing list
> flashrom@flashrom.org
> https://www.flashrom.org/mailman/listinfo/flashrom

___
flashrom mailing list
flashrom@flashrom.org
https://www.flashrom.org/mailman/listinfo/flashrom

Re: [flashrom] Writing to a specific Flash region with Layout approach

[David Hendricks]

On Mon, Aug 1, 2016 at 9:59 AM, Pradeep Ch <shanm...@sysargus.com> wrote:

> How do I pad the bootloader. img to 8MBytes ? But, still it occupies the
> first 106976 Bytes right ? Remaining space is empty I suppose.
>
To create a 8MB file full of 0xff bytes:
dd if=/dev/zero bs=1k count=8192 2>/dev/null | tr "\000" "\377" > test.bin

>From there, you can use dd with skip=, seek=, and conv=notrunc to place
your content wherever you need to in the image. For example,
dd if=test1.bin of=test.bin bs=1 conv=notrunc
dd if=test2.bin of=test.bin bs=1 seek=$((0x1a1e0)) conv=notrunc

Thanks.
> On Aug 1, 2016 9:08 PM, "Urja Rannikko" <urja...@gmail.com> wrote:
>
>> Hi,
>>
>> On Mon, Aug 1, 2016 at 10:33 AM, Pradeep Ch <shanm...@sysargus.com>
>> wrote:
>> >
>> > I am attempting to write to a flashrom using layout/region approach.
>> > The NOR flash size is 8MBytes. The file size I am writing is 106976
>> Bytes.
>> >
>> > The rom.layout file contents are:
>> >  :0001a1df test1
>> >  0001a1e0:007f test2
>> >
>> > The command I am using is:
>> > ./flashrom -p ft2232_spi:type=arm-usb-ocd --layout rom.layout --image
>> test1
>> > -w bootloader.img
>> >
>> > The error I am getting is :
>> > Using region: "test1".
>> > Calibrating delay loop... OK.
>> > Found Eon flash chip "EN25Q64" (8192 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,
>> not change the requirements of the flash file being the size of the
>> chip, so in this case you'd need to pad the bootloader.img to 8MB.
>>
>
> ___
> 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

Re: [flashrom] RFC: New testing script with remote test capabilities and region awareness

[David Hendricks]

I had a bit more time to work on this today and managed to fix several bugs
and simplify the code - now all modes use a single algorithm for testing. I
probably won't do another major revision for a few days, but fortunately it
seems much more usable now. I also updated the documentation at
https://goo.gl/3jNoL7.

I also tried to get the test working with upstream, but there are a few
features that need to be added first:
- Add -i [:] support (
http://patchwork.coreboot.org/patch/4076/)
- Partial reads need to be supported.
- -r/-w/-v shouldn't require a positional argument (
https://gerrit.chromium.org/gerrit/60515) since we want to do purely
partial reads/writes in this case.
- Command-line options from chromium: --get-size to obtain chip size (I
want to rename this --chip-size at some point), --ignore-fmap (which can be
a noop), and --fast-verify (needed for Intel systems with read-locked
regions, but good to have in any case).

So for now, those who want to try this script can do so using the
chromium.org fork:
https://chromium.googlesource.com/chromiumos/third_party/flashrom/

Here is patch revision 20 from
https://chromium-review.googlesource.com/#/c/353912/:

>From 8af85a07966b9486ea78c381c948aeb44bdcca7c Mon Sep 17 00:00:00 2001
From: David Hendricks <dhend...@chromium.org>
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 and secondary programmer support
- Autotest-friendly

Long-term goals:
- Performance measurement
- Endurance testing

BUG=chromium:621715
BRANCH=none
TEST=this *is* the test

Change-Id: Ic643cf2edaf7d8772c63ce8119363d882d1b116d
Signed-off-by: David Hendricks <dhend...@chromium.org>
---
 tests/tests_v2/cmd.sh | 109 +++
 tests/tests_v2/test_v2.sh | 798
++
 2 files changed, 907 insertions(+)
 create mode 100644 tests/tests_v2/cmd.sh
 create mode 100644 tests/tests_v2/test_v2.sh

diff --git a/tests/tests_v2/cmd.sh b/tests/tests_v2/cmd.sh
new file mode 100644
index 000..1cfd219
--- /dev/null
+++ b/tests/tests_v2/cmd.sh
@@ -0,0 +1,109 @@
+#!/bin/sh
+#
+# This file is part of the flashrom project. It is derived from
+# board_status.sh in coreboot.
+#
+# Copyright (C) 2016 Google Inc.
+# Copyright (C) 2014 Sage Electronic Engineering, LLC.
+
+# test a command
+#
+# $1: 0 ($LOCAL) to run command locally,
+# 1 ($REMOTE) to run remotely if remote host defined
+# $2: command to test
+# $3: 0 ($FATAL) Exit with an error if the command fails
+# 1 ($NONFATAL) Don't exit on command test failure
+test_cmd()
+{
+ local rc
+ local cmd__="$(echo $2 | cut -d ' ' -f -1)"
+ local args="$(echo $2 | cut -d ' ' -f 2-)"
+
+ if [ -e "$cmd__" ]; then
+ return
+ fi
+
+ if [ "$1" -eq "$REMOTE" ] && [ -n "$REMOTE_HOST" ]; then
+ ssh $REMOTE_PORT_OPTION root@${REMOTE_HOST} command -v "$cmd__" $args >
/dev/null 2>&1
+ rc=$?
+ else
+ command -v "$cmd__" $args >/dev/null 2>&1
+ rc=$?
+ fi
+
+ if [ $rc -eq 0 ]; then
+ return 0
+ fi
+
+ if [ "$3" = "1" ]; then
+ return 1
+ fi
+
+ echo "$2 not found"
+ exit $EXIT_FAILURE
+}
+
+# Same args as cmd() but with the addition of $4 which determines if the
+# command should be totally silenced or not.
+_cmd()
+{
+ local silent=$4
+
+ if [ -n "$3" ]; then
+ pipe_location="${3}"
+ else
+ pipe_location="/dev/null"
+ fi
+
+ if [ $1 -eq $REMOTE ] && [ -n "$REMOTE_HOST" ]; then
+ if [ $silent -eq 0 ]; then
+ ssh $REMOTE_PORT_OPTION "root@${REMOTE_HOST}" "$2" > "$pipe_location"
2>/dev/null
+ else
+ ssh $REMOTE_PORT_OPTION "root@${REMOTE_HOST}" "$2" > /dev/null 2>&1
+ fi
+ else
+ if [ $silent -eq 0 ]; then
+ $2 > "$pipe_location" 2>/dev/null
+ else
+ $2 > /dev/null 2>&1
+ fi
+ fi
+
+ return $?
+}
+
+# run a command
+#
+# $1: 0 ($LOCAL) to run command locally,
+# 1 ($REMOTE) to run remotely if remote host defined
+# $2: command
+# $3: filename to direct output of command into
+cmd()
+{
+ _cmd $1 "$2" "$3" 0
+
+ if [ $? -eq 0 ]; then
+ return
+ fi
+
+ echo "Failed to run \"$2\", aborting"
+ rm -f "$3" # don't leave an empty file
+ return $EXIT_FAILURE
+}
+
+# run a command silently
+#
+# $1: 0 ($LOCAL) to run command locally,
+# 1 ($REMOTE) to run remotely if remote host defined
+# $2: command
+scmd()
+{
+ _cmd $1 "$2" "" 1
+
+ if [ $? -eq 0 ]; then
+ return
+ fi
+
+ echo "Failed to run \"$2\", aborting"
+ return $EXIT_FAILURE
+}
diff --git a/tests/tests_v2/test_v2.sh b/tests/tests_v2/test_v2.sh
new file mode 100644
index 000..cb9bace
--- /dev/null
+++ b/tests/tes

Re: [flashrom] RFC: New testing script with remote test capabilities and region awareness

[David Hendricks]

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 and we'll shake
out more bugs by virtue of having more users to report issues.

If you have a chance to run it even without reviewing, any feedback /
bug reports will be appreciated (make sure to use the latest patch on
gerrit (https://chromium-review.googlesource.com/#/c/353912/).

> question: the primary/secondary programmer scheme is used to verify one
> while the other is used as kind of golden sample, right?

I actually tried to get away from the "golden sample" approach. The
reason it was important to have the secondary programmer supported by
this script is so that it can follow-along with what the primary
programmer is doing at each step, not just the end result.

In region_partial_write_test(), for example, the primary programmer
writes blobs that are generated to exercise different aspects of
partial writes. There are 8 generated blobs in this test. Each time
the new flashrom + primary programmer is used to write one, the old
flashrom + primary programmer and, if enabled, the old flashrom +
secondary programmer are used to verify.

I think this makes it easier to vigorously test partial write cases
(or other cases) since we have all the filenames, variables, etc.
contained in one place.

> It might make sense to not limit this to two programmers but have one
> golden sample and an unlimited programmers to actually test.
> (The hardware i was talking about above would be a PCB that can be
> remotely cross-switched between any of the attached programmers and
> multiple flash chips (e.g. one at45db, several ordinary *25*, some
> newer *25* with 4B addressing etc.)

In this case I recommend invoking the script multiple times using the
attached programmer which is selected via the switch as the "primary
programmer" in each case. Have some other script select the programmer
you want to test, then invoke the test script by tweaking the primary
programmer args.

I added a diagram and example invocation for testing with only an
external programmer as the first use case in the doc since that's
probably going to be popular with developers.

___
flashrom mailing list
flashrom@flashrom.org
https://www.flashrom.org/mailman/listinfo/flashrom

[flashrom] RFC: New testing script with remote test capabilities and region awareness

[David Hendricks]

Hi folks,
As part of an effort underway to get chromium.org's flashrom sync'd with
upstream (for real), I have written an entirely new test script to help get
thru regression testing. It's still rather fugly and will likely go thru
several more revisions, but is currently usable for all major use cases I
could think of and would benefit from some early feedback.

I wrote up a document with usage examples here: https://goo.gl/3jNoL7 .
Long-term the plan is to migrate this to the flashrom wiki.

There were a few "must haves" for this script in the near-term:
- Region awareness. The script understands how to use layout files and
flashmaps (for Chromebooks). Descriptor awareness is on the TODO list for
Intel platforms.
- Can control flashrom on a remote host.
- Can utilize an external programmer in addition to the native programmer
on the target machine. This allows us to verify changes made to programmer
code since one programmer can be considered to be trusted while the other
can have code that was modified.

Longer-term goals include performance testing and flash endurance testing.
We might also add write-protect testing, though there's an open question 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 Hendricks <
dhend...@chromium.org>

>From 353aa26a174d9beb1ec886f7f752473f94023ed8 Mon Sep 17 00:00:00 2001
From: David Hendricks <dhend...@chromium.org>
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 and secondary programmer support
- Autotest-friendly

Long-term goals:
- Performance measurement
- Endurance testing

BUG=chromium:621715
BRANCH=none
TEST=this *is* the test

Change-Id: Ic643cf2edaf7d8772c63ce8119363d882d1b116d
Signed-off-by: David Hendricks <dhend...@chromium.org>
---
 tests/tests_v2/cmd.sh | 109 ++
 tests/tests_v2/test_v2.sh | 909
++
 2 files changed, 1018 insertions(+)
 create mode 100644 tests/tests_v2/cmd.sh
 create mode 100644 tests/tests_v2/test_v2.sh

diff --git a/tests/tests_v2/cmd.sh b/tests/tests_v2/cmd.sh
new file mode 100644
index 000..443ee2c
--- /dev/null
+++ b/tests/tests_v2/cmd.sh
@@ -0,0 +1,109 @@
+#!/bin/sh
+#
+# This file is part of the flashrom project. It is derived from
+# board_status.sh in coreboot.
+#
+# Copyright (C) 2016 Google Inc.
+# Copyright (C) 2014 Sage Electronic Engineering, LLC.
+
+# test a command
+#
+# $1: 0 ($LOCAL) to run command locally,
+# 1 ($REMOTE) to run remotely if remote host defined
+# $2: command to test
+# $3: 0 ($FATAL) Exit with an error if the command fails
+# 1 ($NONFATAL) Don't exit on command test failure
+test_cmd()
+{
+ local rc
+ local cmd__="$(echo $2 | cut -d ' ' -f -1)"
+ local args="$(echo $2 | cut -d ' ' -f 2-)"
+
+ if [ -e "$cmd__" ]; then
+ return
+ fi
+
+ if [ "$1" -eq "$REMOTE" ] && [ -n "$REMOTE_HOST" ]; then
+ ssh $REMOTE_PORT_OPTION root@${REMOTE_HOST} command -v "$cmd__" $args >
/dev/null 2>&1
+ rc=$?
+ else
+ command -v "$cmd__" $args >/dev/null 2>&1
+ rc=$?
+ fi
+
+ if [ $rc -eq 0 ]; then
+ return 0
+ fi
+
+ if [ "$3" = "1" ]; then
+ return 1
+ fi
+
+ echo "$2 not found"
+ exit $EXIT_FAILURE
+}
+
+# Same args as cmd() but with the addition of $4 which determines if the
+# command should be totally silenced or not.
+_cmd()
+{
+ local silent=$4
+
+ if [ -n "$3" ]; then
+ pipe_location="${3}"
+ else
+ pipe_location="/dev/null"
+ fi
+
+ if [ $1 -eq $REMOTE ] && [ -n "$REMOTE_HOST" ]; then
+ if [ $silent -eq 0 ]; then
+ ssh $REMOTE_PORT_OPTION "root@${REMOTE_HOST}" "$cmd $args" >
"$pipe_location" 2>/dev/null
+ else
+ ssh $REMOTE_PORT_OPTION "root@${REMOTE_HOST}" "$cmd $args" > /dev/null
2>&1
+ fi
+ else
+ if [ $silent -eq 0 ]; then
+ $2 > "$pipe_location" 2>/dev/null
+ else
+ $2 > /dev/null 2>&1
+ fi
+ fi
+
+ return $?
+}
+
+# run a command
+#
+# $1: 0 ($LOCAL) to run command locally,
+# 1 ($REMOTE) to run remotely if remote host defined
+# $2: command
+# $3: filename to direct output of command into
+cmd()
+{
+ _cmd $1 "$2" "$3" 0
+
+ if [ $? -eq 0 ]; then
+ return
+ fi
+
+ echo "Failed to run \"$2\", aborting"
+ rm -f "$3" # don't leave an empty file
+ exit $EXIT_FAILURE
+}
+
+# run a command silently
+#
+# $1: 0 ($LOCAL) to run command locally,
+# 1 ($REMOTE) to run remotely if remote host defined
+# $2: command

Re: [flashrom] Ideas for implementing support for 2nd status register

[David Hendricks]

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
> Winbond , along with some AMIC, Eon, Fudan and Macronix chips follow this
> pattern - around 50 in number. With this pattern, we can now dynamically
> generate the entire block protection ranges on-the-go. We don't need to
> hard-code the tables for these chips anymore and presence (or absence) of
> SEC, TB, or CMP bits is also handles generically! The exact algorithm is
> slightly convoluted, but I'll try my best to explain it. Feel free to skip
> past #5, you will have nothing much to lose. For all practical purposes,
> the BP4 and BP3 bits are identical to SEC and TB bits respectively. We'll
> call tuple of (BP3, BP2, BP1) as BP, and X is don't care.
> 1. For BP=(0,0,0):
> No protection, SEC=X, TB=X
>
> 2. For BP=(1,1,1):
> All protection, SEC=X, TB=X
>
> 3. For (SEC,TB)=(0,0):
> We introduce a parameter f, such that f = chip_size(in kB) / 64 for
> chips_size < 4096 kB; and f = 64 for chips_size >= 4096 kB.
> 3.1 For chip_size >= 4096 kB, we have the following correspondence of
> fraction of chip_size with BP:
> (0,0,1) - 1/64
> (0,1,0) - 1/32
> (0,1,1) - 1/16
> ...
> (1,1,0) - 1/2
> 3.2 For chip_size = 2048 kB, we have the following correspondence of
> fraction of chip_size with BP:
> (0,0,1) - 1/32
> (0,1,0) - 1/16
> (0,1,1) - 1/8
> ...
> (1,1,0) - 1
> 3.3 For chip_size = 1024 kB, we have the following correspondence of
> fraction of chip_size with BP:
> (0,0,1) - 1/16
> (0,1,0) - 1/8
> (0,1,1) - 1/4
> ...
> (1,1,0) - 1
> 3.4 For chip_size = 512 kB, we have the following correspondence of
> fraction of chip_size with BP:
> (0,0,1) - 1/8
> (0,1,0) - 1/4
> ...
> (1,1,0) - 1
> 3.5 For chip_size = 256 kB, we have the following correspondence of
> fraction of chip_size with BP:
> (0,0,1) - 1/4
> (0,1,0) - 1/2
> (0,1,1) - 1
> (1,0,0) - 0
> (1,0,1) - 1/4
> (1,1,0) - 1/2
> 3.6 For chip_size = 128 kB, we have the following correspondence of
> fraction of chip_size with BP:
> (0,0,1) - 1/2
> (0,1,0) - 1
> (0,1,1) - 1
> (1,0,0) - 0
> (1,0,1) - 1/2
> (1,1,0) - 1
> (SEC,TB)=(0,0) represents the upper portion of the chip (which means range
> addresses always end at top boundary).
> E.g. For a 4096 kB chip, (0,1,0) 1/32 means upper 256 kB -
> 0x3fff00-0x3f
>
> 4. For (SEC,TB)=(0,1):
> This represents the lower portion of the chip (which means range
> addresses always start at lower boundary). The same mapping defined earlier
> for fraction of chip_size holds.
> E.g. For a 512 kB chip, (0,1,0) means lower 128 kB - 0x00-0x01
>
> 5. For (SEC,TB)=(1,X):
> (0,0,1) - 4 kB
> (0,1,0) - 8 kB
> (0,1,1) - 16 kB
> (1,0,0) - 32 kB
> (1,0,1) - 32 kB
>*(1,1,0) - 32 kB
> We have upper for TB=0, lower for TB=1
> E.g. For a 1024 kB chip TB=1, (1,0,0) means lower 32 kB - 0x00-0x007fff
> *Some chips have 64 kB block instead of 32 kB.
>
> (You will not lose much if you skip up to here)
>
> 6. For chips with CMP bit:
> For all chips that I have seen (and that is well over a 100 SPI
> chips), the block protection range either starts at lower boundary of chip
> or ends at upper boundary of chip. So, given the range and size of the
> chip, we can compute the complement range.
>
> Please find attached pattern.c. It is an excerpt from the unmerged code I
> am working on and contains the implementation of the discussed model (cf.
> sec_block_pattern_range_generic). There are other functions and structs to
> show the models impact on the infrastructure. IMO, this is an immense
> improvement from what we have in ChromiumOS fork and what we have been
> discussing. Here are the key takeaway points -
> - Having the status register layout member in struct flashchip is
> immensely beneficial. A lot of chips can be supported with the generic
> code, perhaps with only slight adaptation.
> - Based on David's suggestion, shifting to function pointers was a good
> choice - it allows flexibility.
> - Presence (or absence) of CMP, TB (BP3), SEC (BP4) bit is automatically
> taken of, and the corresponding range is also dynamically generated.
> - For chips whose ranges cannot be dynamically generated, we have the
> option of specifying range manually. I think it is best to stick to range
> for such representation, instead of range of sectors/blocks or portions of
> chip (as suggested by David in the previous mail). Sticking with range is
> safe because range is independent of sector/block and will yield the proper
> result.
> - Based on Stefan's suggestion some time ago, having pointers to struct
> status_register and struct wp will allow greater re-use (which is 

Re: [flashrom] [PATCH 0/6] 4-bytes addressing support

[David Hendricks]

Hi Cédric,
Thanks for the patches. Indeed, 4BA is a feature that we've been looking at
for a while. I'll look forward to reviewing these patches in detail.

There are a few cases that need to be considered:
- Chips which have a command to switch to 4BA mode
- Chips which have a parallel instruction set for use with 4BA.
- Chips that exclusively use 4BA commands.

I tried to cover the first two cases in my patch:
https://chromium-review.googlesource.com/#/c/323359/
The third case was brought to our attention by Tim Chick:
http://patchwork.coreboot.org/patch/4437/

Hopefully we can come up with a good solution for all cases.


On Sat, Jun 11, 2016 at 9:28 AM, Cédric Le Goater <c...@kaod.org> wrote:

> Hi,
>
> Here's an old patchset proposed a while ago by Boris Baykov to add
> 4byte support to flashrom. I have been using it to flash N25Q256
> modules from a raspberry pi quite successfully. Could we restart a
> review cycle to see what needs fixing ?
>
> A port of the complete patchset on 0.9.9 is available here :
>
>   https://github.com/legoater/flashrom
>
> Thanks,
>
> C.
>
> Boris Baykov (6):
>   4BA: Basic support for 4-bytes addressing mode extensions
>   4BA: Flashrom integration for the 4-bytes addressing extensions
>   4BA: Winbond W25Q256.V chip (32MB) declaration, 4-bytes addr mode
>   4BA: Support for 4-bytes addressing via Extended Address Register
>   4BA: Support for new direct-4BA instructions + W25Q256.V update
>   4BA: Progress visualization for long read, writes and erases
>
>  Makefile  |   2 +-
>  chipdrivers.h |  22 ++
>  cli_output.c  |   3 +-
>  flash.h   |  21 ++
>  flashchips.c  |  48 +++
>  flashrom.c|  61 
>  serprog.c |   5 +-
>  spi.c |   5 +-
>  spi25.c   |  37 ++-
>  spi4ba.c  | 920
> ++
>  spi4ba.h  | 114 
>  11 files changed, 1231 insertions(+), 7 deletions(-)
>  create mode 100644 spi4ba.c
>  create mode 100644 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

Re: [flashrom] Ideas for implementing support for 2nd status register

[David Hendricks]

Hi Hatim,

On Tue, May 31, 2016 at 3:25 AM, Hatim Kanchwala <ha...@hatimak.me> 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 you have an example
>> for translating status_register_layout structs to a range of bytes
>> protected, for example 0x00-0x1f?
>>
>
> Hi,
>
> I have been researching and developing ideas on how to go about block
> protection. A lot of this is based on Chromium OS' implementation. Here are
> the two models I have.
>
> Before diving into the models themselves, here's idea that both models
> share. We define a struct range (just like Chromium OS) and then define an
> array struct range range[32]. We use the BP bitfield as indexes into the
> array - so a combination of BP4=0, BP3=0, BP2=1, BP1=0, BP0=1 gives a
> bitfield 0x05 and corresponding range is given by range[0x05]={start, len}.
> (32 because we have seen a maximum of 5 block protect bits so that is 2^5 =
> 32 combinations.) The obvious advantage is that status_to_range operations
> will happen in O(1) time.


Interesting approach, but what about SEC/CMP/TB bits? Since those modify
the start and length, we do not have a 1:1 mapping between block protect
bits and range. Also it complicates the "don't care" cases.

Overall I don't think this optimization buys us much.


> 1. Block Protection Table
> The driving idea behind this model is to have a representation of block
> protection table in flashrom very similar to what is given in datasheets
> (just like Chromium OS currently has). But if we are to use array of ranges
> indexed by bitfield as per above idea, then we need to process this
> representation first. I came up with the following algorithm for
> translating the table into the range array -
>
> translate_table_to_range(table):
> proc = []
> done = []
> for row in table
> proc.append(row)
> while proc is not empty
> tmp = proc.pop(0)
> for i = 0:5
> if tmp.bp[i] is X
> new = tmp
> new.bp.replace(i, 0)
> proc.append(new)
> new.bp.replace(i, 1)
> proc.append(new)
> break
> if i is 5
> done.append(tmp)
> for row in done
> index = row.bp4 << 4 | row.bp3 << 3 | row.bp1 << 1 |row.bp0
> range[index] = row.range
>
> These were the few questions came up immediately -
> - When do we call such a function in the code?
> Flashrom will always probe before performing any operation. So once
> the chip is found, we fetch the BP table from the struct flashchip, call
> this function, store the array of ranges, and then perform all future
> operations for that run using the array.
> - Do we call it for all the chips?
> IMO, calling this for all chips is a bad idea and the above answer
> makes this redundant.
> - How to handle corner cases?
> This needs to be dealt with still.
>
> 2. Array of Range
> This model is very simple compared to #1 - instead of any such processing,
> we simply represent the BP table in the form of an array of ranges in the
> first place. This might make representing the table in flashrom more
> cumbersome.
>
> Attached is a prototype of the two models (both implementations are
> combined in the same file). I have extensively annotated the code to better
> convey the models defined above. The output is available here
> http://paste.flashrom.org/view.php?id=2921. Chromium implementation
> defines two separate structs from CMP=0 and CMP=1. This case can be handled
> automatically.
>

Yeah, the different structs for CMP=0 and CMP=1 are annoying, I'll be happy
to be rid of them.


> IMO, #2 is better than #1 and we should go forward with #2. The additional
> processing step that needs to be taken in #1 before array of ranges is
> available is what made me favour #2. I would like to hear your take on all
> this, particularly use cases (I could come up with only one or two, so
> please tell me more). There's a lot of comments in the code, so please go
> through those as well.
>

I agree - #1 seems over-designed for this... I think #2 will be much
simpler and will get the job done just as well.

A couple more ideas:
- Instead of describing the range in terms of bytes, maybe a range of
blocks would be more appropriate. This will require computing the byte
ranges as needed, but will allow you to more easily handle presence of a
SEC bit.

- I'm still not convinced that keeping a member with the status register
layout is necessary, and recommend keeping track of things like CMP, SEC,
and TB bits in another form (sort of like what I start

Re: [flashrom] Ideas for implementing support for 2nd status register

[David Hendricks]

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?
___
flashrom mailing list
flashrom@flashrom.org
https://www.flashrom.org/mailman/listinfo/flashrom

Re: [flashrom] New SPI NOR Flash product Support

[David Hendricks]

Hi Victor,
>From Flashrom's software perspective all chips with the same ID are
indistinguishable.

Part number often includes characteristics such as package and thermal
tolerance which do not affect software compatibility.


On Mon, May 9, 2016 at 3:51 PM, Victor Lim <v...@gigadevice.com> wrote:

> Thanks, David,
>
>
>
> For Gigadevice part numbers, we do keep ID, read, erase, write opcodes,
> sector protection, and architecture the same.
>
> I am wondering if Flashrom program needs to call out the new part numbers
> so that users know which part number to choose from.
>
>
>
> Regards,
>
>
>
> Victor
>
>
>
>
>
> *From:* David Hendricks [mailto:dhend...@google.com]
> *Sent:* Sunday, May 8, 2016 7:43 PM
> *To:* Victor Lim <v...@gigadevice.com>
> *Cc:* Hatim Kanchwala <ha...@hatimak.me>; flashrom <flashrom@flashrom.org>;
> Katherine (GigaDevice//US) <ks...@gigadevice.com>
>
> *Subject:* Re: [flashrom] New SPI NOR Flash product Support
>
>
>
> Hello Victor,
>
> Chips with same ID and read, erase, and write opcodes are supported. For
> ChromeOS platforms it is also important that new revision chips have
> identical block protection capabilities as the older parts (I've had
> difficulties with other vendors regarding this...).
>
>
>
> On Fri, May 6, 2016 at 4:55 PM, Victor Lim <v...@gigadevice.com> wrote:
>
> Hi, Hatim,
>
> We have new revision chips that share the same ID as the previous revision,
> will they be considered supported because they share the same basic Erase
> and program command.
>
> New part # GD25LQ64C: manufacturer ID: 0x6017
> Currently supported part # GD25LQ64: manufacturer ID: 0x6017
>
> New part # GD25LQ128C: manufacturer ID: 0x6018
> Currently supported part # GD25LQ128: manufacturer ID: 0x6018
>
> Do you need new samples for verification?
> We do keep the same ID for new revision release, so the SW should work for
> new revision parts.
>
> Regards,
>
> Victor
>
>
>
>
>
> -Original Message-
> From: Hatim Kanchwala [mailto:ha...@hatimak.me]
> Sent: Friday, March 25, 2016 1:27 PM
> To: Victor Lim <v...@gigadevice.com>
>
> Cc: flashrom@flashrom.org; ks...@gigadevice.com
> Subject: Re: [flashrom] New SPI NOR Flash product Support
>
> Hello Victor,
>
> I am doing fine, thanks :) The following chips have been tested
> successfully
> - GD25D05B/10B, GD25LQ10B/20B/40B/80B, GD25Q21B/41B and GD25VQ41B (reported
> by David Hendrix). Test logs for the first 8 of these chips can be found
> here - https://www.flashrom.org/pipermail/flashrom/2016-March/014537.html.
> The patches for all these chips and additionally GD25Q80C/16C have been
> sent
> and are waiting for further review. I have ordered some IC clips, so I will
> test the remaining chips as soon as those arrive. Unfortunately, one of the
> chips you explicitly requested support for, GD25Q128C was not included in
> the samples so was not tested. But support for it has already been added ;)
> Apologies for the late reply. :)
>
> On Tuesday 22 March 2016 01:20 AM, Victor Lim wrote:
> > Hi, Hatim,
> >
> > How are you doing? Hope all the sample test results are good.
> > Can you please update the status so that I can ask customer to try out.
> >
> > Regards,
> >
> > Victor
> >
> >
> >
> > -Original Message-
> > From: Hatim Kanchwala [mailto:ha...@hatimak.me]
> > Sent: Wednesday, February 24, 2016 9:02 AM
> > To: Victor Lim <v...@gigadevice.com>
> > Cc: flashrom@flashrom.org; ks...@gigadevice.com
> > Subject: Re: [flashrom] New SPI NOR Flash product Support
> >
> > Hello Victor,
> >
> > Support for two chips you requested was added some time ago in r1937
> > (look here https://tracker.coreboot.org/trac/flashrom/changeset/1937).
> > I am waiting for samples to perform tests. FedEx was in touch
> > regarding documents for customs clearance, so delivery should be in a
> > day or two. In the meanwhile I am working on support for other
> > GigaDevice chips (http://www.gigadevice.com/product-series/12.html).
> >
> > On Wednesday 24 February 2016 04:47 AM, Victor Lim wrote:
> >> Hi, Hatim,
> >>
> >> How is the new program to include these two part #?
> >> I have sent the samples to you, but they are held up at the Fedex
> >> facility at New Delhi.
> >> Can you please give Fedex the instruction for delivery?
> >> The tracking # is 806824856677
> >>
> >> Regards,
> >>
> >> Victor
> >>
> >>
> >>
> >>
> >> -Origi

Re: [flashrom] [PATCH 2/2] dediprog: Fix bug where too many transfers would be queued

[David Hendricks]

Looks good to me.

Acked-by: David Hendricks <david.hendri...@gmail.com>

On Wed, May 4, 2016 at 4:37 AM, Nico Huber <nico.hu...@secunet.com> 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 check on the total number.
>
> Signed-off-by: Nico Huber <nico.hu...@secunet.com>
> ---
>  dediprog.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/dediprog.c b/dediprog.c
> index b7276e5..6f82772 100644
> --- a/dediprog.c
> +++ b/dediprog.c
> @@ -462,7 +462,9 @@ static int dediprog_spi_bulk_read(struct flashctx
> *flash, uint8_t *buf, unsigned
>
> /* Now transfer requested chunks using libusb's asynchronous
> interface. */
> while (!status.error && (status.queued_idx < count)) {
> -   while ((status.queued_idx - status.finished_idx) <
> DEDIPROG_ASYNC_TRANSFERS) {
> +   while ((status.queued_idx < count) &&
> +  (status.queued_idx - status.finished_idx) <
> DEDIPROG_ASYNC_TRANSFERS)
> +   {
> transfer = transfers[status.queued_idx %
> DEDIPROG_ASYNC_TRANSFERS];
> libusb_fill_bulk_transfer(transfer,
> dediprog_handle, 0x80 | dediprog_in_endpoint,
> (unsigned char *)buf +
> status.queued_idx * chunksize, chunksize,
> --
> 2.7.0
>
>
> ___
> flashrom mailing list
> flashrom@flashrom.org
> https://www.flashrom.org/mailman/listinfo/flashrom
>
___
flashrom mailing list
flashrom@flashrom.org
https://www.flashrom.org/mailman/listinfo/flashrom

Re: [flashrom] [PATCH 1/2] dediprog: Reimplement target chip option

[David Hendricks]

Looks good to me.

Acked-by: David Hendricks <david.hendri...@gmail.com>

On Wed, May 4, 2016 at 4:37 AM, Nico Huber <nico.hu...@secunet.com> wrote:

> Signed-off-by: Nico Huber <nico.hu...@secunet.com>
> ---
>  dediprog.c | 17 ++---
>  1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/dediprog.c b/dediprog.c
> index 019de46..b7276e5 100644
> --- a/dediprog.c
> +++ b/dediprog.c
> @@ -942,7 +942,7 @@ int dediprog_init(void)
> int spispeed_idx = 1;
> int millivolt = 3500;
> long usedevice = 0;
> -   long target = 1;
> +   long target = FLASH_TYPE_APPLICATION_FLASH_1;
> int i, ret;
>
> spispeed = extract_programmer_param("spispeed");
> @@ -1014,7 +1014,18 @@ int dediprog_init(void)
> free(target_str);
> return 1;
> }
> -   msg_pinfo("Using target %li.\n", target);
> +   switch (target) {
> +   case 1:
> +   msg_pinfo("Using target %s.\n",
> "FLASH_TYPE_APPLICATION_FLASH_1");
> +   target = FLASH_TYPE_APPLICATION_FLASH_1;
> +   break;
> +   case 2:
> +   msg_pinfo("Using target %s.\n",
> "FLASH_TYPE_APPLICATION_FLASH_2");
> +   target = FLASH_TYPE_APPLICATION_FLASH_2;
> +   break;
> +   default:
> +   break;
> +   }
> }
> free(target_str);
>
> @@ -1073,7 +1084,7 @@ int dediprog_init(void)
> dediprog_set_leds(LED_ALL);
>
> /* Select target/socket, frequency and VCC. */
> -   if (set_target_flash(FLASH_TYPE_APPLICATION_FLASH_1) ||
> +   if (set_target_flash(target) ||
> dediprog_set_spi_speed(spispeed_idx) ||
> dediprog_set_spi_voltage(millivolt)) {
> dediprog_set_leds(LED_ERROR);
> --
> 2.7.0
>
>
> ___
> flashrom mailing list
> flashrom@flashrom.org
> https://www.flashrom.org/mailman/listinfo/flashrom
>
___
flashrom mailing list
flashrom@flashrom.org
https://www.flashrom.org/mailman/listinfo/flashrom

Re: [flashrom] Giving to -i option some real use

[David Hendricks]

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've had it in the chromiumos
>> branch for a while now :-)
>>
>> I need to read your implementation. Ours is called "fast-verify" which
>> will read and only verify portions of the flash specified with -i arguments.
>>
>
> What about writes? My problem is that I have a 4 MiB flash and that
> usually need to use 32kB from it.


Yes, it works for writes as well. Using your layout file as an example:
:7e2b fpga
7e2c:003f free

If the eraseblock size is 4KB and you run *"*flashrom -p  -l
layout -i fpga -w foo.bin --fast-verify*"*, chromium's flashrom will:
1. Detect the flash chip.
2. Parse the -i argument
3. Do a partial read. This is broken into a multiple steps.
3a. Determine the "required_erase_size", for example, 4KB. Right now the
mechanism is crude and chooses the smallest block size that is eraseable.
3b. Align regions that are read based on required_erase_size.  is
already aligned, but 7e2b will be aligned up to 7fff.
3c. Read the aligned region content, which is :7fff instead of
:7e2b, into the new content buffer.
4. Copy the new content from the "fpga" region into the new content buffer.
5. Erase and write :7fff
6. Verify from :7fff

Overall it looks pretty similar to what you posted. Here's the original
implementation: https://chromium-review.googlesource.com/#/c/240176/
<https://chromium-review.googlesource.com/#/c/240176/4>. There are a couple
of follow-up patches as well, in case you're interested.

One more thing to note - Be careful about interactions with the proposed
patch to read the current contents of flash from a file:
https://www.flashrom.org/pipermail/flashrom/2015-December/014034.html.
Specifically, make sure that the aligned offsets are used for reading old
content no matter if the old content is in a flash chip or a file.

-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
___
flashrom mailing list
flashrom@flashrom.org
https://www.flashrom.org/mailman/listinfo/flashrom

Re: [flashrom] Giving to -i option some real use

[David Hendricks]

Hello Salvador,
Yes, this is a very useful feature - we've had it in the chromiumos branch
for a while now :-)

I need to read your implementation. Ours is called "fast-verify" which will
read and only verify portions of the flash specified with -i arguments.

It will also restore content surrounding regions (to address Michael's
concern) by aligning the bytes read with the erase size. So if you wish to
change a small amount of content within an eraseable block, the entire
block will be read and erased. The region specified with -i will be written
with new content, and the remaining bytes within the block will have the
old content restored.

Here's our tree in case you'd like to take a look:
https://chromium.googlesource.com/chromiumos/third_party/flashrom/


On Tue, Apr 19, 2016 at 10:48 AM, Salvador Eduardo Tropea <
salva...@inti.gob.ar> wrote:

> Hi All!
>
> Now I'm using an FPGA board with 4 MiB of flash, was using one with 128
> kiB. So now the time to read/write/verify the whole memory is enough to
> annoy me ;-)
> So I tried creating a layout like this:
>
> <--
> :7e2b fpga
> 7e2c:003f free
> <--
>
> Note: yes only 32300 bytes used, the rest can be used for other purposes
> (0,77%).
>
> And then I used "-i fpga".
> But it didn't help ... flashrom read the 4 MiB twice (one at the beggining
> and another for the verification).
> Looking at the code I found a variable named read_all_first with a comment
> about the lack of implementation.
> So I implemented the needed code to:
> 1) Add a command line option to make it 0 (avoiding the big reads). This
> option can be used only when at least one image is indicated with -i
> 2) Skip the big read when read_all_first is 0. Only the regions indicated
> by the user are actually fetched from the memory.
> 3) Same for the verification stage.
>
> Additionally I added a command line option to show the progress, very
> usefull for big memories (and impatient users ;-).
>
> Are these additions desired in the project? If yes: I want to discuss the
> implementation details. If no: I'll just keep them for my use.
>
> Regards, SET
>
> --
> Ing. Salvador Eduardo Tropea  http://utic.inti.gob.ar/
> INTI - Micro y Nanoelectró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
>
>
>
>
>
> ___
> 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