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
Following patch adds the en29lv640b which needs special command sequences in 8
bit mode. Also, 8 bit programming needs actually 16bit double byte program.
The chip is found on bifferboard.
Please check the patch and let me know.
Signed-off-by: Rudolf Marek <r.marek(a)assembler.cz>
Am 21.07.2011 17:54 schrieb Stefan Tauner:
> previously the dummies were initialized to be empty (all ones), which makes writes skip
> erasing altogether. with this patch the default is to fill it with random bytes instead and the
> old behavior can be enforced with stating "empty=yes" on the command line.
> Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at>
Does the following not work for you?
dd if=/dev/urandom bs=1k count=4k of=oldimage.bin
flashrom -p dummy:emulate=SST25VF032B,image=oldimage.bin -w newimage.bin
I've tried to run flashrom -V to see if it could identify the chip on my
new board (AsRock M3A-GLAN), and it got stuck while probing for the
I've tried commenting out that specific chip (AMIC A25L05PT) and then it
gets stuck on the next one. Then commented out all AMIC chips, and it
got stuck on the next one (the first ATMEL on the list)
I've tried with an older flashrom (0.9.2-r1141). It skipped some AMD
chips, then got stuck on AMIC again.
Talked with "tlt" and "stefanct" on irc and they asked for a strace and
a gdb backtrace. Strace produced no results. Gdb log is attached.
"stefanct" tried and reproduced it on a machine with nicintel_spi, but
warned it was with an unsupported nic:
thanks for your mail. I have added the flashrom mailing list in CC:
because we should develop a generic way to handle DualBIOS and similar
On 09.04.2010 08:12, Vadim Girlin wrote:
> I'm going to try coreboot on Gigabyte GA-MA770-UD3.
> It's AMD 770 (RX780 / SB700).
> My motherboard supports hardware dual bios - with two chips on it.
> I'm going to try flashing backup chip and boot from it. It seems to be
> possible - I've tested it (flashing at least). Chips on this board could
> be switched by changing bit 0 at undocumented register EF on LDN 7 of
> IT8720. I can use slightly patched flashrom for accessing any chip I
> want without any problems. And this is tested many times.
> My idea is to use backup chip for debugging - that always keeps my
> chance to reboot from main bios chip. And removes the need for
> desoldering etc.
> And second problem is that original bios is checking second chip - and
> trying to recover it by flashing the bios from main chip on reboot?
> rewriting coreboot. AFAICS this could be solved by including some
> signatures etc. It seems to be easy to find out. May be someone is
> working on this?
> BTW I can send the patch for flashrom - but I think that with
> information I mentioned above somebody could make it much better than my
> ugly hack. I hope the regs should be the same for all latest Gigabyte
> MBs using IT8720/18
It would be great if you could send that patch. It will help us make a
flashrom design decision that works for all boards with multiple flash
By the way, some of us have good contacts at ITE, so we can ask ITE for
details about the undocumented registers.