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.
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.
I'm trying to find out which external programmers should be supported next.
1. There was talk of an AVR-based new programmer using the serprog
protocol on IRC by someone with the nick "coldelectrons", but I have no
idea if he/she is reading this mail. IMHO more hardware using the
serprog protocol is always a good idea.
2. All those Willem/Sivava variants. People regularly request those, but
I don't think anyone in here owns the hardware.
3. RayeR's SPIPGM. I have a preliminary patch which could work, but I
don't have the hardware. Will send the patch to the list soon.
4. LPC^2, Milksop, CheapLPC and other programmers from the Xbox modding
5. Dozens of SPI programmer hardware projects scattered over the net.
Too many to count, and I'm not sure which of them has more than one user.
In general, it seems creating a new programmer hardware design is like
writing IRC clients: A nice way to get started in the field. I have no
problems merging flashrom support for all of them, but I won't implement
support for all of them myself.
On Wed, 27 Jul 2011 18:20:19 +0200
Mattias Mattsson <vitplister(a)gmail.com> wrote:
> Hi all,
> I was able to run flashrom under Linux on PPC (big endian) hardware
> with two small modifications in internal.c and processor_enable.c (see
> attached patch). Not sure if this is the right way to do it but it
> seems to work for me.
i am resending this patch (unchanged) because patchwork did not pick it
up correctly. please do send one patch per mail only in the future
until we have something really working. :)
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
this chip is marked as "untested" in write mode.
So here are my test-results:
Erase in d8-Mode is not working (see log).
But i think it's the already known "serprog bug".
Erase in c7-mode is ok.
Write is working in both modes.
But i don't know why in c7-mode the log shows:
0x000000-0x007fff:W, 0x008000-0x00ffff:S, 0x010000-0x017fff:S,
I have created the test-file with dd and urandom. The file (131072 byte)
is full with data.
So it should write (W) not only to 0x007fff. Strange!
If you need more logs or infos, let me know.
BTW: The chip is labeled "25P10VP". I see nothing with "-A".
And the chip was found on a "Maxtor" hard disk drive.
here are the test results for "Found Micron/Numonyx/ST flash chip
"M25P16" (2048 kB, SPI)".
Erase seems to work, but write fails.
I tried it with an Arduino Uno
Output is attached.
Here is a patch, that provides support for the MSTAR ISP protocol.
Basically, among other chips, MSTAR manufactures SoCs that equip TV sets
and computer screens, and it seems that all of their products use the
same in-system programming protocol. Basically, they use the DDC channel
of VGA or DVI connectors, which is actually an I2C bus, to encapsulate
SPI frames (the flash chip is connected to the SoC through an SPI bus).
I wrote this patch since the screen I bought had a software bug, and the
manufacturer only released a new firmware binary, but no tool or
instructions on flashing it.
More details can be found here:
I only read code from Linux kernel archives published by Acer to figure
out the protocol (for a touchscreen controller and a NFC chip, both by
MSTAR, that shared the same ISP protocol), so I don't think there are
any legal problems with it.
Please let me know what you think about this patch, and whether you're
interested in including it.
email: alex (at) boeglin (dot) org
jabber: alex (at) im (dot) boeglin (dot) org
Add support for AMD's Bolton chipset. The SPI controller on the bolton chipset
uses the same 3-bit speed settings as yangtze, but is otherwise the same as the
hudson chips. Note that the Bolton RRG doesn't specify a speed setting for the
bit setting of 0b111, so I'm assuming that it's the same setting as yangtze.
Signed-off-by: Martin Roth <martin.roth(a)se-eng.com>