Most open source Linux distributions are only partially open source, as while most packages will be built from publicly available source code, they usually come with closed source binary blobs for GPU drivers, wireless module firmware and so on.
Shedbuilt is described as “a decentralized, self-hosting GNU/Linux for Arm devices built from the latest upstream sources”, and as the developer (Auston Stewart) explains – see comments section – it does not contain any binary blob.
Eventually the distribution may support more boards, but for now, the current System 1 “Amano” release supports four Allwinner H3/H5 boards: Orange Pi PC, Orange Pi One, Orange Pi PC 2, and Libre Computer ALL-H3-CC “Tritium”. Orange Pi Lite (with WiFi) and Libre Computer AML-S905X-CC “Le Potato” images are said to be coming soon.
You can download the SD card images and access documentation on Shedbuilt.net. The Linux distribution relies on Shedmake script to automate the compilation, installation, upgrade and removal of software.
Watch Shedbuilt in action on the $10 Orange Pi One board in the demo video below showing tmux terminal, NetSurf web browser, retro gaming with dosbox, basilisk-ii desktop environment, and more.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
I’m Auston, currently the sole Shedbuilt dev. Just wanted to confirm that the posted system images have absolutely no binary blobs. You can see all the packages we ship in our Standard System Images on GitHub (https://github.com/shedbuilt/shedbuilt-system) and build them all from scratch yourself if you so desire using our Bootstrap documentation (http://shedbuilt.net/bootstrapping).
Hi Auston, Really good job. Congrats!
Hey Auston.
Thank you for share. I see that you do not have yet bootstrap for Nanopi Neo. Will this be an option later on, or can i do it myself (*not that good at kernel compiling)?
I don’t currently own a NanoPi Neo to test but I can and will produce a system image for it at some point. This will happen more quickly if someone would be so kind as to submit Pull Requests with the following:
1) Nano Pi Neo default config for shedmake: https://github.com/shedbuilt/shedmake
2) A tested Nano Pi Neo Linux kernel config: https://github.com/shedbuilt/linux
3) A tested Nano Pi Neo U-boot bootloader config: https://github.com/shedbuilt/u-boot
You bootstrap Shedbuilt on your device from Armbian to do this but it would be easier to cross-compile or build a derivative image from Shedbuilt on another Allwinner H3 device.
You should have in mind that some of the upstream settings (e.g. DRAM clockspeeds used by mainline u-boot) are pretty questionable.
I also wonder why you go with 648 MHz for DRAM and 1008 MHz for cpufreq without working DVFS? Both seems to be a recipe for instabilities on a relevant number of boards based on community testing so far 🙂
That aside that’s a great project able to teach a lot of people the inner workings of GNU/Linux. Kudos!
Reminder wrt 1008 MHz cpufreq without working DVFS: https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-sunxi/lower-default-cpufreq-H5.patch
I think I may have just gotten lucky with my H3 devices because I haven’t seen any instability at 1008Mhz / 1.1v on my Orange Pi One or Orange Pi PC. I’m running them with small CPU heatsinks but I’d think the effect would be negligible during an 18-hour compilation session. (That Orange Pi One may be magical though, because it’ll run at 672Mhz DRAM indefinitely with no cooling 🙂 ) I’ll definitely be throttling back if/when I learn more.
With regard to the H5, the only currently supported board is the Orange Pi PC 2. I’m building in support for the SY8106A in u-boot and setting the voltage to 1.2v to support that 1008Mhz clock. It’s been stable for me, but if SY8106A support isn’t really functional there then I’ll definitely need to address that.
I saw v2 patches for SY8106A and SY8113B kernel support go across the LAKML so I’m excited for those to (hopefully) land in 4.17.
The thermal/overheating stuff is totally unrelated to ‘overclocking’. I would give https://github.com/ehoutsma/StabilityTester a try to see whether you’re still able to run this at 1008 MHz without data corruption.
It happened more than one time that linux-sunxi community or hardware vendors chose clockspeeds that were way too high (applies both to DRAM timings and DVFS OPP). Worked somehow on developer’s board (not tested with appropriate tools of course) but then in the wild an awful lot of installations suffered from panics or just data corruption.
And at least I don’t understand why this happens again and again and again…
Thanks again, Thomas. I’m going to go run that tool and see what happens.
I’m not quite sure this worked (why is it showing 3V3 regulator voltage? what’s the significance of the ‘result’?) but here’s what I got, testing from Armbian 5.40 Stretch/Next:
Frequency: 648000 Voltage: 3300000 Success: 1 Result: 0.0048034
Frequency: 816000 Voltage: 3300000 Success: 1 Result: 0.0048034
Frequency: 912000 Voltage: 3300000 Success: 1 Result: 0.0048034
Frequency: 960000 Voltage: 3300000 Success: 1 Result: 0.0048034
Frequency: 1008000 Voltage: 3300000 Success: 1 Result: 0.0048034
Frequency: 1056000 Voltage: 3300000 Success: 1 Result: 0.0048034
Frequency: 1104000 Voltage: 3300000 Success: 1 Result: 0.0048034
Frequency: 1152000 Voltage: 3300000 Success: 1 Result: 0.0048034
I don’t think you need much external help for supporting any H3 or H5 based NanoPi. Without working DVFS, since you intend to ignore Wi-Fi/Bluetooth (BLOB free) and since it seems you want to use only stuff that already landed mainline (unlike e.g. Armbian) the only stuff you really have to care of is DRAM clockspeed in u-boot (which is partially or even mostly wrong in upstream u-boot due to ignorance).
The u-boot defconfig usually takes care of stuff like eMMC already and device-tree should be ok for your choice so it’s really just adjusting clockspeeds and you are able to support any H3/H5 board out there.
Dunno if this can be of any help/use, but just for reference: I found this image generator script to be very useful for the NanoPi Neo2:
https://github.com/mbouron/archlinuxarm-nanopi-neo2
had to adapt it slightly to accommodate install prefixes instead of default locations and replace aarch64-unknown-elf- with aarch64-unknown-linux-gnu- for it to work, but apart from that it worked nicely and saved me a lot of time
Amazing job! Congrats! I have 2 such OPi Ones i will give your image a try later this summer!
How can you make Orange Pi Lite Wi-Fi work without blob? As I know, the Realtek Wi-Fi card driver embeds a firmware blob as an array.
Hey Icenowy, thanks for all the work you’ve done for these boards upstream! The simple answer is that currently we can’t. The Orange Pi Lite image won’t support its built-in WiFi on release.
Does it have full Mali support?
Mali support will be available when the new Lima kernel driver and Lima Mesa driver are mainlined (https://github.com/yuq/linux-lima and https://github.com/yuq/mesa-lima). Qiang Yu and his merry band are making great strides there but it’s probably not going to land until after Kernel v4.17 which will be the basis for Shedbuilt System 2. Keep your fingers crossed for System 3 😉
Hi Auston have you enquired if Friendlyelec are interested in your work?
I haven’t reached out to them yet but supporting their Allwinner H3-based devices would be trivial. I simply don’t have any on hand to test.
Then they (FriendlyElec) should you send one 🙂
You should simply ask, they’re very cool and will likely send you one or two. Don’t be shy 🙂
Do I win a prize if I found a binary blob?
You’d win a ticket in my bug tracker 😉
Wow ! Great thing !
AML-S905X-CC “Le Potato” is very similar to the Khadas Vim btw.
I think they got it mostly blobless
http://forum.khadas.com/t/vim-ubuntu-mate-with-linux-4-14-11-and-u-boot-v2018-01-rc3-rom-alpha-v180106-sd-usb-installation/1791
Anyone have a good resource for getting started compiling the kernel? I’ve tried it once before and got pretty confused quickly
“Le Potato” is mostly supported (you’ll see linux, u-boot, and shedmake configs for it in the repos) but I haven’t produced images for it because, as far as I can tell, it’s broken in upstream u-boot. I can get it to work with BayLibre’s “upstream” 2017.11 snapshot (in combination with vendor sources) but not actual upstream u-boot 2018.01 and later.
Kernel compilation is a breeze, assuming you know what features to enable and disable. Just pull down the source from kernel.org then do this to begin tweaking:
make ARCH=arm64 defconfig
make ARCH=arm64 menuconfig
You don’t need the ARCH bit if you’re compiling natively on the device. linux-meson.com has info about what is and isn’t supported upstream for these Amlogic SoCs.
oh, didn’t know there was config menu 🙂
Thought you have to write a flag file yourself. I’d tried to extra my current system’s flags so that I can modify and add “perf” support – but wasn’t successful
And if you want to apply patches (like from BayLibre or whatever) – how do you go about doing that cleanly? (is that what “modprobe” is for? Or is that for an already running system?)
There are plenty of instructions on the web to build the kernel and apply patches.
One example: https://www.cnx-software.com/2011/10/18/raspberry-pi-emulator-in-ubuntu-with-qemu/#building-the-kernel-for-arm11
To apply a patch simply apply it with the command “patch -p1 < patch.diff"
So why would anyone want to do this? … Should have gone to SpecSavers ..
I too wondered why anybody would want to do this. There is no practical reason, so I assumed its an idealogical reason.
It would be remiss to fail to point out the irony that the majority of “Sizzle Reel” demonstrates this “blob free” distribution running various binary blobs (games, MacOs).
It’s an educational reason more than an ideological one – I don’t want the system to have dark corners that an interested student can’t explore. In high-security applications it’s also nice to have every piece of software be verifiable, but that’s not something I’m pursuing myself. As for the video, I know that retrogaming / retrocomputing are popular uses for these boards and I wanted to demonstrate what can be done with a fully open graphics stack, but I take your point. Plenty of blobs at work in those.
Could have done all this (and WAY more) with Buildroot, and a few scripts for package management, source verification AND build your system in about 20-30 minutes .
There is nothing educational here – more like wrong education – how NOT to build a distro.
Native compiling on arm to build a distro is called borderline insanity.
Well, you’re unfair buildmaster. As much as I hate native compilation (I cross-compile everything), there is some educational value here for beginners. When I was a kid, I spent countless hours and week-ends disassembling BIOS, DOS, commenting asm output to try to understand what all this stuff was doing under my code. Here ensuring that everything is available as source code provides a huge educational value for those who want to dig. And it also makes sense to stick to native builds there to shrink the learning process a little bit. I’d even argue that getting struck by a native build is the best way to be convinced that you never want to do that anymore for your own distro!
.. native compilation doesn’t necessarily teach you any of those lol, We are taking about building a distro, a problem which was solved elsewhere many times over.
If its masochism you are after, well you are welcome to knock yourself out lol