Installing Emteria OS via PINN?
Hi Igor,
You may remember me from a while back when I added RTAndroid to PINN's growing list of installable Operating Systems for the Raspberry Pi.
Someone has asked me if it is possible to add Emteria OS to PINN as well (the free evaluation version, obviously).
It would seem to go against your EULA, but I wondered if that only pertained to the paid versions? So I thought I had better ask first. I am also assuming that the installation/partitioning is similar to RTAndroid.
ProCount.
0
Comments
Sounds great to me, thanks for asking! In general, we don't mind providing explicit permissions apart from our EULA. The initial installation is always a free version, which can be activated in the next step. So there is no way to install paid version immediately.
I have to admit I am not very familiar with PINN, could you please help me getting a general understanding of how the operating system is installed? What happens after an update?
Yes, the partitioning is almost identical to RTAndroid. However, the distribution isn't and we will have to stick to the new model because of some legal implications.
That's good to hear.
PINN is based on NOOBS from the Raspberry Pi Foundation.
It is a very small Linux based boot manager that is used to install multiple OSes onto the SD card from the USB stick, internet download, or from the SD card itself. (A bit like Grub/UBOOT etc). (See https://groups.google.com/forum/#!topic/android-rpi/fUQqR26h1WI to refresh your memory)
When installing an OS, it creates and formats all necessary partitions first, then untars the files for each partition from their respective files. Finally, it fixes up any partition references so that the OS can operate from its new location, which is typically partition#6 onwards, depending on how many OSes are installed. The partitions either have a fixed size, or a minimum size that is expanded by sharing any additional space on the SD card between all the installed OSes.
See https://sourceforge.net/projects/pinn/files/os/rtandroid/ for the files used to install RTAndroid.
A typical Debian based OS can be updated using
sudo apt-get update/upgrade.I'm not familiar with how Android updates itself. If it uses similar mechanisms, or is based on partition names, partuuids, mount points, or updating files, it will probably be ok. It would fall down if it expects to live on the 1st 4 partitions of the SD card, for example.
It looks like the installer will require a login in order to proceed.
Is this information just used to track/authorise downloads, or is it stored in the OS image on the SD card for later licensing use? Obviously, I don't want every copy of Emteria installed by PINN to be licensed to me
Cool. How do you update partitions on-the-fly?
We use 4 partitions (like in RTAndroid):
The boot partitions contains an kernel image, own UBOOT bootloader and standalone recovery which is loaded during an update.
Yes, the installer may be a problem. RTAndroid was shipped as a single image, which may result in GPL-related issues as the kernel was included by default. emteria.OS is shipped in separate files for each partition, such that GPL-stuff only affects the boot partition. Since downloading multiple files and flashing them separately may be too complicated, we have developed the installer. Its only purpose is to download the image files, format the sdcard, flash the images and validate their signature. There is indeed some extended logic for our business customers (including their configuration or licenses into the image), but it isn't required for normal users. We provide an API for downloading the latest stable release which you could use in your installer. Authorization is required, but we could use a dedicated PINN account for that.
Sorry, in what context do you mean?
Do you mean your recovery/updater? If it uses hard-coded partition numbers/references, provided they are accessible, they can be patched to reference the new partitions.
Separate files for each partition will suit PINN better. What format are they in?
That's basically what PINN does too.
Cool. Mostly I have to do some re-formatting or repackaging of the image files, which takes time. But if PINN can access the most up to date files and they are in a compatible format, it makes things a lot easier.
I'd like to know how the partition references are patched.
Yes, it uses hard-coded partition references. So you are patching those partitions in your images (before installation)?
1 FAT + 3 EXT4
What format would be compatible?
I've downloaded Emteria and had a look at it now, although not installed it yet.
I see the partition file formats are zipped images. That's ok. I guess the first 3 partitions are fixed sizes and the 4th one (with no content) can be expanded to whatever size is available? Does Android require a minimum size for this userdata partition - 2GB or similar?
The boot image contains a couple of .uimg files (a small change from RTAndroid) but I think PINN can deal with those. These contain the fstab.rpi3 files (like RTAndroid) which need patching. That is done with an Emteria specific script (partition_setup.sh) that is run after the img files have been installed to their partitions, but before PINN finishes and allows the user to boot into an installed OS. PINN passes the partition references to this script. Again the RTAndroid script can be used with a small adaption. Are there any other files that would need patching for partition references?
I think support for RPF 7" touchscreen or Waveshare screens can be added like in RTAndroid using OS flavours, if you support those.
Normally, I have to convert an OS into a NOOBs/PINN compatible format, but I can use your files as is. Some additional meta-files will be needed (like your downloaded Json files), but if you can adapt your build scripts to create these, it means PINN will always be able to distribute your latest version without any lag through me. Plus you get complete control over what is delivered.
Exactly. You can take a look at the package.json file for more details. There is no specific minimum size requirement, but I'd not go below 2GB for data.
Sounds good to me. I don't remember any other references at the moment. In emteria we provide full recovery support (using TWRP), this is what those .uimg files are for. It would be awesome if they it would work.
There is no need for them. emteria.OS provides native support and automatic resolution adjustment for a bunch of different screens.
It depends on the metadata you need. In general we can extend the json file with whatever we want, but we try to keep it as abstract as possible. The same file is used by our website, our installer and the update application.
I would like to install Emteria with PINN. So that I can have everything I need in the same SD without having to change it. I would even pay for it. Since it has not been like that because of this. I would also need the function of being able to use NTFS partitions since I dislike only being able to use FAT.
My first attempt at moving Emteria to partition #'s 6,7,8&9 results in 7 LED flashes - "cannot find kernel image".
I'm thinking that this is because boot.scr.uimg contains "fatload mmc 0:1". Should I change this to "fatload mmc 0:6" ?
(I'm extracting boot.scr using "tail -c+73 <boot.scr.uimg >boot.scr" - maybe there is a better way? After modifying boot.scr, I package it up again using " mkimage -A arm -O linux -T script -C none -n boot.scr -d boot.scr boot.scr.uimg".)
But even changing to 0:6, I still get 7 flashes indicating missing kernel.
Hmmm... I think the problem is that uboot only looks for boot.scr.uimg on partition#1, from what I've just read. Further, Uboot only seems to work from partition#1, although there has been a project to move the rootfs to different partition numbers. This is probably why I never got a uboot based system multi-booting in the past. Is there a way to boot Emteria without uboot?
Igor,
I have now got Emteria installed and booting through PINN (on partitions 6-9)
To do it, I had to remove uboot and booted it directly from the VC GPU. (I'm not really sure what benefit having Uboot there brings, especially within a PINN environment).
However, this means recovery mode does not work ( 7 flashes again ).
I'm not sure how recovery mode works (I guess you are switching ramdisk.uimg and recovery.uimg somehow), but if you could alter the switching to detect whether it is running with or without uboot and switch appropriately, I don't see any reason why that can't work as well.
Awesome, thanks for your great work and sharing!
Regarding uboot, RPi3 is a kind of exception in the world of embedded devices, since it can boot the kernel based on the configuration in the config.txt file. The vast majority of all other devices typically rely on uboot for system initialization. We could get rid of uboot (maybe), but in that case we would rather move away from the industry standard, which isn't a good thing usually. Using Android without recovery may be sufficient for testing and evaluating, but it is definitely required to install system updates in a safe and reliable manner. I'm not sure whether emteria.OS would be so popular without updates.
It would be great if we can find a way to boot the recovery image (basically just another ramdisk) without uboot.
I am not proposing that you do away with Uboot for a standard installation, just that PINN removes it when it installs it. That part is more or less done now.
It would help me to know the mechanism by which your Android App switches from the ramdisk.uimg to the recovery.uimg to enter recovery mode, and how it switches back again. (Does it rewrite boot.scr.uimg, for instance?)
I did try booting recovery.uimg (after patching fstab.rpi3 and changing the image format like I did for ramdisk.uimg) but it ended up in some kernel panic boot loop and kept rebooting after 5 secs. Maybe I did something wrong, or is there something else that is different between recovery and ramdisk?
The ideal situation would be for UBoot to work from any partition and load its environment, scripts, images etc. from any other partition than partition#1 (even the same partition where Uboot is located would be sufficient). But I haven't seen any successful fork that does that.
Is it possible from "pinn" the installation of emteria?