Open GoogleCodeExporter opened 9 years ago
Here is a patch that is applied against the cvs version of the code. Needs
patch from issue 22 to be applied also.
Original comment by reubendowle0@gmail.com
on 5 Jan 2012 at 10:02
Attachments:
Looks good also, but issue 22 needs to be updated before it will be applied.
Original comment by ge...@spacevs.com
on 14 Jan 2012 at 8:33
See attached for patch against git merging branch, which adds a new -S
address[:length] parameter
Original comment by reubendowle0@gmail.com
on 26 Nov 2012 at 8:58
Attachments:
Thanks for the patch! A very welcome functionality.
Note that I have done some coding style fixups that I will squash into the same
commit. Most of the existing code follows what seems to me like K&R or Linux
kernel coding style http://www.kernel.org/doc/Documentation/CodingStyle so I
try to apply that when changing any code. Maybe later when there is no more
pending patches I will do a full style clean-up of the whole code. In your
patches it is mostly about having spaces after "if" and opening brace on the
same line, and braces on the same line as "else".
Original comment by lists.to...@gmail.com
on 27 Nov 2012 at 7:41
While testing I have bumped into a couple of problems with your patch. When
writing to flash, if I specify address but no length and a small file, it will
error out with "Specified start & length are invalid" because it calculates
"end" from the flash end instead of start + size (of file). "end" should
probably be the smaller of those two. Or the corresponding bound checking must
be rewritten.
Also, per comment "Assume data from stdin is whole device" it neglects any
given start address and this is not good. It should calculate "size" from flash
end - start address in this case.
Original comment by lists.to...@gmail.com
on 16 Dec 2012 at 11:06
Your patch is now in the official code. I'll keep this bug report open just to
remember the issues in my last comment.
Original comment by lists.to...@gmail.com
on 10 Dec 2013 at 7:17
Hi,
How about optionally disabling the address range checks? That would enable
users to read the unique ID bits or other ROM-programmed data.
Original comment by Andrew.Shadoura
on 11 Jan 2015 at 4:10
Actually, it would be extra cool to have an additional option to read the
unique id choosing the correct address for the chip automatically.
Original comment by Andrew.Shadoura
on 11 Jan 2015 at 4:11
Original issue reported on code.google.com by
reubendowle0@gmail.com
on 5 Jan 2012 at 8:50Attachments: