https://sourceware.org/bugzilla/show_bug.cgi?id=19921
--- Comment #12 from Jamey Hicks ---
Thank you, Nick!
On Tue, May 14, 2019 at 5:51 AM nickc at redhat dot com <
sourceware-bugzi...@sourceware.org> wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=19921
>
> Nick Clifton changed:
>
https://sourceware.org/bugzilla/show_bug.cgi?id=19921
--- Comment #6 from Jamey Hicks ---
Created attachment 9179
--> https://sourceware.org/bugzilla/attachment.cgi?id=9179&action=edit
revised patch
--
You are receiving this mail because:
You are on the CC list for the bug.
__
https://sourceware.org/bugzilla/show_bug.cgi?id=19921
--- Comment #3 from Jamey Hicks ---
Created attachment 9170
--> https://sourceware.org/bugzilla/attachment.cgi?id=9170&action=edit
patch adding --verilog-data-width option to objcopy
This patch adds --verilog-data-width option to objcopy. I
https://sourceware.org/bugzilla/show_bug.cgi?id=19921
--- Comment #2 from Jamey Hicks ---
After talking about it with others who use the verilog output, a new option
seems best because it is the most flexible. The data width of a ROM does not
necessarily match the data width of the processor.
I
: enhancement
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: jamey.hicks at gmail dot com
Target Milestone: ---
Verilog $readmemh is rather limited and reads one array value per white-space
separated number. In order to read
