[flashrom] GSoC-2014 Flashrom project "Locking and unlocking of access protections of flash chips"
dhendrix at google.com
Wed Mar 19 19:53:31 CET 2014
On Wed, Mar 19, 2014 at 5:58 AM, Allen Yan <lexkde at gmail.com> wrote:
> Hi, David,
> I was reading flashrom code base following the internal programmer
> way. I also read mail
> and checked the Ibex peak datasheet about ME firmware. Here are some
> about "Locking and unlocking of access protections of flash chips"
> 1 which mechanism locks the flash?a software way or a hardware way
> by the programmer. As in the Atmel AT25DL161, the protection ways are
> "hardware protection, using WP pin", "Sector lockdown with permanent
> freeze option", "individual sector protection with global
> protect/unprotect feature".
All of the above :-)
You will need to determine:
- Which write-protection scheme is in place? Is it intended to prevent
erroneous software from writing to the flash, or is it intended to prevent
any re-writing of the flash?
- Can it be disabled / worked around so that content can be updated?
- How to restore the settings when you are finished.
> 2 Does this problem concerns the ME firmware issue.
> 3 How to do the test? Is the test at specific mainboard and flash chip
IIRC Flashrom already tests for motherboards which are known to require a
workaround, for example if a GPIO must be inverted in order to de-assert
/WP. board_enable.c has many of these tests. It also knows about block
protect bits in SPI ROMs.
I think the main issue with modern systems (Intel in particular) is the
> 4 How to value the work at last as stefan mentioned in the suggestion?
> Actually, a little frustrating after I saw stefanct's mail.
It's very valuable :-) I put some effort into this functionality for
ChromeOS, since handling write-protection is a requirement for Chromebooks.
Here are some examples:
Skip regions locked via flash descriptor for Intel platforms:
writeprotect.c, which contains block protect mapping for several flash
Unfortunately we never reached a consensus regarding how to port this code
to upstream. It would be nice if somebody like you can help to re-factor
this code so that it can be accepted upstream.
> On 3/18/14, Stefan Tauner <stefan.tauner at student.tuwien.ac.at> wrote:
> > On Mon, 17 Mar 2014 09:56:43 +0800
> > 严进一 <lexkde at gmail.com> wrote:
> >> Hi,
> >> I am Jinyi Yan , a second year PhD candidate from Shanghai Institute of
> >> Micro-system and Information Technology, Chinese Academy of Sciences. I
> >> used to be a mainboard BIOS engineer in ASUS Technology Suzhou Co., Ltd
> >> for about two years (2007.7~2009.2). My major now is optoelectronics.
> >> I have a lot of fun while programming, in my heart the working
> >> of being a BIOS engineer is still very exciting.
> >> I think GsoC is a nice platform for me to participate the open source
> >> community. When I search the GsoC projects and organizations, the
> >> and flashrom projects are definitely the right choices for me. I have a
> >> spare ASUS P5KPL PC at my hand, but the chipset is not in the support
> >> of coreboot project. So I consider the flashrom project is the better
> >> choice. I also have a home-made flash programmer based on uspasp.
> >> I'd like to choose “Locking and unlocking of access protections of flash
> >> chips” for GSoC 2014.
> >> Now I'm not very familiar with the program structure of flashrom, so I
> >> expect your guidence and hope to contribute for flashrom and coreboot
> >> if my application is not accpeted.
> >> Thanks! Look forward to your kind advice!
> > Hello Jinyi,
> > thanks for your interest in flashrom. I have been the most active
> > flashrom developer in the last years and would probably be responsible
> > to integrate your work and answer questions if you get stuck. I agree
> > that the coreboot-related projects are probably the best choice for you
> > (there are not many low-level projects participating sadly... that's
> > how I ended up here too ;). I also have to admit that the P5KPL is
> > probably not very helpful AFAICT. But I don't think that this is a show
> > stopper regarding coreboot (or seabios) projects and that your skills
> > and insights obtained at ASUS regarding x86 might be more useful in a
> > non-flashrom project. Also, the project you chose requires to
> > understand two code bases ("ours" and that maintained by google/
> > chromiumos ppl) and interact with two communities and persuade at least
> > one of them that your solution is sound and profitable. On the other
> > hand, I am biased because I will apply for a flashrom GSoC project
> > myself probably. ;)
> > The code bases have a very similar core so that should not be a big
> > issue at all. Producing something that will be praised by everyone on
> > the other hand is really hard. The vanilla flashrom community is
> > traditionally very (very) picky regarding changes, especially user
> > interface changes. This is also the reason why there is a chromiumos
> > fork of flashrom...
> > I have talked to David (dhendrix) and he is willing to mentor you this
> > year. If you want to pursue this project (and the patch you sent seems
> > to indicate that ;) I suggest you talk to him directly about details
> > of the assignment (here or on IRC).
> > Adding new flash chips as you have done is a very good first step to
> > get to know flashrom a bit better. The fun begins with the awkward
> > models though :)
> > I suggest you test flashrom on any hardware available to you (including
> > network cards for example)... there is always room for improvement and
> > learning a foreign code base is always easier when on has a specific
> > goal to reach.
> > --
> > Kind regards/Mit freundlichen Grüßen, Stefan Tauner
> > _______________________________________________
> > flashrom mailing list
> > flashrom at flashrom.org
> > http://www.flashrom.org/mailman/listinfo/flashrom
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the flashrom