I very recently built the freedom-u-sdk for the first time, and I want to give some feedback for the build instructions.
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.
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.
The repo command cannot cope with socks proxies. It needs direct access, or a HTTP proxy.
The first command “Updating Existing Workspace” is “cd riscv-sifive”. This is not needed, as in “Creating Workspace” we already changed into that directory.
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.
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
and then when you’re done
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!