Swift is now Open Source. Did anyone tried compiling Swift for a Raspberry PI? I started to do, but my 8 GB SD card seems to be too small for it ;) Is it possible to cross compile it from Ubuntu?
A 8GB SD Card works ok, but you'll need to extend the root volume. I have it working and the used space on /dev/root partition is around 3.1GB.
The steps below are based on the blog post by Andrew Madsen with a little extra focus on the steps inside fdisk.
Get Ubuntu
Download an image of Ubuntu 14.04 for Raspberry Pi 2 from finnie.org and copy it onto the SD card. Boot the Raspberry Pi.
Change the partition
Log into the Raspberry Pi and change the partition size. The default size for /dev/root is 1.7G with 1.1G available. That is not enough.
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 1.7G 540M 1.1G 35% /
devtmpfs 458M 4.0K 458M 1% /dev
none 4.0K 0 4.0K 0% /sys/fs/cgroup
none 93M 228K 93M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 462M 0 462M 0% /run/shm
none 100M 0 100M 0% /run/user
/dev/mmcblk0p1 64M 20M 45M 31% /boot/firmware
Run fdisk
sudo fdisk /dev/mmcblk0
At the prompt enter p for 'print the partition table'. There are two partitions
/dev/mmcblk0p1 * 2048 133119 65536 c W95 FAT32 (LBA)
/dev/mmcblk0p2 133120 3670015 1768448 83 Linux
When prompted, enter d (for delete), then 2. Then, recreate the partition by entering n, then p, then 2, then pressing enter at the next two prompts accepting the defaults.
Enter p again and see the second partition is now bigger, now all space on an 8GB card is used.
Device Boot Start End Blocks Id System
/dev/mmcblk0p1 * 2048 133119 65536 c W95 FAT32 (LBA)
/dev/mmcblk0p2 133120 15523839 7695360 83 Linux
Enter w to write the changes to disk, then reboot
sudo reboot
Resize the partition
After the reboot, resize the partition’s file system by running
sudo resize2fs /dev/mmcblk0p2
Swap space
Setup a swap file by doing
sudo apt-get install dphys-swapfile
Install libicu-dev and clang-3.6
sudo apt-get install libicu-dev clang-3.6
Use update-alternatives to provide /usr/bin links for clang and clang++:
sudo update-alternatives --install /usr/bin/clang clang /usr/bin/clang-3.6 100
sudo update-alternatives --install /usr/bin/clang++ clang++ /usr/bin/clang++-3.6 100
Then, add #iachievedit’s repository key:
wget -qO- http://dev.iachieved.it/iachievedit.gpg.key | sudo apt-key add -
Add the appropriate repository to sources.list:
echo "deb [arch=armhf] http://iachievedit-repos.s3.amazonaws.com/ trusty main" | sudo tee --append /etc/apt/sources.list
Run apt-get update:
sudo apt-get update
Install Swift
sudo apt-get install swift-2.2
After the installation is complete, you’re ready to compile Swift programs!
Write Swift
Open your favorite text editor, write a program, and save it (e.g. to 'hello.swift’):
let device = "Raspberry Pi 2!"
print("Hello from Swift on \(device)")
Compile it
swiftc hello.swift
and run it:
./hello
Hello from Swift on Raspberry Pi 2!
That’s it! Swift running on Raspberry Pi
The Swift Package Manager got custom toolchain support via
PR-1098
end of April 2017.
I wrote up detailed instructions on how to build a RaspberryPi toolchain over here: macOS -> RasPi Cross Compilation Toolchain
and even the reverse (build macOS binaries on a RaspberryPi) for the fun of it.
The same would work for Intel-Linux to ARM-Linux w/ minimal modifications. The SwiftPM repo contains an example script on how to do this for Intel-macOS to Intel-Ubuntu.
You can find a 2017-05-01 update on Swift-on-ARM over here:
An Update on Swift 3.1.1 For Raspberry Pi Zero/1/2/3.
As a small summary, so that this answer isn't just links ;-), ARM status 2017-05-16:
you can compile Swift 3.1/3.1.1 on RaspberryPi Ubuntu
don't forget to setup swap, some minimal patches are required
for 3.1.1. 8GB disk may be a bit to little.
compilation on Raspbian doesn't seem to work yet (last known version
is 3.0.2)
you can cross-compile Swift using a custom toolchain, which is
reasonably easy to setup
you need to grab a SwiftPM snapshot (Swift 4) for this (but the toolchain itself can be 3.1 or even 3.0.2 w/ minor changes)
you can also run (and compile) Swift via Docker,
e.g. in HypriotOS.
there is a Slack group for Swift ARM: swift-arm
Related
I created a Postgres server locally using virualbox using Ubuntu 16.04. Using the import tool to move it to Google cloud seemed to work fine, but the root drive shows 100% full. None of the disk expansion instructions (including creating a snapshot and recreating the boot drive) seem to make any space available.
There seems to be a boot drive and a root drive. But the root drive shows it is all used. The boot drive shows space available, but it should be 15G in size not 720M.
Filesystem Size Used Avail Use% Mounted on
udev 1.8G 0 1.8G 0% /dev
tmpfs 370M 5.3M 365M 2% /run
/dev/mapper/techredo--vg-root 2.5G 2.5G 0 100% /
tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
/dev/sdb1 720M 121M 563M 18% /boot
tmpfs 370M 0 370M 0% /run/user/406485188
I checked if is possible to use LVM in GCP instances, and I find out that you're free to use it but is not supported by Google Cloud since instances doesn't use LVM by default.
On the other hand, you need to make sure that the Linux Guest Environment is installed in your instance, so you can get the automatic resizing feature. Please follow this guide to learn how to validate: https://cloud.google.com/compute/docs/images/install-guest-environment#wgei
Since your root partition is full and you're not able to install more programs I suggest you 2 workarounds:
Workaround 1: Create a new VirtualBox VM with and import it again, please note that your root partition is pretty small (2.5G) so I suggest you next time create a partition with at least 10GB, and avoid use LVM during the installation.
After your instance is ready in GCP, please check if the Linux Guest Environment is installed in your instance, if not install it: https://cloud.google.com/compute/docs/images/install-guest-environment
Workaround 2: Check which directory is causing problems and then which files are consuming your disk space, delete them to gain space, install the Guest enviroment and try to resize your instance.
a) To check the directories and files sizes, follow these steps:
There are several tools that can display your disk usage graphically but since your root partition is full you'll have to get the information by running commands (old school style).
Please follow these steps:
Please go to the root directory:
cd /
Please run this command to get the size of the main subdirectories under the root partition:
sudo du -aBM -d 1 . -R | sort -nr | head -20
NOTE: Identify which directory is eating your root partition.
Please run this command to get a full list of the files and its sizes:
du -k *| sort -nr | cut -f2 | xargs -d '\n' du -sh
NOTE: The above command will display all files and directories too fast, so in order to scroll down slowly, please run the same command adding the "less" instruction:
du -k *| sort -nr | cut -f2 | xargs -d '\n' du -sh |less
Press the spacebar to scroll down.
Please keep in mind that you have to go to the directory you want to analyze before running the commands in step 3 or 4 (just in case you want to analyze another directory).
Additional to this you can run the command "apt-get clean" to clear the downloaded packages (.deb files) that usually consumes a high part of your disk.
b) To resize your instance, you have 2 options:
Resize your VM instance "primary-server" by following this guide[1].
NOTE: The steps included in this option are pretty easy to follow, if this doesn't work try the second option which requires advanced Linux abilities.
Create a snapshot from the VM instance "primary-server".
2.1 Create a new instance based on a Linux distribution.
2.2 Once it's been created, stop the instance.
2.3 Follow this guide to add an additional disk[2].
NOTE: Basically you have to edit the instance "primary-server" and add an additional disk, don't forget to select the snapshot option from the "Source type" list and click on the snapshot you just created.
2.4 Start the instance.
2.5 Mount the disk by following this guide[3].
NOTE: Please skip step 4. The additional disk it's actually a boot disk so it's been already formatted. So, don't apply the format to it; just mount it, .
2.6 Check the permissions of the file "/etc/fstab".
NOTE: The permissions should be "-rw-r--r--" and the owner "root"
2.6.1 Delete files to reduce the disk size.
2.7 Unmount the disk at OS level.
2.8 Stop the instance.
2.9 Detach the additional disk from the new instance in GCP.
NOTE: Please follow this guide[4] and instead of clicking on X next to the boot disk, please click on X next to the additional disk.
2.10 Create a new instance and instead of using an image in the "boot disk" section, please use the disk you just restored.
NOTE: For this please go to the "Boot disk" section and click on the "Change" button, then go to the "Existing" TAB and select the disk you just restored.
REFERENCES:
[1] https://cloud.google.com/compute/docs/disks/add-persistent-disk#inaccessible_instance
[2] https://cloud.google.com/compute/docs/disks/add-persistent-disk#create_disk
[3] https://cloud.google.com/compute/docs/disks/add-persistent-disk#formatting
[4] https://cloud.google.com/compute/docs/disks/detach-reattach-boot-disk#detach_disk
Please let me know the results.
I have created kubernetes cluster using minikube and installed Jenkins x on it.
I am not able to access the Jenkins x dashboard.
Error 503 Service Temporarily Unavailable nginx/1.13.9.
note: I have tried with restarting minikube cluster also.
As mentioned by James Rawlings in the comments, it's likely to be a resource issue. The recommendations in the manual are:
A known good configuration on a 2015 model Macbook Pro is to use 8 GB of RAM, 8 cores, a 150 GB disk size and hyperkit.
The disk size is particularly large as a number of images will need to be downloaded.
So we highly recommend using one of the public clouds above to try out Jenkins X. They all have free tiers so it should not cost you any significant cash and it’ll give you a chance to try out the cloud.
Default minikube installation uses only 2048 MB of RAM, 2 CPU cores and 20Gb disk space. You can adjust minikube VM size using command line options:
$ minikube start --cpus=8 --memory=8192 --disk-size=150g --vm-driver=hyperkit
or use jx tool for that:
For MacOS
$ brew install docker-machine-driver-hyperkit
# docker-machine-driver-hyperkit need root owner and uid
$ sudo chown root:wheel /usr/local/opt/docker-machine-driver-hyperkit/bin/docker-machine-driver-hyperkit
$ sudo chmod u+s /usr/local/opt/docker-machine-driver-hyperkit/bin/docker-machine-driver-hyperkit
$ brew tap jenkins-x/jx
$ brew install jx
$ jx create cluster minikube
For linux:
$ curl -L https://github.com/jenkins-x/jx/releases/download/v1.3.784/jx-linux-amd64.tar.gz | tar xzv
$ sudo mv jx /usr/local/bin
$ jx create cluster minikube
Inside a Lubuntu VirtualBox VM (macOS host) I'm running QEMU with a U-Boot kernel (?) to load my compiled ARM assembly code (using tftp addr *.bin and go addr).
My problem is that QEMU uses 100% of the CPU. I'm following an Assembly programming course and was told that it wasn't normal (that's also why I'm using a VM)…
I'm not sure where does the problem come from, is it a config issue with VirtualBox (Guest additions are installed) or with QEMU?
QEMU is launched with the following arguments:
export QEMU_AUDIO_DRV=none
qemu-arm/arm-softmmu/qemu-system-arm -s -localtime -m 256 -M reptar -kernel u-boot-arm/u-boot -tftp . -serial mon:stdio -nographic
Version is:
$ qemu-arm/arm-softmmu/qemu-system-arm --version
QEMU emulator version 2.4.1 (qemu-linaro from git), Copyright (c) 2003-2008 Fabrice Bellard
Boot output:
reptar-sp6-emul: sp6_emul_init
sp6_emul_init: failed to connect to SP6 server
sp6_emul_init: terminate thread
U-Boot 2016.09 (Sep 26 2018 - 17:19:23 +0200)
OMAP35XX-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
REDS Reptar board + LPDDR/NAND
I2C: ready
DRAM: 256 MiB
NAND: 256 MiB
MMC: OMAP SD/MMC: 0
Using default environment
Net: smc911x-0
Reptar #
QEMU will use host CPU when the guest CPU is doing something, even if that "something" is "spin around in a tight loop". If the guest code uses the CPU instruction WFI ("wait for interrupt") in its idle loop, QEMU will handle that by stopping until a guest interrupt occurs. (WFI is an Arm instruction; for other guest architectures there is generally an equivalent instruction, like x86's HLT.)
So whether QEMU uses 100% CPU when the guest is "idle" depends on what exactly the guest's idle loop does. The idle loop in a "real OS" like Linux will use WFI (which on real hardware is useful for reducing power consumption) and so will idle at very low host CPU usage. CPU usage sitting at a u-boot prompt will depend on how u-boot is coded; CPU usage in your assembly code will depend on what it does.
You can use cpulimit with -l flag, to limit processor time for particular process. For example:
cpulimit -l 20 -- qemu-system-x86_64 -bios ./u-boot.rom
will limit qemu cpu usage by 20% of one core.
Also, more tricky way on native hardware (probably will not work in virtualbox): if you've got multicore processor, you may dedicate 1 cpu core for qemu, and limit it's clock frequency to lowest possible value, to save energy and keep it cool. Example on my Ryzen 4650u cpu:
install cpupower and tasksel: apt install linux-cpupower tasksel
get lowest possible core clock: cpupower -c 0 frequency-info -l
set core 0 clock frequency to lowest possible value: cpupower -c 0 frequency-set -u clock_freq 1400Mhz
run u-boot in qemu, assign process to core 0: qemu-system-x86_64 -bios ./u-boot.rom & taskset -cp 0 $!
I want to create i386 environment with QEMU and chroot on Raspberry Pi.
I am using Raspberry Pi ver B, but I guess it should not matter much which version is used.
So far I did:
apt-get install qemu qemu-user qemu-user-static binfmt-support debootstrap binutils
Then I mounted chroot directory to /tmp/mnt and ran:
sudo debootstrap --foreign --arch i386 buster ./ http://deb.debian.org/debian/
Then I mounted:
mount -t sysfs /sys /tmp/mnt/sys/
mount -t proc /proc /tmp/mnt/proc/
mount –bind /dev /tmp/mnt/dev/
mount –bind /dev/pts /tmp/mnt/dev/pts/
mount –bind /dev/shm /tmp/mnt/dev/shm/
Now when I try to run second stage of debootstrap:
sudo chroot ./ ./debootstrap/debootstrap --second-stage
I get the following error message:
W: Failure trying to run: /sbin/ldconfig
W: See //debootstrap/debootstrap.log for details
I checked the debootstrap/debootstrap.log:
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
Indeed when I try sudo chroot ./ ./sbin/ldconfig I get same Seg fault.
But when I try sudo chroot ./ ./bin/bash it works.
I am not sure what should be my next step.
I guess it is something related to my qemu config or verison (I am using version 2.8.1(Debian 1:2.8+dfsg-6+deb9u4)). I checked many threads about similar issues, but I could not find one which would help me to find the solution.
OK, I think I figured it out.
It works when I select stretch as Debian version in debootstrap command.
sudo debootstrap --foreign --arch i386 stretch ./ http://deb.debian.org/debian/
Now when I think about it more, it makes sense. I guess running i386 Debian in chroot does not provide full separation from host OS (I mounted proc, sys, etc.).
I had the exact same problem running Raspbian Buster; the problem went away when chrooting Debian Stretch.
So somehow ldconfig from the i386 repository is not working with the qemu-i386-static emulator on buster, but it IS working on stretch!
Has nothing to do with the host system....
everyone. I have been trying to increase the memory of my BleagleBone Black rev c without success.
I have followed these instructions in order to increase the memory of my BBB with a 16GB microSD card. I have already tried burning 2 different images Debian 9.1 2017-08-31 4GB SD LXQT and Debian 8.7 2017-03-19 4GB SD LXQT (without flashing the eMMc) .
The steps that I have been using are listed below.
What I first did was to burn the image into the microSD card using
Etcher.
Then I inserted the microSD into the BBB, I pushed the boot button
and then I plugged it into my computer to turn it on.
After that, I logged into my BBB using ssh and I checked for the
Debian version and it was correct. Indicating that the boot from the
microSD card was correct, but when I tried to check disk space I
couldn´t find the partition for the microSD.
As you can see in the image below it is supposed to show the rootfs where I have the new BBB image and the 16GB extra space, but I´m not able to see the extra partition. Does anyone know what I could be possibly doing wrong?
I am facing with the same issue and I end up with
Login to your BBB by ssh
Run this command
nano grow_partition.sh
copy code from here then paste it on the terminal
save file by pressing control + o then enter
Exit from nano editor by pressing control + x
Run this command sudo ./grow_partition.sh
Reboot BBB
Enjoy :)
I have a beaglebone black (original with 512MB mem) and I was able to use a different method to add swap memory successfully (unfortunately user3680704's method didn't work for me).
I got the idea from this post which basically says the following:
You can check your current memory with
free -h
And you can create the swap memory by running these commands. Again a more detailed better explanation is in the link above, but in case that ever goes dead you can follow these:
sudo fallocate -l 1G /swapfile
ls -lh /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
Next open the fstab file by running
vi /etc/fstab
and add the following line to the file
/swapfile swap swap defaults 0 0
You can then check your swap by running
swapon --show
This worked well for me, added 1G of swap. You can add more or less by changing the 1G value