NixOS, RISC-V, openocd and muforth

[0x0dada]

This is the fastest way to start chatting with the HiFive1 using
muforth/openocd on NixOS. Currently, this has only been tested with
NixOS version 17.03 running 4.9.20-grsec kernel.

Step 1. Git muforth.

$ git clone https://github.com/nimblemachines/muforth

Pay particular attention to the message produced after running muforth/src/configure.sh. Make sure
you append udev.nix to /etc/nixos/configuration.nix.

Step 2. Download the appropriate openocd binary per instructions here:

http://muforth.nimblemachines.com/getting-started-with-risc-v/

Step 3. Make certain that you have both patchelf and libusb-1.0x. If
you're running NixOS I'm assuming you know how to get them if you don't
have them. ;)

Step 4. Since you built muforth from source, you can use patchelf to find out
where your interpreter is located:

$ patchelf --print-interpreter muforth/mu/muforth 

Point your openocd binary at that terrifying output with patchelf.

$ patchelf --set-interpreter /nix/store/<long hairy string unique to
your system>-glibc-2.25/lib/ld-linux-x86-64.so.2 ./openocd/bin/openocd

NB: The above assumes you did the logical thing and untarred that
openocd binary archive into your home directory without naming it
anything cute or clever.

Step 5. You'll need to set your LD_LIBRARY_PATH to point at the location in
/nix/store of the user-environment/lib that contains your libusb* files.
You can use the path of inconvenience and type it manually every login
session or once you figure out where it is, include it in a script. This
is the path of least resistance. I recommend that path. (Binaries and
LD_LIBRARY_PATH cause intermittent grief in NixOS land, so it would be
wise to remember this workaround. It would also be wise to not set
this permanently, as more permanent workarounds to LD_LIBRARY_PATH
issues have been known to cause wailing and gnashing of teeth.)

$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/nix/store/<long hairy string
peculiar to your environment>-user-environment/lib

Remember the Path of Least Resistance: you'll put that in a shell script
and run it once per login session.

Step 6. Ready, set, chat with target. In one terminal window:

$ cd muforth/mu
$ target/RISC-V/start-openocd.sh (remember to modify this per the
   instructions at http://muforth.nimblemachines.com/getting-started-with-risc-v/)

In another terminal window:

$ ./muforth -f target/RISC-V/build.mu4
$ jtag

"You should see a dump of four registers, all zero except for SP."

-- @0x0dada

[nimblemachines]

When setting the ELF interpreter, you can avoid typing quite so much by doing something like this:

$ ldso=$(patchelf --print-interpreter /run/current-system/sw/bin/bash)
$ patchelf --set-interpreter $ldso <path-to-openocd-binary>

And instead of mucking about with LD_LIBRARY_PATH it's possible to set openocd's RPATH instead.

First you have to figure out where 'libusb1' is installed. If you installed it via nix-env as a normal user, you could use ~/.nix-profile/lib as the RPATH, but it might be more "durable" to point to the Nix store location of the installed libusb instead. Then it won't matter if you still have libusb1 installed in your profile or not, as long as it's still in the Nix store. (And we can guarantee that it won't get garbage-collected by creating a GC root, but I'll leave that to a later comment. I have to figure out the exact steps.)

I haven't found an ideal way to capture the store location of the installed libusb, but this will show it:

$ nix-env -q --out-path libusb

On my system - an i686 running the latest 16.09 - I see a -dev version of libusb-1.0.20 and a non-dev-version. Eyeballing the store path of the non-dev version - which starts with /nix/store/sjk3sh - I can finish patching openocd with the help of tab completion:

$ patchelf --set-rpath /nix/store/sjk3sh<TAB>/lib <path-to-openocd>

[nimblemachines]

I've opened an issue over at the sifive/cinco repo to try to help resolve this.

We'd still have to patch ldso, but that's pretty easy, and can be done with a trivial script.

[0x0dada]

Hmm, what a shock, we appear to have different "states" in our machines . ;) I didn't get any joy initially with

$ nix-env -q --out-path libusb

as "Nearly Normal User" and running as sudo pointed to a different derivation -- which apparently refuses to get garbage collected (for reasons outside the scope of this discussion.) Hence, once I found a libusb1.x that worked with openocd (by a convoluted path best avoided in the future,) I went with my method.

I was looking for the fastest possible solution that consistently worked and avoided a lot of the wailing regarding rpath, LD_LIBRARY_PATH , patchelf and other workarounds for unpatched binaries in general . Buried in all of that and scattered elsewhere in the Stygian bowels of der Interwebs are several alarming threads regarding kooky breakage resulting from rpath manipulation. In the interests of my sanity, I'm going to use my method for now and respectfully not use

$ patchelf --set-rpath /nix/store/sjk3sh<TAB>/lib <path-to-openocd>

but let's see what happens on our respective systems. Change is rampant. And, per our discussion earlier, yeah, creating a Nix expression that downloads and patches openocd should definitely be on the table.

For everyone else, welcome to NixOS. Here are two solutions. Brian McKenna thinks he has found a nifty one as well. If you're going to be one of the extremely few working with muforth in NixOS, hopefully these different solutions will at least illuminate something resembling a path.

[0x0dada]

Closing this. Workarounds above work for the few and the brave.

[0x0dada]

Closing this, we workarounds above.