Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

opentitan: Makefile: Use riscv64-elf-objcopy to prepare images #2104

Merged
merged 1 commit into from Sep 17, 2020

Conversation

alistair23
Copy link
Contributor

Pull Request Overview

Call the riscv64-elf-objcopy binary to create binaries.

The LLVM objcopy doesn't correctly create working binaries. So let's
avoid calling it. At the same time the riscv64 will correctly work and
is more likely to be installed so let's use it instead.

Testing Strategy

Running the Makefile to flash images to the OT FPGA.

TODO or Help Wanted

Documentation Updated

  • Updated the relevant files in /docs, or no updates are required.

Formatting

  • Ran make prepush.

Call the riscv64-elf-objcopy binary to create binaries.

The LLVM objcopy doesn't correctly create working binaries. So let's
avoid calling it. At the same time the riscv64 will correctly work and
is more likely to be installed so let's use it instead.

Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Copy link
Contributor

@bradjc bradjc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we dig into why? Conceptually what is happening is pretty simple. And, we have seen how painful it can be to install riscv64-gcc, which is why using the rust provided tools is so convenient.

@alistair23
Copy link
Contributor Author

I have no idea and I don't have a good way to figure out. It's just a binary blob. One boots on OT and one doesn't.

@ppannuto
Copy link
Member

Maybe worth pinging the LLVM devs? They've been responsive to issues like this before, seems they aspire to parity in tooling where sensible / possible, and this is probably a bug there.

@bradjc bradjc added the WG-OpenTitan In the purview of the OpenTitan working group. label Sep 17, 2020
@alistair23
Copy link
Contributor Author

I filed a bug, let's see what happens: https://bugs.llvm.org/show_bug.cgi?id=47563

@hudson-ayers
Copy link
Contributor

@alistair23 does riscv32-none-elf-objcopy not work if used in both positions?

Given that this rule already requires a risc-v specific objcopy because llvm objcopy does not support --update-section, it seems like it might be worth merging this to fix master, especially if we can keep it so we only require the objcopy that people had to use previously.

@alistair23
Copy link
Contributor Author

@hudson-ayers Do you mean llvm-objcopy?

We can't use llvm-objcopy for the first objcopy as it doesn't support --update-sections.

Most machines don't use riscv32-none-elf-objcopy but instead use riscv64-elf-objcopy hence the change to it. Both are GCC tools though. riscv32-none-elf-objcopy came from my OE toolchain, most users will just use riscv64-elf-objcopy.

@hudson-ayers
Copy link
Contributor

@hudson-ayers Do you mean llvm-objcopy?

We can't use llvm-objcopy for the first objcopy as it doesn't support --update-sections.

Most machines don't use riscv32-none-elf-objcopy but instead use riscv64-elf-objcopy hence the change to it. Both are GCC tools though. riscv32-none-elf-objcopy came from my OE toolchain, most users will just use riscv64-elf-objcopy.

I meant riscv32-none-elf-objcopy just because that is what was there previously. But that makes sense, I think it is reasonable to merge this because a non-llvm objcopy is required for this make rule anyway.

@bradjc bradjc merged commit cb748be into tock:master Sep 17, 2020
@alistair23 alistair23 deleted the alistair/opentitan-makefile branch September 17, 2020 20:41
bors bot added a commit that referenced this pull request Apr 19, 2023
3411: Update OpenTitan Makefile and build examples  r=hudson-ayers a=jwnrt

## Pull Request Overview

This pull updates parts of OpenTitan's Makefile and README that I ran into when trying to build and run Tock:

## Disable default board configuration

Disabled the default `fpga_cw310` Cargo feature when a `BOARD_CONFIGURATION` is specified.

Previously, both `fpga_cw310` and `sim_verilator` would be set, leading to conflicting `const CONFIG` definitions in `chips/earlgrey`.

### Objcopy binary

The Makefile is using `riscv64-linux-gnu-objcopy` as documented in #2104. The reasoning was that `llvm-objcopy` wasn't providing correct output.

From #2104 it looks like `riscv64-linux-gnu` was chosen because users were likely to have it installed. `riscv32-unknown-elf-objcopy` is provided by the lowRISC toolchain used for building OpenTitan software, so I thought developers would be more likely to have this already installed.

Happy not to include this change, though. I also haven't checked whether the `llvm-objcopy` bug is now resolved and that could be used instead.

### README examples

The QEMU examples in the README were outdated, possibly since `libtock-rs` has updated. Updated these examples, and tidied up some Markdown along the way.

## Testing Strategy

This pull request was tested by running the updated README examples and make rules.

## TODO or Help Wanted

Any thoughts on using `riscv32-unknown-elf-objcopy` by default over `riscv64-linux-gnu`?

## Documentation Updated

- [x] Updated the relevant files in `/docs`, or no updates are required.
- [x] Updated example commands in OpenTitan's README

## Formatting

- [x] Ran `make prepush`.

Co-authored-by: James Wainwright <james.wainwright@lowrisc.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
WG-OpenTitan In the purview of the OpenTitan working group.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants