Freedom-u-sdk build instructions feedback

I very recently built the freedom-u-sdk for the first time, and I want to give some feedback for the build instructions.

  1. I was completely unaware, until the build had been running for some time, that I was in fact building a Linux distro. The “SDK” part of the "freedom-u-sdk’ name is quite misleading, and there is no particular mention as far as I can see as to what is actually going to be done. The impression I had, from reading about the freedom-u-sdk being “very limited” and all about how we get Linux running using chroot, was that it was limited bootloader of some kind, which provided enough of an environment to get some other distro running.

  2. The repo command with Debian Buster is very old; you need to download the latest version and use that. Probably it is best always to do so.

  3. The repo command cannot cope with socks proxies. It needs direct access, or a HTTP proxy.

  4. The first command “Updating Existing Workspace” is “cd riscv-sifive”. This is not needed, as in “Creating Workspace” we already changed into that directory.

  5. This is IMPORTANT : BB_NUMBER_THREADS and PARALLEL_MAKE need to be explained. I read the Yocto docs (I think it was) and found out what they really mean. Where some of the builds need a LOT of store, PARALLEL_MAKE should probably be 1, with BB_NUMBER_THREADS set to 2x core count to maximize throughput, since many jobs are quite quick. I found this made a huge difference to the rate of progress.

  6. In “Building Disk Images”, the reader needs to be properly alerted that the build will require a lot of memory. My laptop (old, and to be replaced as soon as Librem get the next version of the 13 inch out) has only 4 GB of RAM and a 2 GB swap partition. I had to add a 16 GB swap file to allow llvm to link. It would be useful to make this clear, and to provide instructions as to how to set up a swap file (and how to get rid of it after).

    cd [where you want to go]
    fallocate -l 16G ./swapfile
    chmod 600 ./swapfile
    mkswap ./swapfile
    swapon ./swapfile

    and then when you’re done

    swapoff ./swapfile
    rm swapfile

  7. In “Online Resizing of rootfs (Root File Partition)”, the commands work but they give some eye-opening error messages which are not mentioned in the docs. It would be useful to warn readers these messages will occur, but they are okay, and they should just continue with the following commands.

I have to say, given how much work is done to build the disk image, I am really very surprised it all worked! very well done. I have Linux runnng on the baord, and in fact - although I read that it’s “not useful for real work” it is in fact eveerything I need, so I have no need to now figure out how to get Debian working in a chroot, something for which I am extremely grateful!

There are 3 major versions of the freedom-u-sdk, which are very different from each other. The first version, the one that shipped with the board, is not useful for real work. You have the third version, which can be used for real work. Some people are still trying to use the first version which is why you see comments about it.

Ubuntu 18.04 has a usable apt based repo. Ubuntu 20.04 has a broken snap based repo. I filed a bug report against Ubuntu 20.04 to document the problem but I don’t know if/when it will be fixed. I also notified the freedom-u-sdk team.
We have since changed our docs to tell people to download repo from google instead of using the OS provided version. This will be in the next release. This is probably the same problem you ran into with debian.

I can build llvm with 10G if I don’t have a browser running. 12G if I have the browser running so I can read the build instructions.

I would suggest filing issues in github for freedom-u-sdk bug reports rather than using the forums. The people who maintain freedom-u-sdk are more likely to see the comments if they are in github. But this one was forwarded to our internal slack channel so people did see it.

1 Like

Ah. yes that could well be it! I recall those comments from back in the day.

Oh, well, no, I mean, Debian normally has really old versions of a lot of things, in my experience. This is usual.

Mmm, I mean, I wasn’t experimenting to find the minimum store required :slight_smile:

I have 4 GB RAM and 2 GB swap, I tried with 8 GB more swap and failed (and this with everything else closed, and a single build thread in a single build task). Adding 16 GB to the base 4/2 worked.

Ah, thankyou! I thought you were they!