On Wed, Mar 19, 2014 at 5:58 AM, Allen Yan <lexkde@gmail.com> wrote:

Hi, David,
I was reading flashrom code base following the internal programmer
way. I also read mail
"http://www.flashrom.org/pipermail/flashrom/2013-March/010704.html"
and checked the Ibex peak datasheet about ME firmware. Here are some
questions:
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.

Yes.

3 How to do the test? Is the test at specific mainboard and flash chip enough?

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

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: https://chromium.googlesource.com/chromiumos/third_party/flashrom/+/1ed1d35d8fbce7571accb84c2ba76f7b6f273844

writeprotect.c, which contains block protect mapping for several flash chips: https://chromium.googlesource.com/chromiumos/third_party/flashrom/+/master/writeprotect.c

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@student.tuwien.ac.at> wrote:
> On Mon, 17 Mar 2014 09:56:43 +0800
> 严进一 <lexkde@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. But
>> I have a lot of fun while programming, in my heart the working experience
>> 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 coreboot
>> 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 list
>> 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 even
>> 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@flashrom.org
> http://www.flashrom.org/mailman/listinfo/flashrom

--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.