[Gta04-owner] Upstream Replicant 4.2 support for GTA04

[Dr. H. Nikolaus Schaller]

Am 28.02.2014 um 13:16 schrieb Lukas Maerdian:

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

Yes, this should never be done by any distribution - except the one
for flashing a new boot system.

For details how it should work in the future (device tree based kernels),
please see:

http://download.goldelico.com/gta04/files/Device_Tree_Migration.pdf

This document also discusses partitioning and model specific user-space
configs.

> 
>> 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.
> 
> 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
> some stuff.
> 
> The work we have done is all public here:
> GTA04 device overlay:
> http://git.goldelico.com/?p=gta04-replicant-device.git;a=shortlog;h=refs/heads/replicant-4.2
> GTA04 kernel overlay:
> http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/3.12-replicant4
> 
> 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!
> 
> Regards,
>  Lukas
> 
> _______________________________________________
> Gta04-owner mailing list
> Gta04-owner at goldelico.com
> http://lists.goldelico.com/mailman/listinfo/gta04-owner