Hi there-
I'm looking at swapping out the physical flash chip on my machine for a
larger capacity one, so I wanted to get a quick sanity check:
Does a flashrom -r pick up all the various regions in the chip, or does it
only go after the BIOS region if I don't specify a layout file?
I.e if I do a flashrom -r on the old chip then flashrom -w on the new one,
will I get an identical copy of the entire thing?
Thanks and apologies if this can be found in the documentation, please feel
free to point me there instead.
Rafael
On Mon, 9 May 2016 20:46:18 -0700
David Hendricks <dhendrix(a)google.com> wrote:
> 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.
However, we will add the new names to the in-program (and hence
wiki) database so that this new information becomes public. Thanks for
the heads up, Victor.
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
Hi Steffen,
if that agrees with the free and open source software idea is to discuss by the flashrom owners (I think you deserve an answer by the owners...)
Nevertheless I´d like to try it to look if it performs better than libftdi (at least for debugging where time could be saved).
Would be nice if you could make it available in any way! (via Mail/git/etc.)
Regards,
Simon
I found that libusb calls are mainly responsible for long idle times.
For some improvement/workaround look at E-Mail with topic: ftdi_write_chunksize, block_erasers and spi_read_status_register proposals
https://mail.coreboot.org/hyperkitty/list/flashrom@flashrom.org/thread/W2HU…
But still looking for further improvement.
Regards,
Simon
Here's a list of patches in the flashrom project that haven't been
touched in a while. Someone might want to consider abandoning or
reviving them.
I'm abandoning the coreboot patches next week, but I'll let the
flashrom community decide how to take care of these.
https://review.coreboot.org/q/status:open+before:2018-02-1+project:flashrom
Martin
Greetings everyone,
I'm a new member of flashrom mailing list, searching for info pertaining certain external programmer and corresponding 'flashrom' support. I noticed that the official list of supported programmers has not been updated for quite a while (January 2018), so I'd be interested to know if anyone succeeded to make it work - running 'flashrom' on Linux machine, in combination with this tiny programmer:
Product designation: "NANO USB Programmer"
Mfg: HS-TECH R.O.K, Korea
MPN: NANOUSB001
Site: http://shop3.nanobios.cafe24.com/article/download/7/8/?page=1
Programmer's core silicon:
Name: Cypress enCoRe II
Short description: Low Speed USB Peripheral Controller, with 8-bit M8C core.
Chip designation: CY7C63813-PXC
Ref.: https://www.cypress.com/products/encore-ii
USB ID: 04b4:3813
Name: NANO BIOS Programmer
Link: https://usb-ids.gowdy.us/read/UD/04b4/3813
WIN driver: cyusb3.inf (in case it's relevant);
----------------------------------------------------------------------------
I already contacted the guy, who runs the website mentioned above (shop3.nanobios.cafe24.com), and who also sells these programmers on eBay. He responded that in-the-house software, currently "NANO BIOS Programmer v1.1", is the only software that works with their Nano USB Programmer, but he promised to look into possibility, to "run an open platform software" for this programmer, as he elaborated in his response.
Since I have doubts that Windows based programming SW will be ported to Linux, at least not in a foreseeable time window, I would appreciate any useful information, as in - whether this programmer is supported by 'flashrom' project, what needs to be done to make it happen, which Linux distro you're using (in case it matters), etc.
Thank you in advance !
Kind regards,
Bostjan
Hi,
I´m using flashrom to program a N25Q128E flash with a FT2232H chip (via linux in a virtual machine, I hope the virtual machine does not alter the results too much).
As I found the programming time is quite long, I made some research.
Here are some suggestions about which I think it´s worth to discuss (I started with a programming time of 05:15 min and got down to 1:44 min):
1) Proposal: in ft2332_spi.c change ftdi-chunksize to 269
###### CODE Start #####
//Simon Buhrow: changed from 256 to 269 (1 Byte Flash CMD + 3 Byte Address + 256 Byte Flash-Data + 9 Byte FTDI-CMD)
if (ftdi_write_data_set_chunksize(ftdic, 269)) {
msg_perr("Unable to set chunk size (%s).\n", ftdi_get_error_string(ftdic));
}
###### CODE End #####
Background: Measurements with the oszilloscope let me see, that the transmission of a 256-Byte-page-write-paket takes about 4 ms.
Please check spi_rpd_flashrom_bad_page_write_01.png for that (blue = SCK, green = nCS). Above is the whole measurement and below a zoom.
First there is the zoomed 2000 bit = 250 Byte burst, followed by a 10 Byte burst (= 260 Byte => 1 Byte Flash Cmd + 3 Byte Address + 256 Byte Flash data).
The ftdi_write_data_chunksize refers to all bytes send to the ftdi-chip and not only the raw-flash-data. So the first 256 Bytes of the actually 269 Bytes
(6 Byte FTDI-Start-CMD + 1 Byte Flash CMD + 3 Byte Address + 256 Byte Flash-Data + 3 Byte FTDI-CMD) are send to ftdi-chip in a first paket.
That´s why it sends only 250 Bytes in a first spi burst (as there are 6 Bytes of ftdi-cmds first followed by the flash cmd, address and raw data) and 10 Bytes in a second spi burst.
Changing the value as proposed above the transmission of a 256-Byte-page-write-paket takes just about 80µs.
Please check spi_rpd_flashrom_good_page_write.png for validation.
I did not check the USB-Communication (for efficiency of paket sizes).
But as you can see at spi-level it looks much better. And the total programming time was (in my case) about 30 seconds faster.
2) Proposal: add a flashrom cli parameter to select the block_erasers num
May be there is already a similar functionality. But as I can see, the differen block_erasers given in flashchips.c are always used in the manner, that if the first entry works, the first entry is used and that´s it.
In my case the second erase-function is the fastest (as I do not write the whole flash). Of course the work around is to change the order in flashchips.c, but may be there could be realized a more comfortable solution?
3) Wish: accelerate spi_read_status_register() after program data
Please check spi_rpd_flashrom_bad_page_write_01.png again to see that reading status-register takes quite a long time as well (at the beginning there is 1 Byte send to flash and 2 Byte read from flash and then just idle time).
As it is called quite a lot of times it really matters to timing.
Looking some deeper I found that libusb_bulk_transfer() which is called from ftdi_read_data() is the bottle_neck (simple measured with prints).
I did not get deeper. So I can´t say if the ftdi-chip is bad configured or is too slow or if libusb is not that efficient. To get a good solution for that would be fine.
As a simple workaround for shorter programming time I propose - in case of program operation - to not call spi_read_status_register() but just wait a short time (1ms) (may be configurable with a cli parameter or via data at flashchips.c).
Why? - I think spi_read_status_register() or better the calling spi25.c:spi_poll_wip() does not has any benefit in my case.
It does only check for wip. But as you can see on the scope image it is done several ms after page-program. At least my flash does take much less than 1ms for a page program.
Replacing the spi_poll_wip call for all program operations (not erase operations, as they last longer) by a 1ms programmer_delay speed up my programming time much more than 1 minute!!
Here is what I did: I added a parameter to spr_write_cmd to indicate if spi_poll_wip() shall be done or not:
###### CODE Start #####
static int spi_write_cmd(..., const unsigned int ignore_spi_poll_wip)
{
...
if (ignore_spi_poll_wip == 0){
status = spi_poll_wip(flash, poll_delay);
}
else{
programmer_delay(1000);
}
}
...
spi_nbyte_program(struct flashctx *flash, unsigned int addr, const uint8_t *bytes, unsigned int len)
{
...
return spi_write_cmd(..., 1); // Simon Buhrow: added ,1 to indicate to not call read_status_register
}
###### CODE End #####
May be there are any ideas about making this more general and cleaner?
What do you think?
Regards,
Simon
Signed-off-by: Simon Buhrow <simon.buhrow(a)sieb-meyer.de>
$ sudo flashrom --programmer internal
[sudo] password for wahyudin:
flashrom on Linux 5.0.0-20-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 chipset "AMD FP4".
Enabling flash write... FCH device found but SMBus revision 0x61 does
not match known values.
Please report this to flashrom(a)flashrom.org and include this log and
the output of lspci -nnvx, thanks!.
Could not determine chipset generation.PROBLEMS, continuing anyway
No EEPROM/flash device found.
Note: flashrom can never write if the flash chip isn't found automatically.
hello
i have a problem in use of thid library which has been put in Github.
i dont know how to introduce my chip (for programming).
i am afraid of breaking my laptop with my wrongs.
please help me!
Sara
