On 19.12.18 20:34, David Hendricks wrote:
> 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.
I wouldn't mind a commit hook as long as a human has the last word.
If linters can be taught? I'm sure they can if they are open-source.
Maybe I don't get the question.
Nico
Hello Ben,
I've been looking at your mail again and what looked like a hardware
failure first, obviously isn't:
> Some block protection in effect, disabling... Block protection could not be
> disabled!
(Alas, error messages can somehow be missed in verbose logs...) This is
likely caused by a wrong state on a /WP pin. It should be high, deasser-
ted.
Hope that helps,
Nico
Hi all,
We're slowly moving towards using libflashrom in fwupd, rather than
exec'ing the flashrom binary and screen scraping. So that it can be
consumed by users easily, I'm tempted to use flashrom as a subproject
to the fwupd project rather than waiting for distros to ship any new
bleeding edge version of flashrom to users. To make some of that
possible, I've fixed up a few of the CI failures we would see in
fwupd, which I've filed as a PR here:
https://github.com/flashrom/flashrom/pull/67
If a GitHub PR isn't how you want these kind of general patches please
let me know. One person already told me that I needed to use Gerrit,
but I'm not overly keen on learning a new process if I can avoid it.
Feedback welcome, thanks.
Richard
Hi,
Am 15.12.18 um 02:49 schrieb 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
thanks, this was bugging me for long, but I didn't know when it was
discussed.
>
> It seems that we never really decided on 112-characters vs. 120-characters,
> so I wrote down 112-characters for now.
I guess time decided. 112 chars feels more than enough, IMHO.
> At least most were satisfied with
> an 80-column "soft" limit and an exception to the limits for tables...
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.
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
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/
sudo flashrom --programmer ch341a_spi -w 2ndpad_NVRAM.rom
flashrom v0.9.9-rc1-r1942 on Linux 4.4.0-62-lowlatency (x86_64)
flashrom is free software, get the source code at https://flashrom.org
Calibrating delay loop... OK.
Found Winbond flash chip "W25Q64.V" (8192 kB, SPI) on ch341a_spi.
Reading old flash chip contents... done.
Erasing and writing flash chip... Erase/write done.
Verifying flash... FAILED at 0x000a01a1! Expected=0x8c, Found=0x8e,
failed byte count from 0x00000000-0x007fffff: 0x7e
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!
I am trying to duplicate the audio stored on a GPR25L040B chip. The
datasheet (
https://www.dataman.com/media/datasheet/Generalplus/GPR25L040B.pdf) states
that it is fully compatible with the MX25L4005A. I seem to be able to read
the flash to a file just fine but when writing back to the file I am
getting an error (see below).
Even with the error, I seem to be able to at least partially write to the
chip but the audio that comes back cuts out after a few seconds.
This project's goal is to copy audio from a recorded book that my son's
grandma recorded with him before she passed, to another book that we can
give to my Sister-In-Law for Christmas.
I would also like to back up the audio in case something happens to the
book in the future.
(Alternate backups will be made as well prior to touching that book.) .
Any help that you can provide would be greatly appreciated.
Thank you,
Ben.
The following protocols are supported: SPI.
Probing for Macronix MX25L4005(A/C)/MX25L4006E, 512 kB:
probe_spi_rdid_generic: id1 0xc2, id2 0x2013
Found Macronix flash chip "MX25L4005(A/C)/MX25L4006E" (512 kB, SPI) on
linux_spi.
Chip status register is 0x86.
Chip status register: Status Register Write Disable (SRWD, SRP, ...) is set
Chip status register: Bit 6 is not set
Chip status register: Bit 5 is not set
Chip status register: Block Protect 2 (BP2) is not set
Chip status register: Block Protect 1 (BP1) is not set
Chip status register: Block Protect 0 (BP0) is set
Chip status register: Write Enable Latch (WEL) is set
Chip status register: Write In Progress (WIP/BUSY) is not set
Some block protection in effect, disabling... Block protection could not be
disabled!
Chip status register is 0x86.
Chip status register: Status Register Write Disable (SRWD, SRP, ...) is set
Chip status register: Bit 6 is not set
Chip status register: Bit 5 is not set
Chip status register: Block Protect 2 (BP2) is not set
Chip status register: Block Protect 1 (BP1) is not set
Chip status register: Block Protect 0 (BP0) is set
Chip status register: Write Enable Latch (WEL) is set
Chip status register: Write In Progress (WIP/BUSY) is not set
Reading old flash chip contents... done.
Erasing and writing flash chip... Trying erase function 0...
0x000000-0x000fff:S, 0x001000-0x001fff:S, 0x002000-0x002fff:S,
0x003000-0x003fff:S, 0x004000-0x004fff:S, 0x005000-0x005fff:S,
0x006000-0x006fff:S, 0x007000-0x007fff:S, 0x008000-0x008fff:S,
0x009000-0x009fff:S, 0x00a000-0x00afff:S, 0x00b000-0x00bfff:S,
0x00c000-0x00cfff:S, 0x00d000-0x00dfff:S, 0x00e000-0x00efff:S,
0x00f000-0x00ffff:S, 0x010000-0x010fff:S, 0x011000-0x011fff:S,
0x012000-0x012fff:S, 0x013000-0x013fff:S, 0x014000-0x014fff:S,
0x015000-0x015fff:S, 0x016000-0x016fff:S, 0x017000-0x017fff:S,
0x018000-0x018fff:S, 0x019000-0x019fff:S, 0x01a000-0x01afff:S,
0x01b000-0x01bfff:S, 0x01c000-0x01cfff:S, 0x01d000-0x01dfff:S,
0x01e000-0x01efff:S, 0x01f000-0x01ffff:S, 0x020000-0x020fff:S,
0x021000-0x021fff:S, 0x022000-0x022fff:S, 0x023000-0x023fff:S,
0x024000-0x024fff:S, 0x025000-0x025fff:S, 0x026000-0x026fff:S,
0x027000-0x027fff:S, 0x028000-0x028fff:S, 0x029000-0x029fff:S,
0x02a000-0x02afff:S, 0x02b000-0x02bfff:S, 0x02c000-0x02cfff:S,
0x02d000-0x02dfff:S, 0x02e000-0x02efff:S, 0x02f000-0x02ffff:S,
0x030000-0x030fff:S, 0x031000-0x031fff:S, 0x032000-0x032fff:S,
0x033000-0x033fff:S, 0x034000-0x034fff:S, 0x035000-0x035fff:S,
0x036000-0x036fff:S, 0x037000-0x037fff:S, 0x038000-0x038fff:S,
0x039000-0x039fff:S, 0x03a000-0x03afff:S, 0x03b000-0x03bfff:S,
0x03c000-0x03cfff:S, 0x03d000-0x03dfff:S, 0x03e000-0x03efff:S,
0x03f000-0x03ffff:S, 0x040000-0x040fff:S, 0x041000-0x041fff:S,
0x042000-0x042fff:S, 0x043000-0x043fff:S, 0x044000-0x044fff:S,
0x045000-0x045fff:S, 0x046000-0x046fff:S, 0x047000-0x047fff:S,
0x048000-0x048fff:S, 0x049000-0x049fff:S, 0x04a000-0x04afff:S,
0x04b000-0x04bfff:S, 0x04c000-0x04cfff:S, 0x04d000-0x04dfff:S,
0x04e000-0x04efff:S, 0x04f000-0x04ffff:S, 0x050000-0x050fff:S,
0x051000-0x051fff:S, 0x052000-0x052fff:S, 0x053000-0x053fff:S,
0x054000-0x054fff:S, 0x055000-0x055fff:S, 0x056000-0x056fff:S,
0x057000-0x057fff:S, 0x058000-0x058fff:S, 0x059000-0x059fff:S,
0x05a000-0x05afff:S, 0x05b000-0x05bfff:S, 0x05c000-0x05cfff:S,
0x05d000-0x05dfff:S, 0x05e000-0x05efff:S, 0x05f000-0x05ffff:S,
0x060000-0x060fff:S, 0x061000-0x061fff:S, 0x062000-0x062fff:S,
0x063000-0x063fff:S, 0x064000-0x064fff:S, 0x065000-0x065fff:S,
0x066000-0x066fff:S, 0x067000-0x067fff:S, 0x068000-0x068fff:S,
0x069000-0x069fff:S, 0x06a000-0x06afff:S, 0x06b000-0x06bfff:S,
0x06c000-0x06cfff:S, 0x06d000-0x06dfff:S, 0x06e000-0x06efff:S,
0x06f000-0x06ffff:S, 0x070000-0x070fff:S, 0x071000-0x071fff:S,
0x072000-0x072fff:S, 0x073000-0x073fff:S, 0x074000-0x074fff:S,
0x075000-0x075fff:EFAILED at 0x00075000! Expected=0xff, Found=0x89, failed
byte count from 0x00075000-0x00075fff: 0xf3f
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase
function.
Trying erase function 1... 0x000000-0x00ffff:S, 0x010000-0x01ffff:S,
0x020000-0x02ffff:S, 0x030000-0x03ffff:S, 0x040000-0x04ffff:S,
0x050000-0x05ffff:S, 0x060000-0x06ffff:S, 0x070000-0x07ffff:EFAILED at
0x00070000! Expected=0xff, Found=0x40, failed byte count from
0x00070000-0x0007ffff: 0x79ab
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase
function.
Trying erase function 2... 0x000000-0x00ffff:S, 0x010000-0x01ffff:S,
0x020000-0x02ffff:S, 0x030000-0x03ffff:S, 0x040000-0x04ffff:S,
0x050000-0x05ffff:S, 0x060000-0x06ffff:S, 0x070000-0x07ffff:EFAILED at
0x00070000! Expected=0xff, Found=0x00, failed byte count from
0x00070000-0x0007ffff: 0x79ab
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase
function.
Trying erase function 3... 0x000000-0x07ffff:EFAILED at 0x00000000!
Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x0007ffff:
0x3a0c2
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase
function.
Trying erase function 4... 0x000000-0x07ffff:EFAILED at 0x00000000!
Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x0007ffff:
0x3a0c2
ERASE FAILED!
Reading current flash chip contents... done. Looking for another erase
function.
Trying erase function 5... not defined. Looking for another erase function.
Trying erase function 6... not defined. Looking for another erase function.
Trying erase function 7... not defined. No usable erase functions left.
FAILED!
Uh oh. Erase/write failed. Checking if anything has changed.
Reading current flash chip contents... done.
Good, writing to the flash chip apparently didn't do anything.
Please check the connections (especially those to write protection pins)
between
the programmer and the flash chip. If you think the error is caused by
flashrom
please report this on IRC at chat.freenode.net (channel #flashrom) or
mail flashrom(a)flashrom.org, thanks!
Hello,
I'm trying to manage AT25SF041 using FT4232 MiniModule programmer. I'm
using flashrom v1.0 on Linux 4.15.0-42-generic (x86_64) compiled from
sources. Trying to erase chip at first and get this output:
./flashrom -p ft2232_spi:type=4232H,port=A -Ef
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Found Atmel flash chip "unknown Atmel SPI chip" (0 kB, SPI) on ft2232_spi.
===
This flash part has status NOT WORKING for operations: PROBE READ ERASE
WRITE
The test status of this chip may have been updated in the latest development
version of flashrom. If you are running the latest development version,
please email a report to flashrom(a)flashrom.org if any of the above
operations
work correctly for you with this flash chip. Please include the flashrom log
file for all operations you tested (see the man page for details), and
mention
which mainboard or programmer you tested in the subject line.
Thanks for your help!
Read is not working on this chip. Continuing anyway.
flashrom has no read function for this flash chip.
Aborting.
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!
According to https://www.flashrom.org/Supported_hardware page, this chip
should be fully supported.
Please advice.
Thank you,
Adam
A Hardware Enablement devroom will be taking place at FOSDEM this year,
on Sunday 10 December 2017. This newly-created devroom is the result of
3 proposals that were merged together. It is co-organized by several
individuals.
The devroom covers all aspects related to hardware enablement and
support with free software, including aspects related to boot software,
firmwares, drivers and userspace tools and adaptation.
Proposals for talks related to these topics are welcome and can be
submitted until Sunday 26 November 2017 via the pentabarf interface.
Short talks are encouraged over longer ones in order to cover a wide
range of topics.
The announcement for the devroom, that contains all the useful
information, was published at:
https://lists.fosdem.org/pipermail/fosdem/2017-October/002649.html
Cheers and see you at FOSDEM!
--
Paul Kocialkowski, developer of free digital technology and hardware
support
Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/https://git.code.paulk.fr/
