On Mon, 9 May 2016 20:46:18 -0700
David Hendricks <dhendrix(a)google.com> wrote:
> Hi Victor,
> From Flashrom's software perspective all chips with the same ID are
> indistinguishable.
>
> Part number often includes characteristics such as package and thermal
> tolerance which do not affect software compatibility.
However, we will add the new names to the in-program (and hence
wiki) database so that this new information becomes public. Thanks for
the heads up, Victor.
…
[View More]
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
[View Less]
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 …
[View More]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/
[View Less]
Hello Alex,
On 31.10.2017 07:42, alexlu6(a)mxic.com.tw wrote:
> Dear Sir,
>
> I had posted the patch update for almost 2 months, Can you tell us
> that
> when will the update merged to the main flashrom project trunk ? Our
not any time soon. It looks like you posted your patch to the wrong
version of flashrom. There's another branch/fork at chromium[1]. I'll
put some people in CC who can tell you how to push your patch there.
Thanks anyway for your contribution.
…
[View More]Nico
[1] https://chromium.googlesource.com/chromiumos/third_party/flashrom/
PS. That your original mail had three! times the same confidentiality
note, might have made many people simply ignore it. This is a public
mailing list. Please don't send such notes to the public.
[View Less]
Hi Anders,
On 31.10.2017 01:18, Anders Nelson wrote:
> Hi guys,
>
> I'm trying to compile the latest stable source on my Ubuntu-based GalliumOS
> system running on a recent x86_64 Chromebook.
>
> I get the error:
>
> ichspi.o: In function `ich_init_spi':
> ichspi.c:(.text+0x26b2): undefined reference to
> `read_ich_descriptors_via_fdo'
looking at the code, there seem to be different ways used to decide if
we build for x86. So some code for x86 gets built in …
[View More]but some other
piece is missing. As you only need FTDI support, you can just try to
build without the internal programmers (e.g. `make CONFIG_INTERNAL=no`).
If you know how to apply it, please also try the patch attached and
report back if it helps.
>
> I've installed all the packages noted in the README even though I'm only
> interested in supporting the FTDI 2232H chip on the breakout board sold by
> SeeedStudio.
>
> Any suggestions I can try to get this built? I'm relatively new to Linux so
> I apologize in advance for any gaps in knowledge.
Nothing to apologize for. That error is very unexpected.
Nico
[View Less]
Dear Sir,
I had posted the patch update for almost 2 months, Can you tell us
that
when will the update merged to the main flashrom project trunk ? Our
customer is
waiting for the update. Thanks!
Alex Lu
flashrom-bounces(a)flashrom.org
寄件人: "flashrom" <flashrom-bounces(a)flashrom.org>
2017/09/05 下午 01:04
收件人
alexlu6(a)mxic.com.tw,
副本抄送
主旨
flashrom post acknowledgement
Your message entitled
Patch to flashrom for Macronix M25U12835F flash support and write
…
[View More]protection bug fix
was successfully received by the flashrom mailing list.
List info page: https://mail.coreboot.org/mailman/listinfo/flashrom
Your preferences:
https://mail.coreboot.org/mailman/options/flashrom/alexlu6%40mxic.com.tw
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information
and/or personal data, which is protected by applicable laws. Please be
reminded that duplication, disclosure, distribution, or use of this e-mail
(and/or its attachments) or any part thereof is prohibited. If you receive
this e-mail in error, please notify us immediately and delete this mail as
well as its attachment(s) from your system. In addition, please be
informed that collection, processing, and/or use of personal data is
prohibited unless expressly permitted by personal data protection laws.
Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=====================================================================
============================================================================
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=====================================================================
[View Less]
Hi guys,
I'm trying to compile the latest stable source on my Ubuntu-based GalliumOS
system running on a recent x86_64 Chromebook.
I get the error:
ichspi.o: In function `ich_init_spi':
ichspi.c:(.text+0x26b2): undefined reference to
`read_ich_descriptors_via_fdo'
I've installed all the packages noted in the README even though I'm only
interested in supporting the FTDI 2232H chip on the breakout board sold by
SeeedStudio.
Any suggestions I can try to get this built? I'm relatively new to …
[View More]Linux so
I apologize in advance for any gaps in knowledge.
=]
--
Anders Nelson
+1 (517) 775-6129
www.erogear.com
[View Less]
Dear flashrom contributors,
you might have noticed that there hasn't been a release of flashrom in
the past 1.5 years. That doesn't mean that there wasn't any progress,
though. Development has continued and some patches were merged into a
common branch [1]. Alas, not in the `stable` branch of the official
repository. I'd rather not discuss now, why (it's complicated).
As the original plan was to have two separate branches `stable` and
`staging` anyway [2] and we finally got the first commit …
[View More]for `stable`
together (which was stalling the branch), I thought it would be a good
idea to move the already baked and tested commits from `staging` to
`stable`.
Sadly, even this got stalled again. Plus, there is doubt if the two
branches model is feasible at all:
* How to maintain patch compatibility between them?
* Should everything be first submitted to `staging`?
* If not, who'd be allowed to decide to push directly to `stable`
and why?
* ...
So I propose the following: Forget the two branches model, start
a `master` branch with either the current state of `staging` or
my proposed move to `stable` [3] and release flashrom-1.0 right
away.
Submission to the current `staging` branch took place within core-
boot's Gerrit infrastructure. As for myself, I would like to con-
tinue that for any flashrom branch. IMO, it works reasonably well
to work on a branch together. Though, I know that not everybody is
happy with Gerrit and am open for anything else that doesn't incur
a bottleneck.
Thoughts?
Nico
[1] `staging` on https://review.coreboot.org/cgit/flashrom.git
[2] https://www.flashrom.org/Development_Guidelines#Branches
[3] The result if somebody submits the following patch queue:
https://review.coreboot.org/#/q/status:open+branch:stable+owner:"Nico Huber"
[View Less]
On Mon, 16 Oct 2017 16:14:04 -0700
David Hendricks <david.hendricks(a)gmail.com> wrote:
> Thanks for the detailed write-up. I suppose there's another part coming so
> I don't want to get too deep into discussion just yet, but one part in
> particular caught my eye:
>
> On Sat, Oct 14, 2017 at 7:20 AM, Stefan Tauner <stefan.tauner(a)gmx.at> wrote:
>
> > While there was a bunch of patches that have been piled up back then it
> > was less of a problem …
[View More]then the increasing divergence between the
> > chromiumos fork and upstream. Thus we have discussed ways to converge
> > that (by pulling changes mainly from upstream into chromium but also
> > vice versa) and also increase the pace of merging stuff into upstream
> > later. This was still with no intention to switch to git because of
> > Carl-Daniel's concerns.
> >
>
> I'm surprised that you think that chromiumos's divergence is a *worse*
> problem than the huge backlog of upstream patches. The chromiumos fork is
> self-contained, has its own review system, its own testing, and is targeted
> at a narrow set of devices. I don't understand how it could have been a
> problem for upstream and would be interested if you can elaborate on this
> point.
No *is* but *was*. This was (explicitly) describing my view/conception
in 2014. Back then there was way more progress upstream and less
backlog of big patches. It was actually you who brought up the topic in
that meeting IIRC. The problem as I understood it then was that the
overhead of picking upstream patches for the chromiumos was perceived
as getting out of hand. Likewise it was a petty to backport interesting
things back (support for new intel boards, which were taken by me from
chromiumos multiple times IIRC).
>
> FWIW I did try pushing some features from chromiumos to upstream, but like
> other patches they never really got anywhere. I also tried working with
> Carl-Daniel for a couple months to sync the trees, but that effort didn't
> get very far.
I am not sure how you tried to get them in but I don't see any open
threads regarding any (big) patches by you on the ML... However there
were a big number of changes that were forward ported to chromium by
you back then and more recently Patrick.
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
[View Less]
On Fri, 13 Oct 2017 08:01:00 +0200
Peter Lemenkov <lemenkov(a)gmail.com> wrote:
> Hello Nico,
>
> 2017-10-13 2:40 GMT+02:00 Nico Huber <nico.h(a)gmx.de>:
>
> > So I propose the following: Forget the two branches model, start
> > a `master` branch with either the current state of `staging` or
> > my proposed move to `stable` [3] and release flashrom-1.0 right
> > away.
>
> I believe staging/devel/etc branches in projects managed with git …
[View More]are
> usually a troublesome legacy from old CVS/SVN days where
> branching/tagging and patch management were expensive. They shouldn't
> have even copied into Git repositores at all. Also flashrom
> historically has a very flat and straightforward development model, so
> why making two branches at all?
>
> From the package maintainer's point of view it would be easier and
> simpler from if flashrom just have one single monotonically increasing
> branch (master?) with tags applied to some commits eventually (I
> prefer more frequent tagging though), rather than two branches where
> the purpose of one is to be blindly merged into another.
>
FWIW I too am in favor of a more "usual" branching model.
Besides, git users kind of expect "master" to be the development branch
with all that this entails: e.g. no hard promises on stability,
possible risk of regressions compared to the latest tagged release.
Tags and versioned branches can be used to track and support stable
releases long term, and wild experiments can still be done in topic
branches, can't they?
Ciao,
Antonio
--
Antonio Ospite
https://ao2.ithttps://twitter.com/ao2it
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
[View Less]
On Fri, 13 Oct 2017 08:01:00 +0200
Peter Lemenkov <lemenkov(a)gmail.com> wrote:
> From the package maintainer's point of view it would be easier and
> simpler from if flashrom just have one single monotonically increasing
> branch (master?) with tags applied to some commits eventually (I
> prefer more frequent tagging though), rather than two branches where
> the purpose of one is to be blindly merged into another.
The latter was not the purpose as the future dev thread …
[View More]explains.
Package maintainers shouldn't even be bothered with the staging branch.
It might show them the further plans to give feedback though.
The idea of the stable branch would exactly provide what you wish for:
a branch that is good enough to be a base for a release pretty much at
any time. No build failures, reviewed, tested and guaranteed to not
have features removed later (i.e. no regressions).
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
[View Less]