80/100/132 column line width policy
by Carl-Daniel Hailfinger
Hi,
we're hitting the 80 column limit in our code in ways which actually
reduce readability for the code. Examples are various multiline messages
and complicated nested code where refactoring to a separate function
doesn't make sense.
Keeping the old 80 column limit is not really an option anymore.
Standard terminal sizes have one of 80, 100 or 132 columns.
Given the monitor resolutions many people have nowadays, I think it is
safe to say that you can fit two xterms with 100 columns horizonally
next to each other. 100 columns should also be sufficient for a msg_p*
of roughly 80 columns of text.
132 columns provide more leeway, but IMHO that would be too wide for
good readability (and my screen can't fit two xterms side-by-side anymore).
Of course some files have sections where any column limit is not
acceptable (board lists etc.), but the column limit violations should be
limited to the affected file sections, not whole files.
Comments?
I'd like to get this decided today or tomorrow so we know where we need
line breaks in Stefan Tauner's new struct flashchip patch.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
3 months, 1 week
Spansion S25FL128P......X
by The Raven
I have a spansion S25FL128P......X chip and can do some tests.
The "problem" is that i don't know if its an 0 or an 1.
On the chip i see only "FL128PIF" and one line lower i see "00299012 C".
Probing works (id1 0x01, id2 0x2018):
Calibrating delay loop... OK.
serprog: Programmer name is "serprog-duino"
Found Spansion flash chip "S25FL128P......0" (16384 kB, SPI) on serprog.
Found Spansion flash chip "S25FL128P......1" (16384 kB, SPI) on serprog.
Found Spansion flash chip "S25FL128S......0" (16384 kB, SPI) on serprog.
Found Spansion flash chip "S25FL128S......1" (16384 kB, SPI) on serprog.
Found Spansion flash chip "S25FL129P......0" (16384 kB, SPI) on serprog.
Found Spansion flash chip "S25FL129P......1" (16384 kB, SPI) on serprog.
Multiple flash chip definitions match the detected chip(s):
"S25FL128P......0", "S25FL128P......1", "S25FL128S......0",
"S25FL128S......1", "S25FL129P......0", "S25FL129P......1"
Please specify which chip definition to use with the -c <chipname> option.
BTW: Chip was fund on a Dell-Systemboard.
1 year, 11 months
FOSDEM 2017
by Carl-Daniel Hailfinger
Hi,
FOSDEM 2017 deadlines are soon.
Do we want to have a full developer room, a talk or just a stand?
Unfortunately I won't be able to attend, so someone else will have to be
the formal contact for organizing our stand/devroom/talk. I will help
with submitting proposals if this is desired by the person organizing
our stand/devroom/...
Who is willing to take care of our FOSDEM 2017 presence?
https://fosdem.org/2017/news/2016-07-20-call-for-participation/
Deadlines:
Developer Rooms: 9 September
Main Track Talks: 10 October
Stands: 31 October
Lightning talks: 25 November
Regards,
Carl-Daniel
2 years, 3 months
[PATCH] internal: Dont define functions on yet unsupported architechtures
by Urja Rannikko
This fixes a warning with newer (6.1) gcc on ARM,
as tested by swiftgeek on irc.
Signed-off-by: Urja Rannikko <urjaman(a)gmail.com>
---
internal.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/internal.c b/internal.c
index 4062b64..aa5f1d1 100644
--- a/internal.c
+++ b/internal.c
@@ -131,6 +131,8 @@ int register_superio(struct superio s)
int is_laptop = 0;
int laptop_ok = 0;
+/* This matches with the #if for the registration of par_master_internal */
+#if IS_X86 || IS_MIPS
static void internal_chip_writeb(const struct flashctx *flash, uint8_t val,
chipaddr addr);
static void internal_chip_writew(const struct flashctx *flash, uint16_t val,
@@ -155,6 +157,7 @@ static const struct par_master par_master_internal = {
.chip_writel = internal_chip_writel,
.chip_writen = fallback_chip_writen,
};
+#endif
enum chipbustype internal_buses_supported = BUS_NONE;
@@ -358,6 +361,8 @@ int internal_init(void)
}
#endif
+/* This matches with the #if for the registration of par_master_internal */
+#if IS_X86 || IS_MIPS
static void internal_chip_writeb(const struct flashctx *flash, uint8_t val,
chipaddr addr)
{
@@ -400,3 +405,4 @@ static void internal_chip_readn(const struct flashctx *flash, uint8_t *buf,
mmio_readn((void *)addr, buf, len);
return;
}
+#endif
--
2.9.3
2 years, 3 months
Re: [flashrom] ENE KB9012 patches: new test results
by Paul Kocialkowski
Hi, I got your emails just fine, I just didn't have time to sit down and write a proper reply but I'm very enthusiasic about working with you !
Cheers,
Paul Kocialkowski
Le vendredi 23 septembre 2016 à 03:16 +0300, mikeb mikeb a écrit :
> Good day! I just tried reading from KB9012 and encountered exactly the same
> problem as Joerg Albert has ( https://www.flashrom.org/pipermail/flashrom/2016
> -May/014653.html ) - chip is detected only every second time. This is not
> caused by cabling. While it is recommended for SPI that the wires should be
> shorter than 20cm, my wires are 11 cm: 8 cm of which is 12 strands high
> quality copper and only 3 cm are ordinary aluminium inside the 30 pin 0.5mm
> pitch keyboard-like connector
This is interesting! I still haven't been able to reproduce the issue (but
haven't tried so hard either). Could you indicate whether you are:
* grounding pin 42 to go into test mode
* powering the mainboard
Thanks!
> NOTE: it was much easier and safer to solder 1P wires to this connector rather
> than to motherboard, and you could remove/insert it at any time - what a great
> convenience! The only 1P wire I had to solder to motherboard is to
> motherboard's ground, - to make it possible to unite three grounds
> (motherboard s, KB9012 s and programmer s) - and that was really easy because
> at least one of these orange circle grounds has a great distance between it
> and motherboard's elements so it is difficult to screw up there :) Going to
> share photos and write some manuals about connectivity, hopefully helpful to
> the people like me who want to participate in Origami EC project - creation of
> open source firmware for KB9012 which in case of success will be a HUGE step
> towards Lenovo G505S liberation (AMD laptop with coreboot support) .
> Discovered Paul's presentation talk by pure accident -
> https://www.youtube.com/watch?v=B708jdCiW7o
>
> So I tried using two SPI programmers: 1) CH341A . 2) Bus Pirate v4 . The only
> observed difference is a speed: for CH341A read takes 13-14 minutes, while for
> BPv4 - despite the latest 7.0 firmware with level 3 optimizations ( http://dan
> gerousprototypes.com/docs/Bus_Pirate#Download ) and SPI speed is 8 MHz - it
> takes 40 minutes to read! Checksums of the files are the same and the files
> have almost the same contains as KB9012 image for LA-A091P G505S that I found
> online (same except the area 0x1d000 - 0x1e0f0, their image is filled with
> 0xff there, mine has many 0x00 with a few 0xff and also data - probably
> encoded serial number and similar stuff) , so I am pretty sure these
> programmers both are reading without errors in my setup, just at the different
> speeds for some weird reason
>
> Patches applied before testing:
> 1) https://patchwork.coreboot.org/patch/4412/
> 2) https://patchwork.coreboot.org/patch/4413/
> 3) https://patchwork.coreboot.org/patch/4414/
>
> This problem with 1/2 detection rate is not a blocker, more like a small
> inconvenience, so I strongly believe that these patches should be merged as
> soon as possible! Paul Kocialkowski has committed them almost a year ago, such
> a major feature and still not merged??
>
> Below you could see some -VVV detection logs.
>
> After reading this really inspiring article ( http://code.paulk.fr/article25/a
> n-incentive-for-liberating-computers-my-own-use-case ) I guess that Paul's
> motherboard is LA-A092P, very similar to LA-A091P but no extra GPU. Could that
> be a reason he is not getting a detection problem? Just a wild guess...
>
> Yours sincerely,
> Mikeb
>
> 1) Common part of "2) and "3)" - CH341A tries to detect:
> sudo ./flashrom -p ch341a_spi -c "KB9012 (EDI)" -VVV
> flashrom v0.9.9-r1954 on Linux 4.4.0-36-generic (x86_64)
> flashrom is free software, get the source code at https://flashrom.org
> flashrom was built with libpci 3.3.1, GCC 5.4.0 20160609, little endian
> Command line (5 args): ./flashrom -p ch341a_spi -c KB9012 (EDI) -VVV
>
> 2) FAIL:
> Calibrating delay loop... OS timer resolution is 1 usecs, 578M loops per
> second, 10 myus = 11 us, 100 myus = 92 us, 1000 myus = 914 us, 10000 myus =
> 9661 us, 4 myus = 5 us, OK.
> Initializing ch341a_spi programmer, Device revision is 3.0.4
> Wrote 3 bytes: aa 61 00
> Wrote 4 bytes: ab b7 7f 20
> The following protocols are supported: SPI.
> Probing for ENE KB9012 (EDI), 128 kB: programmer_map_flash_region: mapping
> KB9012 (EDI) from 0x00000000fffe0000 to 0x0000000000000000
> Wrote 40 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 a8 0c 00 ff 00 ff ff ff
> Read 7 bytes: ff ff ff ff 00 00 00
> programmer_unmap_flash_region: unmapped 0x0000000000000000
> No EEPROM/flash device found.
> Note: flashrom can never write if the flash chip isn't found automatically.
> Wrote 4 bytes: ab b7 40 20
>
> 3) SUCCESS:
> Calibrating delay loop... OS timer resolution is 1 usecs, 629M loops per
> second, 10 myus = 11 us, 100 myus = 100 us, 1000 myus = 994 us, 10000 myus =
> 9974 us, 4 myus = 4 us, OK.
> Initializing ch341a_spi programmer, Device revision is 3.0.4
> Wrote 3 bytes: aa 61 00
> Wrote 4 bytes: ab b7 7f 20
> The following protocols are supported: SPI.
> Probing for ENE KB9012 (EDI), 128 kB: programmer_map_flash_region: mapping
> KB9012 (EDI) from 0x00000000fffe0000 to 0x0000000000000000
> Wrote 40 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 a8 0c 00 ff 00 ff ff ff
> Read 7 bytes: 00 00 00 00 fa 0a c3
> Wrote 40 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 a8 0c 00 ff 24 ff ff ff
> Read 7 bytes: 00 00 00 00 fa 0a 20
> Wrote 40 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 a8 0c 00 ff 28 ff ff ff
> Read 7 bytes: 00 00 00 00 fa 0a 00
> Wrote 38 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 a8 02 00 ff 28 80
> Read 5 bytes: 00 00 00 00 00
> Found ENE flash chip "KB9012 (EDI)" (128 kB, SPI) on ch341a_spi.
> programmer_unmap_flash_region: unmapped 0x0000000000000000
> No operations were specified.
> Wrote 40 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 a8 0c 00 ff 28 ff ff ff
> Read 7 bytes: 00 00 00 00 fa 0a 80
> Wrote 38 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 a8 02 00 ff 28 00
> Read 5 bytes: 00 00 00 00 00
> Wrote 34 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 a8 cf
> Read 1 bytes: 00
> Wrote 4 bytes: ab b7 40 20
>
> 4) Small part of Bus Pirate v4 reading log:
> buspirate_sendrecv: write 9, read 4 Sending 0x04 0x00 0x04 0x00 0x03 0x30 0x00
> 0xfe 0xab, receiving 0x01 0x5f 0x50 0x90
> buspirate_sendrecv: write 10, read 1 Sending 0x04 0x00 0x05 0x00 0x00 0x40
> 0x00 0xfe 0xa8 0xc6, receiving 0x01
> buspirate_sendrecv: write 10, read 1 Sending 0x04 0x00 0x05 0x00 0x00 0x40
> 0x00 0xfe 0xac 0x03, receiving 0x01
> buspirate_sendrecv: write 9, read 4 Sending 0x04 0x00 0x04 0x00 0x03 0x30 0x00
> 0xfe 0xab, receiving 0x01 0x5f 0x50 0xec
> buspirate_sendrecv: write 10, read 1 Sending 0x04 0x00 0x05 0x00 0x00 0x40
> 0x00 0xfe 0xa8 0xc7, receiving 0x01
> buspirate_sendrecv: write 10, read 1 Sending 0x04 0x00 0x05 0x00 0x00 0x40
> 0x00 0xfe 0xac 0x03, receiving 0x01
>
> 5) Small part of CH341A reading log:
> Read 5 bytes: 00 00 00 00 00
> Wrote 40 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 a8 0c 00 7f d5 ff ff ff
> Read 7 bytes: 00 00 00 00 fa 0a ff
> Wrote 38 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 a8 02 00 7f 15 fb
> Read 5 bytes: 00 00 00 00 00
> Wrote 38 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 a8 02 00 7f 35 c0
> Read 5 bytes: 00 00 00 00 00
> Wrote 40 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 a8 0c 00 7f d5 ff ff ff
>
--
Paul Kocialkowski, developer of low-level free software for embedded devices
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
--
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.
2 years, 5 months
Flashrom error with request to report
by Thomas Köhn
Calibrating delay loop... OK.
Found Spansion flash chip "S25FL164K" (8192 kB, SPI) on ft2232_spi.
Reading old flash chip contents... done.
Erasing and writing flash chip... FAILED at 0x00000000! Expected=0xff,
Found=0xbd, failed byte count from 0x00000000-0x00000fff: 0x2fb
ERASE FAILED!
Reading current flash chip contents... ftdi_write_data: -110, usb bulk
write failed
send_buf failed at end: 1
Can't read anymore! Aborting.
FAILED!
Uh oh. Erase/write failed. Checking if anything has changed.
Reading current flash chip contents... ftdi_write_data: -110, usb bulk
write failed
send_buf failed at end: 1
Can't even read anymore!
Your flash chip is in an unknown state.
Please report this on IRC at chat.freenode.net (channel #flashrom) or
mail flashrom(a)flashrom.org, thanks!
2 years, 5 months
Flashrom try while logged in
by john
I tried the flashEROm for an older computer A7V266, at the moment it has
the 1011 flash installed, I am intending to try the 1015: only to see if
there are any features that provide more options, such as boot from USB or
set NUMLOCK, which at the moment it does have for either one (USB or
NUMLOCK)
The last flash offer available from global server, not the USA support
site, although the link was provided for other locations..
2 years, 5 months
ENE KB9012 patches: new test results
by mikeb mikeb
Good day! I just tried reading from KB9012 and encountered exactly the same
problem as Joerg Albert has (
https://www.flashrom.org/pipermail/flashrom/2016-May/014653.html ) - chip
is detected only every second time. This is not caused by cabling. While it
is recommended for SPI that the wires should be shorter than 20cm, my wires
are 11 cm: 8 cm of which is 12 strands high quality copper and only 3 cm
are ordinary aluminium inside the 30 pin 0.5mm pitch keyboard-like connector
NOTE: it was much easier and safer to solder 1P wires to this connector
rather than to motherboard, and you could remove/insert it at any time -
what a great convenience! The only 1P wire I had to solder to motherboard
is to motherboard's ground, - to make it possible to unite three grounds
(motherboard s, KB9012 s and programmer s) - and that was really easy
because at least one of these orange circle grounds has a great distance
between it and motherboard's elements so it is difficult to screw up there
:) Going to share photos and write some manuals about connectivity,
hopefully helpful to the people like me who want to participate in Origami
EC project - creation of open source firmware for KB9012 which in case of
success will be a HUGE step towards Lenovo G505S liberation (AMD laptop
with coreboot support) . Discovered Paul's presentation talk by pure
accident - https://www.youtube.com/watch?v=B708jdCiW7o
So I tried using two SPI programmers: 1) CH341A . 2) Bus Pirate v4 . The
only observed difference is a speed: for CH341A read takes 13-14 minutes,
while for BPv4 - despite the latest 7.0 firmware with level 3 optimizations
( http://dangerousprototypes.com/docs/Bus_Pirate#Download ) and SPI speed
is 8 MHz - it takes 40 minutes to read! Checksums of the files are the same
and the files have almost the same contains as KB9012 image for LA-A091P
G505S that I found online (same except the area 0x1d000 - 0x1e0f0, their
image is filled with 0xff there, mine has many 0x00 with a few 0xff and
also data - probably encoded serial number and similar stuff) , so I am
pretty sure these programmers both are reading without errors in my setup,
just at the different speeds for some weird reason
Patches applied before testing:
1) https://patchwork.coreboot.org/patch/4412/
2) https://patchwork.coreboot.org/patch/4413/
3) https://patchwork.coreboot.org/patch/4414/
This problem with 1/2 detection rate is not a blocker, more like a small
inconvenience, so I strongly believe that these patches should be merged as
soon as possible! Paul Kocialkowski has committed them almost a year ago,
such a major feature and still not merged??
Below you could see some -VVV detection logs.
After reading this really inspiring article (
http://code.paulk.fr/article25/an-incentive-for-liberating-computers-my-o...
) I guess that Paul's motherboard is LA-A092P, very similar to LA-A091P but
no extra GPU. Could that be a reason he is not getting a detection problem?
Just a wild guess...
Yours sincerely,
Mikeb
1) Common part of "2) and "3)" - CH341A tries to detect:
sudo ./flashrom -p ch341a_spi -c "KB9012 (EDI)" -VVV
flashrom v0.9.9-r1954 on Linux 4.4.0-36-generic (x86_64)
flashrom is free software, get the source code at https://flashrom.org
flashrom was built with libpci 3.3.1, GCC 5.4.0 20160609, little endian
Command line (5 args): ./flashrom -p ch341a_spi -c KB9012 (EDI) -VVV
2) FAIL:
Calibrating delay loop... OS timer resolution is 1 usecs, 578M loops per
second, 10 myus = 11 us, 100 myus = 92 us, 1000 myus = 914 us, 10000 myus =
9661 us, 4 myus = 5 us, OK.
Initializing ch341a_spi programmer, Device revision is 3.0.4
Wrote 3 bytes: aa 61 00
Wrote 4 bytes: ab b7 7f 20
The following protocols are supported: SPI.
Probing for ENE KB9012 (EDI), 128 kB: programmer_map_flash_region: mapping
KB9012 (EDI) from 0x00000000fffe0000 to 0x0000000000000000
Wrote 40 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 a8 0c 00 ff 00 ff ff ff
Read 7 bytes: ff ff ff ff 00 00 00
programmer_unmap_flash_region: unmapped 0x0000000000000000
No EEPROM/flash device found.
Note: flashrom can never write if the flash chip isn't found automatically.
Wrote 4 bytes: ab b7 40 20
3) SUCCESS:
Calibrating delay loop... OS timer resolution is 1 usecs, 629M loops per
second, 10 myus = 11 us, 100 myus = 100 us, 1000 myus = 994 us, 10000 myus
= 9974 us, 4 myus = 4 us, OK.
Initializing ch341a_spi programmer, Device revision is 3.0.4
Wrote 3 bytes: aa 61 00
Wrote 4 bytes: ab b7 7f 20
The following protocols are supported: SPI.
Probing for ENE KB9012 (EDI), 128 kB: programmer_map_flash_region: mapping
KB9012 (EDI) from 0x00000000fffe0000 to 0x0000000000000000
Wrote 40 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 a8 0c 00 ff 00 ff ff ff
Read 7 bytes: 00 00 00 00 fa 0a c3
Wrote 40 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 a8 0c 00 ff 24 ff ff ff
Read 7 bytes: 00 00 00 00 fa 0a 20
Wrote 40 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 a8 0c 00 ff 28 ff ff ff
Read 7 bytes: 00 00 00 00 fa 0a 00
Wrote 38 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 a8 02 00 ff 28 80
Read 5 bytes: 00 00 00 00 00
Found ENE flash chip "KB9012 (EDI)" (128 kB, SPI) on ch341a_spi.
programmer_unmap_flash_region: unmapped 0x0000000000000000
No operations were specified.
Wrote 40 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 a8 0c 00 ff 28 ff ff ff
Read 7 bytes: 00 00 00 00 fa 0a 80
Wrote 38 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 a8 02 00 ff 28 00
Read 5 bytes: 00 00 00 00 00
Wrote 34 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 a8 cf
Read 1 bytes: 00
Wrote 4 bytes: ab b7 40 20
4) Small part of Bus Pirate v4 reading log:
buspirate_sendrecv: write 9, read 4 Sending 0x04 0x00 0x04 0x00 0x03 0x30
0x00 0xfe 0xab, receiving 0x01 0x5f 0x50 0x90
buspirate_sendrecv: write 10, read 1 Sending 0x04 0x00 0x05 0x00 0x00 0x40
0x00 0xfe 0xa8 0xc6, receiving 0x01
buspirate_sendrecv: write 10, read 1 Sending 0x04 0x00 0x05 0x00 0x00 0x40
0x00 0xfe 0xac 0x03, receiving 0x01
buspirate_sendrecv: write 9, read 4 Sending 0x04 0x00 0x04 0x00 0x03 0x30
0x00 0xfe 0xab, receiving 0x01 0x5f 0x50 0xec
buspirate_sendrecv: write 10, read 1 Sending 0x04 0x00 0x05 0x00 0x00 0x40
0x00 0xfe 0xa8 0xc7, receiving 0x01
buspirate_sendrecv: write 10, read 1 Sending 0x04 0x00 0x05 0x00 0x00 0x40
0x00 0xfe 0xac 0x03, receiving 0x01
5) Small part of CH341A reading log:
Read 5 bytes: 00 00 00 00 00
Wrote 40 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 a8 0c 00 7f d5 ff ff ff
Read 7 bytes: 00 00 00 00 fa 0a ff
Wrote 38 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 a8 02 00 7f 15 fb
Read 5 bytes: 00 00 00 00 00
Wrote 38 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 a8 02 00 7f 35 c0
Read 5 bytes: 00 00 00 00 00
Wrote 40 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 a8 0c 00 7f d5 ff ff ff
2 years, 6 months
Re: [flashrom] Issue programming SPI flash
by Stefan Tauner
On Tue, 20 Sep 2016 23:00:15 +0000
Steve Burks <steve.burks(a)us.kontron.com> wrote:
> Hi,
> I have been flashing Macronix SPI with device ID MX25L12805D. We now have a new Numonyx SPI with device ID N25Q128..3E. However, when I try to flash the device it says that no flash device was found. But when I do the -p internal it clearly shows the device ID N25Q128..3E
>
> I have attached the verbose output from when I ran the command. I appreciate any assistance that you can provide.
>
> Thank you.
>
> Stephen Burks
Hi Stephen,
you have a Winbond W25Q128 there. All of these three are
interchangeable so I guess someone swapped it without telling you :)
In any case you should not use the -c parameter unless you have to and
really know what chip is on there. Without it flashrom will find the
right chip itself if it can.
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
2 years, 6 months
