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 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.
On Sat, 1 Aug 2015 08:34:58 +0200
"Ignatius Grippa" <ignatiusgrippa(a)gmx.com> wrote:
> I found a solution that works.
> I changed the AM29F010A/B entry inside flashchips.c
> Under ".feature_bits" I removed FEATURE_ADDR_2AA leaving only FEATURE_EITHER_RESET, After recompiling, flashrom now detects my Am29F010 and it also successfully reads and writes!
> I'm not a programmer so I can't explain why this works but it does.
that feature flag changes the behavior of the probe command and is
exactly what was needed to get the AM29F010 version to work, thanks for
digging this up. I have created a patch that splits the old definition
into two, which allows to distinguish the chips. I'd be glad if you
could test it if you still have the hardware. The patch is attached.
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
we obviously want to participate in FOSDEM.
Some deadlines already expired. Some can still be managed.
Main track talks: Deadline 2015-10-30 (10 days left)
One hour of entertainment, huge audience.
Anyone up for the challenge?
Stands: Deadline 2015-11-13 (24 days left)
I can send in the proposal if I'm not going to be alone there.
How many tables do we want for our stand/booth(s)?
Who is coming?
Lightning talks: Deadline 2015-11-27 (38 days left)
Short and to the point. Your 15-minute elevator pitch.
Can you sell the project?
All deadlines are at 23.59 UTC
Developer room proposal: Deadline EXPIRED
Maybe some developer room will accept talks/demos from us.
(I am replying to various messages of the thread within this single
email. Hence the quotes below are of different people.)
> For those who missed it on IRC, Stefan (Reinauer) has proposed retiring SVN
> and patch work in favor of Git and (likely) Gerrit + Jenkins. Maintaining
> SVN and Patchwork represents a surprisingly large maintenance burden on top
> of Git and Gerrit that coreboot uses. Additionally, many in the community
> work around SVN's limitations by mirroring the project at places like
> Github anyway.
My counterproposal is to use gitub instead of Gerrit.
- I really can't stand gerrit's interface.
- We (relatively) often get patches from one-time contributors which
is way easier on github because "everybody" has an account there and
knows how to work with it (and if not it is straight forward
compared to gerrit).
- We don't really need jenkins. I am not a big fan of CI although I am
a fan of build testing (hence flashrom is build tested for over 30
architecture/OS combinations manually). Depending on how it would be
to interface my build bot with jenkins it would however be an
improvement (not sure if it is worth it though).
- The only reason to avoid github for me would be due to its
proprietary nature and related problems (lock-in etc).
Please give me other reasons if you prefer coreboot.org-hosted
gerrit over github.
> Though I know stefanct often makes small corrections/modifications to
> patches before submitting them (because our code review process makes even
> small amounts of back-and-forth comments so cumbersome). At least this way
> such changes can be tracked trivially on-line by diffing the N and N-1
> patch revisions in gerrit.
The reason is not because the back-and-forth is cumbersome but because
I am a perfectionist who does not want to bother others with my
annoying views of details and I don't expect anybody to care about these
changes like me (this does not always hold). The same goes for commit
messages. With Carl-Daniel I do exchange my views about these kind of
things *if* there is any exchange that is ;)
> If there really is a large demand for a non-svn hosting, I would be open
> to using mercurial (as master) because it at least has some sort of
> usability and can provide (conceptually limited) version numbers. I have
> worked for a few years with mercurial and the version numbers are
> extremely helpful even if they are per-branch and only semi-stable.
Just to make things clear here: I won't even discuss this option - it
is none. If you want to use another VCS management tool/interface then
you are free to do so, but you are the only person known to prefer
something else than git so you have to take on the burden and not force
everybody else to as it has been up to now - this has to and will end.
> The auto-tag of every commit sounds like an option I could agree with.
> It would preserve the convenience of the global strong svn commit ID
> even for git.
> However, I don't know if this would be acceptable for Stefan (especially
> from a merging perspective).
We have the infrastructure for using this kind of version strings since
about 2,5 years and there is a patch that would make flashrom use them
in prints which is lingering uncommented in the mailing list since
August 2013. It might not be exactly what we want eventually, but if
there are no comments I'll have to decide on something...
My current plan is to do a 0.9.9 release in January 2016 and switch to
git afterwards. I'd like to keep patchwork at least for a while and
figure out a way to keep the patches.
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
just letting you know that I was able to read, write and erase the above
mentioned flash chip without any issues.
Hardware used: HummingBoard (Freescale i.MX6Q, 4x1GHz armv7l). Chip was
attached to the SPI port, and 1 gpio was configured and wired as ChipSelect.
Find the logfiles I made attached.