[Gta04-owner] Upstream Replicant 4.2 support for GTA04

Dr. H. Nikolaus Schaller hns at goldelico.com
Fri Feb 28 21:29:59 CET 2014

Hi Paul,

Am 28.02.2014 um 20:28 schrieb Paul Kocialkowski:

>>> However, I encountered some issues related to the kernel:
>>> * OTG seems to work fine but refuses to configure USB flash drivers
>>> since they apparently ask too much current: this doesn't look like
>>> normal behavior.
>> Well, the official limit of the OTG port is 100mA. In practice it may be
>> 200 mA.
> Oh ok, I'm a bit surprised to hear that. Usually, on other Android
> devices, providing enough power for a USB storage stick is not a problem
> (I tried on OMAP4 for sure), but I reckon it might be a normal
> limitation. I guess I'll try to push the limit a bit and see how far it
> can go without collapsing.
>> No new /sys node. Because we never get that upstream. The 
>> /proc/device-tree/model is the canonical way to do it in the future.
> Understood.
>>> Then, the modules should access that information and behave
>>> accordingly.
>> Yes, it should be /proc/cmdline or /proc/device-tree/model
> How would cmdline come into play here? Does the bootloader detect the
> variant and set something?

Yes. The boot knows on which hardware is running and sets either a mux=
or device-tree= variable that can (also) be seen through /proc/cmdline

Please see for details:


>>> For accessing the information, modules could either read the sysfs node
>>> directly or communicate by a gta04-specific daemon (gta04d or goldelicod
>>> perhaps) that reads the string and returns it to the module upon request
>>> through a unix socket.
>> Much too complex. Please don't introduce new daemons someone has to
>> maintain...
> I don't see the difference in terms of maintenance. Both would do the
> same thing, in different languages. We could also have a library that
> modules can use to detect the variant with a single function call. I see
> no point in implementing the same detection algorithm several times (in
> each module). Having a library or a daemon avoids code duplication and
> actually makes it easier to maintain the code, since all the
> gta04-variant-specific actions would be held there.

Well, IMHO there are not more than 3 or 4 areas that are device specific.
And they are *configuration* at boot time. Nothing running during daily
operation. So having a daemon or a C program appears to be overkill
for some simple tasks of checking a file for the device version and doing
some copy/move commands.

And one part for the letux3704 is running a special backlight daemon.
This is much easier to implement in a shell script by "command&" than
forking and exec in some C code.

So there is nothing dynamic that needs to run after booting. I.e. no daemon

Regarding a library, it would just wrap a fopen/fgets/fclose/strcmp.

>>> The advantage of having a gta04-specific daemon (called at early-init)
>>> is that it also makes it possible to perform all the variant-specific
>>> actions:
>>> * load the correct battery driver
>>> * swap the correct initlogo.rle/bootanimation.zip for each resolution
>>> These actions could also be done by a single script (the way it's
>>> currently done on the goldelico tree), hence without the possibility of
>>> having a socket. However, I would prefer having a daemon cleanly written
>>> in C code.
>> What is bad with a script? It is simple and easily maintainable. And executed
>> only once. So IMHO no need to use C and a complier to achieve what we
>> can do directly.
> I don't see why this brings any further difficulty. Having proper
> programs instead of scripts looks much cleaner to me.

Depends on what you want to achieve. A script is easier to configure
and higher level of abstraction. So you need less code to achieve the
same result. Compiled code is of course faster - but not significantly for
the device config task.

>>> On the single partition approach: I understand this is how you like to
>>> do things on regular GNU/Linux systems, but this is Android. It is
>>> mandatory to have separate partitions for /system, /data, /cache and
>>> having an initramfs.
>>> Android is built around with that assumption and
>>> not following this scheme will draw incompatibilities. For instance,
>>> features such as encrypting the data partition will be unavailable as
>>> well as wiping the data partition will be unavailable.
>> Is there a document describing that in more detail? I have only found tools
>> that manage partitions - but if we haven't we don't need the tools.
> I didn't find any mention of the partitioning scheme in the Android
> Compatibility Definition Document. However, I have never seen any
> Android device not following this scheme and from experience, I can tell
> that the system assumes that particular scheme. Not following it will
> result in the impossibility of using e.g. encryption or factory reset.
>>> I also worked on bringing recovery support (which is something everyone
>>> who installed a community Android version on an Android phone knows
>>> about). It's basically a single binary, packed into an initramfs that
>>> will perform actions such as installing a system zip, wiping /data
>>> (factory reset), making a backup of the system, restoring the backup,
>>> etc. Again, that won't work if we don't have separate partition
>>> for /system, /data and /cache.
>> Why does this need separate partitions? Isn't it sufficient that these directories
>> exist and point to something reasonable? Is it required that they appear in
>> the mount table or do all tools just access them through their file name?
> The recovery binary expects to have /system, /data and /cache as
> separate partitions as well. It will *format* the partitions from their
> mount points when asked to wipe data.

Ah, ok. I understand.

But why doe we need to reformat the card at all? We can provide a GTA04
recovery mechanism that does not wipe it out.

rm -rf /data/* should be sufficient.

So we could patch the recovery tool.

>> Can recovery be simplified if we don't have separate partitions and no
>> initramfs?
> Honestly, I see this as a dirty workaround.

The question that comes to my mind is: workaround for what?

> I'm not going to implement
> that on upstream Replicant 4.2.
>>> On top of that, it doesn't seem outrageous to me to require the whole
>>> sdcard for installing Replicant. That's what it takes.
>> No - that is what we took a lot of work to get rid of having U-Boot on every
>> SD card. Booting is booting - for any system. Therefore Replicant should
>> not do its own story... Even if there is some reason behind.
> I don't see what's wrong with distributing u-boot and its script on
> every sdcard.

Since U-Boot is device specific, you simply can't take the SD card out
of a Letux 2804 and insert it into a Letux 3704. It will in best case use
the wrong U-Boot and in worst case overwrite the U-Boot in NAND
and leave the device bricked.

> I think we cannot assume that the user has a friendly
> boot.scr installed.

Yes, you can safely assume that. That is what I want to educate everybody...
And if not, it is the user's responsibility to fix things, not the one of a distribution.

He/she should restore the boot system by using a Production Image SD card.

> On top of that, our kernel image is not named
> uImage, but boot.img

This could be solved by a simple rename in the build script so that the
kernel is called uImage (what is the benefit of using a different name?).

> and recovery is called recovery.img. We also need a
> way to let the bootloader know which one to boot (this is done
> via /cache/.startrecovery).

Ah, ok. You have essentially two images on one SD card.

> None of that is part of the current
> boot.scr.

Oops. IMHO, the kernel and rootfs should adapt to the boot loader
and not vice versa following a clear layered structure.

Hm. I again start wondering what a recovery image and tool is really
good for? Why do we need it (and take care of it)?

If my GTA04 card is broken and I need to start over from scratch, I can simply
take out the SD, reflash it (or a new one) and I am done.

This is of course different for other Android devices where the memory
chip can't be removed.

But should we really make Replicant on GTA04 try to follow limitations
of other devices just because they are solving some problem we don't

> Hence, I'm thinking we'll need to have the user to update its boot.scr
> anyway if we want it to handle recovery boot too. Now why not avoid
> reflashing what he already has in NAND (so that it can boot what's
> installed on NAND when there is no sdcard) and distribute the
> Replicant-friendly boot.scr on sdcard so that it's only executed when
> Replicant is there?
> That seems to be the option that makes the more sense.

If it works exactly the same on Letux 2804/3704/7004 and allows to swap
SD cards (and data) between them.

> I understand you've been working hard on a unified boot system, though I
> don't see any reason why it would be a necessity. It clearly doesn't fit
> well here.
>>> I also prefer to go with my own minimalistic boot.scr that handles
>>> recovery booting and the Android kernel names (boot.img and
>>> recovery.img).
>>> That's all for now, feel free to share any remark/suggestion.
>> Well, I see that there are some fundamentally conflicting ideas how the
>> future should look like (single partition vs. multi-partition, initramfs, make
>> simple solutions vs. complex ones) which may make it difficult to merge
>> the efforts back into a single one.
>> But we have enough time to let things evolve. And you are free to
>> do it differently from us. If they are good (for our purposes) we will take
>> them of course.
> It might make sense to have a goldelico release of Replicant (you might
> even want to make it CyanogenMod and include the firmwares and SGX blobs
> by default) and a Replicant release, following different boot/partition
> schemes but having the same hardware features supported.

Yes, that is probably the best solution.


More information about the Gta04-owner mailing list