Skip to content
This repository has been archived by the owner on Jan 16, 2023. It is now read-only.

verilog options added to binutils objcopy #168

Closed
DonatoK opened this issue Jan 16, 2018 · 11 comments
Closed

verilog options added to binutils objcopy #168

DonatoK opened this issue Jan 16, 2018 · 11 comments

Comments

@DonatoK
Copy link

DonatoK commented Jan 16, 2018

Hello,

This patch
https://sourceware.org/bugzilla/show_bug.cgi?id=19921
I found to be useful for adding enable specification of data width when writing verilog hex format.
as it is right now verilog's $readmemh() will only read the current version of objcopy -d verilog as bytes only.

Thanks,
Donato

@palmer-dabbelt
Copy link
Contributor

Thanks, that sounds neat. It looks like it's proceeding through upstream well, so I assume it'll eventually land in a branch that we base releases off of. I think this might be a better topic for the RISC-V mailing lists, as it's not really a bug in riscv-tools, so I'm closing the bug.

@palmer-dabbelt
Copy link
Contributor

Oh, I guess I just forgot what year it is -- the patch is actually pretty out of date. I'll ping the binutils people.

@tilk
Copy link

tilk commented Apr 25, 2019

I find this patch useful, too, and it looks like it wasn't merged.

@jim-wilson
Copy link
Collaborator

The patch still needs more work before it can be merged. This probably should be discussed in the binutils mailing lists, not here.

@DonatoK
Copy link
Author

DonatoK commented Apr 26, 2019

Would you know who/where I can link this conversation to? I appreciate any help getting this functionality implemented.

@jim-wilson
Copy link
Collaborator

Your first message points at a FSF binutils bug report. That is where the patch needs to be discussed. The patch needs to be fixed and merged upstream, and then it will eventually end up in riscv-binutils-gdb.

@jim-wilson
Copy link
Collaborator

Fixed upstream.

@olofk
Copy link

olofk commented Nov 18, 2019

Unfortunately we are not quite there yet https://sourceware.org/bugzilla/show_bug.cgi?id=25202

@Riconec
Copy link

Riconec commented Jan 17, 2020

This exatly what I see, endianness is incorrect when I try to objcopy to hex file verilog target

@olofk
Copy link

olofk commented Jan 20, 2020

I spent some time last week trying to fix this to work with both BE and LE architectures but couldn't get it to work. Thought I had it nailed down with

@@ -380,8 +382,13 @@ const bfd_target verilog_vec =
 {
   "verilog",                   /* Name.  */
   bfd_target_verilog_flavour,
-  BFD_ENDIAN_UNKNOWN,          /* Target byte order.  */
-  BFD_ENDIAN_UNKNOWN,          /* Target headers byte order.  */
+#if TARGET_BIG_ENDIAN
+  BFD_ENDIAN_BIG,              /* Target byte order.  */
+  BFD_ENDIAN_BIG,              /* Target headers byte order.  */
+#else
+  BFD_ENDIAN_LITTLE,           /* Target byte order.  */
+  BFD_ENDIAN_LITTLE,           /* Target headers byte order.  */
+#endif
   (HAS_RELOC | EXEC_P |                /* Object flags.  */
    HAS_LINENO | HAS_DEBUG |
    HAS_SYMS | HAS_LOCALS | WP_TEXT | D_PAGED),

but it broke some assumptions about endianness in other places in the code for BE targets. Would very much appreciate if someone with better knowledge of binutils could take a look. Perhaps it would be easier in the end to just add an explicit endianness switch to the verilog output mode

@jim-wilson
Copy link
Collaborator

I would suggest having this discussion upstream, preferably in the existing bug report. I'm probably the only one with binutils expertise reading this, and I'm hopelessly overloaded with things to fix, so I have no plans to work on this. But there may be other binutils developers that have time to work on it.

Note that some targets support both big and little endian as a run time switch. So hard coding endianness here as a build time constant can't work.

Sifive has its own program for converting binaries to verilog. It would be nice if someone fixed binutils, but you can always try using the sifive program instead.
github.com/sifive/elf2hex

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants