Hello Dear Friends.
As asked when the flashrom software works properly with a new chip, i'm
sending the logs. This chip I salvage from a dead HD. Looks like this chip
works like a charm. I'm using an Rpi B+ with SPI do communicate with the
chip
Best Regards from Brazil.
Atenciosamente
Júlio César Zinn Ferreira
juliozinn(a)gmail.com
On Mon, 4 Jul 2016 22:22:29 -0700
David Hendricks <dhendrix(a)chromium.org> wrote:
> Hi folks,
> As part of an effort underway to get chromium.org's flashrom sync'd with
> upstream (for real), I have written an entirely new test script to help get
> thru regression testing. It's still rather fugly and will likely go thru
> several more revisions, but is currently usable for all major use cases I
> could think of and would benefit from some early feedback.
>
> I wrote up a document with usage examples here: https://goo.gl/3jNoL7 .
> Long-term the plan is to migrate this to the flashrom wiki.
>
> There were a few "must haves" for this script in the near-term:
> - Region awareness. The script understands how to use layout files and
> flashmaps (for Chromebooks). Descriptor awareness is on the TODO list for
> Intel platforms.
> - Can control flashrom on a remote host.
> - Can utilize an external programmer in addition to the native programmer
> on the target machine. This allows us to verify changes made to programmer
> code since one programmer can be considered to be trusted while the other
> can have code that was modified.
Cool, something like that is on my long-term todo list... (with some
additional test stand hardware).
I don't have time to look at the code right now so just some quick
question: the primary/secondary programmer scheme is used to verify one
while the other is used as kind of golden sample, right?
It might make sense to not limit this to two programmers but have one
golden sample and an unlimited programmers to actually test.
(The hardware i was talking about above would be a PCB that can be
remotely cross-switched between any of the attached programmers and
multiple flash chips (e.g. one at45db, several ordinary *25*, some
newer *25* with 4B addressing etc.)
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
On Thu, 30 Jun 2016 18:18:02 +0000
"Ma, Peter" <peter.ma(a)intel.com> wrote:
> I would like to hear your thoughts about introducing an override to allow smaller data file sizes to be programmed. Thanks.
Hi,
where would the data be put then? Should it be top-aligned like in all
x86 firmwares, should it be starting at 0 like in many other
applications (not sure about FPGA bit stream storage but I guess it is
one of these), or does it need to be put to another offset (like when
updating only parts of an image?
As you see the trivial override switch you suggest does not work that
well in many situations. However, we are of course aware of that and
there is a fix for this in the pipeline (referred to as layout patches)
that will allow to define names for address regions and use files
matching those address ranges in size to be flashed without a complete
image.
Regarding your use case: is the bit stream image to be written to flash
always of a fixed size or does it depend on the code? I think that's
something we did not mind yet.
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner