I have built a few "distros" for various PPC, MIPS and ARM platforms from scratch. My usual approach is to start with Buildroot and kernel.org, then create a native C/C++ toolchain, then a package manager. Once I have enough in place, I drop the buildroot created root file system and replace it with a native file system.
The problem with rolling your own this way is that unless you adopt a scheme that matches an existing distribution that supports the same OS flavor on the particular platform you're on, you have to create your own package repository for all those additional packages those who adopt your distribution will want. When I've done it, it was for embedded development on custom hardware, and the package repository only had to contain the tools that we documented for the SDK, and the only users worked on the same team as I did.
None of the boards I've done this for had functional video (sure, some had perfectly good video controllers and GPUs in the SoC, but we didn't use them), which made for a much easier job as well. Serial consoles and SSH/Telnet require a much smaller load set than X11 or its descendants.
If I was going to do this for a Raspberry Pi 3, I would be sure that I had a good native C/C++ toolchain build first (including bintools if going with the GNU stuff) and of course you must have "make", "patch", "sed", and "m4". Second, I'd add Tcl/Tk, then perl, python, and once those were all working, I'd just keep adding things until it all seems useful.
One thing I have done is to adapt a debian based distribution to different hardware using "debootstrap". This was for a PowerPC (P1025) based development board (P1025TWR), and I found a debian based offshoot of it that was built for a different core. I built my own kernel with appropriate FP emulation in place, then I was able to use the packages from the repository. They weren't as fast doing FP as they would have been if they'd been compiled for E500v2 instead of E500mc, but they did work. Once again, that board has no graphics adapter on it, so my job was much easier, but I did install lots of X windows programs, just not a server, and used it over the LAN.
Not sure if anything I've said makes any sense, but I figured my experience might be informative.
Considering this is mostly a hardware forum, I'm not surprised. Go is really cutting edge systems programming stuff. I'm not even sure you could toggle an I/O pin with it. But, I haven't looked into it.
Top Comments