I have to say, I’m frustrated that there are no fixes to the SDK going on.
So, I use Fedora 28 Workstation for all my development work, and generally have no problem getting sources and building them.
However, after following the instructions in the Getting Started guide to the letter, I immediately encounter 2 distinct problems. First, there is a problem in the version of automake included in buildroot, which is pretty old.
It’s a syntax error that others have run into on other systems. Yet it isn’t fixed. I can bypass the problem by editing line 3639 of the automake that buildroot puts into the work directory.
Second, there is an init_rpc.h include file that is missing that causes the buildroot to fail subsequent to that.
Also this is reported in the forums. Again, no fix in github.
So: is hardly anyone using their boards, or is there somewhere else where the “real” sources live?
We use Ubuntu 16.04 internally, and freedom-u-sdk builds fine on that. We don’t have the resources to support every version of every distro. It does build on most distros, but fails to build on some distros using the very latest tool versions.
Both problems you ran into are versioning problems, which are not uncommon when using bleeding edge versions of tools. The automake issue occurred because a warning was changed to an error in a new version of a tool (perl?), breaking the build. The init_rpc.h issue occurred because some distros have dropped the SUN RPC code in glibc and replaced it with the alternative libtirpc code, which has different header file structure, requiring code changes.
The first problem will be fixed when we upgrade to Ubuntu 18.04 internally. Unfortunately, Ubuntu 18.04 still uses the glibc SUN RPC code instead of the newer libtirpc code, so a fix for the second one isn’t guaranteed by an internal OS upgrade.
Both problems are fixed in upstream buildroot. You could try moving to a newer buildroot version. We will eventually move to a newer buildroot version ourselves, and get both fixes, but there is no schedule for that.
OK. It would be great if there were a bugzilla where such problems can be reported, and fixes tracked.
Perhaps someone who has solved these problems in the community outside SiFive itself can share on this list a “how to” or perhaps a fork on github they made that got it to build on newer distros? I will do that if and when I solve it in my case.
I tried just substituting the latest buildroot for the master buildroot tree for the sifive buildrooot submodule. That single step didn’t solve the problem… will fiddle further.
Perhaps I can try building in a docker container that emulates Ubuntu 16.04, though that introduces some problems.
PS: This is a first step in a set of projects I have planned, the next step being hosting the SiFive board on a Zedboard as a carrier, instead of the Unleashed Extenders. The FMC connector pinouts match up just fine, except for the power-on signal, which doesn’t connect to the LPC FMC subset on the Zedboard, the only pin that is only in the HPC FMC alone. So I want to solve it sooner rather than later.
It would be surprising if docker didn’t work. We’d like to hear about it, if so.
Realistically, supporting Ubuntu 16.04 in a container is the best way to minimise effort and support problems for both SiFive and customers with varying OSes (including non-Linux hosts).
I’ve rebased the sifive/buildroot tree on top of latest buildroot master, you can find my rebased tree here:
If you update the SDK to use that buildroot tree, it can successfully build a working image on a Fedora 28 host without any hackery.
Next up, I would like to try and adjust the SDK to use the cross-gcc and cross-binutils that are already shipped in Fedora, rather than building their own copies…
That is just wonderful, danc! Thank you.Saved me some tedium debugging a rebase. I’ll feed you back whatever I do that seems useful to others.
At some point, buildroot probably won’t have enough capability for what I’m planning to do with the board, but for now it is plenty useful to build stuff in F28 and share the code with buildroot on the board. So obstacles are out of my way.
For some reason, it says I have “legacy configuration”. I see you are using the newest buildroot, which has indeed got a lot of new configuration options. I’m not sure what configuration options need to be set for the Hifive Unleashed SDK build.
I assume you got this to work for yourself - could you share the “.config” file from the buildroot directory that worked for you?
Ohh yeah I hit this too. Took me a while to figure out where all the config bits and pieces are coming from
The obsolete option it is complaining about is BR2_PACKAGE_HOST_MKE2IMG. I noticed there is a Makefile target in the SDK called buildroot_initramfs-menuconfig, if you invoke that it runs the little curses-based menu configurator for buildroot, which pointed me at the obsolete config option.
You can fix the “legacy” configuration with this diff in the SDK:
And yeah I agree, about Buildroot. I haven’t used it before but it seems like essentially a poor-man’s Gentoo, and although it’s actively maintained at least, it doesn’t seem like a good strategy for producing a real Linux system. I am much more interested in getting Fedora itself running on the board… I just wanted to try building the official images first.
Well, one more thing I discovered. The make encountered a problem toward the end of buildroot, because it wanted a command called xxd. I found this comes from vim-common of all places. I’m not a vim user, and there’s no mention of vim anywhere in the required software for the freedom-u-sdk or buildroot, so maybe it is installed by default in ubuntu 16.04, or it got used in buildroot.
So, danc, it appears I have built a system image under fedora 28. Yay! Now to see if making an SD card with it and booting succeeds.
Thanks for all the help so far. I’f that works, I’ll post a digest of what a fedora-based developer needs to do to get started. I’ll also push the modified SDK to my github account.
