Hi,
We're using flashrom app with a Dediprog (SF100) programmer.
Our OS is SLES11.
Sometimes, I'm getting the "Dediprog_BAD" log after disconnecting and reconnecting the SF100, I'm getting the "dediprog_GOOD" log.
Any idea?
Nadav
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
On Sun, 22 Feb 2015 02:16:57 +0100
Peter Stuge <peter(a)stuge.se> wrote:
> either make the
> lightning bolt smaller or perhaps just remove it, because the
> connection between lightning and memory chips isn't so obvious.
Removing it (without replacement) is not an option... that would make
it simply a chip icon. That by no means qualifies as a good logo for a
software project :)
The logo's background idea does not have to be obvious (i.e. if one
doesn't know it is related to flashrom, one does not necessarily need
to derive that relationship), but it should be recognizable and clear
once you know it to make the whole logo<->project relation memorable...
and I really think that a flash and a rom/chip qualifies to represent
flashrom in such a way :)
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
On Sun, 22 Feb 2015 02:26:19 +0100
Peter Stuge <peter(a)stuge.se> wrote:
> Peter Stuge wrote:
> > Stefan Tauner wrote:
> > > What do you think about my suggestions and the whole matter?
> >
> > soic8_30degrees is really good. I would only suggest to perhaps
> > rotate
>
> clockwise
>
> > around the X axis a little bit,
>
> to view the chip more from the side, rather than from above.
I am not sure where your X axis and origin is, but I have rotated it 30°
"back" around the Y axis now :) Is that what you meant?
That makes the flash look a bit stupid and makes the whole thing way
less recognizable IMHO.
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
On Sat, 21 Feb 2015 15:19:42 -0600
Reggie McMurtrey <reggie.mcmurtrey(a)gmail.com> wrote:
> Not sure why patch seems mangled. I looked at the mailing list archive to
> see what happened and it shows up ok there. I was informed I should have
> bumped the subject to [PATCH v2]. I'll make sure to do that in the
> future. I'll be glad to post patch again if needed.
Focus on the line breaks and number of tabs/spaces after the + signs...
clearly some kind of mangling happened.
>
> Programmer inits don't seem to have any specific meaning other than
> pass/fail.
Why -2 then? :)
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
On Sat, 21 Feb 2015 09:34:23 -0600
Reggie McMurtrey <reggie.mcmurtrey(a)gmail.com> wrote:
> Thanks for the feedback Stefan, Trying again :)
Thanks, but the patch got mangled by your email client apparently.
BTW I am not sure what -2 means in programmer inits from the top of my
head... if there is a macro name for that please use it.
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
On Fri, 20 Feb 2015 18:21:09 -0600
Reggie McMurtrey <reggie.mcmurtrey(a)gmail.com> wrote:
> This is my first time submitting a patch to a project, so let me know
> if I have done something wrong here.
>
>
> I commonly use the C232HM cable from FTDI to program various parts of
> boards I design. This one cable allows me to program SPI, I2C, and
> JTAG parts. Simply adding some muxes to the design I have a single
> header to attach this cable to. The patch below allows control of the
> muxes from the GPIOL3-GPIOL0 signals on the cable and disable write
> protection. I figured other people may like this capability if they
> are using a similar breakout cable of have designed the ft2232 chip
> into their design.
>
> Signed-off-by: Reggie McMurtrey <reggie.mcmurtrey(a)gmail.com>
>
> @@ -262,6 +269,18 @@ int ft2232_spi_init(void)
> }
> free(arg);
>
> + arg = extract_programmer_param("gpio_dir");
> + if (arg) {
> + gpio_dir = (strtoul(arg, 0, 16) & (0xf0 & ~adapter_mask)) | gpio_dir;
> + }
> + free(arg);
> +
> + arg = extract_programmer_param("gpio_value");
> + if (arg) {
> + gpio_value = (strtoul(arg, 0, 16) & (0xf0 & ~adapter_mask)) | gpio_value;
> + }
> + free(arg);
> +
> arg = extract_programmer_param("port");
> if (arg) {
> switch (toupper((unsigned char)*arg)) {
Hello Reggie,
thanks for your patch! I had no time to review it in detail but we
definitely want some error/wrong input handling for the parameter
parsing above. There are various similar checks throughout the code
base that you may wanna look at... not all are perfect yet though. If
you have any doubts then please refer to the strtol(3) manpage.
A more detailed review will follow when that's fixed.
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
The ID bytes are reading as FF's. Double check your connections
<http://flashrom.org/RaspberryPi> and ensure that the C720 is completely
powered off (disconnect both the battery and the AC power).
On Wed, Feb 18, 2015 at 9:09 PM, Remigijus Jarmalavičius <
remigijus(a)jarmalavicius.lt> wrote:
> Hi,
>
> I am trying to unbrick latest Acer C720 with flashrom. What I have already
> done:
>
>
> - Created ROM image successfully for writing with flashrom;
> - Connected wires from Raspberry Pi to EEPROM chip on C720.
> - Enabled kernel modules and tested with spidev_test (it returns data,
> looks normal - not all 00's or FF's)
> - Download latest flashrom from svn and compiled.
> - Then executed: ./flashrom -VVV -p linux_spi:dev=/dev/spidev0.0
>
> After a lot output it said to me:
>
> Found Generic flash chip "unknown SPI chip (RDID)" (0 kB, SPI) on
> linux_spi.
> Probing for Generic unknown SPI chip (REMS), 0 kB: REMS returned 0xff
> 0xff. probe_spi_rems: id1 0xff, id2 0xff
> Found Generic flash chip "unknown SPI chip (RDID)" (0 kB, SPI).
> ===
> This flash part has status NOT WORKING for operations: PROBE READ ERASE
> WRITE
> The test status of this chip may have been updated in the latest
> development
> version of flashrom. If you are running the latest development version,
> please email a report to flashrom(a)flashrom.org if any of the above
> operations
> work correctly for you with this flash chip. Please include the flashrom
> log
> file for all operations you tested (see the man page for details), and
> mention
> which mainboard or programmer you tested in the subject line.
> Thanks for your help!
> No operations were specified.
>
> I saw that sometimes chip numbers are not entered to the flashrom source,
> maybe it's the same case? I think I have read all sites I found on Google
> about unbricking acer c720. What I should try next?
>
> Some details:
>
>
> - Ubuntu 14 OS on Raspberry Pi B version.
> - Acer chromebook c720 (model no: zhn)
>
> Please help me solve the issue. I am attaching complete log
> command: ./flashrom -VVV -p linux_spi:dev=/dev/spidev0.0 > log
>
>
>
> --
>
> *Remigijus Jarmalavičius*
>
>
> _______________________________________________
> flashrom mailing list
> flashrom(a)flashrom.org
> http://www.flashrom.org/mailman/listinfo/flashrom
>
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.