[Gta04-owner] Upstream Replicant 4.2 support for GTA04

Dr. H. Nikolaus Schaller hns at goldelico.com
Fri Feb 28 11:44:49 CET 2014


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.

> * 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.
> 
> 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
> trees:
> * 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

> * 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.

> 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
> variant.

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

> 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...

> 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.

> 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
initramfs?

> 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
> 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.

> 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.

Great.

BR and many thanks for sharing your ideas,

Nikolaus



More information about the Gta04-owner mailing list