store-mac-addr.sh: detect MAC address changes and update NVS file accordingly
Enable swap to zRAM by default

Unlike earlier releases, Android 4.4's memory management framework is
swap-aware, so there is no longer an inherent barrier to using swap on
Android.  We can therefore make our limited memory go farther by
configuring a moderate amount of zRAM-backed swap.

There are two knobs being adjusted in this patch:

* The amount of swap: this represents the total size of data stored in
  the zRAM device *before* compression.  Assuming a (conservative)
  compression ratio of 33%, 96 MB of zRAM swap should result in no more
  than 64 MB of actual RAM being in use at any one time, leaving 384 MB
  of RAM free for other purposes.  Given that other devices get along
  with less than 350 MB of RAM in total (after camera/codec/VRAM
  carveouts, before zRAM and other such techniques), this should be more
  than sufficient to keep the system happy.
* The "swappiness" of foreground processes: this controls how willing
  the kernel is to push anonymous memory (pages not backed by a file) to
  swap.  Lower values for swappiness will cause the system to try harder
  to free memory via other means before touching anonymous memory.  In
  this case, Android sets a much higher swappiness value for background
  processes via the memory cgroup mechanism, so the effect here is to
  cause the kernel to strongly prefer to swap out background processes
  before touching foreground process memory.

We can revisit both of these values later based on user experience.

Change-Id: Ie8d7c47cfda435e1e087a8ec676e21d0cf135ed3
Enable KSM by default

Kernel Samepage Merging (KSM) periodically scans memory marked by the
framework as MADV_MERGEABLE looking for duplicate pages; when it finds
them, it drops the duplicates and points all users at a single copy of
the page.  This is particularly useful on Android, where much of the
Java class data can be shared across processes.  Enabling this feature
on encore can save 16 MB of RAM after just a few hours of uptime.

Change-Id: Ic4eed0e0e42b3170e55831e4c85373b8720ba29a
Tell CM settings we really want KSM enabled by default

CyanogenMod's settings system will blindly overwrite the value in
/sys/kernel/mm/ksm/run with the value of the KSM setting exposed in
performance options, which defaults to off unless we tell it otherwise.

Change-Id: I9435d54216db123418218b8c98f9ad3801627c7d
Change unzip-files.sh to allow default encore_update.zip

Original suggests allowing for encore_update.zip in build directory,
but test on $1 instead of $ZIPFILE bypasses this.

Change-Id: I877eb78188a867f743fb347f4ac015061bd55432
Fix 16bit boot animation

The implementation of the 16 bit boot animation has changed.
Now we need TARGET_BOOTANIMATION_USE_RGB565 := true
See:
https://github.com/CyanogenMod/android_frameworks_base/blob/cm-11.0/cmds/bootanimation/Android.mk#L37

Change-Id: I8d1e3d4dbe9bcd92d6dbea5921019f888c085c90
Update bootloader to pass boot location on kernel command line

Our planned boot-location-agnostic software will need this information
from the bootloader in order to find /system and /data.  Older software
will just ignore the added argument on the command line.

Built from commit 54951a2 ("omap3621_evt1a: pass boot device information
on kernel command line") in the encore_cyanoboot tree.
Add utility to set up device symlinks based on the boot device

We'd eventually like to be able to install an identical software build
for encore to either eMMC or external SD card and be able to boot it
without any modifications.  In order to do that, we'll need to be able
to find the system and userdata partitions at runtime by taking into
account the install location.

Early userspace has no way of discovering the boot location on its own,
so we modify the bootloader to pass this information on the kernel
command line.  fsfinder (this utility) will then parse the command line
to find the boot location and set up device symlinks appropriately.

To be of any use, fsfinder has to run before /system is available, so
to avoid the need to ship a statically linked shell or other interpreter
in early userspace, the implementation is in C and compiles to a
statically linked binary.
Make the early boot process boot-location-agnostic

Instead of using fixed block device names for /system and /data, let
fsfinder set up links for us based on the boot location.  This allows us
to run unmodified from both eMMC and external SD card.
Make the recovery boot-location-agnostic

Instead of using fixed block device names for /system and /data, let
fsfinder set up links for us based on the boot location.  This allows us
to run unmodified from both eMMC and external SD card and to do the
right thing in both cases.
Add script to configure vold based on boot location

On SD card installs, the first partition of the SD card is the FAT
filesystem used as the boot partition.  This leads vold, which searches
the SD card for the first recognized partition when given a partition
number of "auto", to identify /boot as the /sdcard partition.

Fix this by running a script which detects SD card installs and modifies
/fstab.encore to instruct vold to use the last partition on the SD card
in that case.
Configure vold based on boot location in recovery too

To ensure that configure_vold.sh runs before vold starts, we need to use
an init.rc file (postrecoveryboot.sh is run when recovery starts, after
all the various services are started).

We also need to edit the configure_vold.sh script to change the
interpreter location for the recovery (/sbin/sh as opposed to
/system/bin/sh), so we need some build system hackery as well.
Recovery: move fsfinder startup into init.rc

While it doesn't seem to be strictly necessary for fsfinder to be
complete before the recovery starts, it shouldn't hurt either, and it
may prevent some potential problems in cases where recovery has been
instructed to do something when it starts (flash an OTA package, for
example).
configure_vold.sh: clean up identifying last partition on SD card