This mini tutorial is meant for those people providing Android or RemixOS 'DD images'. The DD images currently provided have been created wrong (too large for many SD cards out there). Fortunately it's easy to do it better. Since we're talking here about SBC why not stop wasting time on both creator's and user's side, using an SBC in USB gadget mode, create images with appropriate size and speed up things?
The whole process would work with any Pine64/Pine64+ too but since AFAIK no OS image is around that uses a correctly configured kernel enabling the necessary g_mass_storage module and since a small patch might be necessary to get this working with BSP kernel (can't test right now since ran out of Pine64) we discuss this with H3 devices instead (H3 is A64's little sibling). Ingredients:
1) Prepare the disk
Connect the USB device to OPi One, the H3 board to your Windows machine, then do on the Linux box:
This will hand the whole device as an USB disk to your Windows PC. Since I don't own such thing (only virtualized Windows servers) in the following I will show how it looks like when the SBC is connected to a Mac. You can now use disk utility (no idea how that's called in Windows) to partition the disk that is physically connected to the SBC in reality. I created the necessary partitions in OS X that are all small enough to fit on any SD card later. Now in OS X it looks like this:
And on the SBC itself in Linux it looks like this:
So we created 4 partitions that we will then feed to PhoenixCard in the next steps. Time to eject/unmount the partitions from Windows (or OS X in my case) and then remove the device back in Linux (we switch first to USB host mode which is the equivalent of disconnecting a real USB disk physically and will then unload the driver since we will use it in the next step not with /dev/sda but the individual partitions instead):
2) Provide the partitions as devices starting with 7.8 GB in size
In Linux /dev/sda2 is 7.8 GB in size so now we hand only this partition out to Windows (or in my case OS X):
And instantly on the connected PC a new USB device appears that's just 7.8 GB in size:
3) Let PhoenixCard do the work
Now start PhoenixCard and point it to this virtualized 'USB thumb drive'. PhoenixCard will create a bunch of new Android/Linux partitions on /dev/disk2 (/dev/sda2 on Linux) and use the maximum disk space available (7.8 GB in our case). That's the whole trick: Creating a partition small enough to fit on any SD card later, let PhoenixCard use this partition as device and create its own partitions on this.
4) Create the DD image on Linux
Eject/unmount the virtual USB thumb drive in Windows, mount the next one to create the 16GB version and while PhoenixCard does its job in Windows create a new device image on the SBC that will be way smaller than the images Pine64 folks provide now. The most important thing here is that we create a device image by using a partition. Now /dev/sda2 on Linux contains a bunch of partitions and therefore we use
For the 16GB variant it would look like this (and so on):
(I think Armbian doesn't ship with 7-zip so an 'sudo apt-get install p7zip' would be required before). This way you get pretty small DD images while PhoenixCard is already preparing the next image on the Windows host.
5) Tell your users to use appropriate tools and what's important.
When you put the compressed images online then provide GOOD documentation how to burn images correctly. Don't recommend tools that suck, it's 2016 and burning tools that verify the burning process do exist, for Android and RemixOS images it's VERY IMPORTANT that users choose SD cards that show high random IO performance. Everything is outlined here: http://docs.armbian.com/User-Guide_Getti...-a-sd-card
The whole process would work with any Pine64/Pine64+ too but since AFAIK no OS image is around that uses a correctly configured kernel enabling the necessary g_mass_storage module and since a small patch might be necessary to get this working with BSP kernel (can't test right now since ran out of Pine64) we discuss this with H3 devices instead (H3 is A64's little sibling). Ingredients:
- Any H3 device from this list: http://www.armbian.com/download/
- A short USB-to-Micro-USB cable (or type A to type A when choosing the Beelink X2 or Pine64 later)
- An Armbian image for the device in question using legacy kernel since we need USB OTG support
- A 120 GB disk to store the images with 7.8, 15.8, 31.8 and 63.8 GB size (or a 250 disk when both Android and RemixOS images should be stored on the same disk)
1) Prepare the disk
Connect the USB device to OPi One, the H3 board to your Windows machine, then do on the Linux box:
Code:
modprobe g_mass_storage file=/dev/sda
echo 2 > /sys/bus/platform/devices/sunxi_usb_udc/otg_roleThis will hand the whole device as an USB disk to your Windows PC. Since I don't own such thing (only virtualized Windows servers) in the following I will show how it looks like when the SBC is connected to a Mac. You can now use disk utility (no idea how that's called in Windows) to partition the disk that is physically connected to the SBC in reality. I created the necessary partitions in OS X that are all small enough to fit on any SD card later. Now in OS X it looks like this:
Code:
macbookpro-tk:~ tk$ diskutil list
...
/dev/disk2
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *128.0 GB disk2
1: EFI EFI 209.7 MB disk2s1
2: Apple_HFS Ohne Titel 1 7.8 GB disk2s2
3: Apple_HFS Ohne Titel 2 15.8 GB disk2s3
4: Apple_HFS Ohne Titel 3 31.8 GB disk2s4
5: Apple_HFS Ohne Titel 4 63.8 GB disk2s5
6: Apple_HFS Ohne Titel 5 8.9 GB disk2s6And on the SBC itself in Linux it looks like this:
Code:
root@orangepiplus2e:~# cat /proc/partitions
major minor #blocks name
179 0 15267840 mmcblk0
179 1 15114128 mmcblk0p1
179 32 4096 mmcblk0boot1
179 16 4096 mmcblk0boot0
8 0 125034840 sda
8 1 204800 sda1
8 2 7617188 sda2
8 3 15253392 sda3
8 4 30957032 sda4
8 5 61658076 sda5
8 6 8688952 sda6So we created 4 partitions that we will then feed to PhoenixCard in the next steps. Time to eject/unmount the partitions from Windows (or OS X in my case) and then remove the device back in Linux (we switch first to USB host mode which is the equivalent of disconnecting a real USB disk physically and will then unload the driver since we will use it in the next step not with /dev/sda but the individual partitions instead):
Code:
echo 0 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role
rmmod g_mass_storage2) Provide the partitions as devices starting with 7.8 GB in size
In Linux /dev/sda2 is 7.8 GB in size so now we hand only this partition out to Windows (or in my case OS X):
Code:
modprobe g_mass_storage file=/dev/sda2
echo 2 > /sys/bus/platform/devices/sunxi_usb_udc/otg_roleAnd instantly on the connected PC a new USB device appears that's just 7.8 GB in size:
Code:
macbookpro-tk:~ tk$ diskutil list
...
/dev/disk2
#: TYPE NAME SIZE IDENTIFIER
0: Ohne Titel 1 *7.8 GB disk23) Let PhoenixCard do the work
Now start PhoenixCard and point it to this virtualized 'USB thumb drive'. PhoenixCard will create a bunch of new Android/Linux partitions on /dev/disk2 (/dev/sda2 on Linux) and use the maximum disk space available (7.8 GB in our case). That's the whole trick: Creating a partition small enough to fit on any SD card later, let PhoenixCard use this partition as device and create its own partitions on this.
4) Create the DD image on Linux
Eject/unmount the virtual USB thumb drive in Windows, mount the next one to create the 16GB version and while PhoenixCard does its job in Windows create a new device image on the SBC that will be way smaller than the images Pine64 folks provide now. The most important thing here is that we create a device image by using a partition. Now /dev/sda2 on Linux contains a bunch of partitions and therefore we use
Code:
dd if=/dev/sda2 bs=10M | 7zr a -bd -t7z -m0=lzma -mx=3 -mfb=64 -md=32m -ms=on -si Android-8GB.img.7zFor the 16GB variant it would look like this (and so on):
Code:
dd if=/dev/sda3 bs=10M | 7zr a -bd -t7z -m0=lzma -mx=3 -mfb=64 -md=32m -ms=on -si Android-16GB.img.7z(I think Armbian doesn't ship with 7-zip so an 'sudo apt-get install p7zip' would be required before). This way you get pretty small DD images while PhoenixCard is already preparing the next image on the Windows host.
5) Tell your users to use appropriate tools and what's important.
When you put the compressed images online then provide GOOD documentation how to burn images correctly. Don't recommend tools that suck, it's 2016 and burning tools that verify the burning process do exist, for Android and RemixOS images it's VERY IMPORTANT that users choose SD cards that show high random IO performance. Everything is outlined here: http://docs.armbian.com/User-Guide_Getti...-a-sd-card
