[Gta04-owner] Upstream Replicant 4.2 support for GTA04
contact at paulk.fr
Fri Feb 28 20:28:02 CET 2014
> > 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.
> > 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?
> > 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 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.
> > 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.
> > 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.
> Can recovery be simplified if we don't have separate partitions and no
Honestly, I see this as a dirty workaround. 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. I think we cannot assume that the user has a friendly
boot.scr installed. On top of that, our kernel image is not named
uImage, but boot.img 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). None of that is part of the current
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.
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
> > 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.
Paul Kocialkowski, Replicant developer
Replicant is a fully free Android distribution
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: This is a digitally signed message part
More information about the Gta04-owner