[Gta04-owner] Replicant 4.2 upstream status

Lukas Maerdian luk at slyon.de
Wed Apr 30 11:04:53 CEST 2014

Hi Paul,

2014-04-23 14:28 GMT+02:00 Paul Kocialkowski <contact at paulk.fr>:
> Finally, I found some time to give my GTA04 the kind of attention it
> deserves. I've been cleaning up my Replicant 4.2 GTA04 tree and started
> pushing everything to the Replicant repositories. At this very moment,
> the kernel is still pushing (takes a while from this location) but I'm
> confident it'll be complete by tomorrow morning.

I'm glad you finally found some time to have a new look at the GTA04
and started integrating our device with upstream Replicant again.

> There are many topics to discuss regarding Replicant 4.2 on GTA04.
> First, let's see what's different between the "upstream" Replicant
> version and the Goldelico one:
> * So far, only the GTA04A3/A4 are supported. That means that there is no
> adaptation code and all specific modules are builtin (battery, etc).
> I'll comment more on that in a bit.
> * There are four partitions (/boot, /system, /cache, /data) instead of
> just one and the kernel uses a ramdisk initramfs.

For the time being we just have to cope with that. The Goldelico
version of Replicant will stay on the single partition installation
scheme for now, but maybe we can find a compromise in the future, so
the projects don't diverge too much.

> * Emulated storage is properly configured
> (http://source.android.com/devices/tech/storage/)
> * External storage is properly handled
> * MTP is working properly over USB

Cool! I've strugeled to get those right. I'll have a look at what
you've done and try to integrate it into the Goldelico image.

> * Recovery is fully implemented and can be triggered when no system is
> installed, when AUX is pressed during boot, or when selected in the
> reboot menu
> * Installation is done through OTA zips, such as the ones distributed by
> CyanogenMod
> * The Replicant installer script will setup up the card with the bare
> minimum (partitions, bootloaders, recovery) first, hence the device will
> first boot to recovery, from which a system can be install, but it can
> also directly extract a zip on the card so that the device boots
> directly to Replicant.

This, as well as encryption, seems to be only possible with the multi
partition scheme. So I'll work arround those changes for now.

> * Properly-sized bootanimation.
> * Vibrator support.
> * Working encryption.
> On the kernel side, I also introduced a few changes, some of which will
> never make it to upstream but that I still need to have a better user
> experience:
> * Some defconfig changes (support for block devices for USB storage
> devices), VT console for second splash, no Linux logo)
> * Red led disabled, omapfb uses rgb565 as default

I've already imported some of those changes, which don't harm our
image, into the Goldelico Kernel, as I'd like to keep the kernels as
similar as possible (for easier cooperation).

> * bq27x00 polls more often (1 minute)
> * bq27x00 changes that I'll detail in separate threads (always report
> charge, avoid inconsistent states, twl4030 supplicant)

We've had pretty good results, by using the userspace interface (e.g.
/sys/module/bq27x00_battery/parameters/poll_interval). Maybe you can
have a look at this, to avoid (not mainline-able) kernel changes.

> On the other hand, it is behind compared to the Goldelico version on the
> following points:
> * No Wi-Fi support
> * No Bluetooth support
> * No sensors support
> * No RIL support
> Among the new features I introduced, I think recovery and encryption are
> the most important ones. Both are only possible thanks to the
> multi-partition scheme, which is why I don't think the single-partition
> approach is good.
> Recovery is really great to use as it makes it possible to make backups
> of the system and restore them later, wipe the data (while keeping the
> emulated internal storage, or not), install other systems (for instance,
> if Firefox OS was to run on the GTA04, people could switch easily
> between Replicant and Firefox OS that way) and many other things, all on
> the go and without the need for a host computer and getting the sdcard
> out. It can turn out to be a real life saver.

That sounds interesting and I'd like to have a look at it in the future.

> Encryption seems like a quite straightforward thing to have. The way
> it's implemented makes it mandatory to have distinct system and data
> partitions.
> Regarding other GTA04 variants, I decided to deal with them later on.
> I'll do it through a daemon that will coordinate all the changes to
> introduce at run-time. All the variant-specific pieces will then be
> built as modules and loaded by that daemon. It will also setup props
> that modules such as sensors, lights, etc, will use to figure out how to
> behave.
> Since I have to do the same thing with Allwinner devices, I'll first
> learn how to do it on Allwinner and will implement it on the GTA04
> after.

Sounds good! I can help with the implementation of that daemon, once
you've setup the initial skeleton to your liking.

> Regarding the missing user-space features, I have decided to go with the
> following schedule, more or less in that precise order:
> * GPS
> * Full audio (including headset detection and routing)
> * Wi-Fi (ready on the Goldelico version)
> * Bluetooth (including audio)
> * Sensors
> * Modem (don't forget bluetooth routing)
> * Camera
> A few other details are also left:
> * SELinux
> * Power profile

I'm mostly working on sensors right now. So should easily be able to
import each others changes, once ready. :)

> On the kernel side, there is a lot to do as well:
> * ADB crash, rndis not working

Having a new look at the android-3.10 kernel might help. At the time
when I imported ADB that kernel tree was still marked experimental, so
things might have changed.

> * Headset detection the android way
> * RTC clock wakeup (alarms)

This one might be hard, see: http://lwn.net/Articles/482345/

> * investigate why it takes so long to have an image on screen after
> resume
> * Try to keep the same data on the framebuffer, as set by the bootloader
> (like other Android devices do), so avoid the flashes
> * don't fully suspend if wakelocks are held

Hmm this sort of works, e.g. if you do:
  echo test > /sys/power/wake_lock

The system (CPU) will stay on, but the display will turn off if you
click the PWR button.
If you enter:
  echo test > /sys/power/wake_unlock

The system will suspend normally again. Also apps like OSMand keep the
display+CPU on. We have to check why some apps are not able to grab
wakelocks. Maybe they expect a different name of the "wake_lock" node,
or the permissions are not sufficient?

> This last point is very important! Currently, it will suspend fully
> every time "mem" is written to the sysfs node, but it should not. For
> instance, when playing music, the app holds a wakelock which should
> prevent the device from suspending fully (the music should keep
> playing). Non-critical devices should "earlysuspend" (screen, sensors,
> gps, camera, etc). This works very well on Android devices and still
> saves a lot of power. It is not mainline-complaint though, but we still
> need it.

See above: Our kernel implements the Mainline-Linux way of wake_locks,
which we should try to somehow map to the Android userspace.

> Still regarding the kernel, I tried to move the current draw limit from
> 100mA to 250mA in the code and that makes USB storage sticks work with
> OTG. Since that's a pretty nice feature to have and given that
> apparently, it works properly and doesn't make the line collapse,
> perhaps we should consider it. Most of these devices seem to report
> 200mA max consumption.

That's nice! But I can't find this commit anywhere, could you please
point me to it, so I can import it into the Goldelico 3.12-replicant4

> Well, I think that's about all I had to say, sorry for the long and
> boring email. I hope that'll draw some discussion.
> I don't think I'll release built images yet. I'm late on updating the
> Replicant wiki, though cloning the standard 4.2 tree will include gta04
> support. The build target is set to userdebug, but I've only really
> tried it in eng. In the end, released images should be userdebug and
> shouldn't be signed with the test keys. The build target is "bacon", to
> produce the replicant-4.2-gta04.zip install zip. The installation script
> is still replicant_gta04_install.sh, with updated usage.

Thanks for your efforts!


More information about the Gta04-owner mailing list