flashrom October 2017

flashrom@flashrom.org

18 participants
36 discussions

Re: [flashrom] New SPI NOR Flash product Support
by Stefan Tauner 15 Aug '19

15 Aug '19

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. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

4 4

80/100/132 column line width policy
by Carl-Daniel Hailfinger 14 Dec '18

14 Dec '18

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/

7 9

Re: [flashrom] 回信: flashrom post acknowledgement
by Nico Huber 31 Oct '17

31 Oct '17

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. 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.

2 1

Re: [flashrom] Compiling from source on Chromebook:GalliumOS - can't get libusb?
by Nico Huber 31 Oct '17

31 Oct '17

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 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

1 0

回信: flashrom post acknowledgement
by alexlu6＠mxic.com.tw 30 Oct '17

30 Oct '17

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 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. =====================================================================

1 0

Compiling from source on Chromebook:GalliumOS - can't get libusb?
by Anders Nelson 30 Oct '17

30 Oct '17

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 Linux so I apologize in advance for any gaps in knowledge. =] -- Anders Nelson +1 (517) 775-6129 www.erogear.com

1 0

Future flashrom development
by Nico Huber 25 Oct '17

25 Oct '17

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 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"

4 10

Re: [flashrom] Future flashrom development (Stefan's PoV I)
by Stefan Tauner 23 Oct '17

23 Oct '17

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 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

1 0

Re: [flashrom] Future flashrom development
by Antonio Ospite 22 Oct '17

22 Oct '17

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 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.it https://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?

2 1

Re: [flashrom] Future flashrom development
by Stefan Tauner 22 Oct '17

22 Oct '17

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 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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom October 2017