I thought it would be cool to see how long it takes to make a boot-able Raspberry Pi disk using ELLCC. This is a timed experiment. In the end we’ll have an SD card that can be booted on the Pi. First, get a binary ELLCC release:
[~/ellcc-release] dev% mkdir test [~/ellcc-release] dev% cd test [~/test] dev% wget http://ellcc.org/releases/ellcc-x86_64-linux-eng-0.1.27.tgz --2016-01-12 22:00:19-- http://ellcc.org/releases/ellcc-x86_64-linux-eng-0.1.27.tgz Resolving ellcc.org (ellcc.org)... 174.102.201.124 Connecting to ellcc.org (ellcc.org)|174.102.201.124|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 650187071 (620M) [application/x-gzip] Saving to: ‘ellcc-x86_64-linux-eng-0.1.27.tgz’ ellcc-x86_64-linux-e 100%[=====================>] 620.07M 11.0MB/s in 56s 2016-01-12 22:01:15 (11.1 MB/s) - ‘ellcc-x86_64-linux-eng-0.1.27.tgz’ saved [650187071/650187071] [~/test] dev% tar xvfp ellcc-x86_64-linux-eng-0.1.27.tgz
Second, check what the options are:
[~/test] dev% cd ellcc/libecc/ecclinux/ [~/test/ellcc/libecc/ecclinux] dev% ./build usage: ./build [options] target options: -packages 'packag1 package2 ...' Specific packages to build -exclude 'packag1 package2 ...' Specific packages to exclude -extras Include additional packages -clean Clean up a previous build targets: help This message bcmrpi Raspberry Pi (ARMv6) bcm2709 Raspberry Pi 2 (ARMv7) available packages: kernel sinit sbase ubase smdev nldev nlmon svc sdhcp loksh ntfs3g iproute2 e2fsprogs vim dropbear extra packages: ellcc packages not buildable on the Mac: uboot iproute2 e2fsprogs vim
Third, build an image for the Pi 2 that includes the ELLCC tool chain (-extras):
[~/test/ellcc/libecc/ecclinux] dev% ./build -extras bcm2709j ...
Fourth, insert an SD card and install:
[~/test/ellcc/libecc/ecclinux] dev% su Password: [root@dev ecclinux]# ./install Warning! This command will destroy all data on /dev/sdc. Continue? [yes/no] yes ...
Put the SD in the Pi and boot. Voila!
hen trying ./build -packages=”kernel” bcmrpi he give me unknown option: -packages=kernel … can you help ?
when trying
./build -extras bcmrpi
./build: 1: ./build: realpath: not found
or with
./build -packages=”kernel” -extras bcmr
unknown option: -packages=kernel
You may need to install the coreutils package to get realpath.
No “=”:
I would suggest to add an extra test for FS case-sentiveness to ./build.sh
If the build directory is not located on a case-sensitive FS, the kernel build fails late with an error message which is hard to interpret – I know this is part of the build instructions, but who’s RTFM ? 🙂
Something stupid such as the following patch could help:
— a/build 2016-02-09 10:01:31.000000000 +0100
+++ b/build 2016-02-09 11:25:23.000000000 +0100
@@ -166,6 +166,17 @@
MAKEFILE=makefile
fi
+TESTFILE=”_FileCaseTest_”
+rm -f “${TESTFILE}”
+ltestfile=`echo “${TESTFILE}” | tr [:upper:] [:lower:]`
+touch “${ltestfile}”
+if [ -e “${TESTFILE}” ]; then
+ echo “Not running from a case-sensitive FS” >&2
+ rm -f “${ltestfile}”
+ exit 1
+fi
+rm -f “${ltestfile}”
+
# Tools.
if [ “${UNAME}” = “Darwin” ] ; then
export HOSTCC=clang
Moreover, there are two issues with dropbear build:
* official web site seems to be up and down on a regular basis. There is an alternate URL (mirror) which might be more reliable:
— a/build 2016-02-09 10:01:31.000000000 +0100
+++ b/build 2016-02-09 11:25:23.000000000 +0100
@@ -444,7 +455,7 @@
”
getversion dropbear \
– https://matt.ucc.asn.au/dropbear/releases \
+ https://dropbear.nl/mirror \
dropbear nevertheless fails to build on OSX, as zlib dependency is missing. However I do not get how it is built on a Linux host anyway. Any clue?
Finally, ./install cannot be run as-is on an OS X host, as many tools are not available and device names do not match OS X rules.
Ok, I finally managed to create a RPi2 Linux bootable SD card from OS X.
It requires many changes within the installation script and a couple of external tools (e2fsprogs, Fuse-Ext2) to deal with the EXT4 partition, but it does work, even from an OS X El Capitan (10.11.3) environment.
I think a nice option is to enable an exclusion list to the install script, as writing the whole ECC toolchain to the SD card takes a very long time (BTW stripping ELF file may help) to debug the setup 🙂
Hi Emmanuel,
Sorry it has taken so long for me to get back to you. I promised myself that I’d make some progress on building ELLCC with cmake before my clang/LLVM sources got too far removed from TOT. I have all the builds except mingw working, so I let myself look at Linux again.
It is very cool that you were able to make an SD card on the Mac. I’d love to add changes to the install script to support the Mac if you’re willing to share them.
It is a great idea to have an exclusion list in the install script. It does take way too long to make the SD card when debugging.
-Rich
Hi Rich,
Sorry for the late reply, I though I would receive an email notification on your post but I did not.
Here are the files:
https://gist.github.com/eblot/01b1b4694652866b07d6
https://gist.github.com/eblot/518f815a33562a4cc631
Requirements:
* e2fsprogs package (from Homebrew)
* OSX fuse https://osxfuse.github.io/
* Fuse-Ext2 (which supports Ext4)
Note that the current release for Fuse-Ext2 will not work on El Capitan because of the latest security restrictions introduced with OS X 10.11. A simple fix for this issue is to install the files within /Library instead of /System/Library. While foolish people recommend to “solve” this problem by disabling the System Integrity Protection, you only need to apply a patch to build Fuse-Ext2 for El Capitan and preserve the default security features:
https://github.com/eblot/fuse-ext2/commit/95c8e5f6b416b061f941bcd4333ff0bd32fa00f9
(stick with the original build instructions as documented with the top README file once the patch is applied)
HTH. I hope I forgot nothing, let me know how it goes