[Gta04-owner] Upstream Replicant 4.2 support for GTA04
luk at slyon.de
Fri Feb 28 13:16:30 CET 2014
On 28.02.2014 11:44 UTC+0100, Dr. H. Nikolaus Schaller wrote:
> Am 28.02.2014 um 10:58 schrieb Paul Kocialkowski:
>> As I wrote in my previous message, I'm giving the GTA04 a new try at
>> Replicant 4.2. I see that you have been busy during the time I retired
>> and I'm glad some progress was made, especially on the kernel.
>> I just tried Alexandre's Replicant 4.2 images and the suspend/resume
>> issues seem to have vanished.
>> 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.
>> * The battery driver seems not to work (the sysfs nodes all return
>> errors). I suspect this is because of the 1-wire interface.
> Yes, there is some known bug. Lukas is already looking for it.
I'm usually working and testing on the Goldelico Letux-3704 and not on
the GTA04/Letux-2804. That devices uses the twl4020-madc battery driver
instead of the bq27000. I'll have to check what's wrong with bq27000.
AFAIR it was working on our Replicant-4.0 where the device was detected
by a shell script and the corresponding battery driver was loaded.
My assumption is, that this script is not working in Replicant-4.2 and
the twl4030-madc driver is loaded by default.
>> * ADB driver seems to crash at poweroff
>> * Plugging the USB cable before the device is booted made my host
>> computer crash several times, with kernel panic
>> * I'm not sure audio worked all the time after suspend/resume
>> These are just quick notes, we should look deeper in details for all
>> these points.
Yes, I didn't look into these details either, as it was working well
enough for my development purposes when plugging the USB connector after
the device was booted. I don't have speakers/mic on the Letux 3704, so I
didn't look into sound handling at all.
>> I am going to start over the Replicant 4.2 bringup on my own since I
>> dislike some of the changes that were made on the goldelico replicant
>> * The Replicant logo in the bootanimation is too small, it should have
>> 420px height.
>> * GTA04 model detection is unacceptable. The kernel should provide a
>> sysfs node with that info or something like that, but in no case should
>> the userspace have to parse dmesg.
> I agree that it never should parse dmesg. (I am not aware that it is really
> the case) If we do it, it is clearly a mistake.
> The official GTA04 device detection should go through /proc/cmdline -
> or even better (future) through /proc/device-tree/model
AFAIK we're not parsing dmesg anywhere, but check /proc/cmdline for the
model value provided by U-Boot.
I did this in a script, as it was the fastest and easiest way to do.
>> * I don't want the single partition approach in Replicant.
> Why not?
>> * The Wi-Fi firmwares should not be in the source code
> Ok. I agree. We keep it there for convenience at least during development.
Yep. The best way would be to provide an APK which contains the
Wifi-firmware, I guess. I didn't put effort into this direction, yet,
due to the early state of development.
>> I see two ways of correctly performing GTA04 version detection by
>> userspace. On the kernel side, they involve having a sysfs node that
>> will provide either a number or a string that matches a particular gta04
> 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.
>> Then, the modules should access that information and behave
> Yes, it should be /proc/cmdline or /proc/device-tree/model
Paul, would it be OK to have the model name provided by /proc/cmdline
and/or /proc/device-tree/model? /sys or /proc doesn't make a big
>> 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
I do not yet see the big advantage of having a C daemon instead of a
shell script handle the model differences. Right now this is just
loading the correct battery module...
But if the daemon is the way to go, I'd be OK with it, as it doesn't
need to be maintained a lot, once written, and could live in the
GTA04-device overlay in the replicant tree, similar to liblights.
>> 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
>> * 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.
Hmm, what is the big advantage of having a socket?
>> 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 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?
> Can recovery be simplified if we don't have separate partitions and no
>> 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 also prefer to go with my own minimalistic boot.scr that handles
>> recovery booting and the Android kernel names (boot.img and
>> That's all for now, feel free to share any remark/suggestion.
IMHO most of your changes are acceptable, at least for the official
Replicant version. It should then be easily possible to have go
Goldelico-Variant, which provides a single partition rootfs without an
But PLEASE, don't mess with the boot.scr, which is located in the users
NAND flash. This will break the users boot environment, if they want to
switch between Android/Replicant and GNU/Linux systems. We had a lot of
those problems with Replicant-2.3.
You can still tweak the boot process to your needs, e.g. through
bootargs.scr, which will be executed by the default uboot+boot.scr from
the NAND, see: http://projects.goldelico.com/p/gta04-uboot/page/Usage/
Just please don't flash/override the users uboot+bootenv in NAND.
> 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.
>> My next steps are building a full system with my code, then publishing
>> all the source once the state is as good as 4.0 and then I'll work on
>> particular hardware features.
I think the biggest difference is the single partition rootfs. Maybe we
should go into two directions with this for now and cooperate with all
the other work.
Please send a short heads up mail to this list, once you are happy with
what you have prepared for the GTA04, so I can check and reintegrate
The work we have done is all public here:
GTA04 device overlay:
GTA04 kernel overlay:
I'm happy you're interested in the GTA04 again and hope we can soon
provide users with your free version of Android on our open hardware!
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 490 bytes
Desc: OpenPGP digital signature
More information about the Gta04-owner